Upgrading to Openbravo 3

Now it is one month since Openbravo 3 was Generally Available released.

But what about people using Openbravo 2.50? Should they continue using 2.50 for the next few years? The answer is NO…  Now it is very easy to upgrade to Openbravo 3 for all of them!

From 2.50 MP31 (which is currently in  QA Approved maturity status, learn more) upgrade using ERP’s user interface is supported. We have worked hard to provide an easy upgrade path. Being in 2.50 MP31 or higher, after Scanning for updates you will find, in addition to he updates for your modules, upgrade to Openbravo 3. Upgrade is a new flow (similar to update) that will guide you through the steps required to end up with your instance in the new major version. Even “upgrade” can sound as very a difficult and complex task, I suggest you to try it and realize how it is possible to do it in matter of some hours. Here, you can find detailed documentation on this process.

MMC Upgrade

But this is not all the good news:

  • We wanted to make Openbravo 3 as accessible as possible, so 2.50 MP31 has been released as a Community version, this means Community Edition 2.50 instances will be able to easily update to this version through user interface.
  • For professional subscribers, there is also available an upgrade for the Openbravo Appliance.
Enjoy Openbravo 3!
Advertisements

Base References in Modules

Openbravo ERP 2.50MP12 is about to be released, one of the new cool features it includes is the capability of defining new Application Dictionary Base References within modules.

Application Dictionary References is the way Openbravo ERP defines data type of columns and how is rendered the UI for them. Before 2.50MP12, modules were not allowed to add base references, they only could use the ones provided by core and create new sub-references for these ones. This means that the UI and behavior for all fields in generated windows was set by the references in core, being impossible to define new ones in modules implementing different UI and behavior. The only way to perform all of this was creating manual windows where you are free to implement whatever you need, but as counterpart you loose the maintainability of having windows defined in Application Dictionary.

This limitation has now been broken. You can create base references in your module, which will allow to integrate within generated windows elements having new UI and behaving in a different way than the ones predefined in core.

UI selector

As a first example of how this new capability can improve Openbravo ERP usability you can take a look at the new UI Selector, which through a module (available as commercial) implements a completely new UI for selectors. Being also the first module that integrates SmartClient within generated windows.

Modularity naming rules adjustments

This message is VERY IMPORTANT for all of you developing and maintaining modules. Please read it carefully to adapt your modules to the new rules.

Recently some adjustments in modularity naming rules have been performed in order to prevent possible naming clashes between different modules. These changes have been now applied in pi mercurial repository and they will be released in next Openbravo ERP 2.50MP10 version. Before this, it is recommendable to adapt modules to this adjustments.

Existent modules that do not fit the new rules will raise warning when compiling but they will continue working, anyway it will not be possible to package these modules as obx files till they are fixed.

Below it is listed the complete changes and what is the action to be taken to fix modules in each case.

  • Mapping for WAD code
    • Rule: Mapping for WAD windows contains now the module’s mapping for tabs not in core. As this is automatically generated and shouldn’t be manually edited class and mapping tabs in Windows and Tabs window has been set as non editable.
    • Consequence: When updating to the new core version mappings in modules will be automatically updated to the new rule.
    • Action: Export the module with the new automatically generated mapping.
  • Mapping for manual code.
    • Rule: HTML mapping for all manual objects (forms, searchs, reports and processes) must start now with the module’s package. For example, the mapping for a report in a module with package (org.myCompany.moduleTest) could be /org.myCompany.moduleTesr.reports/MyReport.html.
    • Consequence: Old modules not following this rule will still work, but a warning will be displayed whenever the code is compiled. These modules will not be allowed to be packaged in obx files till they are not fixed.
    • Action: The action to be taken to fix modules is to detect the incorrect mappings (it will be shown as a warning when compiling) and adapt them to the new rule.
  • Column.name value
    • Rule: Name attribute in column must follow now the same rules as Database name (columnname) had. This is, when the column is in the same module as its table, no special rule required; if it is in another module, it must start by EM_ + the module’s db_prefix.
    • Consequence: This rule has been enforced in through database triggers, making not possible to create or modify existent objects if the mapping is not correct. Anyway, old modules not following this rule will still work, but a warning will be displayed whenever the code is compiled. These modules will not be allowed to be packaged in obx files till they are not fixed.
    • Action: Locate columns not following the naming and change it. Note that this will cause a change in the module’s API, because this value is used by DAL to generate the property in Java. Therefore it will be necessary also to change the Java processes accessing the column with DAL.
  • Database indexes and constraints
    • Rule: Indexes and constraints now must start with the module’s db_prefix if they are in the same module as their table. If they are in a different one, the rule is the same as it was (start by EM_ + db_prefix).
    • Consequence. Now when exporting database (if validate.model property is set to true) a warning will be raised if there are indexes or constraints not following the rule. It will not be allowed to package modules in obx files if they do not follow the rule.
    • Action: Rename indexes and constraints to adapt them to the new rule. Note that it is possible to define messages for constraints, in this way it is possible to display a customized message when the constraint is not satisfied. These message have as Search key value the constraint name, therefore it will be necessary to change them if exist.
  • Reference name
    • Rule: In this case a restriction has been removed. Prior to this change, reference name was unique in the whole database, thus it was possible two different module adding two reference with same name and it was not possible to install both in the same instance. Now, reference name is unique per module, so there is no problem with several modules defining the same name for different references.
    • Consequence: Now name cannot be used to identify references. Therefore constructor for TableComboData shouldn’t be used passing as parameter the reference name, but its ID. This constructor has been changed and when passing name the reference is always looked within core but not in other modules.
    • Action: Review module’s manual code to ensure all TableComboData constructors are called using ID when the reference is not in core.

