Patch test
When specific developments are carried out by modifying the standard elements, the lowest level element that has been modified must be protected by an activity code starting with X, Y or Z (for example, the screen field rather than the section or the screen itself). In addition, the use of an activity code is not necessary when SPE or SPX actions (or actions starting with X, Y or Z) are used in a screen.
However, such a development requires verifications upon the installation of standard patches on a modified folder. Indeed, it is necessary to ensure that the patched elements do not conflict with modified elements (in this case, the elements, protected by an activity code, are not patched, and this can be problematic).
This function is used to carry out, in an automatic fashion, a detection of potential conflicts linked to a set of patch files located in a directory. More precisely, it performs the following actions:
- reading all the patches located in a directory
- for each patched object, the function looks if there is a potential conflict due to a specific activity code (unless this specific activity code was put at the head of the patch as meant to be overwritten)
- it generates a log file detailing the possible conflicts.
Thus, when specific developments have been carried out and a standard (or specific) patch list must be installed, all the user has to do is launch this function:
- if no collisions are detected, there is normally no risk (if the specific development standards have been correctly followed).
- if there are conflicts, it is necessary to focus on the detected conflicts (which normally account for only a minor part of the cases).
If multiple patch lists must be installed, it is possible to copy (for the duration of the test) the totality of the corresponding files in the same directory: the only limitation for the tester is 1,000 simultaneous patch files all the corresponding files in the same directory:
The tests performed are the following:
- the screens, tables, objects, functions, data types, inquiries, windows, actions patched and globally protected by an activity code.
- the fields and sections in a screen, the options and variables in a function, the fields and the indexes in a table, the buttons in a window, the left lists (browser tab), tabs, and tables linked in an object, when these elements are protected by an activity code that do not protect the element of higher level.
- the processings and reports locally installed in a folder for which the patch may not be effective.
The conflicts linked to the specific activity codes (starting with X, Y or Z) are all detected, except those that correspond to activity codes given in the patch header (since in this case it is a specific patch, it is understood that the patch will be applied).
In order to allow this type of test when the update has not been carried out by the patch file installation, but by the installation of a new sub-version, a list of files named List_nn.dat will be found from the version 134 CD, in dedicated directories (the sub-directories P132, P133, P134… of the directory named X3patch), and which does not contain the nn patch list, but only the list of objects affected by the patch list, all of which to facilitate the identification of potential conflicts existing in a list. The following example explains the use:
- imagine that the folder that is to be updated to version 134, is at version 132 patched to the level 12 list.
- the upgrade to version 134 requires the installation of the patches 13 to 18 (those which are required to upgrade to version 133: the corresponding List_nn files are in the directory X3patch\P133 on the CD), and the patches 19 to 31 (those that are required for the upgrade to version 134: the corresponding List_nn files are found in the X3patch\P134 directory on the CD).
- it is then sufficient to copy the List_13.dat to List_31.dat files to a temporary directory, then use the patch test function by giving a name to this directory. If the conflicts are highlighted, the element in conflict will be in the log file along with the corresponding list number; it will be possible to test the list in question to provide further information.
Warning, this utility only provides information on potential conflicts, it is not capable of identifying what should be modified in the element in order that all works correctly. On the other hand it is possible to carry out tests on the contentious elements by using the comparison function on the corresponding elements between a patched and a non-patched function.
Screen management
Entry screen
A window is used to enter the parameters of the function launch.
The launch can now be started. An example of a log file that can be generated is given below.
File
field AW |
Destination type (field TYPEXP) |
Patch (field VOLFIL) |
Grid Folders
Folder (field DOSSIER) |
Used to give a list of folders in which the test will be carried out. |
Log file example
Errors in patch P_1252_130 in the DEMO folder: Modification for the DEB
The FUNDEB.adx processing present in the folder will not be updated by the patch.
Errors in patch P_1263_130 in the DEMO folder: DEB Modification
The FUNDEB.adx processing present in the folder will not be updated by the patch.
Errors in patch T_0001_130 in the DEMO folder:
The BAL inquiry protected by the ZDA activity code will not be updated by the patch.
The Crystal Report ATRACE.rpt report present in the folder will not be updated by the patch.
The ZDOMANA.adx processing present in the folder will not be updated by the patch.
The ZPATCHTST.adx processing present in the folder will not be updated by the patch.
The BPC0 mask protected by the ZDA activity code will not be updated by the patch.
Mask BPC1: The block 2 protected by the ZDA activity code will not be updated by the patch.
Mask BPC1: The (4,4) INVDTAAMT field protected by the ZDA activity code will not be updated by the patch.
Mask BPC1: The (4,5) WWCUR field protected by the ZDA activity code will not be updated by the patch.
Table BPCUSTOMER: The (4) BPCTYP field protected by the ZDA activity code will not be updated by the patch.
Table BPCUSTOMER: The BPC1 (2) index protected by the ZDA activity code will not be updated by the patch.
Object BPC: The BPC1 (3) tab protected by the ZDA activity code will not be updated by the patch.
Object BPC: The BPC3 (5) tab protected by the ZDA activity code will not be updated by the patch.
Object BPC: The table linked to the (2) BPADDRESS protected by the ZDA activity code will not be updated by the patch.
Object BPC: The table linked to the (6) TABCUR protected by the ZDA activity code will not be updated by the patch.
Object BPC: The browser (1) BPC line protected by the ZDA activity code will not be updated by the patch.
The BPC data type protected by the ZDA activity code will not be updated by the patch.
The GESBPC function protected by the ZDA activity code will not be updated by the patch.
The ADSVAL action protected by the ZDA activity code will not be updated by the patch.
The CLOPER report definition protected by the ZDA activity code will not be updated by the patch.
The Crystal Report ATRACE.rpt report present in the folder will not be updated by the patch.
Additional note
For processings, the patch tester first verifies that an adx file (executable) corresponding to the processing to patch exists in the current folder. If the executable file does not exist, the existence of the source of the processing is checked instead, and this source is mentioned in the log.