In SYSPRO, self-healing refers to the automatic process in a client/server environment where various components of SYSPRO are updated on the client. This is particularly useful in an environment where a large number of workstations are located in significantly different geographical locations, and where a re-install on each client would be overly cumbersome.
The self-healing process is managed by the system administrator who typically downloads and unpacks the relevant patches and applies them to the server using the SYSPRO Software Upgrade program.
The self-healing process is activated when a client connects to the server and starts using a component for which an update exists. The updated file is copied from the server to the client. This is generally a targeted process in that only the component required at that point in time is copied to the client. The exception to this is the SYSPRO help files which are all copied to the client when the help is called up the first time.
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).
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.
Once the screensets have been removed on the client, the VERGUI.TXT file on the server is transferred to the client.
When you select to run a program from the SYSPRO menu 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.
When each screenset is self-healed, its associated controls (e.g. listviews, tree views, toolbars, status bars, explorer controls, etc.,) are also self-healed. These are transferred from the Base\Bin folder on the server to the Base\Bin folder on the client. The program controls are prefixed by the screenset name (e.g. 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).
This process repeats itself each time a SYSPRO software upgrade takes place on the server.
Executable files such as SYSPROClient.EXE cannot be updated while active in memory. The self-healing process handles this as follows:
When an operator retrieves the SYSPRO Help, the system compares the help on the client to the help on the server. The latest help files located on the server are copied to the client in a single process. These files are copied to the Base\Htmlhelp folder of your SYSPRO installation.
Codejocks are reusable software components that enhance the Graphical User Interface of Windows Desktop Applications. The Codejock and ChartFX controls reside in the Base\controls folder of your SYSPRO installation.
These controls contain embedded forms, listviews, charts and other components used by the screensets. When logging into SYSPRO on a client machine, the menu system checks whether these controls exist. 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. Although these controls are COM (Component Object Model) components, they do not have to be registered on any machine because the main SYSPRO executables (SYSPROClient.EXE, SYSPRO.EXE) contain manifests that include all the required registry information.
These controls support the use of .NET User Controls as well as SYSPRO Reporting Services Document Printing. There are two SYSPROInteropHostControl files that reside in the SYSPRO Base folder - SYSPROInteropHostControl.dll and 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 register SYSPROInteropHostControl40.dll on the client machine using REGASM.EXE (e.g. regasm /codebase SYSPROInteropHostControl40.dll).
Managed Assemblies are customized Microsoft .NET User controls, often designed by a third party developer to perform custom functionality. Managed Assemblies reside in the Base\ManagedAssemblies folder of your SYSPRO installation. Although only a few SYSPRO .NET user controls are shipped, 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 all the contents of the ManagedAssemblies folder on the server are copied to the Base\ManagedAssemblies folder on the client.
The release of a new SYSPRO client executable is accompanied by a set of files to establish whether an update is required. The following files are included:
| File | Description |
|---|---|
| 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 the date that the new
executable was built. The file includes a VER= entry that is a 10 character field which typically contains the last change date in CCYY-MM-DD format. |
The version text file (i.e. SYSPROClient_VER.txt) is compared to the file on the client (i.e. SYSPROClientVersion.txt). If it is different, then the three files are transferred to the client. The SYSPROClient_SET.exe executable is run on the client.
When you re-load SYSPRO, the VER= entry on the client and server should match and no further updates are performed until a new SYSPRO client executable is shipped.
You can force a reinstall of the client executable at any time by editing the SYSPROClient_VER.txt file and changing the VER= entry.
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).
Self-healing occurs if the version entries differ. On the server, all the workflow components are copied from the Base folder to the Base\SYSPROWorkflow folder. 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 and any SRS-specific files or common files are placed into the Base folder on the server.
The upgrade process runs in two phases. The first phase occurs on the server and the second phase occurs between the server and the client.
The SRS and SYSPRO Analytics self-healing process interrogates the IMPHEA.IMP file (located in the Programs folder on the server) and the HEALVER.TXT file (located in the Base\SYSPROAnalytics folder on the server). Each of these files has an entry that contains software version information. Self-healing is initiated if the version information contained in these two files differs. If the version number in IMPHEA.IMP is greater than that contained in HEALVER.TXT (or if the HEALVER.TXT file cannot be found) then the common files are copied from the Base folder on the server to the Base\SYSPROAnalytics folder on the server. This process applies to both SRS and SYSPRO Analytics; they compare the same files and implement the same self-healing procedure.
Once the self-healing process is completed on the server, the upgrade process compares the software version information entry contained in the Programs\IMPHEA.IMP file on the server and the Base\HEALVER.TXT file on the client. Self-healing is initiated if the version information in these two files differs. If the version number in IMPHEA.IMP on the server is greater than what is contained in the HEALVER.TXT file on the client (or if the HEALVER.TXT file cannot be found on the client) then the SRS and common files are copied from the Base folder on the server to the Base folder on the client and the SYSPRO Analytics files are copied from the Base\SYSPROAnalytics folder on the server to the Base\SYSPROAnalytics folder on 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:
The client software determines the file sizes of the following dictionary files:
Lang_??.TXT
base\settings\Lang_??_Custom_Dictionary.TXT
base\settings\Lang_??_Global_Replace_Dictionary.TXT
(where ?? indicates the language code)
This information is passed to the server software, which determines the file sizes of the same files on the server (if they exist).
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.
The self-healing process may take a few seconds while the files are being transferred.