This stage corresponds to the beginning of the transfer to the next version. At this stage, the operation of the solution must be stopped: it will resume when the migration is completed.
This stage is sub-divided into 4 phases:
1. Extraction of the data from the folder to be migrated:
2. Copy of the files of the folder to be migrated to the U9 solution,
3. Creation of a copy folder of the folder tree structure in the new environment of version 6, and import of the exported data into the new environment,
4. Creation of the folder record in the U9 environment. If the import is carried out via the console, the folder record is created automatically. On the other hand, if the import has been carried out via database tools, the folder record will have to be created manually after the import is completed.
These various stages can be combined into a single one. For that purpose, it is necessary to use theremote import wizard available in the SAFE X3 configuration console.
If the console import function is used, the procedure is as follows:
1.Start the console.
2. Choose the required U9 solution and display the Folders screen.
3.Click the Import button (located in the screen tool bar). A window is displayed.
4.Select the name of the folder to be imported, the directory containing the data to be imported (SVG if this is the directory that has been used to perform the extraction) and populate the other fields,
5. Click OK to start the import.
Activity code values may need to be modified in the folder record, for example, to implement new functionalities controlled by new activity codes.The modification of the folder record, or its creation, will be carried out by logging to the Supervisor folder.
Revalidating the folder transforms the structure of the Sage X3 People dictionary, then of the setup tables, then the data tables, of the previous version in order to bring the structure up to the U9 level while transferring the data. To revalidate the folder, click the Validation from the folder management function.
Revalidating the folder performs the supervisor and functional migration of the folder, by running a comparison between the dictionary of the new version and the dictionary of the version to migrate.
The folder revalidation triggers the following stages in the folder to migrate:
This functional migration can be lengthy when the folder is very large. Moreover, some updated tables are potentially independent and, therefore, could be migrated in parallel, thus benefiting from multi-processor architectures to accelerate this phase.
To allow this migration to be scheduled in the best way, it is possible to define a customized migration plan before launching the data validation. This migration plan is described in the Migration procedure function (called from the Supervisor folder). This function is used to define the stages, phases and procedures of the functional and supervisor migration. A migration plan corresponds to the definition of specific migration parameters (impacted folder, number of procedures that can be run in parallel, task sequencing policy, running status). A migration plan is created by recopying all the active elements of the migration procedure. This complete set of procedures is provided as a standard. It allows all the processing routines carried out by the standard software during the migration phase to be run exhaustively. A short description of these procedures is provided in a dedicated documentation.
It is possible, at this stage, to define specific procedures by writing complementary processing routines in conformity with the methodology defined in the following annex. These specific procedures will be inserted in a relevant way between the standard procedures.
Once a migration plan has been defined,it is possible to launch it, interrupt it momentarily, resume its execution, and view its progress status.
When the volume of a folder is not too large and its migration does not require any particular planning, it is not necessary to create a migration plan. In effect, when there is no migration plan, the validation operation of the folder will automatically create a migration plan. The code of this migration plan will be the folder code, except if this code already corresponds to a migration plan that does not have the Pending status. Pending. If it were the case, the plan would be created with a predefined code under the form MIGmmddM##. mmandddare the numbers representing the month and the day of the launching, ## is a sequential number.
However, to customize the migration sequencing options, it is possible to create a migration plan with a code that must correspond to the folder name. This creation will take place in the supervisor folder before launching the folder validation. If there is such a migration plan with the status Pending,it will be used for the functional migration of the folder.
A plan created with a name that is different from the folder to migrate will never be used by the automatic folder validation functions. Such a plan is restricted to a manual launching.
A migration plan is characterized by a folder code and 4 parameters:
If the migration plan is created by default upon folder revalidation, it is created with the following values:
The user can at all times modify these values from the migration plan control function.
The ordered list of the plan procedures is displayed in the screen associated with the migration plan. Specific buttons make it possible to globally control the running of the plan:
Each line of the plan materializes a step in the execution, characterized by:
The migration steps make it possible to split the functional migration. If a procedure linked to a given phase is not completed, the following phases cannot be launched. The phases are linked to the following steps:
One step includes unitary procedures that are organized in phases and ranks.
As soon as the folder is revalidated, it can be accessed without use restriction (there can be some level of restriction if some postmigration operations have been postponed).
The only remaining task in to check and adapt some functional setups. This aspect is described in the documentation on the functional postrequisites.