Patch integration
Using the SAFE X3 technology, packages are created that contain a function that is used to integrate the corrections or functional changes delivered in the form of archived files called "patches." In this way, a business partner developments can be integrated and 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, etc.
Use this function when updating your customer environment with bespoke development or the current product version is prior to 2019 R4. For versions prior to 2019 R4, you must update each patch individually and in order without skipping one. You update 2019 R1 to 2019 R4 without first updating to 2019 R2 and then updating to 2019 R3.
In this situation, use the Patch test function (PATCHT) located in Development > Utilities > Patches > Patch test to perform an impact analysis for each patch prior to installation.
If the current product is at version 2019 R4 or newer and you are not delivering an add-on or bespoke developments, use the Updates function (Updates) located in Administration > Utilities > Update > Updates. Integrating 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: Integrating a table
This is done in two steps:
1. The table title is updated in SAFE X3.
2. The table is validated (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.
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. 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 such as the version number to which the patch can be applied, the coherence with the sequence of the last patch update, etc.
The SAGE partners who want 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 can be long if there are numerous patch files. A progression bar tracks the integration process.
At the end of the patch installation, a log file is stored in the log directory for the folder from which the installation was launched. A close examination of this file is advised to identify possible errors.
Close
Fields
The following fields are present on this tab :
File
|
|
|
|
|
|
Block number 2
|
If this field is not selected, the intergration is run in simulation mode. In this case, the integration is logged but the transfers or update are not implemented. |
|
This check box is useful if you are installing patches in a foreign environment. If it is selected, the log file is in English. |
|
This option disables the direct validation of windows and screens to optimize these objects' validation times. If this check box is selected, the windows and screens are 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.
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.
The patch integration can run at night after the backup and before the restarting the live environment. This can be a long operation. You can view the log file 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 task. This is only a warning message that can be forced when the patch is directly installed and becomes an automatic stop 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 is the product, nnnnn is the chronological number, vvv is the major version to which the patch is integrated, and ppp is the legislation code.
There is only one file for each legislation containing all the documentation created or modified since the previous patch.
The documentation patches are supplied with the application patches. They can be integrated before or after the application patch. The system controls the number chronology.
The documentation patch updates the documentation dictionary but it does not impact the documents placed on the documentation server. For these to be updated, you must generate the documentation.
Generate the documentation
When using a compressed HTML file (CHM), you must the update the automated documents and decompress the documentation file (see documentation server).
If the HTML format access mode is used, the update can be directly started.
Automatic document update
Go to the Documentation function (GESADO).
You need to generate the documentation 4 times, once for each data Type in this specific order:
- APM
- AML
- ATB
- ATY
For each data type, enter the following data according to your language code.
Under Selections:
Language: your language code, for example: ENG, FRA, BRI, etc.
Do not select All types.
In the Type field, enter one of the four data types, i.e., APM.
In Code function from, leave blank and enter X in the to field.
Under Generate ADOCUMENT
Select No.
Under Generate final document
Select No
Leave the remaining fields empty.
Note: The directory is defined in the DIRDOC - Final doc directory user parameter under Setup > Users > Users (GESAUS).
Generate documetation on the document server
To update the documentation on the documentation server, run the following generation, entering your language code:
Under Selections:
Language: your language code, for example: ENG, FRA, BRI, etc.
Select the All types.
Under Generate ADOCUMENT
Select No.
Under Generate final document
Select Complete, Only the validated documentations, and Field helps linked to documentations.
In the To field help codes, enter Z.
Error messages
The only error messages are the generic ones.
Function error messages
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.
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?"