Patch Creation

Element types that can be patched

This table lists objects to be patched. The list is identified by an object type and a name. The definition of the various object types and the meaning of the name are provided. The Rank column gives the order of the element types in the patch (see paragraph below). Elements with the rank 100 in the table are always at the end of the patch (in alphabetical order of element codes).

Code	Meaning	Name	Rank
AAA	Lines arising from a setup model	Specific format, see corresponding section	100
ABA	Batch recurring task	Recurring task code	46
ABF	BI Fact table	Table code	54
ABG	Group of tasks	Group code	47
ABI	BI Dimension	Dimension code	55
ABM	BI Datamart	Datamart code	56
ABO	Report Business Objects	Report code	58
ABT	Batch task	Task code	45
ABV	BI Synchronization rule	Code of the rule	57
ACL	Control table	Table code	18
ACN	Inquiry	Inquiry code	36
ACS	Access codes	Dealt with in the form of a condition (CODACS='value')	14
ACT	Action	Action code	16
ACV	Definition of an activity code	Activity code	1
ADC	Description of a script (dictionary)	Script name	9
ADF	Documentation links	Type ~ Element code	50
ADI	Contents of a miscellaneous table	Table number	24
ADO	Functional help (all paragraphs)	Type ~ Help code	49
ADP	Parameter (both its definition and value if they exist at the general level)	Parameter code	32
Sales Management	Setup of a miscellaneous table	Table number	23
ADX	Script file (only in its compiled form)	Script file name	11
ADZ	Field help	Help code	48
AEN	Import/export sequencing	Dealt with in the form of a condition (CODE='value')	35
AFC	Function	Function code	17
AGB	Global variable	Variable name	20
AHH	BI Hierarchy	Hierarchy code	59
AHI	Purge formulae	Formula code	7
AII	BI predefined condition	Condition code	60
ALH	Query tool	Code for the request	51
ALQ	SQL query tool	Code of the SQL request	52
ALT	Graphical query tool	Code for the request	53
AMK	Screen	Screen code	28
AML	Local menu	Local menu number	2
ANG	Navigation	Navigation code	10
ANM	Definition of a counter:	Code of the counter	15
ANT	Widget Netvibes parameters	Object code for widget	65
AOB	Definition of an object	Code of the object	30
AOE	Import/export template	Template code	34
AOP	Object properties	Code of the object	31
APH	Setup models	Template code	100
APR	Graphical process	Process code	63
ARP	Report definition in the dictionary	Report code	29
ASL	Conditioned style	Dealt with in the form of a condition (COD='value')	19
ASU	Description of a sub-program in the dictionary	Name of the sub-program	21
ASY	Presentation style	Style code	61
ATB	Table definition (the contents are not transferred, the update of the structure is made without losing common data)	Table code	25
ATN	Transactions	Transaction code	8
ATY	Data type	Code of the type	22
AUR	URL	URL code	27
AVW	View	Code of the view	26
AWA	Workflow rule	Code of the Workflow rule	43
AWE	Web service	Publication name	64
AWI	Window definition	Code of the window	33
AWM	Workflow data model	Model code	41
AWR	Workflow assignment rule	Code of the assignment rule	42
AWW	Setup of the Workflow workbench	Code of the workbench	44
BIA	BIAR objects	Object code	4
ELT	Element of the client interface (xsl, image, miscellaneous file)	File path	3
ETA	Crystal Reports report (file with .rpt extension)	Report name	13
EXE	Request to run a script	Script name	6
GAU	Automatic journals	Document code	40
PS1	Statistical trigger	Trigger code	37
PS2	Statistical code	Statistical code	38
TAB	Complete structure and contents of a table (excluding its 'dictionary' definition). The global patch of a table is a 'flat' save of this file: as a .dat file when saving a table in the save directory (SVG). Not all the links to this table are taken into account and especially the translatable texts contained in the ATEXTRA table.	Table code	39
TFO	Formulae table	Formula code	62
TRT	Source of a script (the script will be compiled on patch installation)	Script name	12
TXT	Text file (in the TXT directory)	Text name	5
Table abbreviation	Partial contents of the table	Extraction condition (expressed in the form of a Where clause)	100

Important notes

Total transfer of a table data

