View source | Discuss this page | Page history | Printable version   

ERP/2.60/Platform Team Development Plan

Warning.png   This document is still a work in progress. It may contain inaccuracies or errors.

This page discusses the development plans for the Platform team for the Openbravo 2.60 release. It gives an overview of the main topics and provides a first timing esitmate.

The main theme for the Openbravo 2.60 release is the re-design of the UI to support new UI concepts as outlined in the Openbravo ERP UI Redesign. This in combination with using Data Access Layer functionality.


User Interface Improvements: Select UI technology

To improve the user interface in 2.60 one fundamental choice needs to be made: which UI technology will we be using. This part of the development plan covers the steps needed to select a new UI technology.

Project Steps:

A side goal of the proof of concept is that it can be used as input for the future UI-server architecture and identify the development tasks which need to be done.


Formalizing the new UI design: Functional Design

The new UI design needs to be formalized in a functional design. The focus of this functional design is on how to model the new UI, it should cover the following topics:

The proposal in this document is to not change the current UI (windows/tabs, the WAD generation), but instead develop a completely new UI on top of the data access layer and using the Application Dictionary. The functional design should follow this base philosophy.

Timing: throughput time around 2-3 weeks

Technical Design of new UI-layer development

The technical design combines the results of the proof-of-concept and the functional design into one combined design. This design is made to finalize development decisions on how to incorporate the new UI layer into Openbravo:

Timing: throughput time 2-3 weeks

Development of new UI-Layer

To be determined. This can then be done from mid-end may and further.

Implement business logic using the Data Access Layer in the mid-tier

The next step in the development of the data access layer is to implement business logic using the Data Access Layer concepts. There are two types of current business logic which can be moved to the java layer:

The proposal here is to first move stored procedures to the java layer. As this development plan assumes that the current UI remains untouched a choice can be made to not remove stored procedures but to add their java implementation to Openbravo. The current UI can then still use the current stored procedures. While the new UI makes use of the new java-stored procedures.

Regarding triggers it is slightly more complex. The triggers need to remain in the system to support the current UI. There are two possibilities:

  1. for 2.60 do not implement triggers in Java
  2. implement triggers in Java but maintain them for the current UI and make it possible to automatically disable triggers when Hibernate connects to the database.

The second option is feasible and only requires a small change in the trigger code.

From a project planning perspective it can be best to start this effort with one stored procedure (for example create invoice from shipments). The experience with this implementation should then be used to develop generic components relevant for business logic. In addition a focused developers guide should be written. The guide can be used for additional implementations (by people outside of the platform team). So for the Platform team planning the assumption is made that only one or a few stored procedures are re-implemented by this team.

Improve Application Dictionary

During the 2.50 phase a number of areas were identified on which the Application Dictionary should be improved:

The actual changes first have to be designed and then developed. The exact timing can not be defined at this point.


The current Openbravo middle-tier consists of servlets which directly call specific java classes. This approach has the following drawbacks:

Conversations: stateful web applications

Traditional servlet web application have three scopes: application, session and request. This means that data can either be stored globally (for all users - application), for a user (e.g. the login is stored in the session), or when a page is opened or clicked (request). There is one scope which is missing in this list: conversation or dialog scope. The conversation scope allows the application to keep data over multiple page views of a user. Having conversation scope has the following great technical benefits:

These technical benefits translate in the following functional benefits:

Without an explicit conversation scope it is very difficult to implement these type of functionalities.

Customizing business logic

In the 2.60 release we will be moving business logic to the middle-tier. The business logic is implemented in java classes which are instantiated by a servlet or by other classes. In the current Openbravo approach the instantiation (the creation of a component/class) occurs with the new operator:

MyBusinessLogic procedure = new MyBusinessLogic();

In this case the caller/user of MyBusinessLogic is tightly coupled to the implementation of the business logic, nl. the MyBusinessLogic class. Now assume that a customer/partner wants to make a slight change to the business logic. A first idea would be to implement this by creating a subclass of MyBusinessLogic which has this small change. However, then the real issue arises, it is difficult for the developer to actually let Openbravo make use of his custom subclass: CustomBusinessLogic as Openbravo hard-coded instantiates one specific object (MyBusinessLogic) and not the custom version. To overcome this disadvantage there are two approaches:

MyBusinessLogic procedure = OBFactory.getInstance().create(MyBusinessLogic.class);

The OBFactory can then at runtime be configured to return an instance of CustomBusinessLogic, this is valid as this class extends MyBusinessLogic.

In general it makes sense to make use of standard dependency injection/factory containers instead of creating our own factory implementation.

Other reasons for using a standard middle-tier framework

