...

• 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.

...

The asynchronous nature of events is designed for resilience, however, at the same time performance cannot be predicted individually for each history item. As a rule of thumb history entries 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 entries items with the History View in 3s.

Resilience

 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.

...

The JS7 - Cleanup Service is operated to purge older history data 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:

...