Openbravo ERP 2.50 has a time based release plan. This helps us get bug fixes and new features into our user’s hands more quickly and improve our planning process.

Up to now we’ve been releasing Maintenance Packs on a monthly basis. However we have detected some improvement areas, mainly two:

1. We want to release like a clock:  same time, same day, every month. Everyone gets benefited by this:
   • End users appreciate knowing the release dates without even reading a release calendar. They simply know that they’ll have an update at the end of every month.
   • Our engineering team can organize more effectively: developers, QA, Support, Release Management.
2. Developers should know what commits they push go into what release. This way they can organize their work more efficiently.

So let’s start! We already have the list of desired improvements and we know that we need to set the key dates. So first we need to identify the different kind of events involved in the development process:

• Regular commits (e.g. bugfixes or small features).
• Large project merges (e.g. a new large feature).
• QA automatic tests.
• Feature freeze for the release.
• Release packaging.
• QA manual tests.
• Publish the release.

Now we need to set some dates and deadlines. The QA manual work – bug found – fix it loop lasts around 10 days. So the freeze and packaging should be before the 20th. And we want to provide a guarantee to developers, so that they know which commits go into what release. Here’s a proposal:

• All the commits pushed before the 15th of a month will go into that month’s release. We’ll make sure all the tests are passed, working together with the developers in case there’s a failure.
• We’ll freeze the code the 18th and start the packaging right after this moment. This means we have 3 days to make the code pass all the automatic test suite. It should be more than enough. It also means that commits pushed between the 15th and the 18th might go into that month’s release. If it passes the tests of course.
• From that moment on QA can start the manual work. If they find issues the affected developer will work on the fix and they’ll iterate on this process till QA happy is happy with the result.
• Afterwards the Release Management team can publish the release.

And last but not least, project merges tend to create instabilities in the code main line, compared to having no reintegrations at all. So taking this into account the project merges must be done a specific time frame: from the 22nd of one month until the 5th of the next one. So that we give it enough room (10 days) to get the code stable for the freeze time.

We can see these policies summarized in the following graph:

Improving a release process is usually an evolution, not a revolution. And I believe this is the first step towards better timely releases.

Tagged: Release process, Releases

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

Three months ago we started the beta testing of this package, asking the community to test it in this post. Now, thanks to the testing made by many of you, the package is ready for production. But this does not stop here, the karmic package is also the foundation for an upcoming package for Ubuntu 10.04 Lucid Lynx.

This package simplifies the Openbravo ERP installation in Ubuntu for production and testing environments. You can install it with a few clicks:

1. Go to the new Ubuntu Software Center, and search for openbravo. Then double-click in Openbravo ERP to select it.



2. Once selected click on install. In a few minutes it will be installed, configured and ready to be used. Simply go to
   http://localhost/openbravo
   to start using it.

There are two requirements for this installation: the first one is to enable the partner repository, and the second one is update the Ubuntu Software Center (more specifically the app-install-data-partner package).

These are list of changes from the beta package:

• Update Openbravo ERP sources to 2.50MP11.
• The logs files can also be found  in /var/log/openbravo-erp.

In order to get more information, including other installation methods, you can take a look into the Openbravo ERP Ubuntu installation documentation.

We are very excited with this new package. Enjoy!

It is usual when developing or on production environments to include improvements on your OpenbravoERP instance. Therefore it is needed to deploy a new war file.

Although it could sound obvious, many of us usually stop tomcat service, and erases old deployed sources on webapps. Then new war file is copied and tomcat restarted.

In order to be more efficient and reduce the time tomcat takes to stop and start, it is better to also stop/start apache services. I mean, stop httpd, stop tomcat, copy war file, start tomcat and start httpd. It looks like it should take longer, but it doesn’t. Apache takes short to stop and start, and having Apache stopped, Tomcat stops faster.

This way the interruption will be smaller. Both when developing or on production environment.

Callouts are a piece of client logic in Openbravo ERP designed to be executed whenever a field changes and as a result changes parts of a tab/window without the need of refreshing it.

The logic performed by a callout is executed by a java servlet and you can use SQLC or DAL to access data. After the code has been written you only have to associate the callout to the column or columns that trigger the callout, and recompile the windows where this callout is used.

