Ya hablamos anteriormente sobre las diferencias en arquitectura entre Openbravo ERP y OpenERP. Hoy vamos a hablar de sus soluciones en cuanto al patrón MVC (Modelo, vista y controlador).
El MVC de Openbravo podría resumirse en el siguiente esquema.
En el modelo tenemos por un lado la base de datos a la que podremos acceder por sqlc. Sqlc es una herramienta que nos genera clases java en base a una definición en xml de sentencias sql, de este modo podemos tener una clase en la que cada método nos permitirá ejecutar una sentencia sql diferente. Esta es la herramienta de acceso a datos y persistencia utilizada historicamente en Openbravo. A partir de la versión 2.50 se añadió una capa DAL (Data Access Layer) implementada con Hibernate.
Respecto al controlador, esta es quizá la parte más oscura de Openbravo ya que la lógica de negocio se reparte entre código Java y código Pl/sql en base de datos lo que complica bastante tanto el desarrollo como la independencia del SGBD (Sistema de gestión de bases de datos), esto también provoca que la base de datos se vuelva muy lenta.
En cuanto a código Java existe principalmente una clase de la que herada cualquier otro servlet, luego tendremos nuestras propias clases y métodos en java y por último, y ya hablando de código en base de datos, tendremos una serie de triggers, funciones y restricciones.
La vista está compusta por código estático en html, css y javascript. Además dipsonemos de una herramienta llamada xmlengine que viene a ser un rellenador de plantillas. Por ejemplo, si tenemos un html con una tabla y queremos rellenar esa tabla con datos xmlengine nos puede ser útil.
Si estamos desarrollando una ventana mediante el modelo MDD prácticamente no nos enteraremos de que tecnologías se están utilizando por debajo. En realidad lo que se hace es leer el diccionario y generar código mediante la herramienta WAD, esta internamente genera código para sqlc, DAL, los html, css, javascript, los servlet java, xmlengine, etc. El problema es que hay muchas cosas que no se pueden desarrollar mediante MDD, en esos casos tendremos que picar a mano nosotros todo este código.
El MVC de OpenERP es mucho más sencillo.
Unas de las principales diferencias entre OpenERP y Openbravo ERP es que en OpenERP no hay código en base de datos, la base de datos está completamente limpia y eso tiene muchas ventajas. El modelo está compuesto por una base de datos pero lo que nosotros veremos a nivel de desarrollo será únicamente el ORM, de hecho hasta la fecha no he necesita tocar nada de la base de datos, ni siquiera añadir una columna o una restricción. ¿Y como es posible esto?, pues porque cualquier clase en OpenERP deriva de la clase osv.osv y está implementa el ORM. A este puedes indicarle los atributos que necesitas, de que tipo son y él se encargará del mapeo haciendo totalmente transparente el acceso a datos.
La parte del controlador es completamente código python. Por un lado tendremos las clases que dan sustento a nuestras ventanas y si queremos extenderlas por ejemplo añadiendo o sobreescribiendo métodos es muy sencillo, simplemente hay que utilizar herencia. Además nadie nos impide crearnos nuestras propias clases para hacer lo que se nos ocurra.
En cuanto a la vista esta se define en xml. Hay que recordar que en la arquitectura de OpenERP teníamos un servidor al que nos conectábamos por xml-rcp/net-rpc, esto quiere decir que el servidor le envía los datos al cliente en xml y este será el encargado de construir la interfaz en base a esos datos. Por tanto lo único que tenemos que hacer es definir esos xml que representan a la interfaz, muy sencillo todo.
Como cualquier aplicación software tanto Openbravo ERP como OpenERP tienen sus ventajas e inconvenientes, las dos plataformas de desarrollo son muy potentes pero desde mi punto de vista OpenERP tiene una arquitectura mucho mejor definida.
Nota:
Estoy ofreciendo unos mini cursos de desarrollo en OpenERP por 200€.
Cheli
Hola Cheli,
la arquitectura de Openbravo que describes podría estar cerca de la realidad en las primeras MP de Openbravo 2.50, pero sin embargo en 3.0 es completamente distinto.
Sqlc ya no existe y está totalmente sustituido por el acceso a BBDD mediante los objetos de negocio generados por el DAL (basado en Hibernate).
Y las ventanas no son generadas en código estático html, ni se usa el xmlengine. Toda esta parte se migró a Smartclient, y para el acceso a los datos hace uso de un webservice basado en JSON, no xml.
De todas formas, como dices, el controlador sigue estando dividido en varias capas (javascript, java, procedures pl/sql, y por último, triggers y otros elementos puros de la estructura en BBDD), lo cual no es del todo cómodo en ocasiones.
Hola Gripepe, nosotros desechamos Openbravo ERP 3 porque en su versión comunidad no tienes ni MRP, ni módulo de producción pero principalmente porque no tienes módulo de gestión de proyectos. Además la localización española está muy limitada ya que muchos módulos han pasado a ser privativos y por tanto es imposible tanto migrar los sistemas que tenemos actualmente en producción en 2.50 como realizar implantaciones nuevas. Por eso no hablo de la versión 3, porque no la conozco.
Sabía que sqlc y xmlengine desaparecían, la capa DAL se introdujo en la versión 2.50 como comenté y no tenía sentido mantener una tecnología obsoleta como sqlc. Al cambiar también la tecnología para construir la interfaz de usuario xmlengine ya no era necesario, al margen de ser una tecnología vieja y limitada. En cuanto a xml y webservice, yo no he hablado en este apunte de este tema ni en versión 2.50 ni en 3.0, pero es bueno saber almenos como se ha implementado esta parte.
No se porque dices que lo que he dicho podría ser verdad en las primeras MP de la versión 2.50, yo tengo todos mis sistemas de producción en MP41 que es la última en 2.50 y esto que digo sigue siendo así. Ya comenté que DAL se introdujo en 2.50 pero también es verdad que sqlc se mantiene para muchas partes y se sigue pudiendo utilizar en tus propios desarrollos. Las tecnologías utilizadas para construir la vista en la versión 3 las desconozco.
Interesante análisis. Es cierto que Openbravo ha limitado mucho la edición comunidad en la versión 3.0
Estimado Cheli.
Veo que sabes mucho de la versión 2.50 de Openbravo, quisisera saber si has realizado localizaciones para paises latinoamericanos, sobre la versión libre de Openbravo porque aunque entiendo que existen excelentes alternativas Open Source de ERP (Open ERP, Adempiere) sin localizaciones es un poco complicado y limitante su uso, te agradezco de antemano tu respuesta.
Cheli,
Si pensara que este es un blog objetivo, te pediría que en la entrada especifiques que te refieres a Openbravo 2.50, cuyas primeras versiones son de hace 4 años practicamente.
Openbravo 3, que tiene más de un año ya, tiene una tecnología totalmente diferente (aunque conserva parte de la que comentas) que quizá te vendría bien conocer.
La entrada tendría mucho más interés si compararas Openbravo 2.50 con una versión de OpenERP de hace 4 años. Pero entonces las conclusiones quizá no fueran las que tu quieres que sean y no te quedaría tan bien la entrada.
Saludos y perdona mi realismo.
Antonio, no ha sido nada intencionado, he comparado la arquitectura de Openbravo comentando como ha ido evolucionando hasta donde yo la conozco, si no comento la versión 3 de Openbravo es porque yo sólo implanto soluciones con licencias libres y como eso no es posible con la versión 3 no me he preocupado en conocerla. De todas formas el cambio principal en Openbravo 3 es la parte de la vista, en el resto las tecnologías que están utilizando ya existían en 2.50 y yo las comento en este apunte (DAL, todo el código en base de datos, MDD), estas tecnologías son el corazón del API de Openbravo así que no se donde está el sesgo. El patrón MVC sigue siendo muy parecido en la versión 3 respecto a la versión 2.5, cambia sqlc + DAL por únicamente DAL y cambia las librerías utizadas en la vista, pero como sigue utilizando MDD significa que hay un generador de código (WAD o su homólogo actual) que genera el código, incluida la vista, en base al diccionario. No voy a invertir tiempo en conocer algo que no voy a utilizar, no tengo tanto tiempo libre y el que tengo no lo voy a emplear en esto, así que si el debate entra en que si la vista ahora es así o asá entonces lamentándolo mucho no podré participar.
En cuanto a lo de comparar el Openbravo de hace 4 años con el OpenERP de entonces creo que OpenERP ganaría por más diferencia. Que yo sepa el MVC que he expuesto aquí ya existía en TinyERP con su ORM, sus objetos openobject y sus vistas entregadas por xml-rpc. Por contra Openbravo aún no utilizaba DAL, sólo sqlc, DAL apareció en el 2009 con la versión 2.50, también hacía muy poco tiempo que se utilizaba dbsourcemanager con lo fundamental que es para poder gestionar el código de diccionario, la primera vez que lo vi fué a finales del 2007 en la 2.35 y en esta aún no era muy robusto, un año después salío la 2.40 donde ya si que se utiliza con bastante fiabilidad. Tampoco existía la modularidad en el 2008, tenías que gestionar tus desarrollos a base de diffs de código y eso era una locura a la hora de aplicar una actualización del core, sinó que se lo pregunten a los que tuvieron que desarrollar y gestionar las subscripciones profesionales de la época de 2.35 y 2.40, yo las tuve que padecer como implantador.
Así que como puedes ver mi intención no era dejar mal a Openbravo, sólo intentaba comparar los patrones MVC de estos dos ERPs de la manera más objetiva posible según los conocimientos que tengo de cada uno de ellos.
Hola Francisco, pues precisamente he desarrollado para una consultora de Ecuador gran parte de la localización que ellos ofrecen a sus clientes. Principalmente los módulos de gestión de nóminas y de impuestos donde se gesionan las retenciones en la fuente, comprobante de retención, etc. Actualmente ellos están realizando implantaciones localizadas para sus clientes de Ecuador.
Estimado Cheli, estoy muy interesado en el ultimo parrafo expresado en cuanto a que has desarrollado localizacion para Ecuador en el tema de retencion a la fuente, comprobante de retencion y expreso si esta solucion desarrollada puede interactuar con la version de openbravo 3.0
Saludos.
Hola iecosa. Posiblemente funcione con Openbravo 3, no está testeada porque nosotros consideramos que no es posible hacer una implantación libre de Openbravo en su versión 3. La versión en la que se desarrolló fué la versión 2.50.
Hola Cheli, yo estoy muy interezado en las localizaciones para Ecuador de Openbravo si me pudieras ayudar con mas detalle estaria muy agradecido, de antemano gracias y buen dia.
Hola Stalin, te he enviado un correo-e con la información de la localización para Ecuador, revísalo y me cuentas.
Un saludo.
Excelente articulo, igual ha sido para mi la evaluacion de los dos. Todo tiene sus pros y contras, conocer ambos es lo mejor que se puede hacer para brindar el servicio que el cliente necesita, no el que mas me guste.
Saludos