Projects:Modulescripts ERP Version Update Expose/Functional&Technical Specifications

Contents 1 Introduction 2 Functional requirements 3 Technical requirements 4 Performance Requirements

Introduction

The objective of this project is to provide a mechanism that will allow modulescripts to identify whether they should be executed when performing an upgrade.

Functional requirements

Prior to this project, the modulescripts did not have the ability to identify the version where their logic should be applied when upgrading the ERP system. As a workaround, a preference was created for every modulescript in order to check if it had been executed before.

The functional requirement of this project is to provide an easier and more transparent approach that will allow developers to set a dependency for a modulescript with a particular module in order to determine if it should be executed or not during an upgrade (See image below).

• First Execution Version: defines the first version since the moduleScript should be executed. Before an upgrade, if the dependent module has a version lower or equal than this version, the moduleScript will not be executed. By setting this limit we are ensuring that this version and previous ones do not require the module script execution.

• Last Execution Version: defines the last version of the dependent module for which the moduleScript should be executed. Before an upgrade, if the dependent module has a version higher or equal than this version, the moduleScript will not be executed.

Technical requirements

The technical requirements of this project consist of two parts:

• Modulescript API: provide an API that can be used to set a dependency between a modulescript and a particular module version (this module will be usually core, but it could be another module). This dependency means that when upgrading from a version higher than a limit version, the modulescript will not be executed. To achieve this, two new methods are going to be included in the API. Modulescripts sub-classes (those classes that extends ModuleScript class) will be able to override these two methods in order to define their own limit dependency:
  • getModuleScriptExecutionLimits(): this method returns a ModuleScriptExecutionLimits object with the information of the module we want to establish the dependency with. This entry contains the module UUID and the first and last versions of that module which defines when the modulescript should be executed.
  • executeOnInstall(): this method can be overridden to specify if the modulescript should be executed when installing the dependent module. If not overriden, this method always returns true by default.

• DBSourceManager: adapt the code in the DBSourceManager in order to retrieve the current version for each module into a list, before performing the upgrade. This information will be used to identify whether modulescripts should be executed or not, according to their particular dependency (if any).

Performance Requirements

The performance requirement of this project is not to impact on the execution time of some build tasks affected by this change:

• update.database
• update.database.mod
• import.sample.data

Also, the possibility of avoid modulescripts execution during this tasks should help to decrease their execution time.