Folder validation

Folder validation can be run in batch mode from the folder management in the reference folder. It moves the folder to a state where connection and normal operations are possible on the corresponding endpoint. It always runs on the main application server. The server is automatically assigned by the node.js platform.

Folder validation is a complex process that involves several tasks.

• Complete creation of a new folder
• Structural changes to an existing folder when:
  • The reference folder has been upgraded
  • Activity codes configuration has changed
  • New languages have been set up
  • New modules are activated
  • A history folder has been updated

The CREHISTO function is used specifically to create a history folder. The process involves several steps that are described below.

1. Prerequisites for history folders

If a history folder exists for a given folder, it is not revalidated until after the upgrade of the folder it is attached to. If the history folder remains installed in a stand-alone environment, its revalidation is performed in a second (or later) step.

History folder revalidation requires a minimum level of patches or maintenances depending on the version you start from.

The list of the prerequisites is as follows:

2. Preliminary controls

The folder validation process tests validation parameters with the following actions:

• If a history folder is validated, the reference folder is set to the associated exploitation folder.
• The reference folder is checked and must be at the current version level.
• If the folder already exists, it is a revalidation process. If not, it is a validation process.
• The activity code values are controlled:
  • If an activity code is not set in the reference folder, it is deactivated.
  • For a revalidation, the list of activity codes that have been changed is updated.
  • The updated list of legislation activity codes is managed separately (some updates settings are linked to legislations).
  • The evaluated activity code values are computed through dependency formulas.
  • The specific activity codes present are identified and checked.
• Additional functional controls are performed on certain parameter values.
• For a history folder revalidation, make sure that view ADOVALHIS is in the reference folder. If not, the correct preliminary patch has to be installed.
• The length of miscellaneous tables is checked (datatype ADI).
• The engine version is checked to ensure that an optimized update (upgrade plans) can be executed.

If any of the preliminary checks fail, the revalidation process stops and the trace log shows the reason for the failure.

3. Preliminary validation

If the folder is revalidated, the folder is first switched to mono-connection mode, which means that no user can connect to the folder during the revalidation. This is only possible if no user is currently connected, otherwise the revalidation fails.

Flags indicate if elements in dictionaries need to be validated. By default, the revalidation is set to "No", unless a folder is being created. In the next steps, the flag can be set to "Yes" by one of the update procedures.

4. Directory and database creation

If the folder is created, a set of directories are created in the application folder. The scripts that create the user database, along with the corresponding tablespaces, are run as well.

If the folder is revalidated, a check is performed and the additional directories can be created. For example, additional directories are created when a language is added or if a new directory has been defined in the reference folder.

If the validated or revalidated folder is a history folder, the local dictionary elements (local table description) are created according to the data already stored. The dedicated menu and text files used for the user interface are generated.

5. Data transfer and purge

If the upgrade plans have been enabled:

• The list of the temporary tables is set:
  • Every module returns a list of tables to be purged.
  • Some tables are temporary and can be purged without any problem (ALISTER, AWRKLOG, and ATMPTRA for the Supervisor module, or PWRKSTT and PWRKORDERS for the Purchase module).
  • Some tables are purged but are reconstructed later. This applies to tables like BALANCE, BALANA, and GLCONSO for the Accounting module.
• The list of 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.
• Movement tables are copied by direct SQL transfer to the dedicated U* upgrade tables.
• Movement tables are then purged.

6. Table upgrade

The tables are now updated using the AMAJ routine located in the DOSMAJ scripts. The principles are as follows:

• The indexes and triggers are deleted.
• The columns to be added are appended to the tables.
• The new tables added in the new version are created.
• The AMAJ routine in the DOSMAJ* scripts are run in the correct order:
  For each release gap, a dedicated DOSMAJ* script is run to go from one release to another. To go from release X1 to Xn, you have to run all the intermediate DOSMAJ scripts successively. These processes can fill a new column with the content of an old column, or fill a new table with the content of an old table that might disappear at the next step.

