In my last post, I wrote about the new HTML 5 features and how can these new features be a revolution in the ecosystem of current web applications. But I do not want to stop here without exploring a little bit about the possibilities of combining these new HTML 5 features with Openbravo ERP.

The plan is to start a series of posts with the objective to create a prototype of a web application for hand held devices like iPod Touch and iPhone, oriented to mobile users of Openbravo ERP.

The requisites I am imposing to myself for this prototype are the following:

• It will be an HTML application and take advantage of HTML 5.
• The application will run in an iPod Touch or iPhone, because these devices are broadly available, can be considered "cheap" for this task, and also because it is a device I love :-). It also will run in Firefox 3.5 for debugging purposes.
• It will consume standard Openbravo ERP REST Web Services. Nothing else than a fresh Openbravo ERP community edition will be needed.
• The application must be capable to work online and offline without any loss of functionality, just the need to work without the latest data available. It will be required when working offline, to cache data and to store data. And refresh the cache data and send stored data when the device is connected again.
• The functionality developed should be "useful".
• It should be just a prototype. Not expend too much time, handling exceptional behaviours, errors. Just make it work.

In this first development iteration I created a very simple application for sales men to allow them to have the list of products with details like the category and the unit of measure of the product (UOM). And with the ability to change there prices shown between all price lists available. It works completely offline and has the ability to refresh the data when the device is online.

I plan to publish the source code after polishing it in the Openbravo forge under the Openbravo Public License with small instructions to install it. In the mean time here you have screenshots of the application working:


In the next steps I plan to build a simple form to submit sales orders and also I would like to display charts. And if you have suggestions about how to improve this prototype I will be glad to hear them.

Disclaimer: The project I am developing here is done in the personal investigation time I have reserved during development sprints and it is not in the roadmap of Openbravo ERP and there is not commitment from Openbravo to his partners, customers or community related to the availability or support of this project.

Openbravo ERP has currently two major versions: 2.50 is the latest one and it’s actively developed. 2.40 is a maintenance release for Professional Edition users, and it mainly consists of bug fixes, with an average of 20 fixes per month.

These 2.40 updates are distributed as Maintenance Packs (MPs – a collection of bug fixes), with a frequency of one month during the first year and of two months during the second one (since November 2009). Starting from 2.40MP11 we are introducing a new concept of MPs. Instead of releasing bi-monthly updates we will release them on a bi-weekly basis, tested and verified by our Continuous Integration Framework. This is the workflow that this automated process follows:

• Mike reports an issue and it gets assigned to Ken, a Openbravo ERP developer.
• Ken fixes the issue and pushes the commit into the 2.40 Mercurial repository.
• Our build farm runs a set of tests on that changeset:
  • Incremental update test on PostgreSQL and Oracle. This is important to test updates to this changeset.
  • Full clean builds on PostgreSQL and Oracle. This is used to test new installations based on this new changeset.
  • Verify the database consistency. This verifies that the database model matches exactly its definition in the XML files.
  • Functional tests on PostgreSQL and Oracle. This runs a set of graphical on a web browser, powered by Selenium.
  • Other minor sanity tests, such as checking that no database data is entered using the reserved ID ranges.
• If all the tests pass successfully, we tag and sign the release in the Mercurial repository, and later on replicate it into our Subversion mirror. If one test fails the system waits for new changesets and starts the process again.
• Mike gets notified about the availability of a new MP that includes a fix for the issue he reported.

These kind of MPs are easily identifiable by it’s version numbering, following the 2.40MPX.Y schema. As an example, we currently have released four, called 2.40MP11.1, 2.40MP11.2, 2.40MP11.3 and 2.40MP11.4.

What does this mean for a 2.40 user?

• We are reducing the delivery time. You get maintenance updates every two weeks.
• You get updates of the fixes you reported faster than ever.
• You update your 2.40 installation using the usual method (Subversion), this does not change.

Note that we are also planning to release two more “traditional” MPs during the 2.40 life cycle, that will consist of additional manual verifications. They will be called 2.40MP12 and 2.40MP13, scheduled for February and August 2010 respectively. Here’s a table that summarizes the 2.40 MP frequencies:

Version	Release date
2.40MP11	November 2009 (already released)
2.40MP11.X	Bi-weekly
2.40MP12	February 2010
2.40MP12.X	Bi-weekly
2.40MP13	August 2010

Tagged: Continuous Integration, QA, Release process, Releases

I am happy to announce that a new version of the module Initial Data Load 1.1.0 is now available.

Initial Data Load is focused to Openbravo ERP partners and customers that aims to reduce the time needed to deploy a fresh Openbravo ERP installation simplifying the import of all master data and operational data needed to start working with Openbravo ERP. This can save a lot of time in the deployment of Openbravo ERP for the following reasons:

For Openbravo ERP, two of the characteristics that differentiate the Community Edition and the Professional Edition are the life cycle guarantee and the bug fixing guarantee.

Community Edition users are expected to stay current with our product evolution and therefore to upgrade to the next version of our product to receive maintenance.
By contrast, access to packaged maintenance on a stable version for an extended period of time is a commercial service offered as an exclusive benefit for Professional Edition customers. We call this service the life cycle guarantee.

In practice this means that as a Community Edition user, you can expect Openbravo to fix defects that you report but, in general, the defect will be addressed in the development code line and made available to you as part of the subsequent major version. Community Edition users can receive the fix by either upgrading to the next version when available or manually transplanting the fix to their own code line.
For example, if 2.40 Community Edition users were to log a defect today, we will fix it in the 2.50 based development code line and users would either need to upgrade to 2.50 or perform a manual transplant of the code change to their environment.

By contrast, as a Professional Edition customer, you have subscribed to a service that gives you the right to receive a fix for any defect that impacts you directly in the version that you are using. This means that Openbravo will not only address the fix in the development code line but will also create a backport to the stable code line of your version and release a professionally tested maintenance pack. This way Professional Edition customers can consume maintenance without having to upgrade or develop a backport themselves.

In addition to the life cycle guarantee, the bug fixing guarantee ensures that defects affecting Professional Edition customers are addressed in a timely manner and according to specific service level agreements.

The combination of these two services, life cycle guarantee and bug fixing guarantee delivers a very significant value proposition for Professional Edition customers and contributes to the peace of mind that users can expect from a professionally backed open source solution.

Going back to my earlier example, if a 2.40 Professional Edition customer were to log a defect today, not only we will fix it in an expedited manner (the bug fixing guarantee) but we would also backport the fix to 2.40 and release a new 2.40 maintenance pack (the life cycle guarantee). Thanks to this service, the customer would simply need to apply a maintenance pack in order to receive the fix.

In past versions of Openbravo ERP, like 2.35 and 2.40, we have been applying this principle by making the maintenance code repository for those releases private and releasing periodic maintenance packs. The packs are initially publicly available to the whole community and when the release reaches a stable state, they become private and available only to Professional Edition customers.
For example, in 2.35 maintenance packs 1 (MP1) to 5 (MP5) were made available to the Community; at that point we deemed that the release had reached a stable status and subsequent packs - MP6 to MP16 - were made available only to Professional Edition customers only. In 2.40, however, we felt that the product was stable enough from the beginning and all maintenance packs, from MP1 to the latest MP11 (released in November 2009), have been exclusively available to Professional Edition customers.

In 2.50, however, this approach is no longer valid. In this release we introduced modularity support and this allows us to deliver a significant number of functional enhancements as modules, separate from core. Because of this, the development code line for core is very stable and we have not felt the need to create a separate maintenance code line. We think that we will not need to create one for several more months.

Since maintenance happens in the development code line and Openbravo strongly believes that for an open source solution the development code line must be open to the community, how do we provide the life cycle guarantee to Professional Edition customers only?

Up to now, we felt that 2.50 maintenance packs, which are released in the form of a module update, packaged as an OBX file, had to be publicly available. This was both because the release, similar to 2.35, had to go through a stabilization phase (this was a motivation up to 2.50 MP3, after which I would consider 2.50 sufficiently stable) and because we still had to add a number of capabilities to our modularity infrastructure in order to fully support the activity of our ecosystem. We wanted the maximum number of Community Edition users to have access to those capabilities in order for them to be able to easily produce and consume modules.
As of 2.50 MP8 (released on October 30th, 2009) we have completed that infrastructure. We then publicly released an additional maintenance pack, 2.50 MP9 (December 1st, 2009) and from this point onwards we do not see a compelling need to release additional 2.50 maintenance packs publicly.

Therefore, the next maintenance pack, 2.50 MP10, will be exclusively available to Professional Edition customers. System administrators of the Professional Edition will be able to go to the Module Management window, perform a scan for updates to discover the availability of a new maintenance pack and download and apply the update directly from that console (reminder: we always recommend to execute this operation in a test environment before applying a maintenance pack to a production environment).

System administrators of the Community Edition performing the same operation will receive a notification that the access to the maintenance pack is reserved for Professional Edition users and will be invited to acquire a subscription license and activate their system in order to proceed with the update.
Community Edition users in version 2.50 will be able to update their installation to the latest code version by accessing the main Mercurial code repository.

We intend to continue with this approach until the next major version is published. At that point, we will recommend Community Edition users upgrade to that version if they want to continue to receive maintenance. At the same time, as a service to our Professional Edition customers, we will establish a private maintenance code repository and we will backport fixes there allowing them to stay in production on 2.50 for an extended period of time after the release of the following version, while continuing to enjoy the benefits of the bug fixing guarantee and receiving packaged maintenance.

