Does your company perform sales – purchases between internal organizations? Do you need to create matching documents for those flows? The Inter-company Documents module is the solution you are looking for! What are inter-company documents? An inter-company document is an order or invoice created within two subsidiaries of one same company. Whenever a document of […]

Need to modify a core Procedure? Some times while we are developing a new functionality or customizing an implementation for a customer we get stuck having to deal with existing core procedures that we shouldn’t modify. This happened to us recently while we were developing the Intercompany Documents module. In this module it is needed […]

Human Capital Management capabilities are now available in Openbravo ERP! Human Capital Management module is intended to provide solid base employee information management capacity so further human capital management functionality can be developed on top of it. The module adds a Human Capital Management folder to the main menu that contains windows to manage employees, […]

As some of you may know we are currently prototyping a new user interface library. As part of the development for the new user interface we have developed a JSON REST webservice module.

This module is a very good example on how you can extend the Openbravo webservice functionality using Openbravo modularity. It shows how easy it is to extend Openbravo not only when coding your functionality but also when configuring your services (extending web.xml and other configuration files).

JSON is a light-weight data-exchange format used extensively for client-service communication in web based applications. The JSON REST module is similar to the standard Openbravo XML REST webservice in that it makes Openbravo information available through a webservice supporting CRUD operations.

The module can be downloaded from the forge here or can be installed from the central repository. After installing the module and restarting Openbravo you can try out the webservice directly. For example enter the following url in the address-bar of the browser:

http://localhost:8080/openbravo/org.openbravo.service.json.jsonrest/Country/100

This call will retrieve the Country business object with id 100 as a JSON string. You can save the returned content and open it in a text editor. The JSON will look like this:

{"_identifier":"United States","entityName":"Country","$ref":"Country\/100","id":"100","client":{"_identifier":"System","entityName":"ADClient","$ref":"ADClient\/0","id":"0","active":true},"organization":{"_identifier":"*","entityName":"Organization","$ref":"Organization\/0","id":"0","active":true},"active":true,"creationDate":"2009-10-26T19:20:06","createdBy":{"_identifier":"System","entityName":"ADUser","$ref":"ADUser\/0","id":"0","active":true},"updated":"2009-10-26T19:20:06","updatedBy":{"_identifier":"System","entityName":"ADUser","$ref":"ADUser\/0","id":"0","active":true},"name":"United States","description":"United States of America","iSOCountryCode":"US","hasRegions":true,"regionName":"State","phoneNoFormat":"Y","addressPrintFormat":"@C@, @R@ @P@","additionalPostalCode":false,"default":true,"language":{"_identifier":"English (USA)","entityName":"ADLanguage","$ref":"ADLanguage\/192","id":"192","active":true},"currency":{"_identifier":"USD","entityName":"Currency","$ref":"Currency\/100","id":"100","active":true}}

Each of the properties of the Country object is present for example. client, id, iSOCountryCode etc. Openbravo JSON REST adds some special properties: _identifier and $ref which can be useful on the client. Each foreign key reference is also represented in a special way. for example the Country refers to the English (USA) language, the reference to that language is represented like this in the JSON string:

"language":{"_identifier":"English (USA)","entityName":"ADLanguage","$ref":"ADLanguage\/192","id":"192","active":true}

the 'language' is the property of the Country then within brackets the information of the language object itself is present. Adding this information in the returned JSON string has as advantage that it is not needed to do extra requests from client to server to display all the details of the Country object (including referenced objects).

The JSON REST service also supports query and paging parameters, some examples:

• http://localhost:8080/openbravo/org.openbravo.service.json.jsonrest/Country: this will return all countries
• http://localhost:8080/openbravo/org.openbravo.service.json.jsonrest/Country?_startRow=10&_endRow=50&_sortBy=name this will return 40 countries (rows 10 to 50) sorted by name
• http://localhost:8080/openbravo/org.openbravo.service.json.jsonrest/Country?name=United&_textMatchStyle=startsWith this url will return all countries which start with United (which are for example United Arab Emirates, United Kingdom and United States).
• http://localhost:8080/openbravo/org.openbravo.service.json.jsonrest/Country?_where=currency.iSOCode='USD' returns all countries which have a currency with the isocode USD. The _where parameter can contain a valid HQL where-clause. contain all the clauses supported by HQL.

See the JSON REST Developers Manual for more details on the querying capabilities and on the format of the returned information. The JSON REST module uses the same authentication and authorization functionality as the XML REST webservice functionality and the data-access-layer.

The JSON REST service also supports insert, update and removal of information. To insert a new Country you have to post a message like shown below to the Openbravo application and use the POST HTTP method. To try this directly in your browser you can make use of a Firefox plugin like poster.

