View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Show collection (0 pages)
Collections help

Search

ERP 2.50:Developers Guide/Concepts/Modularity/it


Contents

Panoramica

Openbravo 2.50 comes with the new concept of Modularity: the ability for developers to build, package and distribute Extension Modules and for users to install, uninstall and update Extension Modules.

An Extension Module is a piece of additional functionality that can be deployed optionally and independently on top of Openbravo ERP. Examples of modules are: additional reports, additional windows, connectors, content packs (translations, chart of accounts, list of tax codes, product categories, etc).

The objectives of modularity are:

This document contains the developers manual for developing Openbravo ERP Modules.

Prima di iniziare

Requisiti di Sistema

To develop a module you must use version 2.50 or later of Openbravo ERP.

Configurare la propria istanza

There are some new requirements in 2.50 when configuring the environments. Please review the Development Stack Setup documentation before going ahead.

Concetti

Before you start it's also required to understand some new concepts. These concepts are described in detail in following sections in this document.

Artifatti in un Modulo di Estensione

There are four types of artifacts that can be included in an Extension Module:

Openbravo platform itself can not be modified through modules. In particular you are not allowed to modify wad (src-wad code) in a module. It should not be a limitation since the platform is designed to be extensible.

Tipi di Modulo di Estensione

There are three types of Extension Modules:

The three of them are generically referred as Modules.

Packaging e files .obx

All the content of a module -code, utility files, data- is packaged together in an isolated folder for each module. All the content in that folder is related to and only related to that module. There is a new folder within the main Openbravo folder called modules where all the modules that you have installed or developed are located. For each module there is a folder identified by the module java name. In that folder the source code structure of openbravo (config, src, src-db, lib, etc.) is replicated as required to store the content of the module.


Modules are distributed as .obx files which are compressed files of the module folder. You can directly decompress it using a zip tool to browse its content.


ModulePackaging.png

Module Manager Console (MMC)

This is a new window in Openbravo ERP where System administrators can see installed Extension modules in their instances, and where they can install new ones and uninstall or update the ones that are already installed.

ModuleManagement1.png

ModuleManagement2.png

Repository Centrale

The Central Repository is a system embedded in the Openbravo Forge to provide services related to Openbravo ERP Modules for developers and users:


CentralRepository.svg

Introduzione al processo di sviluppo di un Modulo

The process of developing a Module has three main steps:

  1. Register your Module in the Application Dictionary and in the Central Repository.
  2. Develop the artifacts included in your Module. Depending on the functional specification and technical design of your module it might include only one type of artifacts or a combination of them. In following sections each type of artifact is described in detail.
  3. Extract the .obx file of your Module and publish it in the Central Repository.

Steps 1 and 3 are common to all types of modules and straightforward. Step 2 depends on the requirements of your module. It has not significantly changed from the way you have developed Openbravo ERP code in previous releases to 2.50 but a few details that you need to know and that are described throughout later in this document. In particular the development tasks (create/update the database, build and compile the system, etc.) have been lightly modified to fit the Modularity paradigm.

Be aware that from now on every piece of Openbravo ERP code belongs to a module, including Openbravo ERP core itself. You should do all your new developments through modules, including your customizations. Still you can do changes directly in other modules -including Openbravo ERP core- but it is highly recommended not to do that. Maintenance will be dramatically better if you keep your changes isolated by doing them through modules.

Following sections will describe each step in detail.

Registrare un Modulo

The first thing you have to do is to create a new Module entry in the Module Window within the Application Dictionary menu folder.

ModuleWindow.png

There are some details that you need to be aware of:

The Include tab is intended only for Packs and Industry Templates. In this tab you include all the modules that are members of the Pack. You can only choose from the ones that you have installed in your instance. You have to provide the Version Number for each of them following Openbravo template as described. In a later section there is a description of how the system manages Version Numbers of Includes (for Packs and Industry Templates) and for Dependencies (for Modules).