The problem for developers is that callout servlets have a lot of boilerplate code that is very similar in all callouts. This code is not related to the callout logic and makes it dificult to understand and maintain callouts.

To help here there is a new java class has been introduced to simplify the code of callouts and keep focused only in the logic and not in the plumbing needed to make the callout servlet work. This class is SimpleCallout and to develop a new callout based on this class you only have to create a new java class that extends SimpleCallout and overwrite the following method:

protected void execute(CalloutInfo info) throws ServletException;

In this method you can develop the logic of the callout and use the info object of class CalloutInfo to access window fields, database and other methods. The most important are:

• public String getStringParameter(String param) : This method returns the value of a field named param as an String.
• public String getStringParameter(String param, RequestFilter filter) : Returns the value of a field named param as an String using the filter to accept values.
  
• public BigDecimal getBigDecimalParameter(String param) throws ServletException : This method returns the value of of a field named param as a BigDecimal.
• public void addResult(String param, String value) : This method sets the value of a field named param with the String value indicated.
• public void addResult(String param, Object value) : This method sets the value of a field named param with the value indicated. This method is useful to set numbers like BigDecimal objects.
• public void addSelect(String param) : Starts the inclusion of values of a field named param of type select.
• public void addSelectResult(String name, String value) : Adds an entry to the select field and marks it as unselected.
  
• public void addSelectResult(String name, String value, boolean selected) : Adds an entry to the select field.
• public void endSelect() : Finish the inclusion of values to the select field.
• public String getLastFieldChanged() : Returns the name of field that triggered the callout.
• public String getTabId() : Returns the Tab Id that triggered the callout.
• public String getWindowId() : Returns the Window Id that triggered the callout.
• public VariablesSecureApp vars : This instance field contains the VariablesSecureApp associated to the callout servlet.
  

You can find an example of a class that currently uses SimpleCallout to implement the logic of a callout. The class is SL_Project_Service. This callout just takes the numeric value of two fields, calculate the sum and writes the result in other field. This is the interesting part of the code that performs the logic:

@Override
protected void execute(CalloutInfo info) throws ServletException {

    BigDecimal serviceSerCost = info.getBigDecimalParameter("inpservsercost");
    BigDecimal serviceOutCost = info.getBigDecimalParameter("inpservoutcost");

    BigDecimal serviceTotalCost = serviceSerCost.add(serviceOutCost);

    info.addResult("inpservcost", serviceTotalCost);
}

SimpleCallout is currently in the pi repository of Openbravo ERP, there has not been released any version with this class included. It is not also part of the Openbravo ERP public API and until it is not included here you cannot rely on it because could change without notice. If you find that this class is interesting to be included in the public API, let me know and I will push to include it and extend it with more new functionality and functionality from other Callout helper classes.

by Renate Nieuwkoop
Senior Education Specialist at Global Partner Services

After a successful launch of Foundation Certification programme last year, we are now happy to announce the first Graduate Exam. The Functional Graduate Certification has been made widely available starting February 26, 2010.

Since the launch of the Foundation exams, many partners have become certified and can now progress to the next level to become certified at a Graduate level.

Certification is essential to end customers, partners and us at Openbravo for several reasons:

• Assures customers of your knowledge, skill and credentials
• Shows tangible evidence of your ability
• Adds to your credibility in the Openbravo ecosystem
• Allows Openbravo to set a brand standard and monitor the quality of our partners

Whereas the Functional Foundation knowledge can be mastered through participation in the Basic Functional Training, the Graduate exam is going beyond that and is based on knowledge that can only be gained through practical use and implementation of the Openbravo ERP application. The objective of the Graduate exam is to demonstrate the ability to configure and use the application in a real life scenario.

For more information about the Functional Graduate Certification, please click here. For any questions, do not hesitate to contact us directly at training@openbravo.com

You may have noticed that the Localization Team in Spain have started a new series of blogs on "Building a Localization Pack".
I want to take a moment to stress the benefits of actually doing this (creating a pack) , both to users of Openbravo ERP and to the developers of modules that could be packaged.

For end users the benefit of downloading a pack is that they have confidence that they are getting a complete solution within that pack. The end user doesn't necessarily know whether there are 2 or 20 modules that make up a particular solution (like a localization pack for a particular country), so the concept of a "pack" is very reassuring to them. They know if they select the pack they are getting a complete solution.

