Folder validation
The folder validation operation is an operation launched from folder management in the reference folder. It can be launched in batch mode. Its aim is to perform the operations to bring the folder in a usable state, ie. a state where connection and normal operations are possible on the corresponding endpoint.
The folder validation is a function that always runs on the main application server. The server assignment is automatically performed by the node.js platform.
The folder validation is a complex process that handles several cases:
The creation of an history folder is done from a dedicated function (CREHISTO).
The process description has several steps, and these steps are described here.
If a history folder exists for a given folder, its revalidation is done in a second step, and can even be done much later (if for instance the environment where the history folder is installed remains as a stand-alone environment). But a history folder can only be migrated after the migration of the folder it is attached to.
The history folder revalidation is only available for migration that go from version 150, version 6, version7, or upgrade 8 to the upgrade 9 or later. Take care that this requires a minimum level of patches or maintenances depending on the version.
The following list gives the prerequisite:
| Product | Version or upgrades | Minimum patch list or maintenance |
|---|---|---|
| Sage X3 | Version 5 | Maintenance 7401 and 7402 must be installed |
| Sage X3 | Version 6.x | Patch list >=33 |
| Sage X3 | Version 7 | Patch list >=10 |
| Sage X3 | Upgrade 8 | Patch list >=2 |
| Sage HRM | Version 5 | Maintenance 2211 and 2212 must be installed |
| Sage HRM | Version 6 | Patch list >=29 |
| Sage HRM | Version 7 | Patch list >=3 |
The folder validation first tests the parameter of the validation, with the following actions:
If some of the preliminary checks fail, the revalidation process will stop and the trace log will give explanations about the reason of the failure.
If the folder is revalidated, the folder is first switched to mono-connection mode (no user can connect on the folder during the revalidation). This is of course possible only if no other user is already connected, otherwise the revalidation fails.
Flags defining if elements in dictionaries will have to be validated. By default, the revalidation is set to No except if we are in a folder creation. In the next steps, the flag can be set to Yes by one of the upgrade procedures.
If the folder is created, a set of directories will be created on the application folder, and the scripts that create the database user with the corresponding tablespaces are run as well.
If the folder is revalidated, a check is done and the additional directories can be created (for instance when a language is added or if a new directory has been defined in the reference folder).
If the folder validated or revalidated is an history folder, the local dictionary elements (local table description) are created according to the data already stored, the dedicated menu files and text files used for the user interface are generated.
If the migration plans have been enabled:
* the list of the temporary tables is set:
* every module returns a list of tables to be purged
* some of them are temporary and can be purged without any problem (ALISTER, AWRKLOG, ATMPTRA for supervisor for instance, or PWRKSTT,PWRKORDERS for the purchase module)
* some of them are purged but will be reconstructed later. This includes tables such as BALANCE, BALANA, GLCONSO for the accounting module.
* the list of the movement tables is set as well
* an entry point allows specific developments to add their own tables in the list
* The temporary tables are purged
* The movement tables are copied by direct SQL transfer to the dedicated U* migration tables
* the movement tables are then purged
The tables are now updated by using AMAJ routine located in the DOSMAJ scripts. The principles are the following:
* the indexes and the triggers are deleted.
* the columns to be added are added in the tables.
* the new tables added in the new version are created.
* the AMAJ routine in DOSMAJ* scripts are run, in the right order : For every release gap, a dedicated DOSMAJ* can run. For instance, to go from release X1 to Xn, the intermediate DOSMAJ that might exist to go from X1 to X2, from X2 to X3... from Xn-1 to Xn will run successively. This processes can, for instance, fill a new column with the content of an old column that might disappear at the next step, or fill a new table with the content of an old table that might disappear in the next step.
The table dictionary is now updated and the revalidation of all the modified tables will occur. This will drop the standard columns that are no more present in the version and reindex the existing tables.
The movement table transformation are also managed by this step. But if the migration plans have been used, the movement tables are empty and the update will be done later.
If deliverable or kits have been added, they are copied from the reference folder (this step is not performed on history folder).
When revalidating a normal folder, the dictionary contents is updated for all the elements. This includes tables, views, actions, screens, objects, windows, data types, action parameters, functions, reports, activity codes, general parameters, miscellaneous tables, purge formulas, system transaction, inquiries, navigations, transactions, memo codes, type prototypes, global variables, constants, context variables, sub-programs, formula assistant contexts, URLs, documentations, data models, classes, representations, help keywords, entry-points, business object related dictionaries.
The update takes in account the changes that have been made (especially new activity codes, new legislations).
The tables are now revalidated according to the new dictionary definition: the columns that are no more present are deleted, the index are recomputed.
If we are updating a non history folder, depending on the changes in the set-up, some data might be copied from reference folder (for instance if a language code has been added, if new setups are delivered in table that are copied). The operation that might happen are the following:
At this step, a link control procedure is executed on all the table except the movement tables if the migration plans are used.
Still for non history folder on this step, the dictionary elements are validated:
For history folder updates, only the tables and the views are generated and validated (all the other dictionary elements are inherited from the main folder).
If the we are in an upgrade process for non history folders, the MAJ routine in DOSMAJ* scripts are run, in the right order : For every release gap, a dedicated DOSMAJ* can run. For instance, to go from release X1 to Xn, the intermediate DOSMAJ that might exist to go from X1 to X2, from X2 to X3... from Xn-1 to Xn will run successively. This processes can, for instance, perform additional updates. This step runs for both history folders and normal folders, but the scripts executed can of course be different.
If we are upgrading a non history folder, the classes and representation links are updated and the validation flag is set to trigger the validation later.
Still on a non history folder validation, the following operations are performed:
* The transactions a are generated.
* If we create a mono-legislation folder, additional mass changes are done on some key linked to multi-legislation.
* If the folder has been created by the validation, default parameter values are filled according to the reference folder, default periods and fiscal year values are set.
* Menu files are generated from menu profiles
* Triggers are generated on the tables
* The update flags on the dictionary elements are reset
* The BI parameter and code generation are done
* The index file of compiled scripts are regenerated
* Miscellaneous status flags are updated
* The current version number is updated
* Finally the folder is again switched in multi-user mode.
This step is relevant only if we are in an upgrade process and if the migration plans have been selected (otherwise, the folder validation is finished).
At this step, all the main, parameters and dictionary tables are up to date, but all the movement tables are empty, and the corresponding data is located in the U* tables.
Running the migration plan steps will transfer the data by massive insertion in the final movement tables. This can be done with several steps in parallel, and is defined by the migration plan setup.
When finally this step is finished, the folder is again ready for normal operation. The U* table remain with the movement data image before the migration. They can be purged later (for instance after a given period of normal operation, to be able to analyze further data inconsistencies that weren't detected).
They need to be purged before the next upgrade will be done. This is done with the function TRTMIGDEL.