Introduction

• The History View includes a number of sub-views to display the
  • JS7 - Order History for the execution of orders passing workflow and jobs,
  • JS7 - Task History for the execution of tasks and respective 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 submissions of orders for the respective 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 that receives events.
  • 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 entries on the fly for all users connected to JOC Cockpit.
• Any sub-views of the History View offer to export history items to 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 if e.g. 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 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 events are released from a Controller's journal. Consider that the Controller journal can grow in case of longer outages of the History Service if a larger number of jobs and/or jobs with abundant log output are 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.
• The History Service will resume after an outage and will continue to receive events from a Controller and write them 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 entries.

By default the Cleanup Service will purge history entries older than 90 days. The Cleanup Service can be configured for an arbitrary retention period of history entries, 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 passive JOC Cockpit instances.
• The History Service will fail-over to the next active JOC Cockpit instance in case of outage of the current JOC Cockpit instance.