ERP 2.50:Configuration Manual/Modules Management
Contents |
Modules Management
This document explains how to mange modules in Openbravo ERP. All module management is done through the General Setup || Application || Module Management window.
The Openbravo ERP Central Repository is the official online source of commercial and community modules that can be installed from the browser, directly into your Openbravo ERP instance.
Note: some modules hosted in the Central Repository are commercial, which means your Openbravo ERP Professional Subscription must be activated before the module can be installed. Many Openbravo-authored commercial modules are free to customers who have activated their professional subscription. Some commercial modules require pre-payment prior to installation. In this case, after payment confirmation but before installing the module, you will need to do an instance refresh.
When searching modules to install, commercial modules can be distinguished by the icon bellow the Isntall now button.
Note: active Openbravo Business Partners are issued a partner-specific, limited-used license (aka "golden key") entitling installation of all commercial modules for evaluation, testing, and demonstration purposes. As a partner, you must activate your test instance with the "golden key" that has been emailed to you, and then you will be able to install any module as documented below. Every 30 days you will need to perform an instance refresh to keep using your golden key. Additionally, you will need to do an instance refresh to install a new commercial module that has been added to the central repository since your last instance refresh.
Installation
Installation of new modules is performed from the Add Modules tab in Module Management window.
There are two possible ways of installing a module, remotely or locally.
Remote Install
Remote installation connects to Openbravo Central repository to look for the latest version available of the module to install. It pulls all the module dependencies, installing always the highest compatible version and in case it is needed, updates the currently installed modules to the latest compatible version with the modules to install or update. That's why this is the recommended way of installing modules.
You can look for the module you want to install using the Search text box. When Search button is clicked, the application will connect with Openbravo's Central Repository to look for the modules matching the criteria and will show them, in each module there is a View Details link which will open an information box about the module.
When the module to install is selected and the Install Now button is clicked, the installation process will start.
Install from File System
For those instances that are not connected to Internet or for installing modules that are not available in Central Repository, it is possible to install modules from File System.
First of all you need to obtain the module as an obx file and save it in your file syetem. The obx files for all published module versions can be downloaded from Central Repository.
Once you have the obx file, clicking the Browse File System button will open a dialog window to select the file and afterwards the installation process will start, this process is the same as the explained for Remote Installation. The only difference is that dependencies will not be installed or updated, so in case a required dependency is not included within the obx file and it is not installed in the instance, the process will stop.
Update
In the Installed Modules tab of Module Management window the modules that are installed in the system are displayed, here it is also possible to see information about the modules.
Like for installation, it is possible to update modules remotely and locally.
Remote Update
To update modules remotely, just click on the Scan for updates button. This process will look in the Central Repository for all the latest compatible versions of the modules installed in the ERP instance and will show them as update available.
When there are updates available, a message is shown next to each module and on top of the modules box.
It is possible to install the update for just one of the modules by clicking on the link on the left or the module, or to install at once all the available updates by clicking in the link on top of the box. After doing any of these two actions the installation process will start.
Update from File System
Updates through obx files are done, in the same way as installation from file system, from the Add Modules tab clicking the Browse File System button. If in this window is selected a obx file containing a newer version of an already installed module, this module will be updated to this version.
Uninstall
Installed modules can be uninstalled from Installed Modules tab.
To uninstall modules select them in the modules box and click on the Uninistall selected button. This process will remove the module from modules directory, after uninstalling modules a system rebuild is requiered.
Be aware that uninstalling a module removes everything related with the module, including user data in database, so for example if a module includes a database table, this will be dropped with all data it might content.
When uninstalling a package or template, all modules that are included within it will be also uninstalled.
Modules that participate on dependencies for other installed modules cannot be uninstalled unless the ones that define the dependencies are uninstalled as well.
Disable
 | The contents referred on this sections are available from 2.50MP21 |