{data: {"entityName":"Country","active":true,"name":"Test","description":"Test Country","iSOCountryCode":"ZZ","hasRegions":true,"regionName":"State","phoneNoFormat":"Y","addressPrintFormat":"@C@, @R@ @P@","additionalPostalCode":false,"language":{"id":"192"},"currency":{"id":"100"}}}


You see the result below. The system replies with a response JSON object which contains all the data of the inserted Country. The important one to take note of is the id.


We will be using the id in the next step to update the name of the Country to a better one (if you try this your self, the id will be for sure different!).

{data: {"entityName":"Country","id":"FF80818124923C2C0124923D39A80002","name":"My Great Test Country"}}

The response will return the complete JSON object with a status code (0 for success).

Then to clean up, let's delete the newly created country. Use this url (replacing the id part with your id) and do a DELETE HTTP method request:

http://localhost:8080/openbravo/org.openbravo.service.json.jsonrest/Country/FF80818124923C2C0124923D39A80002

A response with status 0 is returned with the deleted object as the data entry. This clean up action concludes this short tutorial. I hope you found it interesting.

As always we welcome feedback. We will be using this module as part of our new Openbravo user interface development and extend it further based on new requirements.

Hi all, this is the first post of the Tips & Tricks category. In the articles of this category we will share with all of you the tricks that we have learned over the years working in Openbravo and we’ll give you tips that might make your life easier working with Openbravo ERP. Lets start […]

As explained in my previous post, a new verification has been added before compiling WAD windows to detect possible errors.

The problem has appeared with the “Identifier verification” which forces all the tables used in the tabs to be generated to have at least one column set as identifier. This is strictly mandatory just in case the table is a part of a foreign key, but as now modules expose all their tables as part of their public API, we decided to force all tables to have identifier. But as before it did compile, it is possible there were modules with tables without identifier.

To solve this problem, now the verification does not stop the compilation process in case errors are found, but it is highly recommendable to fix them in your modules as soon as you see them to prevent possible incompatibilities with other modules. In a future core release, this check by default will stop the process, in case it is not successful.

Posted in Openbravo Tagged: build process

Although developing automatic windows in Openbravo ERP is quite straight forward and saves a lot of coding time, in case something goes wrong it can be difficult to find out where the problem is. Of course you have the compilation log, but this is not always as user friendly as it should be. In many occasions, it is quite hard to figure out the root cause for the error. It must be inferred from a ton of lines of log and some times it fails in a place that it is not expected, for example a missing identifier for a table can cause a SQL error.

Currently we are working on improving the build process, and one of the improvements we are putting in place (it is already pushed to pi) is a verifier that is run before generating WAD windows, this verifier will check a number of common mistakes that make the tabs not to be properly generated and will display a clear message about this stopping the process.

The idea is to gradually include new checks to this verifier, now we just look for tables without identifier and for tables without primary key. Any feedback on which checks would be useful is welcome.

I hope this makes life a little bit easier to Openbravo ERP developers.

Posted in Openbravo Tagged: build process

Like in any other team, some of the tasks we do in the Release Management Team have consequences in users, other times in developers and some times even in other company staff. We feel it’s important to notify other teams about what has been done. Not the progress or the future plans, we have Scrum of Scrums for that. But about the actual specific results.

So this is a simple as this: whenever there’s something new we think it could useful to a specific groups of users we’ll write a short summary to them. This will happen every 2 weeks.

Continuous Integration

• There’s a new set of tests called erp_sanity_tests. This intends to collect various basic checks that are not worth to keep as a single Hudson job. As for now there’s one included, to Check if the primary keys of the database in erp/devel/pi that were present as columns in erp/stable/2.40 have a onCreateDefault value set.New tests are accepted either by describing them to us or by sending us the code to be run.
• The QuickStart and Module Installation jobs have been moved from slave1 to slave2. We currently have 4 machines for builds.openbravo.com, and with this change one 100% dedicated to smoke tests.This affect developers in the way that now smoke tests will be finished quicker without interruptions from other jobs.

Ubuntu package

There was a demand for instructions on how to install the Ubuntu package with Tomcat in one server and PostgreSQL in another. This steps are currently manual and they’ve been documented.

Release Notes

They have been refactored. Now there’s a main page where you can see all the versions.

Then you can access the specific summary notes for each release. Check 2.50MP6 for an example.

And if you’re interested in more details, the Changelog page shows the complete list of fixed issues.

The 3 pages are linked. And the idea is to replace the Changelog page at some point, by delegating in Mantis to do this automatically.

Openbravo ERP API Javadoc

The Openbravo ERP API is now available for online viewing.

This includes all the releases since 2.50, as well as docs for erp/devel/main and erp/devel/pi, which are automatically updated in each incremental build of our continous integration framework.

Tagged: API, Continuous Integration, Packaging, Release process, Scrum, Ubuntu