Introduction

• The History View includes a number of sub-views to display the:
  • JS7 - Order History for the execution of orders passing workflows and jobs,
  • JS7 - Task History for the execution of tasks and their log output,
  • JS7 - File Transfer History for details about transfers performed with the YADE Add-on,
  • JS7 - Deployment History with information about objects such as workflows deployed to a Controller,
  • JS7 - Daily Plan History for details about submission of orders for a particular Daily Plan date.
• The JS7 History works asynchronously:
  • Events about JS7 - Order State Transitions can occur with the Agent and with the Controller.
  • Such events are subscribed to by the JS7 - History Service background task.
  • Events include state transitions and log output of jobs that are added to the JS7 - Database and are available with the History View.
• The History Service works independently from user interaction and displays added or updated history items on-the-fly for all users connected to an active JOC Cockpit instance.
• All sub-views of the History View allow history items to be exported as files in Excel® format.

Controller Interaction

The JS7 - History Service is a background service that receives events from connected Controllers and adds information about order state transitions and log output to the database.

• The History Service automatically subscribes to events from any active Controller instance connected with JOC Cockpit.
• The service acknowledges receipt and processing of events to the originating Controller. The Controller will then release events and will drop them from its journal.
• With a number of JOC Cockpit instances being in place only one JOC Cockpit instance can acquire the active role of running the History Service and related services. Any additional JOC Cockpit instances share the history information from the database but will not receive near real-time events about added or updated history entries.

Performance

The asynchronous nature of events is designed for resilience, at the same time performance cannot be predicted individually for each history item. As a rule of thumb history items are available in near real-time within 2-3s.

• Performance of the History Service depends on the following factors:
  • Database performance is essential for the History Service to persist data in good time.
  • If a larger number of tasks are starting and completing in short intervals then the workload of the History Service will increase. This can cause delays for order and task history entries becoming visible with the History View. No history entries will be lost, however, it could take minutes for history entries to become available, e.g. if 100 tasks are starting and completing per second.
• Reasonable performance can be expected for approx. 30 tasks completing per second which includes visibility of history items with the History View in 2-3s.

Resilience

 The History Service supports a number of outage scenarios:

• In case of outage of the Primary Controller instance the History Service will automatically switch to the Secondary Controller instance to retrieve history items. Fail-over typically takes place within 10s.
• In case of outage of the History Service the Controller will store events with its journal until the History Service is up again and will acknowledge receipt of events. Only then will events be released from the Controller's journal. Note that the Controller journal can grow during longer outages of the History Service if a larger number of jobs and/or abundant log output of jobs have to be handled by the Controller. Therefore a Controller should be assigned sufficient storage to hold its journal for the maximum expected duration of an outage of JOC Cockpit, see JS7 - Sizing.
• The History Service will resume operation after an outage and will continue to receive events from a Controller and to write events to the database.

Cleanup Service Interaction

The JS7 - Cleanup Service is operated to purge older history items from the above views. Therefore the Cleanup Service limits the lifetime of history items.

By default the Cleanup Service will purge history items older than 90 days. The Cleanup Service can be configured for individual retention periods of history items, see JS7 - History Service.

Cluster Operation

The History Service is operated with a JOC Cockpit active-passive cluster:

• Only one instance of JOC Cockpit and of the History Service is active at a given point in time.
• The history information provided from the active History Service instance is available to any active and passive JOC Cockpit instances. The active JOC Cockpit instance only will receive near real-time events and will update the GUI automatically, any passive JOC Cockpit instances will display the updated history if the user navigates to the respective History View.
• The History Service will fail-over to the next active JOC Cockpit instance in case of outage of the current JOC Cockpit instance.

Further Resources