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

SEEREFERTTO Refer to documentation Implementation

Screen management

Entry screen

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.

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.