SYSPRO Self-healing

Managed Assemblies are Microsoft .NET User controls typically developed using the Microsoft .NET Framework.

These include standard libraries shipped as part of the SYSPRO product and may also contain components designed by a third party developer to perform custom functionality.

Use the Upload Files to Server program ( SYSPRO Ribbon bar > Administration > Customization) if you are a developer and have created new, or updated existing, Microsoft .NET User controls (i.e. managed assemblies) that require loading onto the server.

This will then transfer your .NET User Control to the server in such a way that the files will also be self-healed to each client.

Codejocks are reusable software components that enhance the Graphical User Interface of Windows Desktop Applications.

The following explains how the self-healing functionality synchronizes screensets:

1. Each time you log in to SYSPRO, the system compares a VERGUI.TXT file on the server with a VERGUI.TXT file on the client (located in the \Screens folder of your SYSPRO installation).

2. If the program detects a difference between the VER= entries (usually because new software has been installed on the server) then all the screensets on the client are removed.

3. Once the screensets have been removed on the client, the VERGUI.TXT file on the server is transferred to the client.

4. When you select to run any SYSPRO program, the size of the screenset file on the client is compared to the size of the screenset on the server.

   If they are the same size, then the screenset on the client is run and the program continues as normal.

   However, if the size differs (or there is no screenset on the client) then the latest screenset from the server is transferred to the client screenset folder.

   This transfer is handled by SYSPRO automatically. After the screenset has been transferred to the client, it remains on the client for future use.

   All this happens seamlessly and, unless you are running SYSPRO over a relatively slow WAN, you will not notice that it has occurred.

   All files that are self-healed are compressed during the transfer to reduce network traffic and provide the best performance.

5. When each screenset is self-healed, its associated controls are also self-healed:

   • List views

   • Tree views

   • Toolbars

   • Status bars

   • Forms, etc.

   These are transferred from the \Base\Bin folder on the server to the \Base\Bin folder on the client.

   In addition, the associated files in the \Base\UI folder are self-healed at the same time as the files in the \Base\Bin folder.

   The program controls are prefixed by the screenset name.

   For example:

   The screenset for the Inventory Query program (INVPEN) is called INVPEN.RS. The associated program controls in the \Base\Bin folder are named INVPEN??.INT.

Executable files (such as SYSPROClient.EXE) cannot be updated while active in memory.

Therefore, the following process explains how the self-healing process handles the SYSPRO client executable:

1. The release of a new SYSPRO client executable is accompanied by the following set of files to establish whether an update is required:

   • SYSPROClient_NEW.exe

     This is the new executable that will be named SYSPROClient.exe on the client.

   • SYSPROClient_SET.exe

     This is the setup program that will rename the file on the client to SYSPROClient.exe.

   • SYSPROClient_VER.txt

     This text file contains a VER= entry that is a 10 character field which typically contains the last change date in CCYY-MM-DD format.

   These new files are downloaded into the server \Base folder, but remain inactive alongside the active SYSPROClient.EXE:

2. The next time the user logs into SYSPRO, the self-healing process will verify the VER= entries of the SYSPROClient_VER.TXT file in both the server and client.

   If these entries differ, the system will transfer the three new files from the server \Base folder to the client \Base folder.

3. The system detects that this has occurred and will then automatically run SYSPROClient_SET.EXE on the client.

   When SYSPROClient_SET.EXE is running, the regular SYSPROClient.EXE has already exited - and is therefore not locking the standard client executable.

4. The SYSPROClient_NEW.EXE file is then copied over the top of SYSPROClient.EXE.

5. The user will then be notified that the new client executable has been installed and that they simply need to re-run the standard client executable – this will run the new SYSPROClient.EXE.

The Codejock and ChartFX controls reside in the \Base\Controls folder of your SYSPRO installation. These controls contain embedded forms, list views, charts and other components used by the screensets.

The following process explains how the self-healing functionality handles Codejocks and ChartFX Controls:

1. When logging into SYSPRO on a client machine, the menu system checks whether these controls exist.

2. If they don't exist (or are not the correct version) then the controls are copied from the \Base\Controls folder on server to the client.

   As the SYSPRO executables contain appropriate manifests, there is no requirement to register these components.

There are two SYSPROInteropHostControl files that reside in the SYSPRO \Base folder:

• SYSPROInteropHostControl.dll

• SYSPROInteropHostControl40.dll.

If the SYSPROInteropHostControl.dll is not found, then SYSPRO will not start. It will create an entry in the Windows Event log indicating a side-by-side error message.

You must then register SYSPROInteropHostControl40.dll on the client machine using REGASM.EXE.

For example:

regasm /codebase SYSPROInteropHostControl40.dll

Managed Assemblies reside in the \Base\ManagedAssemblies folder of your SYSPRO installation.

Self-healing is based on changes made to the folder on the server.

If the last modified date has changed (typically because of a third party publishing a new Microsoft .NET user control) then the entire contents of the \Base\ManagedAssemblies folder on the server are copied to the \Base\ManagedAssemblies folder on the client.

There are some additional core client components of SYSPRO 8 that may require self-healing.

Specific checks for files in the \Base folder are used to determine when these components require self-healing.

You will be notified when self-healing has occurred for these components.

When you exit SYSPRO and reload the client, the newly-updated components will be in use.

The self-healing process for SYSPRO Workflow Services involves comparing the version entry contained in the IMPSWS.IMP file (located in the Programs folder on the SYSPRO server) and SWSVER.TXT file (located in the \Base folder on the SYSPRO client).

If the version entries differ, self-healing occurs as follows:

1. On the server, all the workflow components are copied from the \Base folder to the \Base\Workflow folder.

2. Thereafter, all the workflow components in the \Base\SYSPROWorkflow folder on the server are copied to the \Base\SYSPROWorkflow folder on the client.

SYSPRO Reporting Services and SYSPRO Analytics are closely bound with regard to self-healing. When SRS initiates a self-healing session, SYSPRO Analytics is self-healed at the same time, and vice versa.

When new ports are downloaded and extracted (using IMPUPD) any SRS-specific files are installed in the SYSPRO \Base folder, while any specific SYSPRO Analytics files are loaded into the \Base\SYSPROAnalytics folder.

There is a group of files common to both SRS and SYSPRO Analytics. Referred to as the common files, they reside in the SYSPRO \Base folder.

SRS can directly accesses the common files, but SYSPRO Analytics requires the common files to be copied to the \Base\SYSPROAnalytics folder before they can be accessed.

Whenever an upgrade occurs:

• SYSPRO Analytics-specific files are placed directly into the \Base\SYSPROAnalytics folder on the server.

• SRS-specific files or common files are placed into the \Base folder on the server.

The upgrade process runs in two phases:

1. The first phase occurs on the server.

2. The second phase occurs between the server and the client.

In a client/server environment, the system attempts to self-heal dictionaries from the server to the client.

This is done as follows:

1. The client software determines the file sizes of the following dictionary files:

   • Base\Lang_??.TXT

   • Base\settings\Lang_??_Custom_Dictionary.TXT

   • Base\settings\Lang_??_Global_Replace_Dictionary.TXT

     (where ?? indicates the language code)

2. This information is passed to the server software, which determines the file sizes of the same files on the server (if they exist).

3. Any of these files which exist on the server, but not on the client, are then transferred to the client.

   If the files currently exist on both the server and the client, but the file sizes differ, then the files are transferred from the server to the client. In this way, changes to the dictionaries are automatically self-healed.