The Dependency tab is intended only for Modules. In this tab you declare all the Modules that your Module depends on. It is of paramount importance that you declare them properly since the system will check that dependencies are met when the User installs or updates your module. It is also important to declare them as soon as you are aware of that because some tools and processes in the development process takes into account dependencies and the result might be wrong if they are not declared when developing your module. You declare dependencies along the modules you have installed in your instance. Tipically a module will depend on core (Version no. 2.50.0000 or higher) and eventually in other modules. You have to provide the Version Number for each Module it depends on following Openbravo template. Optionally you can provide a second Version Number (higher than the previous) to express that your Module depends on any Version Number of that module between the two provided. Later in this document there is a complete explanation of Version Numbers and how dependencies and includes are managed.

There is no need you to edit the Translation tab. It is a tool for translators and will be described in the translation section.


ModuleWindow Packages.png


If your Module includes a table in the Application Dictionary then you need to register one (or many) packages in your Module. For a full description on how packages are used look at the DAL developers manual. For each package you have to set the next properties:

If your Module includes any database schema object (a table, a stored procedure, etc.) or an AD message then you need to define the DB_Prefix. This is a seven characters length string. All your database schema object names need to start with this prefix so it needs to match Oracle and PostgreSql naming requirements (case insensitive and stored in uppercase, alphanumeric characters and start by an alphabetic character). You can only register one DB_Prefix, just Openbravo core Module is allowed to have more than one. DB_Prefix is needed to guarantee that there are no naming clashes when installing modules.

Once you have completed the set up of your Module then you need to register it in the Central Repository. It is needed to ensure that your DB_Prefix and your java package are not already registered by other Modules. You can do it through the Register Module button in the main tab of the Module window. It will send to the Central Repository your Module information. If your DB_Prefix and your java package name are not already registered it will register them and will return a success message and the Module in your instance will be marked as registered. If there is a conflict then the process will propose you other DB_prefix or package name values.

Once you have completed the registration of your module you are ready to start developing your artifacts!

Sviluppo di artifatti di Modulo

As stated in the Concepts section there are four types of artifacts: Application Dictionary Components, Software resources, Reference Data and Configuration Script. The requirements of your module and its technical design will define the needed artifacts to build your module. This document explains the details you need to be aware for each type of artifact, one by one, related to modularity. It does not explain how to use them together to build solutions, it is described in the Openbravo Developers Guide. At the end of this document there is an explanation of a number of simple "Hello World" examples that cover all different type of solutions.

Componenti di Application Dictionary (componenti AD)

Most of AD components can be included in your module but a few exceptions that are explained later in this section. The general rule to describe how Applications Dictionary components are included in your module is simple: set the module field of that component to your module. If you only have one module in development or you are working in your default module it will be done automatically by the system.

Only modules marked as "in development" are available when you edit an AD component. If you change a property in a AD component that is not in development the system will raise an error to avoid you to perform not intended changes.

Translations are managed in a particular way and you don't need to take care about translations when developing. There is a detailed description on the translation process in the Translations section. But remember that your module has a native (base) language so the UI components (Windows, tabs, fields, elements, messages, textInterfaces, etc.) that you develop have to be created in that language.

Access information is not included in modules so you can forget it when developing your module. In a later section it will be explained how to include a particular configuration for openbravo rbac (role based access control).


WindowWindow.png


There are some details on top of the general rule that you should understand to have better control of the content of your module. It is worth to review each type of AD component.

Tabella e colonna

Registering tables in the AD is the first exception to the general rule. Tables are not assigned directly to a module but to a package in a module. It is needed by DAL to properly manage packaging of generated entities and xml naming. Only packages of "in development" modules are available when you edit a table. The module of a table is the module of the package of a table.

Columns are assigned by default to the module of their table. But you might want to add in your module a column within a table in a different module (eg. add a new column to the M_Product table in the core module). To do that you are forced to use a naming rule for that column: its physical name (ColumnName property) has to start by the prefix "EM_XXX_" where "XXX" is your module DB_Prefix. "EM" stands for External Module. The Create Columns from DB process has into account all this rules when importing columns from the database.


TableWindow.png


Finestra, Scheda e Campo