Middle-Tier solutions

In general one can say that there are two main solutions for the middle-tier:

  1. Seam
  2. Spring

Both solutions are stable, used by many companies and have a very vibrant user community.

A summary which touches on the main difference between the two frameworks: Spring is an integration framework for many popular Java frameworks whether they are web frameworks (Struts2, JSF, Spring MVC), persistence (Hibernate, iBatis) and so on.

Seam on the other hand focuses heavily on the JEE 5 technologies (EJB3, JPA, JSF) and provides tight coupling to JBoss technologies (Drools, jBPM, RichFaces).

After a short analysis and discussion with several people, here is a list of pros of each of the two frameworks. The pros of one framework are the cons of the other.

The pros of Seam:

The pros of Spring:

Background links related to seam/spring: [TO BE DONE: comparison]

Define the technical database model in the Application Dictionary

The technical database model is now defined in xml files which are used by the DBSourceManager to create and update the database schema. This information (the technical database model) can also be maintained in the Application Dictionary. This has the following advantages:

Next to defining the technical database model in the application dictionary also the logic which creates and updates the database model should be integrated into the current Openbravo application. It will probably make sense to re-use the current logic and for example generate the xml used by the DBSourceManager from the technical database definition in the Application Dictionary.

From a project perspective this task needs to be first designed (functional/detailed design), implemented and tested. The design phase will take approx. 1-2 weeks. The implementation phase can be estimated later.

Make Openbravo Reporting easier to change/edit by end-users

The main goal of a new integration with a (new) reporting tool is to make it easier to let end-users create and change reports in Openbravo without needing to contact consultants. Currently we support Jasper Reports, the idea is to research if we can support other open source reporting tools as well. Other options which should be researched:

The following steps can be done as part of this task:

Translated Business Objects and the Data Access Layer

In Openbravo 2.50 there is no explicit support for translatable business objects. Translatable business objects are business objects for which the data itself can be translated into a specific language, an example is the Country which has a translated CountryTrl equivalent. There are two situations were it makes sense to show/use translated data:

To support these cases the Data Access Layer should offer an api which returns the translated version of a business object or a set of business objects.

The total development effort to accomplish the above is fairly limited and can probably be done as part of the overall UI re-development.

Re-design security model

The Data Access Layer currently makes use of the window_access information to determine to which tables a user has access (read/write and derived read).

In the 2.60 release the access and authorization definition and use must be made much more detailed, granular and flexible. For example:

While designing the new security model attention should be paid to the question if certain access checks are done in specific layers of the system (for example read access in the UI layer).

This development task requires a thorough design phase before implementation can start.

Improve Job system

In Openbravo 2.60 it should be possible to directly define a job from a (process) window. This makes it possible to create a job using parameters defined by the user.

Other aspects of the 2.60 Job system:

Specific attention should be paid to support of date fields which are part of the job parameter sets, for example sometimes it makes sense to automatically move the date after a job has run.

This task requires a functional design to be done before the development can start.

It should be decided if the required changes are done for the new UI, the current UI or for both.

Improve Test-driven Development Practices

In the 2.60 release Openbravo should further extend its test-driven development practices. More specifically time and resources should be spent on the following tasks:

Optimistic Locking

Database locking is important when two or more users open the same data, then change it and save the data to the database. In Openbravo 2.50, the save action of the last user will overwrite all changes of previous users. To prevent this the concept of optimistic locking should be implemented in Openbravo. Optimistic locking is a standard feature of Hibernate. It requires that every table gets an additional column to keep a version number.

Conversations (described above) will result in longer periods over which users work with in-memory data. This means that in a new UI implementation (supporting conversations) it is even more important to use optimistic locking.

The proposal here is to only support optimistic locking in the new UI and not change the old UI.

Improve Import Client to handle very large datasets

The current Import Client procedure reads all data in-memory before committing it in one transaction to the database. This means that the import client function is usefull for setting up initial clients (as the dataset is comparably small, like the demo data). However, if the copy client function needs to be used for backup and restore functions then the current logic will not work. It needs to be decided if export/import indeed needs to support backup scenarios. If so then the following changes should be made:

Modularity Improvements


Some ideas:

Points from the product backlog

These are topics of the current Platform team product backlog which are not explicitly included in the above sections. We have to decide what fits where in the development plan for 2.60 and under which sections: Prepare a mechanism to update demo-data dates to a current date (current demo-data is from 2006). It should be consistent (accounting, duplicated data such as dateordered, ...)

Retrieved from ""

This page has been accessed 7,592 times. This page was last modified on 17 May 2009, at 11:33. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.