Updates management

Administration PageApplication/ContractSyracuse/CollaborationClassupdatesRepresentationupdate

An update is a new function that can be used to patch Sage X3 People folders in an easiear way than the traditional patches.

The aim of this function is to allow "one click" updates.

Doing this is possible by selecting a file that has a new format (a set of compressed patch archives with additional meta data). This format is supplied from version 10 for all standard updates, and is described in the corresponding section.

Using the previous patch format remains possible: any list of .dat files, and especially vertical or specific delivery or updates remains possible thanks to the patching function available in Development/Utility/Patches menu of every folder.

This function allows to add updates supplied as zip file by uploading it. Once this update record is added, it is possible to modify the list of endpoints and folder on which the update should apply.

Two operations are available on an update record:
* the update testing, that will check that the update can be installed.
* the update application, that will update the selected folders and return a log file that can be displayed.

Information associated to updates

The information that must be entered for an update is as follows in different sections:

Update

This box allows you to upload the update file. You can drag and drop a file or use the file explorer. An update file is a zipped file (.zip extension) that contains a list of directories and files as defined in the appendix.

Version

Displays the final version number in which the folder updated will be after installation of the update that has been uploaded.

Dependency

Displays the minimal version number for a folder to apply the update on it.

Description

Displays the description of the update.

Patches

A update is an archive that can contain several patches list, and some of them can be optional (this happens for instance for patches managing pre-setting data). This array contains the following information:

Name

The name of the patch

Description

A more detailed description of the patch

Mandatory

This check box defines if the patch is mandatory or not.

Apply

You can modify this check-box only if the patch is not mandatory. This allows you to enable the patch installation or to disable it.

Apply to endpoints

This grid can be filled by multiple selection from the Endpoint list. Once the Endpoints are selected, the system will display the list of folders that are present in the folder, in a hierarchical array , on a section that opens when clicking on the chevron present on every endpoint line:

In this hierarchical array, you can:
* see the current version of every folder, the latest update date, the status (a message describing if the patch successfully applied, if errors were found...) and possibly a link to display the trace when the patch already applied.
* delete folders if you don't want to patch them. The folders hierarchically dependent from the folder will also be deleted from the list (a folder cannot be patched at a higher level than its reference folder). In the picture given previously, deleting the folder SEED2 from the list can be done independently from the others, while deleting the folder SEEDPROD from the list will also delete SEEDPROD2, and deleting the root folder (PAIE) will delete all the folders.

The reasons why you can deactivate the update on some folders can be one of the following:
* the folder is an old one that is no more used but has not yet been deleted; patching it would be a waste of time.
* the folder is folder that is not frequently used, on which the update application can be postponed. This can be the case for example on a history folder, that stores a lot of data. As some patches can modify the data structure, it can take a long time.

Take care that a folder on which the patch has not been applied will no more be usable until it is in the same patch level than his reference folder.

Operations available on a patch

The following operations are available:

Test update

This function is executed in asynchronous mode, and tests, for every folder present in the list, if the conditions are fulfilled to apply the patch. The version dependencies are checked, a popup displays the progress of the execution:

Apply update

This function is also executed in asynchronous mode, and tests if, with the same type of popup to display the progress?

Technical details about the patch testing or application

Execution order

Technically, the patch test and application is based on the batch server. The system stops first the batch server, starts it in a mode that disables all the normal batch tasks to work, and launches the patch application or test in parallel on folders, in descending level order. This means, that, in the case of the folder hierarchy displayed previously, the system will:
* first apply on PAIE folder, and wait until the patch has been successfully applied
* then, apply on SEEDPROD, SEED2, and SEED. As they are located at the same level, the application will be done in parallel on all these folder.
* when the application will be successfully finished on SEEDPROD, apply on SEEDPROD2

Resuming a patch application after an error

If the application of the patch isn't successful for any reason (stop of the server or the database, error that doesn't allow to integrate a given patch), the corresponding error status will be displayed on the corresponding folders.

If the error is linked to an inconsistency on a folder, you will of course have to fix the inconsistency before the patch can apply again. To restart the patching process, you just need to come back to the patch application (or to refresh the page if you are still on the page), and to launch again the application. The system will automatically restart and apply the patch starting from the stopping point.

Appendix : format of the patch archive

The patch archive is a zip file that contains:
* a list of folders containing a patch hierarchy files.
* a configuration file in json format that contains the meta data necessary to know the content of the archive.

An example of such a file is given here:

{"name": "X3V8_P2","version": "8.0.2","dependency": "8.0.1","description": "Update that brings Sage X3 People From version 8.0.1 to 8.0.2","patches": [{"name": "X3V8_P2","type": "$ROOT","mandatory": true,"path": "X3V8_P2/FILPATCH","description": "8.0.2 mandatory maintenances"},{"name": "X3V8_P2BIS","type": "HRM","mandatory": false,"path": "X3V8_P2BIS/FILPATCH","description": "8.0.2 optional maintenances"}]}

In the previous description:
* the version and dependency conditions are given in the header
* the patches collection describes 2 patches by giving their name, type, the relative path where the .dat files will be found, ans the mandatory property.