Operating principle
This chapter covers the operating principle of the IBI-aws Client application. It first explains the behavior of the application when an error occurs. Then it explains the steps that the application performs when particular events occur at startup or during continuous operation.
Capture of Warnings, Errors, and Logs
The IBI-aws Client application is capable of capturing certain events that occur during operation.
The application distinguishes three types of events: warnings, errors and information.
Warnings and errors are collected in one file. If a warning or error needs to be captured, the application tries to document the event in a file. For this to happen, there must be a folder named Errors in the directory in which the remark file is located. If the event cannot be captured in the error log file, it is entered into the event log of the operating system. In contrast to warnings, when an error occurs and has been captured, the application stops. Warnings are marked with a W in the error log file; errors are always marked with an E.
In addition to warnings and errors, certain operating information can be captured. This information is stored in a separate file. For the capture to succeed, a folder called Logs must be created in the directory in which the remark file is located. If capture of the information in that folder fails, the IBI-aws Client application stops automatically. Unlike errors and warnings, an event of this type is not entered in the operating system’s event log. To capture events of this type, the appropriate function must first be activated by starting the application with the appropriate start parameter (e.g., see LogFileModCheck). The capture of errors and warnings is activated by default.
The storage location of log files can be moved by specifying the appropriate start parameter (ErrorLogPath or LogPath).
Behavior upon starting the application
After startup, the IBI-aws Client application by default first creates a copy of itself in the user’s local application data directory then runs this instance and terminates itself. This step is executed in order to reduce network dependence to a minimum. This permits the application to continue running even if the network connection is interrupted.
The start parameter /NoLocalCopy makes it possible to prevent the creation of a copy in the local application data directory. However, this parameter should be used only if the application has already been started from a local storage location.
If the locally saved application runs successfully, the information is read in from the remark file.
The application starts three attempts in an interval of 15 seconds to find the remark file. If this fails, the application will search every ten minutes again.
Once the remark file is found it will be copied to the local application data directory and the application will read the information from the remark file.
The diagram below shows how the application behaves after startup.
Behavior during operation
During operation, the IBI-aws Client application checks the remark file for changes at regular intervals. If the remark file has been changed since last access, a copy of the remark file is created in the user’s local application data directory. This keeps accessing of the centrally stored file to a minimum. Then remark data are synchronized.
The following diagram illustrates this process.
If a remark file is missing during operation (for example because of a missing network connection), the application behaves as though the remark file has not been modified. This means that if an event linked to these remarks occurs, the application will continue to display all remarks that were read during the last successful synchronization.