This policy is summarized in the table below.

	Community Edition	Professional Edition
Available from source code repository	Yes	Yes
Life cycle duration	Until the next release is available	Extended guarantee
Available as packaged OBX file	No	Yes
One click update from the Module Management window	No	Yes
Bug fixing warranty	No	Yes

We are proud to announce the immediate availability of the Openbravo ERP beta package for Ubuntu 9.10 Karmic Koala.

Earlier this year, Openbravo increased its line up of deployment options by making an Openbravo ERP server available as a package for Ubuntu 9.04 Jaunty Jackalope.

This option proved to be very popular and resulted in more than 2000 unique installations during the first month alone. Leveraging this package Ubuntu users have been able to setup a working Openbravo environment for either either evaluation or production purposes with just one command. Additionally, customers of our Professional Subscription offer have been able to acquire a fully supported Ubuntu stack at a very competitive price.

We are now in the process of making this deployment option available for the latest version of Ubuntu, 9.10 Karmic. Not only this package will support the latest Ubuntu version but it will also include several improvements based on the experience we gained with Jaunty.

Finally, this package is the first step to include Openbravo into Ubuntu’s next long term support release, Ubuntu 10.04 LTS Lucid Lynx.

We plan the production availability of Openbravo ERP for Karmic in the January 2010 time frame. Today, however, we are proud to announce its immediate availability in beta status.

This beta package will allow us to improve the quality of the final release of the package, so we encourage you to test and provide us feedback.

This is a beta package, so keep in mind these important notes:

• Do not use it in production environments.
• The official release of this package is scheduled for mid-January.
• This beta package is built with Openbravo ERP 2.50MP9, but the final package will have Openbravo ERP 2.50MP10.

The instructions to test the package:

1. You should have a running Ubuntu Karmic installation.
2. Add the Openbravo ERP PPA’s GPG key to your apt keyring:

   sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C2F11D81
   

3. Add openbravo-erp launchpad repository URL’s:

   sudo sh -c 'echo "deb http://ppa.launchpad.net/openbravo-isv/ppa/ubuntu karmic main" >> /etc/apt/sources.list'
   sudo sh -c 'echo "deb-src http://ppa.launchpad.net/openbravo-isv/ppa/ubuntu karmic main" >> /etc/apt/sources.list'
   

4. Update the apt-get cache:

   sudo apt-get update
   

5. Install the openbravo-erp package:
   • By command line:

     sudo apt-get install openbravo-erp
     

   • Using graphical interface:
     Search in Synaptic for openbravo-erp.

Compared to the Jaunty version, these are the features included in this version of the package:

• Don’t compile at install time, ship binaries. It reduces the installation time.
• Add Apache and connect with Tomcat using the mod_jk connector. So that now Openbravo ERP is accessed from http://ip_address/openbravo and we can use the fine tunning of Apache (e.g. gzip compression enabled).
• Add the BigBazaar sample data, with a lot more data to test the Openbravo ERP functionalities.
• Use PostgreSQL 8.4.1 instead of 8.3.8. With this we’ll start our 8.4 support in Openbravo ERP.
• Manage our PostgreSQL database cluster in the Debian/Ubuntu way: using pg_cluster. With this feature you can start/stop openbravo-erp cluster with pg_ctlcluster start/stop 8.4 openbravo-erp. To list the status of the clusters you can use pg_lsclusters. Also you can still use /etc/init.d/openbravo-erp-postgresql script.
• Removing the package without the purge option now maintains the database and the sources. In the previous version of the package maintains the database, but for avoiding inconsistencies between the sources/binaries and database, now it is maintained the sources/binaries and the database.
• Centralized directory to read all the logs from our stack, (PostgreSQL, Apache, Tomcat, mod_jk). You can find all this logs at /opt/OpenbravoERP-2.50/logs.
• Clean and simplify the installation output to make it shorter and to display only the most relevant installation points.
• Secure the Tomcat Manager to allow connections from the ERP only.
• Ability to update every part of the package except for Openbravo ERP.   So the apt-get upgrade command will update your  Tomcat, PostgreSQL or Apache configurations for Openbravo ERP, but will not update your Openbravo ERP version. The ERP updates are managed through the Module Management Console inside Openbravo ERP.

And the fixed issues:

