Para poder entender que ha cambiado o mejor dicho, que no ha cambiado al desarrollar sobre Openbravo ERP después de la introducción del sistema de módulos y plantillas en la versión 2.50 tendremos que hacer un poco de historia de lo que teníamos antes.
En versiones anteriores a la 2.50 la recomendación de openbravo a la hora de introducir un desarrollo propio era meterlo en un directorio que existía por defecto en el árbol de código llamado srcClient. ¿En qué consistía esta metodología? es muy fácil de explicar, si querías introducir un nuevo archivo de código lo que debías de hacer era replicar el árbol de directorios donde se iba a ubicar dicho archivo en src/ pero sobre srcClient, pongamos un ejemplo.
Si yo necesitaba como desarrollador añadir un nuevo informe (un archivo jrxml de jasper) que iba a estar ubicado en src/org/openbravo/erpReports lo que tenía que hacer es lo siguiente:
- Replicar el árbol de directorios donde va a quedar ubicado el archivo pero en srcClient.
mkdir srcClient/org
mkdir srcClient/org/openbravo
mkdir srcClient/org/openbravo/erpReports - Copiar el archivo a esa ubicación
mv archivo.jrxml srcClient/org/openbravo/erpReports
Ahora al compilar el codigo lo que hacía la tarea ant correspondiente era copiar todo lo que encontraba en srcClient y lo volcaba en src sobreescribiendo los archivos originales si se diera el caso para posteriormente empezar la compilación. Con esto lo que conseguíamos es tener nuestros desarrollos separados del resto de código, única y exclusivamente, pero no nos servía para nada más. Yo como siempre utilizo un sistema de control de versiones no le veía ninguna ventaja a este método ya que en el histórico de mi scv tenía qué archivos había tocado y qué había hecho con ellos por lo que los cambios siempre se hacen directamente en la rama src. Mi opinión es que si utilizas un scv el método de srcClient es completamente inútil.
A este método hay que sumarle una serie de inconvenientes adicionales. Por ejemplo, si queríamos modificar un archivo ya existente en openbravo (core) tenías que hacer una copia sobre srcClient y modificarlo ahí. Si ahora en algún momento se aplicaba un cambio al core que involucrara a ese archivo el primer problema es que el archivo que encontraba el actualizador era una copia del tuyo (srcClient) pero en src (recordemos que al compilar se machaca la versión src con la de srcClient) con lo que ya teníamos los primeros problemas de conflicto de código. Lo que te tocababa hacer si utilizabas srcClient es:
- recuperar la version original del archivo sin tus cambios y colocarla en su lugar en src.
- Aplicar la actualización de openbravo para ese archivo con lo que no se produciría ningún conflicto.
- Y por último integrar (hacer merge) de los cambios de ese archivo en tu versión en srcClient para que funcionara.
La otra opción sería la misma que si no utilizaras srcClient, o lo que es lo mismo la que he estado utilizando yo que consiste en:
- Aplicar la actualización de openbravo para ese archivo con lo que si ese archivo es consecuencia de un archivo en srcClient (insito en que machaca sobre src) o de una modificación directa en src, cabe la posibilidad de que exista un conflicto.
- Resolver el conflicto.
- En caso de que ese archivo fuera consecuencia de uno en srcClient tendríamos que actualizarlo en este árbol (srcClient).
¿Cómo funciona el sistema de módulos?, en esencia es muy parecido a srcClient. Cuando vas a crear un módulo debes crear un directorio al estilo srcClient para recrear los archivos, sean del core o no, y su posición en el árbol de código en el directorio de soporte para el módulo (llamémoslo moduleClient, esto es una convención que me acabo de inventar por si alguien no se había dado cuenta). Lo que sucede ahora es que cuando se actualiza el core lo que hace openbravo es desacoplar todos los módulos (limpiar todo el código moduleClient de todos los módulos), dejándo el código original de la versión de core instalada y sobre esa aplicar la actualización al siguiente (hacen merge) así se aseguran que el actualizador de OB ahora ya no va a tener virtualmente coflicto alguno. Pero el problema lo volvemos a tener en el momento de volver a acoplar los módulos (volver a meter el código moduleClient) igual que lo teníamos con srcClient de ahí que diga que virtualmente no hay conflictos ya que realmente hay exactamente los mismos conflictos que en cualquier otra versión anterior.
Como dije en un comentario a Pepe, ahora OB puede afirmar con rigor frases propagandísticas del tipo «Hemos solventado los problemas de actualizaciones, ahora ya no vamos a tener ningún conflicto y actualizar el core es tan sencillo como dar un click». Pero si uno tiene dos dedos de frente y sabe como funciona openbravo sabría que la magia no existe y pensaría lo que suelo pensar yo en estos casos ¡estos se piensan que soy imbécil!.
Aquí no se queda la historia, ni siquiera los que toman las decisiones de diseño en OB saben como van a mantener la compatibilidad de módulos en versiones posteriores. Cuando le vieron las orejas al lobo pensaron, bueno vamos a intentar mantener lo más estable posible las partes del core que son subsceptibles de desarrollo por parte de terceros y a esto lo vamos a llamar API, que en cierta manera lo es, pero hacer eso como toda compatibilidad hacia atrás y sobretodo con un desarrollo tan poco estable como el que lleva OB es imposible.
Al final pasan cosas como por ejemplo si mi código moduleClient contiene una modificación en el core y por alguna razón como puede ser corregir un bug en el core OB necesita cambiar algo de esa supuesta API (crear o eliminar campos, modificar la interfaz de un método de una clase, etc) que pueda afectar a los desarrollos de terceros lo que hacen es publicarlo en una página de wiki para que lo tengas en cuenta. En menos de dos meses ya llevan 19 cambios en esa API.
Hablando incluso con algunos desarrolladores proponen alguna solución de compromiso pero que no dejan de ser chapucillas poco elegantes, a mi a veces me ha tocado hacer alguna de estas. Sigamos con los ejemplos, imaginemos que en mi código moduleClient tengo un archivo del core y en la siguiente versión del core se modifica, pues una de las propuestas es que dejes tu antiguo archivo del core que tienes en tu moduleClient sin las nuevas modificaciones. Esto tiene un peligro que es que si el desarrollo que provocó el cambio en ese archivo también afecta a otros archivos y tu mantienes la versión anterior puede que no compile o que funcionalmente casque. No te queda más remedio que o bien integrar el cambio en tu archivo del core que tienes en tu moduleClient o revisar si realmente se va a romper la aplicación.
Otro ejemplo que me llegó hace poco en una propuesta de un desarrollador de OB era, -bueno cuando tengas que hacer una modificación en una ventana del core duplícala de forma que las mejoras que se apliquen a esa ventana se harán sin conflictos en la ventana origina que dejarás oculta y tu seguirás con tu versión de ventana sin aplicar ningún cambio ni mejora-. Esta en cierta manera me alarmó ya que si se pretende vender el soporte de actualizaciones automáticas y de forma transparente en network pero para evitar problemas lo que haces es rodear el sistema para que no se apliquen en la versión del cliente pues no sirve de nada.
Por último comentar que respecto a una consideración que me hacía Pepe en la que indicaba que el sistema de módulos permite organizar mejor los desarrollos vuelvo a no coincidir. Los desarrolladores para este fin lo que hacen es utilizar un sistema de control de versiones que aporta muchísimas más ventajas en organización y reutilización de código que el hecho de poder paquetizarlo.
Un ejemplo sería que podemos ir al detalle que queramos en las modificaciones. Si queremos aplicar una modificación que hemos desarrollado para un cliente pero para ello hay que aplicar un módulo entero a lo mejor puede implicar que al margen de esa modificación se vayan a aplicar otras que no deseamos, o alrevés, requerir de varios módulos para una única modificación. Para esto tenemos el sistema de control de versiones, sus ramas, etiquetas y demás mecanismos.
El hecho de generar un diff y aplicar con patch es inmediato en el momento que has superado la curva de aprendizaje de este tipo de herramientas. Y ahora con los sistemas descentralizados tienes aún más ventajas como poder hacer push contra la rama local de los desarrolladores que te interesen, etc etc.
Espero haber sido claro y haber podido explicar porque considero que los módulos y plantillas no aportan nada o muy poco al desarrollo en Openbravo ERP pero por otra parte si aportan mucho a la hora de generar entregables.
Un saludo.
Hi Cheli,
my name is Raphael Valyi, I had the opportunity to study Openbravo a bit along with other open source ERP’s. I should say I quickly understood the architectural flaws (inefficient modules in a procedural programming paradigm, non competitive «appliance» offer…) of Openbravo you mention and for that reason decided I’ll never even try to integrate it (chances are you can survive an ERP failure only once) before an other say 2 years if Openbravo finally comes up with something strong (considering their venture capital, they could eventually survive, others did much better with way less, so let’s give them a chance, but let’s not be their collateral victims for now).
Finally, I advise you to have a look at OpenERP instead. Not perfect either, but way better and already competitive for some situations (which already represents a Huge market. More promising also. I’m in touch with Spanish integrators and they are getting better and better instead. In France there are no known Openbravo deployement, while OpenERP deployments are popping all over the place, with a few professionnal integrators too.
I came from the Java camp too but learnt Python for OpenERP. Python itself is only 1 or 2 weeks of learning for an experienced OOP programmer, meaning it’s peanut in the whole ERP learning curve (and will only making you win time instead of fighting against the tons of Openbravo legacy pl/SQL). And if you does it for OpenERP, I believe you will be rewarded much more.
I could highlight a few decisive advantages of OpenERP:
– OpenERP is object oriented all the way. It’s like if the DAL system of Openbravo were already running and really used by the code since 3 years and even better than that (view inheritance, better migration system, BPM engine, interface is component oriented…). Overall I would tell that it’s a solid 3 times quicker to developp a custom feature X in OpenERP than in Compiere clones. Given that all those ERP’s have missing feature, this is something decisive how quick you add those.
– OpenERP has a much wider feature scope than Openbravo, I would say something like 3 times wider. See CRM or projects for instance. But only MRP or chained pickings are more powerful I think.
– OpenERP is more integrated, this is probably due to its OOP structure.
– OpenERP is already modular and modularity in OpenERP is not a myth, it already works for real, overall the maintenance headache you speak about doesn’t exist in OpenERP and module are reused for real.
– OpenERP has no Venture Capital. When I see how wrong gone Compiere and Openbravo and a few other Venture OSS projects of that kind, I think that’s definitely an advantage not owing a big money to rich morons.
– OpenERP is lead by the initial tech guy, not like Openbravo which has been designed by the Compiere guy and then abandoned to non exceptional architects.
– A few months back I annotated the Openbravo 2.50 roadmap to highlight what was already working in OpenERP:
http://docs.google.com/View?docID=ajb639cjf9fb_132ct6kdxgx&revision=_latest
Now yes OpenERP does have a few pitfalls too, let’s list some:
– they are hardly professionnal enough, but they are getting better and really the product is more important, isn’t it? And given that they have no Venture, the main guys tend to overwork quite a bit, for that they should be forgiven, open source is not easy every day.
– they just started over-marketing too, but really far from the Openbravo mystification though. Getting in touch with the real community behind it will tell you what works and what is not 100% OK yet. And you can expect things announced to work finally after some maturation.
– there are some regressions and lack of testing (while more than Openbravo I believe), again they are on the good track and it should be fixed over the year.
Ok, enough said. I’m glad to see someone who really know Openbravo giving detailed explanations about what doesn’t really work yet and where are the marketing mystifications.
If you try OpenERP, you might recycle a large part of what you learnt in something that work already instead, eventually coming back to Openbravo in a few years if it matures enough if you still love it.
Also OpenERP is going to just run over the Java stack too, by the end of the year, see my blog post if you are curious about this:
http://rvalyi.blogspot.com/2009/05/openerp-jython-unladen-swallow-where-do.html
IMHO, Openbravo has an acceptable technology considering the dinosaur ERP’s usually are. Openbravo might even be a bit better than those proprietary.
However, lot’s of those proprietary ERP’s gained a wide and mature feature scope that is still lacking in Openbravo, for lot’s of them it took them decades and hundreds of millions of euros (SAP invest $ 1.5 billions in R&D per year).
Now, when targeting SME’s and SMB’s just like Openbravo is doing, this is just not competitive (yet at least) to spend so much integrator engineering time in building in one shot the missing features, that’s why I didn’t even try it.
Ok, anyway, good luck to you, that’s just an advise in case you face some dead end with OB. I hope OB is going somewhere still because it would be nice to have several open source ERP actors in the future and because a few honest guys invested a lot in its fate too.
So far they seem to keep progressing, but as I said the road is still very long for them (considering their codebase and because they didn’t anything exceptional themselves yet aside from loud marketing).
My take is that they need some 2 years at this progression rate (when the code base will be rewritten in Java over the DAL + mature module system at the very least) to compete against the proprietary offer. But considering that I see no reason why OpenERP wouldn’t lead by a fair margin (they are developping faster), I have some concerns for such an expensive business model.
Keep posting nice blog posts and sharing real open source ERP experiences.
Raphael Valyi
(I’m working for an integrator like you, in France, but will be running on my own in Brasil in less than a month).
Nice comment. I ‘m very interested in OpenERP but I haven’t had enough time to take a look into this ERP. I hope to be able to investigate about OpenERP soon.
Hi Cheli,
May be one more thing about OpenERP: I think the quickest way to connect to the Spannish community is through this site:
http://www.openerpsite.com/
They did a meeting a few weeks ago:
http://www.openerpsite.com/conferencias-openerp/469.html
I just discovered that they also commented one of your post:
http://www.openerpsite.com/post-sobre-openbravo-su-vision-del-sw-libre-y-su-relacion-con-la-comunidad/503.html
And finally they are organizing a formation next week:
http://www.openerpsite.com/cursos-presenciales-openerp-a-nivel-usuario-en-catalunya-bilbao-y-madrid-juniojulio-2009/486.html
I think that you can transpose a good 80%% of your business knowledge to an other ERP like OpenERP. Now, that’s true, aside from Python which is arguably one of the simplest languages to grasp, learning the ERP framework and the implementation details of the main module take has a learning curve too, I understand it’s really hard to learn on spare time.
Ok, let us know whatever you do.
Raphael Valyi
Hola, no se si sea el medio mas adecuado, pero estoy buscando alguien que me pueda dar clases sobre el opnebravo, ya en la parate operativa del sistema como tal, he avanzado con alguna informacion que encontre el la web pero tengo dudas que no me dejan avanzar, mi correo es potesc@hotmail.com y estoy en barcelona.
Buah, de acuerdo en «casi» todo, pero sobre todo por cosas como:
Imagina que un cliente no quiere la mitad de los campos de la pestaña producto. Como la pestaña y la tabla son de core, lo suyo, parece, es realizar la modificación de que tal campo no se vea en la pestaña asociada a tu módulo, no? Es decir, que con tu módulo, el campo X de la tabla Y ya no se muestra –> adivina el mensaje de error… DBPrefix… es decir, que te tienes que crear la ventana entera para quitar un campo estándar de una pestaña?!?!
O editar core… con el lío de las actualizaciones que comentas… así, algo tan tonto como dejar de mostrar un campo en una pestaña, parece, se convierte en replica la ventana para poder hacerlo…
Salu2
Gorka,
I just want to emphasis the kind of customization you are speaking about (add or remove custom fields from standard views) is just very straightforward and very effective in the proven OpenERP module system on the contrary, see explanations here:
http://doc.openerp.com/developer/2_6_views_events/views/view_inheritence.html
Any view XML structure can indeed be extended at any point by a custom module, respecting dependency order and all…
Just the difference between a hyped immature system and a mature one…
Raphaël Valyi