My name is Rachel Johnston and this is my first blog post as Openbravo's technical author. In the months that follow, I'll be posting here to keep you up to date with documentation at Openbravo.

I started working at Openbravo at the end of August 2008, and as the company's first full-time author, I'm starting off by trying to address some of the immediate needs that users have identified. In particular, I'm aiming to deliver a complete configuration guide for Openbravo ERP by the end of 2008. As part of that process I'm also working on a quick start guide which covers the essentials - a small, easy-to-follow document that will make it easier for new customers and evaluators to get Openbravo ERP working "out of the box".

In the longer term I'll be completely revising, restructuring and rewriting the documentation set - including comprehensive online help. The aim is to change the user documentation from a product based approach, (describing what you can see on the interface) to a task based approach (explaining how to use the product to get things done). For more technical users, there are also plans to develop better resources for contributors and developers.

Although there is now a professional author in-house, contributions from the community are still very welcome. The wiki is still at the heart of Openbravo documentation, but the coming improvements will make better use of the material that's there, fill in the gaps and enable you to use the wiki in a more productive way.

If you have any requests, feedback or corrections, there is a Documentation thread on the sourceforge forum. Alternatively, post them here or e-mail me in person at rachel dot johnston at openbravo dot com

Woof, Woof, … the dog is not barking! is people on the office sharing files each other.
Woof is a small application for simply file exchange, based on Python. It is very simple and useful to share files with people around. Instead of sending via mail, messenger or skype, using a pendrive, … just Woof!

Have a look to this screenshot to understand how it works.

- You can see how to activate Woof.
- Once woof is executed, anyone can download the file I am sharing using the browser while you get the complete log of all downloads.

Thanks to Jaime, who talk us about it! Since them I have impressed many people with this little toy.

Openbravo ERP 2.50, freshly released in alpha status, introduces many significant architectural enhancements in our ERP platform. Chief among them is modularity support.

With modularity, developers adding new capabilities to Openbravo ERP are able to easily extract, package and redistribute their extensions. Users of Openbravo ERP, on the other hand, are able to browse public extension in a central catalog, and download and install them from there, very much in the same way that they install browser plugins.

This modularity mechanism overcomes one of the most significant limitations of earlier versions of Openbravo ERP. In those releases, users were allowed and encouraged to change and extend the core product to adapt it to their specific requirements. The problem, however, was that once developed, it was very difficult to distinguish the extension from the core. As a result, it was virtually impossible to manage the extension independently.

People wanting to distribute new functionality were essentially limited to two options:

1. Build their features directly into core in strict collaboration with the Openbravo core development team and transferring their code under the terms of the Openbravo Contribution Agreement; or
   
2. Manage an entire version of Openbravo, assuming the overhead of not only supporting their own extensions, but the full Openbravo ERP base, including core and extensions.

Modularity resolves this problem by properly separating the ownership of software artifacts within the system. Each artifact, regardless of its type (database object, meta data registered in the Application Dictionary, source code, binary library or reference data) is owned by one and only one module. It is therefore possible, literally at the press of a button, to isolate, extract and package in a reusable container any individual extension.

Once packaged, a module is contained in a single obx file, which makes it very easy to transport it and to re-use it in different environments.

Additionally, in case developers want to share their work with the rest of the Community, they can very easily publish their modules to a Central Repository. Other users are then able to browse the Central Repository in search of modules providing features that are relevant to them, and easily deploy them to their environment.

So...why is this so important and why should you care?

If you are a developer, a system integrator, or an independent software vendor, modularity enables many interesting things for you:

• Distributed development - Developers can now develop and distribute additional functionality in a totally independent manner with minimal interaction with the Openbravo development team.
• Lower barriers to contribution -  Contributing to Openbravo core is quite time consuming. Core features need to be general enough to be used by different users, in different industries and different geographies; they need to be fully aligned with the current Openbravo architecture and its future directions; they need to be multi-lingual and platform independent; they need to be tested on both Oracle and PostgreSQL; they need to be thoroughly documented, fast and scalable. All of this takes a considerable amount of effort.
  With modules, on the other hand, developers have a lot more control on the amount of investment they want to make. They can choose to do all of the above; or they can do less. They can, for instance, decide to develop a feature that targets only one industry; or to develop it in only their native language; or to support only one specific database. These trade-offs will limit their audience, but that is perfectly OK for a module and, if the modules proves to be successful, it can always be broadened in subsequent versions.
• Shorter time to market - Core contributions can only be published together with Openbravo ERP, typically in the next version of the product. On the other hand, because modules have an independent life cycle they can be published as soon as they are ready.
  
• Global reach for all contributors - Anybody, anywhere, can publish a module to the Central Repository and anybody, anywhere, can download modules from it.
  Thanks to that, module developers in our Community now have a channel to distribute their independent work anywhere in the world, taking advantage and leveraging the global Openbravo Community.
  
• Licensing freedom - Because modules are distributed independently from Openbravo ERP, module authors have the flexibility to choose their preferred license. They can distribute their work under the Openbravo Public License, but they can also choose GPL, BSD or any other license. Module authors can even choose to distribute their work under a proprietary license that allows them to commercialize their efforts.
  
• Community collaboration - Because modules are published in the Central Repository, all developers in our Community are informed of what others are doing, and can decide to reuse and collaborate instead of restarting from scratch. For example,  an ISV interested in providing an advanced Human Capital Management pack, rather than starting from ground zero, could reuse an existing personnel management module and an existing payroll module developed by other Community members. The ISV could then complete the solution by developing a brand new recruitment module, package, and deliver the whole thing as a single solution pack.
  
• Development scalability - As a consequence of distributed development, the Openbravo development team, with its limited capacity, is no longer a constraint to our Community's ability to grow and to advanced the overall value of the Openbravo ERP solution.
  
• Drive-by contributions - I first heard this term reading one of Matt Asay's posts and I immediately loved the idea. The concept is that people rarely start a project with the idea of contributing it to the common code pool of the community. In most cases, they just do something because they need it, and the success of an open source community largely depends on its ability to capture and leverage these efforts, enabling people to contribute their work while driving-by, on their way to somewhere else and without getting too much out of their way.
  One of the small but very important features of 2.50 is that Openbravo Core is itself a module, initially delivered in status "not in development", which means that, by default, it cannot be modified. While it is possible to change this default setting, now the natural behavior is to implement extensions and personalizations as separate modules. If later developers realize that what they built is of generic interest and decide to package and publish it, they can do so very simply, by just pressing a button. It's that easy, and it does not require them to plan ahead. They can do it on their way to the implementation project, without having to think twice.
  

If you are a user, modularity will bring you the following benefits:

• Broader and deeper functional coverage - Because of the points above, soon our users will be able to choose among a very large set of available modules, which will enable Openbravo ERP to support all sorts of functionality, targeting many different industries and companies of all sizes.
  
• Better localization support - We expect that our localization support - a key success factor for an ERP - will dramatically improve. Today every implementation project, in every country, needs to develop a number of custom extensions to meet local business practices. Local legal reports and declarations, connectors to local banks and support for local payment methods are only examples of things that every implementation needs to sort out. Thanks to the drive-by contribution power of modularity, all of these customizations can be easliy published as modules facilitating local communities to leverage each other's work and experience.
  
• Lower total cost of ownership and improved ROI - The broad availability of extension modules, some of them packaged as implementation templates targeting specific verticals in specific geographies, will simplify most implementations  to the selection and assembly of pre-existing compenents. Eliminating most of the effort in custom development will dramatically drive down the implementation costs, making the leading  open source ERP solution accessible to an even broader class of enterprises and further improving the return on investment for everybody.
  