Clearly if there are actually 20 modules that make up the solution then the pack is also a great time saver; the user has the benefit of not having to hunt around and select the 20 different modules they think they might need...the pack is a quick and easy "one stop shop" for them to select.

As a developer you also benefit from knowing that your users are installing everything they might need, but there is also the increased recognition that offering packs brings. Our intention is to promote packs more visibly. As an example you will notice that the Spanish Professional Localization Pack features first on the list under the "Localizations" tab on the Exchange. The name of the seller is also prominently displayed to the right of the pack name. So, quite simply, creating packs is one way to increase your own visibility within the Openbravo community.

There is also guidance on combining localization modules into packs on the Localization pages of the Openbravo Wiki.

Good Luck and Good Packaging!

Cloud Computing services offer a great deal of advantages to end users and sysadmins. I’m sure most of us appreciate not taking care about the hardware, having agility to provision new resources, getting the ability to recover fast from disasters, taking benefit of a very high network bandwidth speed, and so forth. It’s a very good solution for many situations.

However managing a Cloud is different compared to the traditional server management. We have been using Amazon EC2 in Openbravo for the last couple of years, so I would like to share some tips with you with regards to backup management and recovery.

DNS management: Elastic IPs

Making backups is the first step towards a successful system recovery. But in order to take benefit of these backups it is also essential to react in a quick and easy manner when something goes wrong, so that we have the system is back up and running in a matter of minutes.  One of the biggest delays tied to the traditional server management comes with the DNS changes. That is, migrating to a new machine usually means having a new IP address. And therefore it forces you to update the DNS records, and this might take days to propagate.

Amazon has a nice feature called Elastic IP that allows you to forget about this. You basically allocate an IP address for you, so that you can assign it to any of your machines “on the fly”.

Think about the difference:

1. Traditional DNS management: if a new server gives me a new IP I have to change the DNS records.
2. Elastic IP DNS management: I can assign my IP address to any of my instances.

The first option might take several days to be spread in the entire world, while the second one is immediate.

EBS: persistent storage

Amazon EC2 has continuously improved the features they offer. One of the limitations it initially had consisted of the fact that the hard drives where not persistent. That is, if you shut down a machine you lose your data. In September 2008 Amazon introduced the EBS hard drives (Elastic Block Storage), which means persistent storage that essentially works like a normal hard drive that you can attach to any of your instances. However you could not run the entire operating system in one of these EBS drivers. In any case this was a big step forward, given that you could save your critical dynamic data (e.g. a database) in a persistent storage. Starting from December 2009 you can finally run an entire operating system in a EBS unit.

This feature is relatively new so most of the public AMIs are still based “instance-store”, instead of in “EBS-store”. The recommendation here is incremental:

• Make sure you save your critical dynamic data in a EBS drive.
• If possible, run the entire instance in a EBS drive.

I’ve just said that it works similar to a regular hard drive you can attach to any instance. This is not entirely true, it’s better: you can make snapshots of the entire disk. As many as you want, and they are incremental. You can of course restore them into a new drive any time you want.

So as a last tip with EBS do regular snapshots, and make sure you purge the old ones.

Off-site backups

There’s a golden rule with regards to backups: “Do not put all the eggs in the same basket”. It is very unlikely for Amazon EC2 to suffer a general downtime or disaster so that you would loose your data (e.g. a fire). They make sure this won’t happen and they do their backup homework as well. In any case it is generally a good idea to have a second recovery plan, physically isolated from your main backup location.

Amazon EC2 currently has two independent regions (US and EU), so the first option is to replicate the backups from region to another. However if a malicious user gets your EC2 credentials they might have temptations to wipe out all your data in both regions. To avoid this, as a recommendation, create an extra EC2/S3 account with complete read-only access to the first account. So that your backups cannot be compromised in that way.

If you are more paranoid than this, you can schedule weekly or biweekly backups to an external storage service provider.

Physical backups

It is sometimes very useful to have a recent backup available with you at your office. One option is to download it. But depending on the size of your backups and your network speed this might be prohibitive. Amazon has a nice feature called Import/Export that covers this need:

