IntroductionEvery business is different and every company adopts different business practices. As a consequence, every ERP implementation is different and being able to adapt the software to the customer's specificities is a key characteristic of a good ERP package.
In this area, open source has a clear advantage compared to proprietary solutions thanks not only to the access to source code but also to the free availability of knowledge about the inner logic of the product.
Openbravo ERP, in particular, has been designed and managed considering the need for adaptation as a key requirement:
- Its model driven architecture enables users to change standard functionality in a very easy manner.
- The free flow of information available on the project wiki and forums have empowered the community to make changes to even the innermost core part of the product.
This openness and flexibility provides great power to implementor and allows them to customize the product to meet practically any business requirement.
However, as
Ben Parker said, "with great power comes great responsibility" and in this case the great responsibility is to your own implementation as it is very easy to abuse this great customization power and change the product to the point where you can no longer afford to upgrade it nor benefit from the improvements made by the rest of the community.
If you are not very careful, it is very easy to find yourself in a position where you are either stuck on a product version that will eventually age and become obsolete or you have to bear the burden of maintaining and evolving the full solution instead of only your code. In both cases, you started with a packaged off the shelf application and you ended up with a bespoke piece of software.
It is important to notice that this danger exists both in open and closed source software. Countless literature has been published on the topic of customizations and upgrade nightmares and the prevailing wisdom is that, for mature ERP packages,
customizations should be avoided at all costs. Many experienced implementors also recommend that
a vanilla solution should be adopted for the first few months of production usage as many users discover that customizations initially thought essential are in fact not needed.
The problem of excessive customization, however, is much more pervasive in open source software because:
- Often the open source solutions are more recent and innovative than their proprietary counter parts but not as mature; therefore, the pressure to customize is stronger.
- Most importantly, the "hacking ethos" of the open source movement makes open source implementors culturally more disposed to implement invasive customizations.
Openbravo to the rescue!Openbravo ERP 2.50 introduces a set of very powerful adaptation techniques that will allow you to personalize the software to meet your unique needs without the need to customize it.
This approach guarantees that you will be able to apply patches and maintenance packs without impacting your adaptations and minimizes the cost of upgrading from one major version to the next.
The core principle of these techniques is summarized in the title of this blog: as you design your adaptations, you should think of them as extensions and not customizations.
Openbravo ERP 2.50, in fact, introduces support for
modularity, which allows you to define and package additional functionality and configurations as extension modules, independently from the core product.
One of the key features of modularity is that your configurations are also defined as extension modules. Because of that, they are kept separate from core and you can safely update the latter without touching you configuration.
Let's see how it works. To start your adaptation process you need to set the system in Configuration mode. You can do that by navigating, in System Administrator role, to General Setup / System Info and checking the box Customization Allowed (see picture below).
This will automatically create a
template called "System Customization" and any configuration change or addition that you make will be added to this template.
In this template, you can safely modify the Openbravo core model (the meta-data that describes Openbravo ERP out of the box) and you can add your own model elements, such as new windows and processes. You can also add code-based artifacts such as new PL/SQL functions or Java classes and add or modify their corresponding calling points within the application.
What you can do is practically unlimited and, most imporantly, it is always update safe.
Examples
To illustrate this principle, I would like to consider a few concrete examples.
Let's start with something simple. Let's assume that your adaptation consists in modifying the default screen layout for the Sales Order screen, to change the order of the fields, hide some that are not needed in your business, and rename some labels. After having set the system in customization mode, you would proceed by performing your configuration changes in the same way you did in 2.35 and 2.40 by navigating to the Application Dictionary / Windows, Tabs and Fields, querying the definition of the Sales Order window and
modifying its configuration there. Similar to previous releases, to see and test your changes you then need to rebuild the system.
What is new with 2.50 is that, once you are satisfied with your application, you can export your configuration script using the
export.config.script ant task and that at this point your configuration is saved in the file system.
If at a later point in time you need to apply a core maintenance pack, you can do so safely because the pack will override the files for the core module but it will not touch your configuration file. Once the system is rebuilt, you configuration is considered once again and automatically applied to the updated core.
This is a much easier process compared to previous versions when your configuration changes were saved in the same files as core definitions and you therefore had to go through a very difficult and error prone merge process to apply the maintenance pack without loosing your adaptation.
Let's consider another example. In this case, we will assume that your adaptation consists in creating a new window. After having set your system in customization mode, you can define and declare the new tables that are needed to support your window and proceed by defining the window in the Application Dictionary. If you are not an experienced Openbravo developer, you can follow the
tutorial in the Developer's Guide for step by step instructions.
The concept is very similar to the previous example and in this case as well your adaptation will be saved in a separate set of files and preserved when you apply maintenance.
A difference worth mentioning in this case is that you need to create your new window as a module separate from the "System Customization" template; this will give you more flexibility, including the option of reusing this window in another Openbravo instance without having to share the full configuration; you can even publishing it to the whole community leveraging the
Central Repository.
This process can be extended directly to very similar examples, like adding a
new report or a
new background process. In both cases, you can adapt your system through extensions that are both easy to implement and maintenance safe.
At this point, you are probably thinking that this is quite good for configuration changes and additive extensions but you might be wondering how can you modify core. For example, does Openbravo let you add a column to a core table and a new field to the corresponding window?
Of course, it does. Just create a module and follow
this tutorial. The concept is the same and, in this case as well, your changes will be preserved when you apply the next maintenance pack.
You want something very sophisticated? How about adapting the accounting logic to account asset depreciation in a different manner?
This is easy is easy to do. You need to define a module that contains a small Java class that implement your asset depreciation accounting logic and declares it in Openbravo as an accounting template
Impressive, isn't it?
So, what are some of the limitations? Well... they are not many, but the major limit is caused by the fact that the lowest level of modularization is the finest grained software artifact.
This is very fine grained in the case of Application Dictionary elements where you can adapt the software at the level of the individual property. However, it is less fine grained in the case of code, where you can adapt by logical file replacement: you add a module with the new file that substitutes the core one and you repoint the calling points as a configuration.
For example if you need to modify a core report, the lowest level of granularity is the jrxml file and you will need to create a module that includes a copy of the original core report and make your changes there; you then need to change the report declaration in Application Dictionary to invoke your modified report in lieu of the core one.
The consequence of this is that you have now taken the ownership of the whole report and that maintenance changes to the core file will not impact your adapted one.
Depending on the extent of your changes, this might or might not be an undesirable effect.
Similarly, if you want to modify a selector to, for example, add a column in the results table, you will need to create a copy of the full selector and maintaining it from that moment onwards.
In most cases, this is a small limitation and does not cause any significant issue. In a few circumstances, however, it does result in adaptation modules that are too large compared to the desired change in functionality. A typical example is a small change required in a database procedure like C_INVOICE_POST that will require you to own and maintain the whole procedure.
We have been uncovering cases like this working with the early adopters of release 2.50 and our experience has been that we can easily refactor these components so that there is always a clean way of plugging-in your extended logic without the need to take over the full component.
Because of that, I encourage you to contact us if you find yourself in that situation; in most cases, we can work with you and make small changes to core that will make your extension much easier. If you are a partner or a professional subscriber, you can request our assistance through your Channel Business Manager or through the
Openbravo Support portal respectively; if you are a community user, you can contact us using the
Help forum.
Do you still want to customize?We strongly believe, and our experience so far confirms it, that using the techniques that I illustrated above, you can meet any adaptation need through extensions rather than customizations.
That said, since Openbravo ERP is an open source solution, you continue to be free to change its code. You need, however, to be conscious that this freedom comes with a high price tag in terms of maintainability.
The only legitimate reason to customize core is when you find a defect and rather than relying on a fix provided by Openbravo, you decide to implement the change yourself. In that situation, we would strongly encourage you to report the defect in the
issue tracker and - if possible - to contribute your fix as a patch attachment to the issue. By contributing your fix, you can be sure that it will be included in the subsequent maintenance pack as well as in the next release; this way, when you update or upgrade your system, you will not have to neither merge the code nor reimplement the fix.
In the unlikely event that your really cannot meet your requirements through an extension, first I would encourage you to contact us before considering a customization: we might be able to make a small core change that makes your extension possible.
You should also consider whether the benefits of the customization are really worth the maintenance problems that they are going to cause. Perhaps, you can trade off that functionality in favor of ease of maintenance.
In the end, if you decide that you still want to customize core, you can follow the same approach that was recommended with 2.35 and 2.40: manage your customizations as source code and merge your development stream with our maintenance stream using a source control tool like Mercurial. Even in this case, Openbravo ERP 2.50 will result in a better experience than previous releases and the effort of resolving conflicts will be much lower because:
- A good portion of the customizations should be done through modules anyway
- The only core customizations are likely to be for code and not for meta-data and merging code is a lot easier than merging the XML based meta-data.
Above all, remember: extend, don't customize!