7. Dictionary updates and structure changes

The table dictionary is now updated and the revalidation of all the modified tables is performed. This drops the standard columns that are no longer present in the version and reindexes the existing tables.

The movement table transformations are also managed by this step. However, if upgrade plans have been used, the movement tables are empty and the update is performed at a later stage.

8. Deliverables and kit management

If deliverables or kits have been added, they are copied from the reference folder. This step is not performed on history folders.

9. Dictionary update

When revalidating a normal folder, the dictionary content is updated for all 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, navigation, transactions, memo codes, type prototypes, global variables, constants, context variables, subprograms, formula assistant contexts, URLs, documentation, data models, classes, representations, help keywords, entry points, and business object related dictionaries.

The update takes all the changes that were made into account, especially new activity codes and new legislations.

The tables are now revalidated according to the new dictionary definition. The columns that are no longer present are deleted and the indexes are recomputed.

10. Parameter updates and data copy

If you are updating non-history folders, and depending on the changes in the setup, data can be copied from the reference folder, for example if a language code has been added, or if new setups are delivered in the tables that are copied. Below are some of the operations that are possible:

• The parameters that were newly created in the release are copied and initialized, if necessary.
• The new miscellaneous tables are copied and initialized.
• The content of the new tables that are delivered with the automatic or conditional copy (if the copy has been set) is copied from the reference folder to the updated folder.
• The data related to the kits that have been enabled is copied from the reference folder.

At this stage, a link control procedure is executed on all tables, except the movement tables if upgrade plans are used.

11. Dictionary generation

For non-history folders, dictionary elements are validated:

• The views are generated.
• The local menu files are generated.
• The screens, objects, windows, and inquiries are validated.
• The vocabulary elements are validated.

For history folder updates, only the tables and the views are generated and validated. All other dictionary elements are inherited from the main folder.

12. Post upgrade data updates

During an update, the MAJ routine in DOSMAJ* scripts are run successively for non-history folders. These processes can also perform additional updates. This step applies to both history folders and regular folders but the scripts executed can be different.

13. Classes and representation synchronization

When updating non-history folders, the classes and representation links are updated, and the validation flag is set to trigger the validation later.

14. Final dictionary operations

For non-history folder validation, the following operations are performed:

• The transactions are generated.
• If you create a mono-legislation folder, additional batch changes are done on certain keys linked to multilegislation.
• If the folder has been created by the validation process, 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 is performed.
• The index files of compiled scripts are regenerated.
• Miscellaneous status flags are updated.
• The current version number is updated.
• The folder is switched to multi-user mode.

15. Additional step for upgrade (if upgrade plans are selected)

This step is only relevant for update processes if upgrade plans have been selected. Otherwise, the folder validation is complete.

At this stage, all the main parameters and dictionary tables are up to date, but the movement tables are still empty, and the corresponding data is located in the U* tables.

Running the upgrade plan transfers the data in batch in the final movement tables. This can be done with several steps in parallel and is defined by the upgrade plan setup.

When this step is complete, the folder is ready for normal operation. The U* table remains with the movement data image before the upgrade. They can be purged later, for example after a given period of normal operation, to be able to analyze further data inconsistencies that were not detected.

Note: They need to be purged before the next update is performed. This is done with function TRTMIGDEL.

Additional comments regarding history folder update

The following limitations apply to application table update in history folders:

• Only the tables with a standard history rule are upgraded.
• The post-upgrade process is not performed on history folders, except for balance resynchronization.

The consequence is that the following V6 fields remain empty for historical data:

• FIY and PER on BUD, GCOMMIT, SINVOICE (Sales/AR), PINVOICE (Purchase/AP), and PAYMENTH tables.
• UOM in GCOMMIT and BUD tables.

Keep in mind that the accounting cumulated tables (BALANCE, BALANA, BLACMM, BLAQTY) are erased in V6. The upgrade procedure resynchronizes the balance table. If you want to use balance historical data, the GACCENTRY* and GCOMMIT* tables must also have been historized.