Loading...
 

Updates

Updates (module exchange)

Updates in ClassiX are called diffs. Diffs are created by ClassiX at regular intervals and contain all changes (module extensions, DLL extensions and error corrections) that have been made since the last software release (the last diff). The diffs are created individually for each customer, so the cycle of replacement may vary from customer to customer.

1. delivery Diffs

The diff is a zip file which is sent to the customer by email or file transfer. If the diff contains new DLLs (program libraries), it is not possible to deliver it by email due to its size. DLLs are provided separately via FTP server.

The name of the zip file consists of the customer's abbreviation and the consecutive diff number itself (e.g.: CUSTOMER-4.4.111.zip is the 111th diff for CUSTOMER).

2. analysis of the diff

The diff always contains a file changes.html. This file describes which changes have been made since the last diff. Based on this file

  • any necessary data updates or reorganisation runs must be initiated
  • the user areas affected by the changes can be informed about the changes
  • you can make your own tests regarding the changes.

3. testing the diff

A diff, which has been delivered by ClassiX, has already been subjected to quality assurance. Nevertheless, the diff should first be imported into a test system before being transferred to the real system. Depending on the support model, the customer has to check once again whether the changes made in the standard system harmonise with the customer-specific adjustments. In addition, an overview of the changes should first be obtained in the test system and the changes in schools should also be checked using the test system before the diff is transferred directly into the real system.

Note: A separate test system is characterised not only by its own test database but also by its own module and DLL directories etc.

4. recording the diff

The recording of the diff in the real system does not differ from the recording in the test system. The necessary procedure therefore only needs to be described once here:

  • A new diff can only be recorded if all previous diffs have been recorded. So before importing, make sure that the current AppsWH version (the number of the last diff) is the direct predecessor of the new diff version to be imported.
  • The zip file must be extracted into a separate directory. Usually this directory is called "Label", is located below the Classix directory and is therefore on the same level as the main directory (CX_ROOTDIR) of the real system. ( ../ClassiX/Label)
  • After unzipping the zip file you can see that besides folders like AppsWH, System, etc. (the number and the name of the folders can vary depending on the size of the diff) the file changes.html is always included in a diff.
  • With this changes.html file the diff has to be analysed. This file is displayed in the browser by double-clicking it. Right below the first title "Jobs" you can jump to the description of the changes contained in the diff (jump to changes...)
  • It is necessary to obtain an overview of the action to be taken after transferring the files to this machine before loading them. If, for example, the diff contains files of the type workflows (*.wfl), transaction descriptions (*.txn) or reports (*.rpt), these must be imported immediately after the diff has been imported using the corresponding modules.

    Entries with an identifier "#######" must be given special attention. These are notes on the work that must be carried out after the files have been transferred.
  • Now the files are transferred: all files and folders in the extracted directory are to be copied into the ROOTDIR (./ClassiX/"Customer") directory.

5. DLL exchange

DLLs are programme libraries which are usually located in the directory ..\ClassiX\KUNDE\Bin (see also the general overview of the folders). It makes sense to create further subdirectories below the Bin directory in order to be able to manage different programme versions.

If a new DLL version is available, the packed file is unpacked and copied as a subdirectory of the bin directory.

Finally, the file for starting ClassiX (..\Classix\KUNDE\Projects\KUNDE_init.bat) must be saved under the entry CX_BIN=... must be adapted.

6. reworking

After a restart the module and programme changes are available. Please pay attention to the display of the DLL and AppsWH version numbers in the start screen. These should be the same as the versions you have just installed.

Now, any tasks that may have to be carried out must also be carried out immediately: