View source | View content page | Page history | Printable version   

Projects:Backup Tool/Technical Specification



This document will analyse the different options to implement the backup tool, and compare them.

Options analisys


Model 1

In this model the backup tool consists of three parts: the code itself and two web interfaces to access the functions, one inside Openbravo and other a web page external to Openbravo.

The three components:

All the functionality should be in the webservice. The external UI and the module UI don’t implement nothing except to call webservice external functions and display its results.

This model require an authentication for users using the web page external to Openbravo.

Backuptool Model1.png

Model 2

This model is based on a Command Line Interface tool that can be called directly and has all the functionality inside. Also has a module inside Openbravo that can access to its functionality.

Backuptool Model2.png

Programming language

In both models all the files are shipped inside an Openbravo module. The part of Openbravo GUI will be done in Openbravo standard way of do windows (WAD or manual).

And the common part for the functionality of the backups is where can be many options:

The external part is where can be many options:


This option is more compatible with the model 2, since with bash generate html pages is not very usual.




Is the language used in Openbravo and this add these extra features:






Options chosen


The model chosen is the second: the Openbravo module with the option of use from the command line.

This model is very much simpler than the other and also system administrators will not have any issue with use the command line instead of a web page.

This model don't need to implement a authentication method for the users that access to the external web/webservice when Openbravo is not available.

The determinating point here is that the tool is intended to be used always from inside of Openbravo, and when Openbravo host has a not recoverable issue, then make a clean install of Openbravo in another host and restore the last backup from Openbravo interface. Taking into account this, the easier way is to put all the functionality inside the Openbravo module and allow the command line interface to access directly to the functionality inside the module.

Programing languages

The natural choice is Java since is an Openbravo module. But always having a separation between functionality and interface in order to allow the command line to use its methods.

The use of Java provides its error control and the ability to run it in all the platforms that run Openbravo without needed to install anything.

The use of Java is more oriented to the use of the tool from the Openbravo interface to call the methods. In the other hand, this makes the call from the command line more tricky.

Another advantage of use Java is that there are a lot of libraries and we think that will be someone to support to write into different file systems without the need to mount it at operating system level.

In any case it's not a definitive election, since it is possible that the implementation of the backup (list directories, create a zip, uncompress the zip, restart tomcat/apache, make a dump of the db and restore the dump) probably are easier to implement in bash.

Retrieved from ""

This page has been accessed 1,828 times. This page was last modified on 8 June 2012, at 05:26. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.