Versions Compared

Key

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

Table of Contents

Introduction

  • In the JS7 - System Architecture
    • Workflows and related objects are deployed to one or more Controllers and Agents,
    • Orders are submitted to a Controller. This operation is available from the JS7 - Daily Plan view,
    • Calendars and Schedules are released for use with the JS7 - Daily Plan.
  • Wording
    • Deployment includes forwarding objects to Controllers and Agents that store deployed objects with their respective journal.
    • Submission includes adding orders to Controllers and Agents. Submitted orders can be cancelled or suspended..
    • Releasing objects includes making JS7 - Calendars and JS7 - Schedules available for processing by the Daily Plan.
  • The JOC Cockpit holds the inventory of objects that can be deployed to one or more Controllers.
    • Any Controllers connected to a JOC Cockpit instance can act as a deployment target.
    • Use cases include the operation of separate Controllers e.g. for "dev", "test" and "prod" environments with the same JOC Cockpit instance and the deployment of objects individually or in batches to one or more Controllers.
  • For underlying security requirements see JS7 - Secure Deployment of Scheduling Objects.

Deployment

The Configuration->Inventory view allows management of deployable objects:

...

  • Deployment operations are available:
    • from the tree panel at any folder level, with objects being deployed recursively,
    • from the detail panel, allowing deployment with a single click.
  • Redeployment is available at folder level and allows deployment of the same versions of objects that previously had been deployed to a given Controller.
    • This operation can be used if the Controller's journal has had to be renewed and inventory objects have to be deployed once again.
  • For a number of objects, deployment includes digitally signing of the object:
  • Deployment is performed asynchronously.
    • This translates to the fact that it might not be immediately visible whether or not the deployment result was successful.
      • A Controller or Agent might not be available at the point in time of deployment. The deployment is completed only after an Agent acknowledges receipt of the deployed objects to a Controller and the Controller confirms deployment to JOC Cockpit.
      • Unavailability of Controllers or Agents does not prevent deployment but causes delays for the deployment result to become available after the connection to the relevant Controller and Agent has been restored. This mechanism recovers deployment results after outages for minutes, hours or days. However, if the JOC Cockpit is restarted during an outage then the deployment result cannot be verified. In this situation users should repeat pending deployments.
    • The History->Deployment History view allows the deployment status to be verified.
    • The JS7 - Audit Log includes the information about the deployment request.

Deployment History

The JS7 - History view provides the Deployment sub-tab for the verification of past deployments:

...

Find further details from JS7 - Deployment History.

Digital Signing of Objects

Digital signing is required for Workflows, File Order Sources and Job Resources required for JS7 - Secure Deployment of Scheduling Objects.

...

  • Security Level Low
    • Inventory objects are automatically signed with the private key that is stored with the "root" account.
    • Signing is automatically applied when performing the "Deploy" operation.
  • Security Level Medium
    • Inventory objects are automatically signed with the private key that is stored with the current user's account.
    • Signing is automatically applied when performing the "Deploy" operation.
  • Security Level High
    • Inventory objects are signed outside of the JOC Cockpit:
      • Inventory objects are exported using the "Export" operation that offers the option "for signing".
      • The export archive is transferred to a secure device, e.g. to a secure desktop machine.
      • The export archive is extracted and each inventory object file included is individually signed. 
        • There is no pre-requisite about the tools used for signing, 
        • For example, the OpenSSL command line utility can be used and tools such as OpenPGP Kleopatra can be used.
        • The signing step includes the creation of a signature file with the same name and the extension .asc for each inventory file.
      • The signed inventory files and signature files are added to the same or to a new archive file.
    • The archive file that includes signatures for inventory objects is imported to JOC Cockpit. The deployment step is performed inline with the import step.

Versioning of Objects

The following deployable objects are versioned:

...

  • orders in current execution of a workflow will use the previously deployed version of the workflow.
  • submitted orders that will start later on will use the updated version of the workflow.

Further Resources

Display children header