Projects:Modularity/Technical Documentation

Contents 1 Export process 1.1 Algorithm 2 Configuration script 2.1 Configuration script definition 2.1.1 Script elements 2.1.1.1 Backwards compatibility 2.1.2 Script files 2.2 Exportation tool 2.2.1 Algorithm 2.2.2 Dependencies 2.3 Exporting a customization

Export process

Algorithm

• Export DB objects
  • Export DB objects: Create object filters based on module name and export following this filters. These filters could be designed as pairs of prefix and path. In case AD information about module and physical name do not match show a warning, another approach would be to guarantee this at db level with check constraints (it would not be possible to create a table in a module if naming rules are do not match). A module cannot add a mandatory column to a table that is not part of that module.
• Export AD components
  • AD components are defined in DB, a filter must be created taking into account this definition. The elements to be exported are the tables that have a AD_Module_ID column and its childs (looking to the isparent column) in a recursive manner. This means that for ad_tab table the ad_model_object and ad_model_object_mapping tables will also be exported. Additionally some tables (ad_elemnt, ad_textinterfaces?) do not have ad_module_id column but will be exported in all the modules that have an element that reference them, this is clear for ad_element table but not for ad_textinterfaces because this one does not have a db link between elements. These filters would replace the current ones for sourcedata.
    • Exceptions: There are some elements which value is not exported as is, but as an expression. These elements are ad_treenode (for menu entries), ad_field.seqno, ad_tab.seqno. For all them it is necessary to decide what and how will be the done. (dbsm/dal...?)

Configuration script

Configuration script definition

Script elements

The elements that can be part of a configuration script are a limited set of database attributes. These elements are the only ones that can be within a clean configuration script. In order to allow more complex customizations the rest of elements can be exported as dirty configuration scripts.

In order to define which elements are script ones all the columns in the dictionary will have a check that will indicate whether the column can be part of a configuration script.

Backwards compatibility

When a script element becomes a non-script element the scripts containing this element will warning the user saying he is importing as clean something dirty but it will be imported anyway.

Script files

A script can be divided in two parts:

• Clean script It would consist in a single file with the information about the element that is modified, its old value and the new one.
• Dirty script: It consists in a script like the clean one (it also can contain additions and deletions) and a set of resources files (PL, java...).

Exportation tool

The exportation tool allows to export as a set of modules and a configuration script any customization. When this tool is executed the result it gives is:

• Modules that compose the current installation. This will be done calling the export module utility. The purpose of not exporting just the script but also the modules is to avoid inconsistent scripts. For example if a customization adds a new window and modifies a table to make use of it, the first modification would be exported as part of a module and the second one in the script. If only the script would be exported it would make reference to a table that is not anywhere. In case modules are modified a warning might be raised.
• Clean configuration script.
• Dirty configuration script. In case the current customization includes dirty modifications the user will be warned but another configuration script will be created containing all the non-script elements.

Algorithm

The way the exportation tool works is as follows:

• The name of the script (industry template?) to be exported will be requested as parameter, it is the current active template (which only can be one). Also the modules that are part of the industry template are taken as parameters.
• The first step will be to call the module export utility to obtain as files the current modules in the installation. This process will export only the modules checked as “in development”.
• The exportation tool will create a database model composed by all the "clean" objects of the original components (modules and scripts) except the script it is going to export. This is done reading from files, and selecting just the columns that are considered valid for a clean script.
• It loads the clean objects of the current model in database and compares with the read one.
• It compares both models. Note that as the modules checked as “in development” are already exported in files they will be equal in both models and the differences will appear for the rest of modifications in the other modules that are included within the industry template. These differences will be saved as part of the clean script.
• Afterwards, a new database model is created by reading the files. This time, the database model contains everything except the columns that are not considered script columns, such as the audit columns. A new model is read from the database with the same criteria. Both models are compared, and the differences are saved as part of the dirty script. The following cases will be included in the dirty script:
  • Any modification in PL code.
  • Any addition or removal for non-in-development modules.
  • Any model modification in non-in-development modules.
• Additionally it should compare all the current source files with the current ones and in case any difference between them they would be saved as part of the dirty script. In order to be possible this comparison it is needed to now the original sources, there are two possible approaches:
  • A copy of all the original sources is maintained, this copy would not be modified, making thus possible to compare the actual sources with the original ones.
  • A new table can contain a hash for all the source files, the comparison would consist on a hash comparison in case they are different they would be included in the dirty script.

Dependencies

While the exportation is achieved it can store a list of modules that the script is modifying, these modules will be necessary to apply the script so they should be saved as dependencies for the script. Note that though all they are dependencies there could be other modules that are also dependencies.

Exporting a customization

A common case of use is to export a customization as an industry template. In this case all the new elements that are part of modules should be in the “customization” module which should be checked as “in development”. The result of running the exportation tool would be:

• A new “customization module” with all the new elements.
• A clean configuration script.
• And, depending on the performed customizations, a dirty configuration script.