Patch Integration
The software packages using the SAFE X3 technology contain a function that is used to integrate the corrections or functional changes delivered in the form of archived files called "patches". It is in this way that a business partner development can be integrated, that additional data can be loaded in a table and that corrections can be applied.
A patch can contain one or more elements such as the screens, the table definitions, the activity codes, the data types, the objects, local menus, message chapters, the processes, the process execution requests, the data.....
The integration of a patch modifies the dictionary and the folder databases to which it is applied. There is a single exception to this principle: the processes delivered by patch are only installed in the supervisor folder (except in specific cases described later).
Particular case: Integration of a table
The integration of a table is done in two steps:
1. Update of the table title in SAFE X3.
2. Validation of this table (running the valfil): during this stage, if database statistics exist for this table, they can be deleted.
This depends on the types of changes on the table.
For example:
- Addition of a field after the table title: the database statistics are kept.
- Insert a field between two others: the database statistics are lost for the whole table.
Indeed, the table is deleted and then created again.
Files
A patch file is characterized by a name integrating in principle a number sequence, in order to control, when several files exist, that the patches are correctly applied in order.
Corrective patches delivered as standard are managed in the following way:
- the files are defined using the name P_nnnn_vvv.dat, nnnn is a chronological number, and vvv the major version on which the patch can be applied (so far, vvv can be 110, 120, 130, 140, 150). A file of this type contains a group of constituent objects or elements for a correction or a functional change (for example, the delivery of a new entry point).
- several patch files (in general at least a dozen, but it can more) are organized in the form of a list that is available from Sage partners.
- the installation of one or more lists is performed using this function, which integrates the files in sequential chronological number order, a certain number of coherence controls being carried out (version number to which the patch can be applied, the coherence with the sequence of the last patch update).
The SAGE partners who wish to supply functionalities in the form of patches are advised to adopt the same file naming policy, using a specific identifying first letter (for example X, Y, or Z). In effect, a sequence control is made from the moment the file name contains the character _ (underscore) at 2 and 7 position in the file name: the characters 3 to 6 are a sequential number on which (with the same root) will be carried out a sequential control. The characters above the 8th (excluding the file extension) are controlled with respect to the major version number.
Prerequisites
Refer to documentation Implementation
Screen management
Entry screen
Presentation
The information relating to the integration of the requested patch is entered in the opening window, then the screen is revalidated.
The integration is then processed; it can be long if there are numerous patch files but a progression bar can be used to track the integration process.
At the end of the patch installation, a log file is obtained that is physically located in the log directory for the folder from which the installation was launched. A close examination of this file is advised in order to identify possible errors.
Close
Fields
The following fields are present on this tab :
File
|
|
|
|
|
|
Block number 2
|
If this field is not ticked, the intergration will be in simulation mode. In this case, the integration is logged but the transfers or update are not carried out. |
|
This check box is useful if the patches are to be installed in a foreign environment. If it is checked, the log file for the integration results will be in English. |
|
This option disables the direct validation of windows and screens in order to optimize these objects validation time. If this check box is ticked, the windows and screens will be validated at their first use. |
|
|
|
|
Grid Folders
|
Enter the codes for the folders in which the patch is going to be integrated. |
|
|
|
|
|
|
|
|
Close
Batch task
This function can be run in batch mode. The standard task PATCH is provided for that purpose.
The installation of the patch lists can be carried out as a batch task (up to a maximum of 50 folders).
This option is very interesting because the integration of the patches can be carried out at night after the backup before the re-starting of live environment. In effect, the installation of patches can be a long operation. The viewing of the log file can be made directly from the batch task inquiry management.
Warning, a standard patch that has already been installed or that is not in sequence will not be integrated with the batch: this is only a warning message that can be forced when the patch is directly installed becoming an automatic stop reason in the case of batch execution.
Documentation patch
A documentation patch is integrated in the same way as explained above and applies to the selected folders.
The files are defined with the name Dy_nnnnn_vvv_ppp.dat, 'y' being the abbreviation of the product, 'nnnnn', the chronological number, 'vvv', the major version to which the patch is integrated, and 'ppp', the legislation code.
There is only one file for each legislation containing all the documentations created or modified since the previous patch.
The documentation patches are supplied together with the application patches. They can be integrated before or after the application patch. The system controls the number chronology.
The integration of a documentation patch updates the documentation dictionary but it does not impact the documents placed on the documentation server. For these to be updated, a documentation generation must be carried out.
Documentation generation
When using the compressed format access mode (CHM), the update of the automated documents and the decompression of the documentation file must be carried out (see documentation server).
If the HTML format access mode is used, the update can be directly started.
Automatic documentation update
In the documentation function, click on the Generation button and enter the following data according to your language code:
N B: the directory comes from the DIRDOC user parameter.
Restart another 3 generations with the same parameters except for the data type that should specify AML, then ATB, then ATY successively.
Generation of the documents on the documentation server
To update the documentations on the documentation server, start the following generation, depending on your language code:
When using the compressed mode to access the documentation, the files need to be recompressed (see the documentation server).
Otherwise, the update is finished.
Error messages
Error messages at the launch of the function
In addition to the generic error messages, the following messages can appear during the entry :
No patch in the directory
An empty directory has been specified.
Error messages in the log file
All error messages are written in the log file. Amongst these, the following messages are found:
The folder must be as a minimum in version nnn
The patch can not be applied, because the folders are not at minimum version required.
xxxxx: module not installed in the folder
The patch has not been applied to the folder, because the functional module is not used.
Abnormal file end
Incorrect file structure
The patch file is probably corrupted, the installation process could not read up to the corresponding data or has found a non-conforming structure.
XXX file management: <<error messages>>
A transactional type error has been produced during the dictionary update.
Error in line NNN: <<error messages>>
An error has occurred in the execution of a process accompanying the patch.
More recent patch already integrated
Patches are missing, the last installed is ###
Patch normally included in version NNN
These three messages concern the patch application sequence verification. Normally, if the standard patch number N1 is the last to have been applied, the system does not expect to apply an older patch (first message), nor a patch with a number greater than N+1 (second message). In addition, the installation of an intermediate version includes the standard patches which should therefore not be installed (message number 3). In any case, in interactive mode these messages are not blocking, and it is possible to continue by answering Yes To the question Do you want to continue in spite of errors?.