启封管理咨询

修身,齐家,治国,平天下
热 线 电 话 400-618-3060

X3 系统升级

The migration of a folder can be performed in two ways:

  • By updating an existing solution.
     

    Target version

    Source version

     

    V5

    V6.5

    V7

    U8

    U9

    V11

    V12

    V5

     

    Direct

    Direct

    Indirect (via V7)

    Indirect (via V7)

    Indirect (via V7)

    Indirect (via V7)

    V6.5

       

    Direct

    Direct

    Direct

    Direct

    Direct

    V7

         

    Direct

    Direct

    Direct

    Direct

    U8

           

    Direct

    Direct

    Direct

    U9

             

    Direct

    Direct

    V11

               

    Direct

  • By installing the latest version solution, then integrating all existing patch lists to your root folder.
    Follow the optimized migration procedures described below.

Main migration steps

To migrate a folder from one major release to another:

  1. Carry out controls in the original folder before the migration, without stopping the Enterprise Management operations.
  2. Install the latest version on a dedicated environment, or update an existing environment.
  3. Extract the data to be migrated from the original folder, and reintegrate it.
    Stop the operation and resume it when the migration is complete. The data extraction will be carried out in a "flat" format for small folders, or with database extraction tools for larger folders.
  4. Revalidate the folder in the latest version environment.
    This step can be divided in several substeps based on the migration plan setup. Defining a migration plan is optional for smaller folders. However, it is necessary if transfer processing routines need to be run in parallel (to benefit from the power of a multi-processor server), and if their sequencing needs to be checked using resumption marks.
  5. Perform post-migration controls (setup checks and adaptation).

These steps are detailed in this document.

Performing the premigration steps

Premigration steps are launched in the source environment, and can be spread over a period of time, before the actual migration. It is not necessary to stop any operation beforehand.

  1. Make sure the original folder is at the minimum patch level required to run a migration:
    • To migrate from version 6, the minimum patch level required for the source folder is patch 29.
      You can display this patch level from ? > About.
      Caution: For Portugal, you have to migrate from version 6 to update 8, and then from update 8 to version 11.
    • To migrate from version 7, the minimum patch level required for the source folder is patch 9.
      You can display this patch level from Administration > Version information.
    • To migrate from version 8, the minimum patch level required for the source folder is patch 3.
      You can display this patch level from Administration > Version information.
    • To migrate from update 9, no minimum patch level is required.
  2. Check the functional prerequisites for the migration process.
  3. Trigger the automated procedures in the original folder, using processing routines with names starting with "UU".
    You can launch these procedures from Development > Utilities > Miscellaneous > Run processes. The processing routines are supplied upon request, according to the release number, as a specific patch list dedicated to migration. Two types of procedures are delivered:
    • Control procedures for the data contained in the original folder. These controls can reveal errors or inconsistencies that need to be corrected before launching the migration itself. This can be anticipated several weeks ahead of migration to have enough time to correct the data. However, it is still necessary to relaunch these procedures right before migrating to the next version to make sure everything is correct.
    • Loading procedures that revalidate tables by adding additional fields and populating them. Since these procedures are independent from one another, they can be planned weeks before migration. Their purpose is to significantly accelerate the actual migration steps. However, they are not mandatory for the execution of the migration procedures.

Copying data and adjusting the folder parameters

This step takes place at the beginning of the transfer to the next version. At this stage, operation of the solution must be stopped: it will resume when the migration is completed.

  1. Extract the data from the folder to be migrated:
    • In a "flat" format for smaller folders. You can do so by clicking Development > Utilities > Extraction/integration > Data extract.
      The files are created in the default SVG backup directory.
    • As databases for larger folders. The format depends on the database and tool used.
  2. Copy the files to be migrated to the latest version solution.
  3. Create a copy of the folder tree structure in the latest version environment.
    Import the exported data in the new environment.
  4. Create the folder record in the latest version environment.
    If the import is carried out using the console, the folder record is created automatically. If the import was done using database tools, the folder record will have to be created manually after the import is complete.

Note:

  • You can perform these four steps at the same time using the remote import wizard available in the SAFE X3 management console.
  • If the standard process has to be relaunched from the data import in the migration folder, you can use the TRTMIGDEL function to clear the tables storing the migration report.

If you use the console import function, the procedure is as follows:

  1. Start the console.
  2. Select the solution and display the Folders screen.
  3. Click Import.
  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 complete the other fields.
  5. Click OK.

Caution: Before revalidating folders, always adjust the value of the activity codes in the folder record. The modification of the folder record (or its creation) can be carried out by logging in to the Supervisor folder.

You cannot trigger another folder validation without performing this step. An error message is displayed as a reminder when launching the validation.

Revalidating folders

