At the QA team we have been playing for a while with Selenium Grid, a great tool to run Selenium tests in parallel.

The first task was to reduce the execution time of the Smoke Test Suite having more than one browser running the tests. This is a complex suite with a lot of dependencies, so there's a limit on the parallelization that is possible to achieve. Pablo Luján prepared a graph to explain this a little better:

Even though we have reduced the execution time of 114 tests from 160 minutes to 90 minutes. And we are working on some options to reduce this even more.

Now that the integration of our testing code has been thoroughly tested we are ready to promote the changes from the experimental branch to the stable one. But this change will require some adjustments on the jobs and scripts.

We have new components: a Selenium Hub and one or more Grid Remote Controllers. The Remote Controllers register themselves with the Hub and wait for requests. The Hub will send tests to idle RCs or queue them if none is available. And the RCs will execute the actions on his browser.

In order to execute a suite on the Grid, the first step will be to create a Firefox profile for each Remote Controller. Otherwise, all the browsers in a machine will share the Openbravo session, a bad idea because the tests involve starting and closing sessions many times. The following command will create a new profile named rc1:

firefox -no-remote -CreateProfile rc1

Then, the Selenium Hub has to be started:

ant seleniumhub.start < /dev/null &

After that, start the Remote Controllers with an instruction like:

ant -Dport=5555 -DseleniumArgs="-firefoxProfileTemplate /srv/hudson/.mozilla/firefox/g2jc2ulk.rc1"

And finally, run the test suite and enjoy your successful tests:

ant test.integration.smoke -f src-test/com/openbravo/test/integration/erp/testsuites/smoke/build.xml.

More details can be found at the wiki. And we have documented there some options to execute tests sequentially as before.

The second task with the grid will be to use it with independent tests that can be fully parallelized. So if we have 100 tests on a suite and 100 Remote Controllers, the whole suite will be executed... really fast :) More about this tomorrow...

Hi,

Skinning Openbravo ERP to fit a company's corporate colors is usually a required task in an implementation project. Let me show you a few easy steps to start creating your new skin and seeing the effects from the beginning.

What Im going to do is to create a skin that for now, only changes the user logo in the login page, and the Openbravo logo in the application.

Step 1: Follow the steps to create the folder structure of your new skin module

At the end of this point, the result should be something similar to this.

Step 2: Edit the Openbravo_ERP_250.css file and state that you want both images ( User logo and Openbravo logo ) to be used from inside your module and not for the standard skin.

Note that any other image you want to change ( usually the green colored bars ), should follow the same guidelines as this examples.

Now put the modified images in your folder structure.

Step 3: Create the skin module inside Openbravo ERP

Step 4: Compile, restart tomcat, and see results ;)

Have you made your own skins? Thought it was a difficult task? Think again!

Release Candidate 1 is our first step towards Openbravo ERP 3.0. It is an early release that is comparable to a pre-alpha release. It gives a sneak peek into what is coming in 3.0 but be aware that this release candidate is largely incomplete. In fact it contains only 39% of the functionality we plan for the 3.0 core delivery. It sports tabs, quick launch menus, a new application menu and a first stab at the My Openbravo portal page. In addition to the new GUI, we also introduce:

• A narrowed down scope based on the key flows
• New standard roles (discuss)
• Redesigned financial flows, including advanced payables and receivables management (discuss)

View some screenshots, read the release notes, download the virtual appliance, run it in our demo instance online (Openbravo/openbravo) and discuss it all on the early release forum. Enjoy!

"Knowledge increases by sharing"
The need that triggered me to search for this was to recommend Hardware as well as Software configuration to support 100-200 concurrent users on Openbravo ERP and postgres/Oracle as the database.
Coming back to the main point:
Postgres doesn't support too many users (concurrent) by default, it comes with very solid configuration aimed at everyone's best guess as to how an "average" database on "average" hardware should be.
Postgres has some default configuration options to fine tune it, like:
- max_connections
- shared_buffers
- effective_cache_size
- etc etc.
In a reply of my query to postgres performance mailing list, I came to know about connection pooling.
One and the only con that I saw in this is that it is external, I mean we have to configure an external tool to do connection pooling.

We were working using Selenium for several years now, and our experience is great. Selenium is flexible, powerful and easy to learn.

We have the Smoke Test running as a required step for code promotion in Continuous Integration release cycle.

However, we are looking for moving the Selenium tests earlier in the ERP’s development cycle. Here we face one of the biggest drawbacks of our tests: They were developed thinking in a full execution starting from scratch.

That is, test cases depend of successful run of previous test cases in order to execute. A first snapshot of these dependencies appeared when we worked in parallel execution .

Now the following scenario. I am a developer and I made a fix that could cause some instability in Production module. I should not make the commit and wait CI’s email about the result, not to say waiting for QA’s standard testing cycle, nor a customer after the fix was included in some release.

Release Management team has done a very cool feature, named “Try” and we would like to add something else. Instead of executing an “all-purpose” test, we look for specifics suites.

So, in the example, even if we know that only Production module could be affected by the change, current available test would only allow a full run. Could the Production Smoke suite be executed separately? Well, yes. We added some extra capabilities to our suites by combining standard Selenium scripts with DBUnit scripts. The concept is quite simple, as explained in the DBunit’s web page:

DBUnit is a JUnit extension targeted at database-driven projects that, among other things, puts your database into a known state between test runs.

A DBUnit script will be executed before launching the Selenium script, and it will do the required changes in order to fulfill the Selenium script preconditions. Then, the test case is executed as usual.

DBunit data is created using XML files containing the rows that will be used by the next script. This has a complicated issue. The DBUnit part should be created in a safe way, meaning no interferences with current data are allowed. So static XML files were not enough. We created tags where dynamic data was required and then made that dynamic data parameters so we could use them as part of the next tests.

The result of this work can be seen at pi-dbunit branch . Currently, there is only an small set of tests available, and that is because generating the XML files is a hard task, requiring deep knowledge of Openbravo’s DB structure, table names, triggers and constraints.

Our goal is to have a full set of tests for every major module in the ERP, making easier to make specific testing in a very fast way.

Just for info: A full DBUnit+Selenium execution in Production suite could take ten to fifteen minutes. Currently, it takes ten minutes… but you have to execute one hour of tests before getting there.

Openbravo would like to congratulate Spain on a great World Cup victory.  It was well-deserved and a testament to the team's patience, stamina and skill.  They stayed  true to their philosophy, and did not waver from a proven strategy--even after an upset loss in the first match.


As a global company with origins in Spain, Openbravo is proud of this landmark achievement, and also the way it was achieved.  I think there is a lot that companies can learn from the hard work,  perseverance and interdependence of the Spanish players.  I also see many of the same underlying attributes in Openbravo’s team and extended  ecosystem, and I know that similar perseverance, execution, and faithfulness to our open source strategy will ultimately yield great results for Team Openbravo. 


¡Felicidades España!

For several weeks we were working on infrastructure improvements. In order to make more reliable our Department’s processes, and now that parallel execution is ready to run, we also automated the test of our own code.

One of the most critical processes in our automation cycle is the testing of the code we deliver. We work in several branches, and we have to assure a proper integration in order to execute Hudson‘s ERP-CI jobs in a reliable way.

Our goal was to use the same approach the ERP has. All in all, Automation and the ERP are both development projects, so what has proved to work great for the ERP has to be also good for Automation. So we mounted our test contexts in Hudson. The infrastructure is a simplified version of current ERP structure. We use to develop several branches, as many as our projects require. Smoke Test is the project, but there are other projects as well.

Name assignment for the branches was not easy. We got three levels of branches: Development, Product Integration and Stable. And the stable branch was required to run either in ERP’s PI and Main branches.

Tagging revisions for selecting the version that will run with PI and for Main would be the most logical choice. However, it would be inefficient. Since ERP branches for PI and Main are different, Main branch is updated in bulk (when Continous Integration tests passed) or through individual transplants. That means that, potentially, a transplant could change the behavior of the ERP, making the tag for the Automation useless.

So, we choose to use two branches to match the ERP layout. And for easy understanding, stable branch that is executed against Main is named Main, and the one for PI, PI.
That lead us to the next problem. Since we took the PI name for one stable branch, another name has to be chosen for the Product Integration branch. And we decided to use “int” (for Integration).

Finally, development branches have a simple naming convention: pi-* (i.e. pi-smoke, pi-regression, pi-localization, and so on)

All these branches are periodically synchronized using the Integration branch (int) as a hub. When Integration branch is considered stable, code is promoted to PI branch.

Once there, PI branch’s control is taken by Release Management team, in order to assure that proper Automation version is executed with any given ERP version. The Automation PI branch is considered stable, and it is used to test an ERP PI branch. If test passes, ERP code is promoted to Main branch, and Automation Main is updated to that version of Automation PI. That means that an specific version of the stable automation code is “frozen” so it can be executed successfully as many times as required.

If a new version of the ERP (in PI branch) requires testing, Automation PI will be used. And if ERP behavior changed for some expected fix, a change in automation could be developed and promoted to PI without changing the code in Main.

It could happen also a more complex scenario. When QA team is testing a Maintenance Pack candidate, that is last Main branch revision, could happen that a change were required (i.e. a defect was not properly fixed) triggering a transplant. The developer push to ERP PI a new changeset for fixing the issue and Release Management team transplant it to Main branch.
In that case, the automation code will remain the same, since it is expected that ERP behavior will remain unchanged. However, there is a small chance that the fix changed the behavior on purpose. So a fix in the automation branch should be pushed and then transplanted as well to Main branch, allowing a successful execution of the changed Automated Test.

At this point, we got a huge improvement by automating part of the deploy cycle. In next weeks we will add another cool feature (also inspired in current ERP’s process), automatic code promotion. The plan is to have a deamon monitoring the Integration branch. Whenever it detects a commit coming from any of the development branches, it will run a series of tests. If all of them succeed, code will be considered stable and code will be automatically promoted to stable PI branch.

Do you you want to try our automation code? Get the selenium code here or go through our documentation at Openbravo’s wiki

Simple, real-time business intelligence by manipulating grids

Reporting is an essential part of everyday business and therefore an essential part of an ERP. Today´s businesses need relevant, up-to-date, accurate and consumable metrics that help them make the right decisions. Traditionally, reports are generated once in a while (month, quarter) and are exported to PDF for printing & annotating or Excel for further manipulation. Reports are used in presentations and meetings to look at past performance, understand the status quo and project future performance. The danger lies in the choice of dimensions and the interpretation of the data. Reports are static and generated as a one-off document with a set of dimensions, normally defined by a ready-made SQL query or via a visual query builder. Openbravo´s Sales Dimensional Reports allow the user to choose a number of filters and dimensions and even the sorting order can be set. This works well if the user knows in advance what metrics she is looking for and what data set she wants to look at. The drawback is that it does not allow analyzing the data in realtime by changing the filters and dimensions and looking at the impact on the results while doing so.

A while ago, in the Family Grid, I have presented a fairly abstract idea for basic business intelligence functionality by combining parent and child data in one grid, joining grids and filtering and aggregating columns. Now, I´d like to show you a more simplified version of this idea.

The Family Grid II scenario (download it here) lets the user view sales orders in one grid and a set of order lines for all of these in the other. Both the sales order grid and the order lines grid can be filtered on any attribute using column filters. Columns containing numerical values can be aggregated (sum, count, average, median). The grids can be joined (inner or outer join) with the click of a button which, for example, lets the user find all sales order that contain a certain product (or all sales that do not contain that certain product). Final result sets can be exported to Excel or PDF and the view (which is in fact a query rather than a report) can be saved for reuse.

It should be noted that this approach does not intend to replace traditional reporting because many SQL queries just cannot be build using the Family Grid. However, I believe that this way of manipulating grids is very powerful and can lead to insights that can be hard to discover using traditional one-way reporting. Playing with a data set in real time using parent and child grids, filters, aggregations and joins with an easy-to-use GUI lets non-expert users unlock the power of data in an ERP without having to invest in hi-end business intelligent software.

Are you as convinced as I am about the business value of this feature? Discuss it here.

By the way, we´re not happy with the name of this functionality. Family Grid does not cover it really. What about RapidGrid, GridSift, PowerGrid, Data Distiller, Metrix, EasyAnswer, RapidAnswer, IntelliGrid, "Openbravo RapidEdge Edition – the fastest way to start a competitive edge", "PerfectGrid - the fast & simple way to your information"?