• Reduced implementation time and faster ROI - Minimizing custom development will shorten the implementation time, producing a faster return on investment for all projects and allowing users to join the revolution and start enjoying the benefits of their Openbravo ERP in a shorter period of time.
  

Modularity is a very significant step forward in the progression of the Openbravo ERP project. Starting from 2.50, Openbravo, the company, ceases to be the only party with the power and authority to move Openbravo ERP forward. That responsibility is now shared with an ecosystem of users, developers, system integrators and independent software vendors that together form a fully empowered Community, able to unleash the full potential of open source.

For all of these reasons, Openbravo ERP 2.50 is a seminal release for our project. Please help us to stabilize it and quickly bring it from alpha to production status by installing it and helping us with testing. You can also experience the power of modularity by developing a module of your own: simply follow the Developer's Guide and you will be ready in no time. If you are unsure of what module to build, we can even provide you with some ideas.

In any case, do not forget to give us your feedback by posting your comments in the Early Releases Discussion forum.

Openbravo announces the immediate availability of the Openbravo ERP 2.50alpha-r1 virtual appliances. These images simplify the Openbravo evaluation process. The images are available for the VMware, Xen, QEMU, Parallels and VirtualBox virtualization systems. (0 comments)

Featuring an exciting new modular architecture, usability improvements and broader functional coverage, Openbravo ERP 2.50 is the latest release of the leading open source ERP solution. This is an alpha version and it is intended for evaluation and stabilization purposes only. Openbravo 2.40 remains our best version for production usage. You cannot upgrade an existing system to 2.50alpha-r1 and you will not be able to upgrade a 2.50alpha-r1 instance to any subsequent version. (1 comments)

Always have been said an ERP implementation project has 4 main hot issues: FIREs (Forms, Interfaces, Reports and Extensions). And I will like to go a bit further on reports issue.

As the technology has improved and new platforms have been developed new and much more sofisticated reports can be done. The users know it, and they want to have more detailed and feature full reports.

Nowadays, and from a consultant point of view, reports should be classified properly:
1- List: A list of activity or master data. Including some columns. An being able to filter by any column on the list. Not difficult to achieve.
For example: A list of all the invoices ordered by invoice date and including business partner, invoice date, base amount, tax amount and total amount.
2- Report: Detailed information, properly structured, ready to make a decision. Information filtered by dates, customers, products, organizations, etc. and also totalized per period and business partner. Not as easy as a list.
For example: A report which shows all the cash forecast depending on may pending payments and receivables.
3- Dynamic analyzers: It is not enough having the data well structured on the report. The users wants to be able to play with the data the report toke out of the system. They want to build an scenarios with data provided through all the activity, and be able to change some parameters before they make the decisión.
For example: A Dynamic analyzer where the systems puts an actual forecast, in which the user can change some parameters (credits the user may extend, or payments the user would pay later, etc.) and automatically the new forecast is build.

Thus, it is important to take into account what the user is expecting when asks for a report.

P.D: For the first two report types, Jasper is a good solution. For the third, I am investigating POI. I let you know something about, soon!

In the Openbravo Manifesto that we published in April this year, Openbravo as company leading Openbravo ERP and POS projects committed to a few principles, including meritocracy. Quoting the manifest:

We believe we should gain people's respect and recognition due to our work. We shall always make sure that everybody has access to our open resources on an equal basis and we will accept contributors based on the merit of their work and their skills.

Today we present our meritocracy policy that has the objective of building a meritocracy access system based on community members' reputation. The levels are based on people's technical abilities, skills and shown responsibility. The role names are built on the name of the (b) mark, which we pronounce "obi" (as in letter "o" and letter "b"). On top of providing more responsibility and rights to different services, these levels would be highly visibly and an important indicator of the contributor's reputation within the Openbravo ERP and POS communities.

