Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • The History Service is used to receive events about executions the execution of workflows and jobs from any connected Controllers and to add them to the JS7 - History.
  • As a result, the execution history and logs of orders and tasks becomes become available. Due to the asynchronous nature of JS7 components this task is performed by a background service.

...

The History Service connects to the Controller by use of the Proxy Service, see JS7 - System Architecture.

For any subscribed History Service instance the The Controller holds events occurring from JS7 - Order State Transitions for any subscribed History Service instance and forwards them to the History Service. After any subscribed History Service instances have received events and confirmed receipt by releasing events then the Controller will drop these events from its journal.

Behavior of the History Service in case of Outages

Should If a Controller is not be active or should the network connection to a Controller is not be available then the History Service will repeatedly try to connect. This behavior continues will continue for minutes, hours and days.

Should If a fail-over or switch-over occur with a Controller occurs then this does will not affect the History Service that which is automatically routed to the active Controller instance by use of the Proxy Service.

Behavior of the Controller in case of Outages

Should If the History Service is not be active and therefore dies not release events then such these events will remain with the Controller and will fill - up its journal. Events include any log output that is created from jobs and workflow instructions. Users should make an assumption about the maximum duration of an outage of the History Service during periods of high job frequency. The Controller's journal will grow as large as allowed within the limits of the file system. Due to the fact that individual log output of jobs is included and that jobs are executed at individual frequencies we cannot give an estimate of the growth rate. However, reserving a few GB disk space for both the Primary and Secondary Controllers' journals is required.

  • It is desired desirable that no events will be lost during an outage of the History Service or an outage of the connection between History Service and Controller no events will be lost
  • Should If users operate jobs with considerable log output at medium frequencies, e.g. > 10 000 jobs per hour, then sufficient disk space should be made available. There is no problem in having a Controller journal exceed e.g. , for example 30 GB of disk space. The journal will shrink automatically after events have been processed and have been released by the History Service.

...

  • The History Service logs general messages, warnings and errors to in the joc.log file.
  • More detailed information in addition is logged to in the Main Log service-history.log file.
  • In addition to the Main Log detailed debug information is logged to in the Debug Log service-history-debug.log file.
  • For details see see the JS7 - Log Files and Locations article.