...

• 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 items on-the-fly for all users connected to an active JOC Cockpit instance.
• Any sub-views of the History View offer to export history items to files in Excel® format.

...

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

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

...

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

...