The TAB code is used to transfer the data in a table, by reloading it in the database with its structure and its data. However, the dictionary elements related to this table are not created, so the table might be hidden. Also, this code is useful when you want to reload a table already created in the folders to be patched, where the structure has not changed. If this is not the case, it is necessary to place two lines in the patch definition: the first applies to the table definition (ATB XXXXX), the second applies to its content (TAB XXXXX). Even if they are not sorted in this entry order, the patch function will replace them in the order above. At the patch integration, the table will be created in the dictionary and in the database, if it does not already exist (if not, its structure will be updated if it has changed). Then the table will be reloaded with the data.

Partial transfer of a table data

To partially transfer a table data, provide the table abbreviation in the type column and enter in the Name column a logical condition used to extract the source folder and perform the integration to the destination folder. It is important to note that the data extracted in this way can modify the existing data with the same keys, or create new data. However, for security reasons, the data may never be deleted during the patch integration. For example, in the following situation, in the country table (TCY abbreviation):

Initial folder		Target folder
Country code	Country name	Country code	Country name
AD	Andorra	AD	Andorra
AE	United Arab Emirates	AF	Afghanistan
AL	Albania	AL	Germany
AR	Argentina	AU	Australia
BE	Belgium	BE	Belgium
…		…

If in the patch the line with TCY is indicated and the condition CRY = 'AL', the patch will only contain the line corresponding to Albania, and the integration of the patch in the target folder will rewrite AL, Germany and replace it with AL, Albania.

If indicated in the patch is a line with TCY and the condition pat(CRY,'A*'), the patch will contain 4 lines AD, AE, AF and AR. On integration, the record AE, United Arab Emirates and the record AR, Argentina will be created, the AL, Germany will be replaced by Albania and keep A, Afghanistan and AU, Australia, that existed already in the target folder and were not delivered in the patch.

If in the patch there is a line with TCY and the condition find(CRY,'AD','AE','AL'), the result will be the same, except for AR, Argentina, which would not have been transferred.

The only way to delete data consists in:

• Either globally replacing the contents of a complete table (TAB type patch)
• Or supplying a script file via the EXE code (see below). For example, in order to be certain for the countries starting with an A, that only the countries with codes AD, AE or AL remained on the list, a script file would have been delivered (called MAJPATCHnnn for example), which would contain the lines described in the example below.

Running a script

One specific case must be mentioned: The EXE code, which makes it possible to give the name of a script to be run. Despite its rank number, this script is run at the end of the patch integration (it may exist beforehand or be delivered in the patch itself, since the execution is only carried out at the end of the integration).

The script must contain a subprogram called PATCH, with a parameter being the folder code. This is the subprogram that will be run. In this way, for the situation above, the following program is obtained:

Subprog PATCH(NOMDOS)
Value Char NOMDOS
Local File =NOMDOS+'.TABCOUNTRY' [TCU]
Trbegin [TCU]
Delete [TCU] Where pat(CRY,'A*')=1 & find(CRY,'AD','AE','AL')=0
Commit
End

In this way it can be seen that it is necessary to declare the tables in this subprogram whilst considering the fact that they must be declared in a folder that is not necessarily the current folder (the syntax, Local file = FOLDNAME + '.TABLENAME', ensures this).

Generic scripts to be run

When patches are carried out on model elements of the user interface (model screens used to create transaction windows), the screens concerned need to be revalidated.

This revalidation can be performed by declaring the running of the appropriate script in the maintenance. The standard scripts to be started, depending on the type of patched element, are as follows:

Patched element	Script to be launched	Result
Screen used as the basis for an inquiry which can be set up.	SUBGTC	Validation of all the inquiry screens
Presentation styles	SUBASY	Generation of the styles
System transaction	SUBAMI	Validation of the system transactions
Statistical parameters	SUBPS2	Revalidation of all the statistics
Basic screen of a transaction on object XXX	SUBXXX	Revalidation of the transactions associated with the object

This type of functionality can also be carried out within the framework of a specific development (simply add the PATCH subprogram as specified in the previous paragraph).

Documentation patch

The structure of the data in the documentation slightly differs. In effect, the following default rules are applied on folder creation and revalidation:

• The documentation texts and files (tables ADOCBLB and ADOCCLB) are entered in the supervisor folder and are not transferred to the dependent folders (it is nevertheless possible to create local help texts for a folder that will be stored locally).
• The documentation structure (documentation links, that are nearly dictionary elements, and paragraph structures) is stored in each folder and copied to those folders located below in case of revalidation (while complying with the vertical or specific activity codes that may have been defined in a child folder).