Revalidating the folder changes the structure of the Enterprise Management dictionary, of the setup tables, and of the data tables of the previous version in order to bring the structure up to the latest version level. It is triggered by clicking Validation in Setup > General parameters > Folders, and it happens while transferring the data.

This step triggers 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.

Caution: If a migration test is first carried out in a folder containing specific developments, and if it can potentially stop in case of errors, the default size of global variable GTRALIG ("200" for optimization reasons) will not allow the retrieval of the operations carried out before the system stopped. In this case, you have to temporarily set GTRALIG to "1".

Re-enter value "200" after the migration, and make sure you log out and then log back in for this value to be taken into account.

Performing the main revalidation steps

The folder revalidation process triggers the following steps in the folder to migrate:

  • Purge of specific temporary or totalling tables whose recreation will be carried out at a later stage. The Supervisor tables impacted by this purge are the following:
    • ALSTRD
    • ALISTER
    • AWRKLOG
    • AWRKLOGIND
    • AWRKLOGMES
    • ATMPTRA
    • Other temporary functional tables are also purged (LABELPRN, PRTSCRWRK, BALANCE, BALANA, GLCONSO, BALCONSO, GAJOUSTA, FUP, FUPTOT, BATCH, TMPEXPENSE).
  • Migration of the database dictionary and the Supervisor tables necessary for the operation of the database (connection, user management, development environment, and minimum setup). Once this migration has been carried out, it is theoretically possible to log on, even though the tables containing the flow application data are still empty.
  • Functional migration. Whenever there is a change in the structure of a table, the procedure carries out the necessary changes by assigning the appropriate default values through procedures sequenced in steps and phases. This is the lengthy part of the migration, depending on the volume of data to migrate.
  • Post-migration process (essentially resynchronization of the totalling tables). Some of these steps can be postponed and then resumed, but the software will be functioning in a downgraded mode during the intermediate phase. These stages must have been carried out for the migration to be complete.
  • Final deletion of the temporary tables. This is a manual phase which can be postponed, for safety reasons, as long as there is no absolute certainty that all the flow data has been correctly migrated.

Using the migration plans

This functional migration can take a long time for larger folders. In addition, some updated tables are potentially independent and could be migrated in parallel. Such tables would benefit from multi-processor architectures, which would, in turn, accelerate this phase.

For the migration to be efficiently scheduled, you can define a custom migration plan in Usage > Migrations > Sequencing monitor before launching the data validation. This migration plan is described in Usage > Migrations > Migration process 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). It is created by copying 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 here.

It is possible, at this stage, to define specific procedures by writing additional processing routines in conformity with the methodology defined here. These specific procedures will be inserted in a relevant way between the standard procedures.

Once a migration plan has been defined, you can launch it, temporarily interrupt it, resume its execution, and view its progress.

When a folder is not too large and its migration does not require any particular planning, you do not have to create a migration plan. The validation of the folder will automatically create a migration plan if you do not define one. The code of this migration plan will be the folder code, unless it already corresponds to a migration plan that does not have the "Pending" status. In such a case, the plan is created with a predefined code: MIGmmddM##, with mm and dd representing the month and the day of the launch, and ## being a sequential number.

To customize the migration sequencing options, you can create a migration plan with a code that corresponds to the folder name. This can be done from the Supervisor folder before launching the folder validation. If a migration plan with the "Pending" status exists, it will be used for the functional migration of the folder.

Note: A plan created with a name different from the name of the folder to migrate will never be used by the automatic folder validation function. Such a plan is restricted to a manual launch.

Operation process in a migration plan

Description of the migration plan

A migration plan is characterized by a folder code and four parameters:

  • A title.
  • The maximum number of procedures likely to be launched simultaneously. Only procedures that can be run in parallel will be launched simultaneously. Note that this number is limited by the number of batch tasks likely to be run simultaneously (defined in Setup > Usage > Batch server > Batch server parameters) and by the user license.
  • An indicator specifying whether the procedures must be launched automatically or not.
  • An indicator stating if the post-migration procedures must be linked to the migration itself.

Migration plan values

If the migration plan is created by default upon folder revalidation, it is created with the following values:

  • Number of simultaneous tasks: Same value as the NBRTACSIM parameter, or value "2" if this parameter does not exist.
  • Automatic sequencing: "Yes".
  • Post-migration operations: "Yes".

You can always modify these values from the migration plan control function.

Managing the migration plan

You can view the ordered list of the plan procedures in the screen associated with the migration plan. Specific buttons make it possible to globally control the run of the plan:

  • by launching its execution,
  • by temporarily interrupting the launch of new procedures,
  • by interrupting all the procedures in progress,
  • by relaunching its execution.