In the future, these levels will be precomputed automatically from the different Openbravo collaboration sites. Until, this is done, we do maintain the list manually, if you think that you are entitled to be listed please do not hesitate to contact me (jmas at openbravo.com)

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 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");


Posted in Openbravo Tagged: developers utilities, modularity, r2.50

We are in the final stages of the Openbravo 2.50 development cycle and the release is getting ready to enter the alpha phase. Alpha testing will be public and open to the whole community and since we are now only a few days away from that milestone, it is time to ask for community volunteers to help us with testing.

The process is going to change from previous releases:

1. An alpha version will be published once a week. The community will have the release at the same time as the QA team ready to be tested

2. During the week the engineering team will fix the bugs

3. At the end of the week a new release will be published

4. We will not be producing installers at this time but we will be producing a virtual appliance with both Openbravo ERP and its stack pre-installed. This will simplify deployment. Alternatively, you can install on your native hardware building from sources from the alpha tags.

The goal of this alpha phase test is to validate that:

1. The product installs from sources and works on all the most important operating systems (we will certainly test Linux and Windows but we hope that you will help us in testing other platforms as well)

2. The product installs from sources and works against both Oracle and PostgreSQL

3. The product works in the virtual appliance

4. All the major flows are in working condition

5. The new features are complete and stable

If you are interested in participating in the alpha testing, you are lucky, now it is very easy so please read the following instructions:

1. Openbravo brings you a new tool to track the functional testing called TestLink

2. The URL to access it is: http://tools.openbravo.com:8891/testlink

3. Click the link New User and after creating the user then login

4. You will be in the Home page under the Community Sandbox test project

5. Under the Test Execution section link the option Execute Tests

6. You will see some filters but only two of them are relevant:

   1. Build: The build you are working with that corresponds with the Virtual Appliance or the Tag

   2. Assigned to: You must put in blank this combo box otherwise you won't be able to see anything after pressing the button "Apply filter"

7. Another thing that it is very important is to specify the environment. Please use the text field "Notes/descriptions" to describe the environment. Also please feel free to write what ever you want

8. After following the steps of the test cases you have to give a result, three options here:

   1. Passed: Everything was fine as per the expected results

   2. Failed: The execution failed as per the expected results. In this case address a bug in our bug tracker, taking in note the guidelines of how to report a bug. It would be nice if you put the link to the bug in the text field "Notes/descriptions"

   3. Blocked: The test case cannot be executed due to an issue that blocks it

9. Then Press the button "Save execution" and keep going with the rest of the test cases

All testers will receive special support during the alpha cycle and can ask their questions in the "Early Releases Discussion" forum.

I would like to remind you that participation in the testing of a new release is not only a great way to contribute to the Openbravo ERP project but it also has very concrete benefits to you:

• It is a great opportunity to make sure that the features you care about are properly working in the new version.

• It is a great way to learn all the exciting new features that have been built in 2.50 so that when the version is released in production you are ready to start taking advantage of them in your implementation projects.

• It is a great way to establish good relationships with both members of the Openbravo development team and other Community members that will be able to assist you in the future.

We look forward to your continued support to our project and your participation in this important test

Pablo Sarobe

The Development Environment ID was created to allow merging dictionary changes made by several developers simultaneously. Previously, the Development Environment ID list was centrally maintained by Openbravo.

With the inclusion of UUID in version 2.50, the Development Environment ID is not needed any more. Because of this, Openbravo is no longer going to maintain this list of Development Environment IDs.

However, if you are working on a development of Openbravo ERP in a version prior to 2.50 with several developers, you still need the Developer Environment ID. In this case, you can manage the Development Environment IDs of your project taking into account two things:

• Development Environment IDs should be five digit numbers starting by ’1′ (e.g.: 10001, 10002, 10003).

• Assign a different Developer Environment ID to each of the developers in a project. Note that the same ID could be used through different projects.

Please, do not hesitate to visit the developers forum if you have any question or suggestion regarding Openbravo ERP development.