Window, Tab and Field follow the general rule. The three of them are linked to a module. By default when you add a tab to window it will be linked to the module of its window and when you add a field to a tab it will be linked to the module of its tab. This is true but when the window or tab modules are not in development. Then the defaulted module will be proposed. The Create fields process has into account all this rules when creating fields from table columns.

When editing the field sequence the system will guarantee that you do not change the sequence number of fields that are not in you module, so if you add a new field in a tab of other module the sequence number of the original fields will not be modified. If you edit manually this information be aware that you can not modify information in a module that is not in development. It also applies if you are adding an additional tab to a window in other module.

The tab class and mapping is automatically managed by the system and you not need to take care about it. In a later section it is explained how Class and Mapping are managed and what you can do to add additional entries there.

Riferimenti

There are four types of references: Data type, List validation, Search validation and Table validation. In Openbravo 2.50 only List validations and Table validations can be included in a module different to Openbravo core. Data types and Search validations will be supported in modules in future releases (currently it requires to modify Openbravo WAD).

All the values included in a List validation are included in the module where the List validation is defined. In Openbravo 2.50 you can not add in your module new values to a List validation in a different module nor modify the values included in it.


ReferenceWindow.png

Report e Processi

Reports and Processes follow the general rule. You can declare a new process or report in your module by just creating a new entry in the Report and Process window and linking that entry to your module. All parameters in a Report or Process will be included in the module where the Report or Process is declared.

Finestra Manuale

Forms follow the general rule too. You can declare a new form in your module by just creating a new entry in the Form window and linking that entry to your module.

Message

Messages follow the general rule but with an additional detail you need to take care. You can declare a new message in your module by just creating a new entry in the Message window and linking that entry to your module, and the search key of the message has to start by your module db prefix (to avoid clashes between messages from different modules). It means that you can not include in your module a message with a numeric search key to be raised by a pl/sql object through the RAISE_APPLICATION_ERROR function.

Text interfaces

Text interfaces window usually is not edited manually but entries are automatically generated by the translation process when it parses files to be translated. This process takes into account the packaging of the file being translated and the text interface entry is properly assigned to the module. This process should be transparent for developers but you can browse the entries that your manual developments have created and edit them.

There is a detailed description on the translation process in the Translations section.

Element

Elements are usually automatically generated by the Synchronize terminology process when you create new columns. This process takes into account the name of the columns that you have included in your module and searchs in your module and the modules your module depends on for an element with that column name. If it is found your column will be linked to that element, if not a new element will be created in your module. This process should be transparent for developers but you can browse the elements included in your module and edit them.

Field category, Auxiliar input, Callouts and Validations

These four Application Dictionary components follow the general rule too. You can declare a new component of them in your module by just creating a new entry in the proper window and linking that entry to your module.

Model - Implementation mapping

Model - Implementation mapping is generalization of the Model-Object concept that was present in previous releases. You can see a detailed description in the explanation of the Model - Implementation concept.

Through this new window you can include in your module the entries you need to add to the web.xml file of Openbravo context.


ModelImplementationWindow.png

Model - Implementation mappings follow the general rule. You can declare a new entry in your module by just creating a new record in the Model - Implementation mapping window and linking that entry to your module. All mappings and parameters assigned to it will be included in the module where the Model - Implementation mapping is declared.

Software Resources

To develop your module you may require to include some software resources. Software resources are Openbravo ERP components not expressed as metadata such as xml definition of database schema object, java classes, jar libraries, XML files, etc. All you need to add to your module has to be packaged within openbravoMainFolder/modules/yourModuleJavaName (eg. for the module org.openbravo.examples.helloworld the packaging is /home/user/src/openbravo/modules/org.openbravo.examples.helloworld in a linux box or c:\openbravo\modules\org.openbravo.examples.helloworld in a windows one). Within this folder you have the standard openbravo folders to hold your software resources (src, src-db, lib, etc). See the image in the packaging section for details.

