JS7 JobScheduler

Space shortcuts

Page tree

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:


Explanation:

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


Explanation:

  • The deployment status is "deployed" or "not deployed".
  • This status can be updated at a later point in time by asynchronous operations in case a Controller or Agent is not accessible.

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.

  • This process includes creating a signature from the JSON representation of an inventory object.

Depending on the JOC Cockpit security level in use, the signing process includes the following steps:

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

  • Workflows

The following deployable objects are not versioned:

Versioning means that after deployment of a new version of an object, the previous version will remain in place as long as any orders are assigned the object. Practically speaking: a newly deployed workflow does not become effective for orders that have already been submitted for a previous version of the workflow. 

  • This allows management of the point in time when a new version of a workflow becomes active.
    • Already submitted orders use the previous version of the workflow.
    • Newly submitted orders use the updated version of the workflow.
  • The JS7 - Daily Plan view allows submitted orders for a given date or date ranges to be cancelled and the submission of new orders for the same dates. This allows specification of the date after which the updated workflow is used by newly submitted orders. 

For non-versioned objects deployment boils down to the fact that:

  • 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

Pages

 
 

Navigation


  • No labels