Each line of the plan materializes a step in the execution, characterized by:

  • the code of the procedure and its title,
  • the step and phase the procedure belongs to,
  • the functional module the procedure is linked to,
  • the execution rank.

The migration steps make it possible to split the functional migration. If a procedure linked to a given phase is not completed, the next phases cannot be launched. The phases are linked to the following steps:

  • The initialization step is a preliminary step that has to be completed first. It allows specific procedures to be executed before the migration itself.
  • The common data step allows data used by the next steps to be migrated.
  • The module step is used to carry out migrations linked to each functional module. An operation belonging to this step is associated with a functional module. This association does not have any binding effect on the execution.
    For example, some data migrations linked to different modules can be run in parallel if they belong to the same phase. Their launch will follow the order of the modules, and then the order of the execution ranks.
  • The post-migration step is used to carry out synchronization operations, or secondary updates whose execution is not mandatory to restart operations in a downgraded mode. It can be used to postpone the migration of old data, for example.
    Caution: Even though this step is not mandatory to restart operations, it must be carried out at some point for a folder to be considered as completely migrated.
    The post-migration operations are launched by default in a migration plan but they are optional. They are listed in the appendix describing the migration procedures.

The unitary procedures are organized in phases and ranks:

  • Two procedures defined in the same phase can be run simultaneously and should therefore be independent. The assignment of a standard procedure to a given phase cannot be changed. As long as all the procedures belonging to a phase are not completed, the next phase cannot be launched.
  • The rank order is a purely preferential launch order but it can be modified when the plan is defined, including for standard procedures.

Purging the entry tables

This phase is manual. It is triggered by executing the TRTMIGDEL function. Running it deletes all tables with the "MIG" activity code.

Caution: You first have to make sure that the migration processing routines have been carried out successfully as this phase cannot be reversed.

Note: You can resume normal operations while the temporary tables are still in the folder. This allows you to access the original data for comparison or analysis purposes, should any problem occur in the weeks following the migration.

Verification after the migration

As soon as the folder is revalidated, it can be accessed with no restriction (unless some post-migration operations have been postponed). The only remaining task is to check and adapt some functional setups. This is described in the functional post-requisites.

Example of sequencing on flow migration

  • Initialization step, 7 operations:
    • IN1 and IN2 in phase 1 (ranks 3 and 7)
    • IN3 and IN4, IN5 and IN6 in phase 2 (ranks 1 and 3, 5 and 9)
    • IN7 in phase 3
  • Common data (TC) step, 6 operations:
    • TC1, TC2 and TC3 in phase 1 (ranks 3, 6 and 9)
    • TC4 in phase 2
    • TC5 and TC6 in phase 3
  • Module step, 5 operations:
    • Step MO1, in the Financials module, in phase 2 (rank 1)
    • Steps MO2 and MO3, in the Stock module, in phases 1 and 2 respectively (ranks 1 and 2)
    • Steps MO4 and MO5, in the Sales module, in phases 1 and 2 respectively (rank 1)
    • Steps MO6 and MO7, in the Purchasing module, in phases 1 and 5 respectively (rank 1)

Assuming the migration plan is launched with a sequencing of tasks and a maximum number of two procedures running simultaneously, the sequencing can be as follows:

  1. Initialization step:
    1. Procedures IN1 and IN2 are launched in this order.
    2. If procedure IN2 is completed first, no other procedure can be launched until procedure IN1 is completed (the following procedures are included in a phase or a step with a higher rank).
    3. When procedure IN1 is over, procedures IN3 and IN4 are launched in this order.
    4. If procedure IN4 is completed before procedure IN3, procedure IN5 will be launched. If procedure IN5 is completed before procedure IN3 is over, procedure IN6 will be launched, and it will run at the same time as procedure IN3.
    5. When procedures IN3 and IN6 are both completed, the initialization step is over.
  2. Common data (TC) step:
    1. Procedures TC1 and TC2 are launched in this order.
    2. Procedure TC3 is launched when one of the two previous procedures has been completed.
    3. Procedure TC4 is launched when procedures TC1, TC2 and TC3 are completed. It will run on its own since there are no other procedures in this phase.
    4. Procedures TC5 and TC6 are launched and run in parallel when procedure TC4 is completed.
  3. Module step:
    1. Procedures MO2 and MO6 are launched in this order and run in parallel.
    2. When one of these procedures is completed, Procedure MO4 is launched in parallel with MO2 or MO6, depending on which one of them is not completed.
    3. Procedures MO1 and MO3 are launched when all the previous procedures are completed.
    4. When one of them is completed, procedure MO5 is launched.
    5. Procedure MO7 is launched when procedure MO5 is launched.
本原创文章未经允许不得转载 | 当前页面:启封管理咨询 » X3 系统升级

评论