The build process of Openbravo has been modified to take into account the new source code structure that now is split into modules. Be aware that this concept is completely different from the srcClient that Openbravo used in previous releases: you are not allowed to physically overwrite a file in Openbravo core distribution. In fact, the packaging of your software resources should be located in com.yourCompany.xxx or org.yourCompany.xxx so you will not use org.openbravo.xxx to package your code any more.

Similarly to AD components, although this general rule for packaging is applied to all software resources there are some details for each type of software resource (Database schema objects, java classes, jar libraries, web static content, etc.) that you need to be aware when developing your module.

Database schema objects

The typical flow to add a new database schema object (table, column, constraint, index, trigger, view, stored procedure, function) or modify it in Openbravo ERP is as it follows:

From a modularity perspective there is no need you to do any additional task to take care of Application Dictionary metadata since it is managed by the system as described in the previous Application Dictionary Components section. But to avoid naming clashes in the database and to allow DBSourceManager to kwow the module of not mapped database schema objects it is required to follow the next naming rule for database schema objects:

And that's all. Following this simple rule you can include in your module as many database schema objects as you want. But be aware that you can not modify database schema objects in other modules as it would break the main rule: "a module can not modify components in other modules".

When DBSourceManager exports the database it will only take into account modules "in development", the other ones will not be exported. The exported xml files will be located within the src-db/database folder within the module folder. Look at packaging to see an example.

At the end of this document there are some examples explained that show how to include in your module any type of database schema object. You can use them as a reference to develop your module.

Exceptions

It is possible to define database schema objects within a module that do not follow the naming rules explained in the section above. This is specially useful in order to move to modules existent Openbravo ERP instances in older versions.

When a database schema object is defined as an exception for a module it is exported to that module instead to the one that should be according to its name and the naming rules.

Exceptions are defined in Application Dictionary || Module || Module >> Naming Exceptions tab which contains two fields:

Notice that these are exceptions and they should be avoided if possible. Take also into account that a module with exceptions will not be shareable.

Java classes, other Openbravo MVC stuff and jar libraries

Java classes, other Openbravo MVC stuff (html, xml and xsql files) and jar libraries follow the general rule to add software resources in your module. You have to package this code within the src folder located in your module folder.


ResourcePackaging.png


When Openbravo ERP builds the system it will dinamically add to its java project all the src folders within all installed modules as java resources of the project. It uses an intermediate location, build folder, to generate code from xsql files and to compile all java resources and put them together. You can include in your module jar libraries made by you or by any other third party and use them along your code. All jar libraries included in the lib folder are added to the classpath at compilation time and finally deployed to the openbravo context.

After the generation of code and compile process the build process deploys all the content to the openbravo context in the servlet container. There are two modes of deployment -class and war- that are explained later in the Advanced Concepts section.

Web Static content (css files, images, javaScript)

If you need to add some web Static content (css, images and javaScript) to your module you have to place these resources in the web folder of your module, within a folder named as the java package of your module to avoid clashes of files when deploying resources from different modules.