Installed modules can be disabled. This is performed by selecting the modules to disable and clicking on the Disable selected button.
When a module is disabled all the features it defines are not longer accessible. But unlike uninstalling it, the module remains installed so no user data is removed from database and new updates for this module can still be installed (though the module will be kept as disabled).
Enable
| | The contents referred on this sections are available from 2.50MP21 |
Disabled modules can be enabled again by clicking on the Enable link that appears next to them.
Enabling a module will make all its features accessible again.
Installation Process
Installation process is executed as part of module install, update or uninstall (see above), it is composed by two tasks: install and rebuild. The execution of these two tasks are necessary to completely install the module, but is is possible execute the second one delayed on time from the first one. Furthermore, it is possible to execute several times install for different modules and to rebuild the system just once for all of them.
Install
Module installation consists on downloading obx files and extracting them to the modules directory. So when this task finishes, the source for the modules are in the system, but they are not still applied to the instance.
This process is executed in a pop up window and involves four steps:
- Information about the modules to install or update is shown. These modules will be the ones selected for install or update and for remote install/update all the required dependencies that need to be installed or updated.
- Next step will be reading the licenses for all the modules to be installed or updated.
- After accepting these licenses the modules indicated in first step will be downloaded and installed in your system.
- Finally, it returns to the Installed Modules tab where it is possible to launch the rebuild task.
Rebuild
| | Be aware that this step will end existing user sessions! |
After a module is installed or updated it is required to rebuild the system to apply its changes. Modules in this status are shown in Installed Modules tab.
By clicking on any of the links next to the modules with pending changes or on the click on top of the modules box. The rebuild process will start, it includes two main steps:
- System rebuild. Database is updated with the information the module contains and sources are compiled and deployed to tomcat.
- Tomcat restart. If the previous step was completed successfully, it is only pending to restart tomcat or reload the context to make effective the installation.
Advanced settings
Advanced settings can be configured from Settings tab of Module Management window, in most cases it is not necessary to change the defaults for these settings.
Allowed Maturity Status
| | The contents of this section are available form 2.50MP20 |
Maturity status is a property module versions have which is used to define their life cycle. The value for this property is defined by the module owner.
Introduction
During the life of a module, it can be at different maturity statuses in Central Repository. The maturity status for a version should be promoted after passing some tests and/or being used for some time in a real production instance. Setting the maturity for a version is up to the module administrator.
The possible values version maturity status can have are:
- Test: This status is intended to be used for versions that have not been completely tested. A version published with this status should be installed only in instances which desire to test it, generally to provide feedback to the module administrator/owner. Versions with this maturity shouldn't be installed in production environments. Not recommended for production purposes.
- QA Approved (ex. Controlled Release): This second stage is for versions that have been deeply tested and it is ready for production. The module owner feels confident with it, but he wants to have some maturity period before he tags it as Confirmed Stable. It will become available for the instances of this module early adopters, where it can be installed for production. Recommended for production purposes to early adopters.
- Confirmed Stable (ex. General availability): It is the final stage for a version. It is supposed to have passed the two previous ones, so it is tested and it has been working during some time in production instances. It is available for every instance and can be safely installed for production. Recommended for production purposes to all users.
- Canceled: Canceled versions are not available to be installed in any instance.
Allowed Maturity Status in ERP
| | By default only Confirmed Stable versions can be installed in Openbravo ERP instances. Instances in a version prior to 2.50MP20 will not be able to install versions with a lower maturity status. |
It is possible to define a different minimum maturity status for versions to be installed or updated than the default Production.
This is controlled by 3 parameters that can be changed in the Settings tab of the Module Management window:
- Update Minimum Maturity: It is the minimum accepted maturity status for updates of already installed modules.
- Install Minimum Maturity: It is the minimum accepted maturity status for installing new modules.
- Module Specific Minimum Maturity: Apart of the two global settings described above, it is possible to overwrite module by module their accepted minimum maturities for update. This can only be set for modules that have already been installed in the instance. In case a module has a specific value, it will prevail over the generic ones. Note that modules contained inside of packs or templates are treated can have different levels of acceptance, so in case it is desired to have accept for all the modules inside a pack a level different than the global one, it will be necessary to add for each of them a specific value.
Important note: If the level of Install global setting is lower than the Update one, it will be possible to install modules having a maturity level, which in case a new version with the same level is published, will not be updatable. To allow updates at this level, it will be required to add a new specific setting for this module.
To better illustrate how it works you can visit the User Stories section of the project functional documentation.
Overwrite Dependencies
| | The contents of this section are available from 2.50MP21 |
| | Overwritting dependencies is risky and should only be done in case you are completely sure about it. |
Module owners can define different types of enforcements for dependencies and they can also decide whether they are user overwritable.
Enforcement for dependencies defined as User Editable Enforcement can be overwritten from Settings tab.
In case any of the modules installed in the instance defines a user editable enforcement, this dependency will be shown in the Editable Dependencies section of Settings tab. User is able to change the enforcement for this dependency, once it is selected a different enforcement than the original one (marked as Default), it will overwrite the default one and it will be used when calculating compatibility between modules (both locally and in central repository). If the Default setting is selected, dependency type will be the one defined by the module version and the instance will not overwrite it.
In this way it is possible to freeze a module version making not possible to install newer major versions for it, or in the other way around it is possible to relax dependencies making compatible a newer major version for a module that the owner has not defined as compatible yet.
Be aware of the risk of overwritting dependencies, specially in the case of relaxing them, because in this case, central repository could provide updates for modules that have not been tested to be compatible and it could be possible they not to work with the installed versions.
| Languages: |
ERP 2.50:Configuration Manual/Personalizing Openbravo ERP | ERP 2.50:Configuration Manual/Configuration changes that affect the Core module