Thus the principle is as follows when integrating a doc patch (ADO type):

• The documentation structure can be integrated to all the folders listed when applying the patch, irrespective of the patch type (based on the list of folders supplied on integration)
• The texts and files are only integrated to the supervisor folder if the patch type is Supervisor (this is the case for the standard doc patches). In the event of a different patch type, the texts and files are integrated to all the folders.
• The ADF type patch (links) can be integrated to all the folders, even if the patch has the Supervisor type. Supervisor.

Selection of the configuration files

The patch integration checks the application sequencing of the patch files, whenever they include a numerical sequencing in their name. It is recommended to name the patch files using a name defined under the form X_yyyy_zzz.dat, with the following meaning:

• X is a character (different from P, since P is used to specify standard patches) that identifies the patch type
• yyyy is a sequential number (in principle starting at 0001).
• zzz is an identifier for the version to be integrated.

If this standard is applied, during the integration of a group of patch files in a directory, the following controls will be made:

• Files from different versions are not mixed during the same integration
• It is not possible to skip a sequential number if patches identified by the same character and the same version number have already been integrated. In this way for example, if the patch Z_0005_150.dat has been integrated, if an attempt to integrate patch Z_0007.140.dat is made without first having integrated the Z_0006_150.dat patch, an error message is displayed on integration.

Order of the elements in a patch file

When a patch file is created, the rule is for the elements contained in said patch file to form a consistent whole which leaves the folder consistent after it has been applied. In particular, if a new function is created by the patch, be it defined by an action, a window, a screen, a table and two scripts, it seems logical for all these elements to be part of the patch.

When some elements are used to constitute a patch file, the creation function sorts them in a specific order of types, so as to avoid integration errors. For example, if a window is integrated before the screens included in this window, the error Nonexistent screen is triggered upon validation. As a consequence the data types are always integrated before the screens and tables, the screens before the windows, and so on and so forth.

The order used on generating the patch matches the rank specified in the grid below: It is also the proposal order that appears in the automatic patch.function.

Let us underline the fact that it is impossible to solve all the possible conflicts. For instance, a data type can refer to an action, that may refer to a window, that may refer to a screen, that may refer to this data type. To solve this situation of conflict (although rare), it may be necessary to break down the patch file into two files (for instance, the first file supplying all the elements with a data type that does not refer to the action, the second file supplying the data type that integrates the action).

Dictionary elements that are not patched

If you are installing a patch containing dictionary elements, please note that some fields, considered as dictionary elements that can be set up, are complied with irrespective of their protections by means of activity codes. This is the case of a default destination in a report.

Please refer to the detailed technical appendix for details on the applicable fields.

Specific format for AAA elements

A patch of AAA type corresponds to a line coming from a setup model. It uses a specific format for the element code. This format is one of the two following:

MODELE~CODE_LEG~CODE_TRS~='FORMULE_SELECTION'

MODELE~CODE_LEG~CODE_TRS~CLE~SOUS_CLE~SOUS_SOUS_CLE...

On these lines:

• MODELE corresponds to the data model used to describe the tables to extract
• CODE_LEG corresponds to the legislation code, which can be empty (in this case, two ~ are placed one after the other)
• CODE_TRS corresponds to the transaction code, which can also be empty
• FORMULE_SELECTION is a filter condition. Any text chain must be put 'in double quotes' since the formula is put in 'simple quotes'.
• CLE~SOUS_CLE~SOUS_SOUS_CLE (the number of sub-keys being variable) corresponds to the specific case when it is required to select a key value corresponding to the model main table. It is only possible when calling up a model (AAA code) from the patch creation and then opening the window making it possible to select the model and enter the key by direct search.

Reports

By default, the following reports are associated with this function :

  PRTSCR : Screen print

This can be changed using a different setup.

Batch task

This function can be run in batch mode. The standard task ZPATCHC is provided for that purpose.

Specific Buttons

Recall

This function is used to recall the list of elements contained in a patch file in order to complete it if needed and recreate a patch file. The window that opens then is used to select the patch file to read.

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

…. : nonexistent directory

The access path for the patch file does not exist.

Object type is incorrect

The object type does not correspond either to one of the predefined objects or to the abbreviation in an existing table.

... Dictionary XXX record nonexistent

An attempt has been made to extract an object from a non-existent dictionary.

Incorrect value

The extraction condition associated with the data extraction from a table contains an incorrect syntax.

Tables used

Refer to documentation Implementation