When the system is built all files in the web folder of your module are copied to WebContent and from there it is deployed to openbravo context in a standard way so this resources can be accessed from the pages in your module by referencing them. Take into account that xmlEngine performs an automatic translation of urls through a replace of "../../../../../web" (replaceWhat parameter) by "@actual_url_context@/web" (replacWith parameter), being "@actual_url_context@" the absolute path to your openbravo context (eg. http://localhost:8880/openbravo).

The Solitaire module is designed to demonstrate how to include typical web static content in your module. Through this example it is simple to understand how it works. For example, this is a snippet of Solitaire.html to reference to solitaire.js file that is located within the web/org.openbravo.examples.solitaire folder of Solitaire module:

<script language="JavaScript" src="../../../../../web/org.openbravo.examples.solitaire/solitaire.js" type="text/javascript"></script>

At execution time, once openbravo context is deployed and loaded you can get solitaire.js javascript library from @actual_url_context@/web/org.openbravo.examples.solitaire/solitaire.js. When the main page of Solitaire module is delivered, xmlEngine will replace "../../../../../web" by "@actual_url_context@/web" and by so properly referencing to the available resource.

Of course you can also reference to other web static content resources included in core or other modules. In that case remember to explicitily declare the dependency to that module.

Config files

You might also need to include some configuration files in the config folder of your module. These files will be copied to WebContent/WEB-INF when the system is built and deployed to openbravo context.

For example, in HelloWorldService module there is file named org.openbravo.examples.webservice-provider-config.xml within the config folder. This file is copied to openbravo context and by this mean the class that implements the webservice is declared.

To avoid clashing of files deployed by different modules files within config-folder should be prefixed with the PackageName of the module.

Reference Data

Openbravo Modularity supports Reference Data: business information referred by transactions and that tend not to change frequently such as translations, charts of accounts, tax codes, banks, product categories, etc. They can be defined at system, client or organization level and it will define when they are loaded into the instance: System information will be loaded at intallation time while Client and Organization information will be loaded during the "Initial Client/Organization Setup" or "Enterprise module management" processes.

Reference data modules are also versioned and can publish updates and upgrades during their life cycle.

There are three types of reference data supported: Translations, Chart of Accounts and standard Reference Data.

Translations

Traslation modules are a special kind of module. They have to be marked as "Is translation module" in the Module window. No other contents than translations are allowed in translation modules, and only translations for one module to only one language, the native language declared for the module (eg. translation for core module to Spanish, translation for HR module to French) . Translation modules only depend on the module they translate.

Create a translation module is a straigthforward process. First you have to create your module as usual. Remember to define it as "translation module" and define the its native language as the language you are going to translate to, and to use the native language of the module writing its name, description, etc. Keep unchecked the other properties related to reference data (Translation required, Has chart of accounts and Has reference data). This module does not need any Includes, Data packages and DB prefix and will only depend on the module version you are translating.

Then create the main folder of your module -named as its javapackage- within modules folder, you can do it manually or just by executing export.database -Dmodule=yourModuleJavaPackage ant task (remember that the module has to be In development).

Then all you have to do is install the module you plan to translate and declare the dependency of your translation module to this module, and follow the standard tranlation process following this document. Take into account that from release 2.50 the export languages process splits the xml files in different folders for each module installed: core is exported directly to the language folder (eg. es_ES) and any other installed module will be exported to a folder named with module package name within the language folder (eg. es_ES/org.openbravo.examples.hellowold). Once you have completed the translation you have to copy the translated xml files of the translated module -only these ones- to referencedata/translation folder within your module folder, and package it as usual by executing the ant task package.module -Dmodule="yourModuleJavaPackage" that will create an .obx file that is ready to be published or distributed.

Translation information is always at System level. When a translation module is installed the process takes care of all details to import a transalation pack: it will mark the Language as System Language if it was not and will load all translations in Openbravo Application Dictionary.

Chart of Accounts (CoA)

Tipically you should add just one Chart of Account in your module, although you can create as many modules including CoA as you want and then put them together in a pack if needed. Chart of Accounts are stored in a particular .csv file, please read this explanation to learn more about how to create a .csv file for a Chart of Accounts and test it is ok.

It is easy to create a module including a Chart of Accounts once you have prepared the .csv file. All you need to do is create a new module and mark as checked the Has a chart of Accounts property. Keep unchecked the other properties related to reference data (Translation required, Is translation module and Has reference data). This module does not need any Includes, Data packages and DB prefix and will only depend on the core version you are using (the structure of the .csv file is defined in core).

Then create the main folder of your module -named as its javapackage- within modules folder, you can do it manually or just by executing export.database -Dmodule=yourModuleJavaPackage ant task (remember that the module has to be In development). Withing the main folder you have to create the subfolder referencedata (all in lower case) and within it the folder accounts and place your .csv file there. Remember that folders are case sensitive so the folder must be identically named and use the correct capitalization.

Now your module is ready to be packaged. Execute the ant task package.module -Dmodule="yourModuleJavaPackage" and it will create an .obx file that is ready to be published or distributed.

Chart of Accounts are always at Client/Organization level so nothing happens when you install this type of modules but just that the chart of accounts is available to be applied to new clients (during Initial Organization Setup), new organizations (during Initial Organization Setup) or to existing Client/Organizations (by Enterprise Module management).

Standard Reference Data

You can also include any other data in your module through standard reference data using data sets.

First you need to create in your instance the data you want to include. It could be taxes for a particular country, product categories or a collection of alerts for a particular industry or any other data. You can combine different data from different tables in your module.

After that, the next step is to create a module and mark as checked the Has reference data property. Keep unchecked the other properties related to reference data (Translation required, Is translation module and Has chart of accounts). Complete the Reference data description with information about the data you are including (this description might be different from the module descriptions since the module might include some other content). This module does not need any Includes, Data packages and DB prefix and will depend on the module versions that define the data structure you aim to include (eg. if your data comes from table defined in core 2.50.1234 then it will only depend on this module-version).

Then you have to create within your module as many data sets as you need to define your data. A data set is a collection of data defined by the tables where those data are stored, the rows included -defined through a filter clause for each table- and the columns you want to include for each table. Data sets support advanced data definition to include full business objects (eg. when including an invoice you might ask the system to include all its members -lines, taxes, etc.- as well). Click [ERP/2.50/Developers_Guide/Concepts/AD/Dataset here] for a general description of datasets.

You can create datasets in the Data Set Window within the Application Dictionary menu folder.

DataSetWindow.png

There are some details you need to be aware when creating data sets:

Next step is to define the collection of tables included in your data set.

DataSetTableWindow.png

Again some details you need to be aware:

Take into account that the system will export not only the data defined by you data set but also any information referenced by it. This way it is guaranteed that the system will be able to import that data in any other instance although the referenced data does not exist there. If it is the case the import process will also import any referenced data needed to complete the operation.

Now you have to define the columns included for each table.

DataSetColumnWindow.png

Usually there is no need to define columns in your table since tipically you want to include all of them but audit info and you can do it in the table itself as described before. Some times you might want to exclude some other columns by checking the Excluded field.

Once you have completed the definition of all your data sets you have to export them to xml files so they are included in your .obx file when packaging your module. To do that you have to click on the Export Reference Data button in the data set header. It will create a xml file named as the data set in referencedata/standard subfolder within your module folder. Of course you can run this process as many times as you need to fine tune your data. Finally package it as usual by executing the ant task package.module -Dmodule="yourModuleJavaPackage" that will create an .obx file that is ready to be published or distributed.

As described before you can also publish new versions of your reference data modules. Take into account that to ensure data consistency reference data is not deleted from the instance when applying an update/upgrade where the new data set does not include some records originally included. So instead of remove them from the data set you should inactivate them.

Configuration Script

Up to know we have seen how to extend Openbravo through modules. As you remember modules are able to add new artifacts -application dictionary components, software resources and reference data- but are not allowed to modify other modueles to avoid crossed dependencies between them.

But there is a special type of modules -Industry Templates- that can include changes to other modules within it. It is done through configuration scripts. A configuration script is a collection of changes that your Industry Template does in other modules included in the Industry Template.

Create a configuration script is straightforward. You don't need to manually edit it but the system will generate it automatically as you go. You only need to create an Industry Template in your instance. You can only have one Industry Template "in development" at a time and any change you do will be included in the configuration script of that Industry Template.

Development tasks

All development tasks have been reorganized in Openbravo 2.50 and modules are properly managed so you can update your database or compile your system taking into account only changes in a given module. Read this document to get a complete explanation of all available development tasks.

Publish the .obx file of a Module

Once you have finished developing your .obx file, you can publish it to the central repository.

  1. Package your module using the following ant command, where yourModuleJavaPackage is the java package you defined in your module:
     ant package.module -Dmodule=yourModulePackage
  2. Access the central repository, supplying your username and password.
  3. From the Appliation menu, select Central Repository
  4. Click Add .obx.
  5. Navigate to the .obx file you want to upload.
  6. Click Continue.
  7. The .obx file is uploaded to the repository.

Advanced concepts

This section explains in detail some advanced concepts of Openbravo Modularity. It is not strictly necessary you to read all these details but it is worth to do it, it will help to avoid mistakes when creating your modules.


Version numbers and how dependencies and includes are managed

Different releases of an Openbravo module are identified with a version number. An Openbravo Version Number is an string up to 10 characters lenght following the format x.y.z where:

A major release is identified by the two first digits (x and y). For example, core 2.50.3642 and core 2.50.3921 are two different minor versions within the core 2.50 major version.

Modules have to declare any dependencies between them and all of them must depend finally on core module. Dependencies are declared to a particular major version of a module or a range of major versions. For example, module A depends on core 2.50 or module B depends on any version of module A from version 1.0 to version 1.6. In a similar way Packs and Industry Templates declare the modules (including other packs and Industry Templates) that are included within them. In this case ranges are not supported, just a major version of a module can be included in a Pack/Industry Template. Be aware that both dependencies and includes use a full version number (x.y.z) to identify the version but only the major version of it (x.y) is taken into account. The minor version (.z) is used just for keeping track of the actual release that was used when the module was developed.

Usually a major relase matures in a process through three phases of increasing stability: alpha, beta and production. Many minor versions can be published in each phase but the release can not be considered stable enough to build something on top of it till the beta phase is reached. You should not develop a module that depends on an alpha version of other module to avoid inestabilities inherent to this stage.

To improve maintainability minor versions of modules are not taken into account when managing dependencies. It means that in the previous example module A should be compatible with any minor version of core 2.50. It causes some limitations on what developers can do when working on a minor version but highly improves maintainability by minimizing the effort of checking dependencies. You only need to review if your module remains compatible with a module it depends on when a major version of that module is released.

To enforce this behaviour it is of paramount importance to clearly state what changes are forbidden within a minor version and to enforce them before publishing. The general rule is that the public API of the module should not change, and it can be expressed in more detail with the following set of not allowed changes within a minor version:

These restrictions make the fixing bugs exercise more difficult but are a key factor to create a maintainable ecosystem. They should be guaranteed during the beta and production phase of any release of any module. During the alpha phase -when bug fixing activity is high- you could break this rule to get some flexibility and taking into account that there should not be any other module depending on it.


Model - Implementation concept

AD_Model_Object is a table in Openbravo Application Dictionary to link Application Dictionary components and the class (servlet) that implement that object. So this table is a mapping between the logical side (AD components) and the physical side (classes). It is useful for two main reasons:

  1. It allows to implement in a generic way rules that apply to all AD components like security, navigation and others.
  2. It is the mechanism to automatically populate the web.xml file where classes (servlets) are declared. The AD_Model_Object_Mapping is an utility to create the mapping entries in the web.xml file.

There is a few number of exceptions to this description: some servlets that are deployed in Openbravo context but are not linked to any AD component, such us the DataGrid or the AuditInfo servlets. They are invoked from manual or standard components (windows, forms, etc.) through http requests by hardcoding its url-mapping in the request. It can be interpreted still as a mapping of actual classes that implement a functionality that is not described in current Openbravo model, although it may be in the future.

Modularity project aims to allow through modules the deployment any type of optional content in an Openbravo instance, including additional entries in the web.xml file of openbravo context. It is done through the AD_Model_Object table. Developers can create entries in this window not linked to any AD component. To support any type of web.xml content (servlet, listeners, filters, etc.) a new column is added to the AD_Model_Object to represent the type of web.xml entry that the developer is adding. They can also declare a set of mappings for the entry and a set of parameters if needed.

The module of a AD_Model_Object entry is calculated with the following rule: if it is linked to any AD component then the module is the one assigned to that AD component, otherwise the module is the one assigned to the AD_Model_Object record itself.

With this extension the web.xml file in the openbravo context will be fully extensible through modules.

Example on how to create and package your module

Now it is time to go practice. You can follow this howto that will guide you step by step on how to create and package your first module.

Retrieved from "http://wiki.openbravo.com/wiki/ERP_2.50:Developers_Guide/Concepts/Modularity/it"

This page has been accessed 3,720 times. This page was last modified on 14 June 2011, at 11:03. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.