As addition, all default messages used to be displayed when a constraint is not satisfied have been removed from database as they are automatically managed. This means that hundreds of messages have disappear and it is recommended for those of you maintaining a translation to repackage it again without  all of these messages.

Sorry for all inconveniences this might carry.

New stuff for Openbravo ERP developers

Recently modularity project has been merged back to Openbravo ERP 2.50 trunk. Apart from the features described within the project, some other useful utilities have been developed, these features are usable from r2.50 by any development. Some of them are:

GenericTree

GenericTree

GenericTree allows to represent an ajax tree for any tree data structure in Openbravo ERP. It draws the user interface for the tree and manages the ajax calls for opening and closing nodes.

GenericTree is an abstract Java class that can be extended by other classes to implement different trees. These subclasses just need to populate a FieldProvider object with the information for the concrete tree. Once this is done in order to show an ajax tree it is only needed to instantiate a subclass.

Let’s see some code:

This is the Java piece of code

ModuleTree tree = new ModuleTree(this);
tree.setLanguage(vars.getLanguage());
//Obtains a tree for the installed modules
xmlDocument.setParameter("moduleTree", tree.toHtml());
//Obtains a box for display the modules descriptions
xmlDocument.setParameter("moduleTreeDescription", tree.descriptionToHtml());

And here is the HTML side


<tr>
<PARAMETER_TMP id="
moduleTree"/> <!-- Prints module tree 4 cols -->
<td/>
<td/>
<tr>

<tr>
<PARAMETER_TMP id="moduleTreeDescription"/> <!-- Prints module tree desc  4 cols -->
<td/>
<td/>
<tr>

In this example ModuleTree class is a GenericTree’s subclass which implements the queries for the tree of modules, creating a new instance of this class and setting the toHTML() in the HTML template will display the User Interface and manage all the ajax requests.

FieldProviderFactory

This class allows to transform any object with setter methods into a FieldProvider object. This is useful to represent this non-FieldProvider object within a structure inside a xmlEngine template.

Here’s the code:


WebServiceImplServiceLocator loc = new WebServiceImplServiceLocator();
WebServiceImpl ws = (WebServiceImpl) loc.getWebService();
Module module = ws.moduleDetail(recordId);
ModuleDependency[] dependencies = module.getDependencies();
xmlDocument.setData("dependencies", FieldProviderFactory.getFieldProviderArray(dependencies));

In this example ModuleDependency is a class that has setter methods, so to use it to fill a HTML template it is possible to convert it into a FieldProvider using FieldProviderFactory class.

AntExecutor

AntExecutor is able to execute any ant task from any build.xml file. It is also possible to set different loggers, for example a file log or an OBPrintStream which can be used to display the generated log in real time.

This is a basic example that just creates a new AntExecutor for a buil.xml file, adds a task and a property and executes the task.


AntExecutor ant=new AntExecutor("/path/to/build.xml");
Vector tasks = new Vector();
tasks.add("apply.modules");
ant.setProperty("module", "test1");
ant.runTask(tasks);

Zip

Zip class zips and unzips files.

It is easy to use:


Zip.zip("/path/to/zip/", "/file/to.zip");
Zip.unzip("/file/to/un.zip", "/path/to/unzip");

First modularity merge to trunk

I have merged the first part of modularity project into trunk. This does no add any new functionality, it just contains the new database infrastructure to manage modules which includes a table (AD_Module) to maintain the installed modules in the instance and a reference to this table in many application dictionary tables (you can see the complete list of the affected tables here).

The purpose of this early merge is to try to affect other projects for r2.50 as llittle as possible but, in any case, it would be advisable to synchronize these projects with trunk as soon as possible in order to minimize the risk of conflicts.