This argument holds true as long as two conditions are met:
- Most adaptations are possible as extensions, without requiring changes to the application itself.
- The interface and the semantics of the application are stable and we can be guarantee that any extension that works against a specific version of Openbravo will continue to work when the application is updated to subsequent versions through maintenance packs.
It is my belief that both conditions are satisfied in Openbravo ERP 2.50 and today I would like to describe how we ensure that Openbravo is stable and that that the second condition holds true, leaving the exploration of the first point to future blog posts.
Let's start with some background information.
Openbravo ERP is itself delivered as a module that we call Core. All extensions, both base modules and templates, reference Core. Templates can directly change the attributes of artifacts included in Core; for example, a template can disable a field. Base modules, on the other hand, cannot change Core directly but can influence its behavior by adding artifacts that add to Core; for example, a module can add additional fields to a sales invoice line and consider those fields at invoice completion by adding to the extension point of the Invoice Post process.
In all cases, modules depend on Core to the extent that they reference artifacts that are defined in Core. It is therefore essential, to keep modules working, that Core artifacts are not changed or removed as part of the maintenance of the application. By guaranteeing that, we ensure that users can confidently apply mainteanance packs without the risk of breaking their adaptations.
We call the set of Core artifacts that other modules can reference the Openbravo Public Application Programming Interface or the Public API for shorts.
In other softwares, the term API usually refers to the signature of procedures and modules that can be invoked to execute specific functions. In the case of Openbravo, that definition is too restrictive as the application is meta data driven and, in many cases, modules interact with meta data rather than procedures and classes (actually, in a perfect meta data driven application, all interactions are at meta data level).
We are therefore using the term public API in a more generic sense, referring to all artifacts that other modules can reference in their definition, including:
- Web services
- Public Java classes and methods
- Javascript libraries that developers can use in their manual UIs
- All meta-data defined in the Application Dictionary
- PL/SQL functions and procedures
- Database tables and views
Soon after the launch of 2.50, we completed the formal definition of the public API. You can find the results of this work as part of the Developer's Guide.
Once the public API had been defined, the next step was to guarantee its consistency and perpetuity. This is particularly challenging in the case Openbravo given the very diverse nature of the artifacts it comprises. To achieve this objective, we have developed a tool that compares two revisions of the Openbravo code and performs a number of checks to ensure that there are no changes in the public API that could break already published modules.
For instance, this tool verifies that no mandatory column has been added to an existing table without a default value associated to it because that would break any module that attempts to insert new rows into that table and is not aware of the new column; similarly, it checks for addition of constraints, changes in column names or types, etc. When it comes to the Application Dictionary, the tool verifies that no meta data has been removed as other modules could reference it. It also verifies that the signature of a procedures, functions and methods has not been altered in any way.
With the tool in place, the logical next move was to integrate into our Continuous Integration framework. This way, any possible change that breaks the public API is discovered as soon as possible and in most cases only a few minutes after the developer has committed the change. This early detection system allows us to resolve any inconsistency well before it affects our users.
You can monitor the periodic execution of the API Consistency Check here.
Because the API consistency check is a static verification of consistency, it can only cover the formal integrity of the API at a syntactic level but there is still a small possibility that the API has changed semantically. To cover this eventuality, we have developed another automated test, also integrated in the Continuous Integration framework, that verifies that installing a few representative modules continues to be successful. We are also considering extending this test to cover at every execution a few randomly selected modules among the ones published by our community and possibly to integrate their regression testing as well.
You can monitor the period execution of the Module Installation Check here.
Of course there are always exceptions and, in a few cases, we need to accept small breaches in the API consistency. This typically happens when the API definition is wrong in the first place and we need to tread off addressing functional issues with the API stability. For example, we recently had a case where the product allowed the definition of duplicate accounting periods for the same calendar; this could have resulted in product failures under those circumstances as the accounting engine does not know under which period to post a transaction and the fix was to add a new unique constraint on the period table. Formally, this is an API change but the chances of this change breaking other modules are very small compared to the risk of leaving the defect in, so we accepted the exception.
In general, these exceptions represent very low risk to our consumers.
Whenever they happen, however, we publish them to our community using so that module owners can review them and assess if they are affected and adapt their code accordingly. We do so using as many communication channels as we can to reach the broadest possible audience:
- a dedicated page on the wiki;
- the openbravo-development mailing list;
- a dedicate thread in the forums.
With public API defined and this infrastructure in place, we can guarantee that modules published for 2.50 will continue to work unaffected throughout the whole life cycle of the release.
Additionally, by discovering and publishing API changes we can also ensure that, as we start the development of a new major version, our community is fully appraised of changes in our application and module developers have a very accurate description of the changes that affect their extensions.
In other words, this allows us to maximize the preservation of the investment that our community makes in the Openbravo platform and ensure the health of our ecosystem.