• You send a hard drive to them with instructions.
• They load the requested data into the hard drive.
• They send you the hard drive back.

Openbravo ERP and EC2

OK, those tips sounds reasonable. So what should I specifically do with my Openbravo ERP instance in EC2? Stay tunned, a new post will be coming soon covering this topic.

Tagged: Cloud computing, EC2

by Jorge Monfort
Senior Consultant at Global Partner Services

When you are facing an Openbravo ERP 2.40 to 2.50 upgrade project the first thing you need to consider is what the real purpose of this upgrade is and what your client's expectations are.

The upgrade process, in fact, entails converting core customization into modular extensions and the effort required to perform this task greatly depends on the degree of re-use that you want to achieve.

For most companies, who have customized 2.40 for their own usage and do not have an interest in sharing their extensions, the scope is limited to a straight technical upgrade. On the other hand, if the client wishes to obtain reusable modules that can be distributed through the Central Repository or sold through the Openbravo Exchange, more work is required.

At the extreme end of complexity, you will find the case where the client wants to achieve a complete and fully packaged and reusable vertical solution.

I recently worked on such an upgrade and I would like to share here some lessons learned in this project. Let's try to analyze these different scenarios and the impact of each one of them.

Case 1: Single company that just wants to upgrade to 2.50:
There are many reasons for upgrading to 2.50

• To take advantage of the new functionality included in the 2.50 version
• To leverage the easy maintainability experience of the modularity platform
• Due to the sunset of their current Openbravo ERP version

In this case, just an upgrade could mainly fulfill the expectations. The Openbravo ERP upgrader would create a single extra module including all customizations, and after some adaptations and manipulations we could enjoy a real 2.50 implementation, always taking into account that this module wouldn't accomplish the necessary naming rules required to be able to publish it in the Openbravo Central Repository or in the Exchange.

Apart from this first simple scenario we could think of enhancing it by re-factoring our big module into smaller ones to simplify its maintainability in production environments and reduce the effort of resolving future potential bugs or naming conflicts (reviewing and updating a small module will always be easier than having to create a new version of the whole big industry template module). It would involve creating new modules and moving some customizations from the original big module (mycustomization module) to these new modules.

Although we should always take into account the significant increase in effort required, it would also constitute a pre-step to future module reusability which will lead us to case 2.

Case 2: Client that expects to commercialize his customizations
In case our client considers that customizations implemented for them could have commercial relevance, or just thinks that it could be a chance to recoup their investment, we should take some specific actions in order to be able to publish them in the Openbravo Exchange.

• In this case, re-factoring into independent modules is a must. That means a higher investment but it is justified by a commercial return.
• Adjusting to Naming Rules would also be a must in order to guarantee that our modules are fully compatible with others published in Openbravo Exchange. This task also implies a big effort for renaming all our customizations.

So, notice that all this judgments need to be done and scope should be clearly defined before starting the project because it has a clear impact in the effort load calculation and in reaching the client's expectations.

Advance Payables and Receivables Management is a new workflow for the users that increase the speed and ease of doing their receivables and payables.

This development with respect to the existing “Payment” workflow and it should be able to use their process without reconfiguration.

We have also created a test instance for the community to work around with this project / workflow. Click the link as mentioned below with the credentials of demouser / demouser.   http://79.125.67.45/openbravoengdev/security/Login_FS.html

Please find the link for the user guide / demo script to work around with this project.

And you can post your doubts and comments in our forum Online appliance


Hi all,

The Openbravo’s Platform Team is happy to announce the next webinar in our series, “New Selectors”. It will be held on next Thursday March, 11th from 16h to 17h (CET).

The session will be time-boxed to one hour with the following agenda:

• Overview
• Module functional demonstration
• Technical architecture – Focused on SmartClient integration
• Q&A

You can join the session through this link:

http://openbravo.emea.acrobat.com/r96401077/

If you have never used Adobe Connect Pro before you should test your connection in advance:

http://openbravo.emea.acrobat.com/common/help/en/support/meeting_test.htm

The session is open to everybody but limited to one hundred (100) participants. Attendees will be accepted from 15:45 (CET).

This webinar will be recorded and published in the Extension Module Demonstrations Videos section of the Openbravo Developers Guide.

We look forward to see you in the session.