• Installation hangs in localized Ubuntus (#435412, #410182, #442484)
• Fixed JAVA_HOME issue when updating Core.
• Global variables are correctly set if user openbravo already exits. This perform a backup of the existing /home/openbravo/.profile in /home/openbravo/.profile.bak
• (many other minor fixes)

We’re very excited with this package, help us fine tuning it for the final version!

Gorka

UPDATE:  see the list of known issues

(EDIT: fixed the command to add the repository URLs to sources.list)

These are the latest news from the Release Management Team:

2.3x discontinued

Important note! The 2.3x version of Openbravo ERP has been discontinued:

• We have removed all the continuous builds involving 2.3x from our build farm.
• It’s no longer possible to report bugs against this version in our issue tracker.
• The wiki documents related to 2.3x have been marked as deprecated.
• The Mercurial code repository is permanently frozen.
• The 2.3x installers have been removed from the SourceForge download area.

I would like remind you that if you’re running a Community Edition installation you should always be in the latest major release. Currently this means 2.50. Running an old major version is possible of course, but the voluntary support you get in the forums is provided on the latest major release. The professional support is offered in all the major releases: 2.3x, 2.40, 2.50 until now and 2.40, 2.50 after this 2.3x end of life.

So this means that if you’re running 2.3x you should seriously consider upgrading to 2.50 as soon as possible. If you have problems during this process you can either post your question in the forums, which is run by volunteers, or contact your closest partner to get professional support.

Continuous Integration: graphical upgrade test

We have a new job in our build farm that really makes a difference: perform an upgrade using the Module Management Console, starting from the last release Maintenance Pack and using to the latest daily Core OBX module. This test is now a prerequisite before merging changesets from pi to main.

It’s been developed using Selenium by the QA Team (thanks for that!) and we have adapted and integrated it into our continuous integration framework.

New issue tracker statuses

Soon we’ll have 2 new statuses in our issue tracker: Ready for integration and Ready for QA. They will be placed before the Resolved status. With this change we increase our compromise with the quality of the product. Because this means that we won’t consider an issue to be resolved until our Continuous Integration and QA Team have tested them. Check the rationale behind this decision or check the new workflow in the following graph:

Issue tracker and build farm integration

Every time a changeset is successfully promoted to erp/devel/main we automatically generate an Core OBX file out of it. Now we have integrated the issue tracker with our build farm so that a note is added with information regarding when this promotion happened, in what changeset and how to get the generated OBX file. See issue #11470 to see this in action.

For a complete list of the on-going stories we’ve been working on, check the Sprint 29 page of our Scrum spreadsheet.

Tagged: Continuous Integration, Issue Tracker, QA, Releases, testing

The end of the year is near and we in education department are in full span of preparing plans for the next one.

We are very happy with the enrichment of our online curriculum made in 2009. Nevertheless, we know there is always room for further improvements and innovation.

That's why we're calling upon you to submit ideas and cast your votes for courses and materials you would like to see in the upcoming year.

Help us improve and innovate Openbravo curriculum by visiting http://obeducation.uservoice.com/ and dropping an idea or a vote.

We look forward to hearing from you,
Rok Lenardic
Senior Training Specialist

Functional Design: This module is developed on top of Openbravo ERP core and loads the regions or states which belongs to India. India has union of states comprising of 28 states and 7 union territories. Basically this module will have these states and union territories of India. Anyone can download and install this module to view the regions of India.  Click here to know more on Functional Specification.

Technical Design: This is a simple design of the Indian State module which has been developed with the dependency of Core module and it is defined as an extension module. Find below the technical content of the design document.

1. Module Creation
2. Data Feed
3. Dataset
4. Exporting the Module
5. Packaging the Module

Note: An example has been included in HowTos section under “How to create dataset” link.

Conclusion: The Indian States extension module will act as an independent module. The country India already exists in theCore module but there are no states (Openbravo ERP refers this as Region) available. So this new module will have the states of India like TamilNadu, Andra Pradesh, etc in the Region Tab which comes under General Setup || Application || Country Region and City || Country.

1. In Openbravo Module Manager window do a scan for updates. You will get available updates for core module (2.50 MP9) and at least for any of those modules if you had installed them
2. You have to “Apply all” updates together

Managing Reference Dataset is a new functionality based on Modularity Project. Its goal is to be able to provide some module information, apart from the development, so the user gets the module fully installed when applies the module.

But as many other developed functionalities, Reference Dataset can be also used in many ways. For example:

- If you are preparing your final environment and few users introduce valuable information on your testing environment, using Reference Dataset is very easy to move master data from one environment to other one.

- I guess it could also be useful for off line synchronizations between disconnected OpenbravoERP instances or between two any applications. For example, having PDAs as routers.

What ever is your situation:

- Create a module, and check “Has reference” check box to “Y”.

- Set up a reference data, type Organization. Define tables and columns you want to include or exclude.

- Export reference data, it will create a XML file.

- Export the database.

- Export the module.

- Import the module on your destination environment.

- Go to Enterprise module management (General Setup-Enterprise) and import reference data.

Of course, some improvements can be achieved to simplify this process. For example allow exporting and importing XML files without having to manage modules. It is already registered as feature request.

There is also some more documentation available.

Do you have any other situation where reference data is useful?