JS7 JobScheduler

Space shortcuts

Page tree

Versions Compared

Old Version 7

changes.mady.by.user Andreas Püschel

Saved on

compared with

New Version 8

changes.mady.by.user Alan Amos

Saved on

Key

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

...

  • 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 to forward forwarding objects to Controllers and Agents that store deployed objects with their respective journal.
    • Submission includes to add adding orders to Controllers and Agents. Submitted orders can be cancelled or suspended..
    • Releasing objects includes to make 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 to operate the operation of separate Controllers e.g. for "dev", "test" and "prod" environments with the same JOC Cockpit instance and to deploy the deployment of objects individually or in batches to one or more Controllers.
  • For underlying security requirements see JS7 - Secure Deployment.

...

  • Deployment operations are available:
    • from the tree panel at any folder level, with objects being deployed recursively,
    • from the detail panel that allows ,  allow 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 the 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 to digitally sign 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 being successful or not might not become immediately visiblewas 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 respective 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 to verify the deployment status to be verified.
    • The JS7 - Audit Log includes the information about the deployment request.

Deployment History

The JS7 - History view offers provides the Deployment sub-tab to verify 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 that a Controller or Agent is not accessible.

...

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

  • This process includes to create creating a signature from the JSON representation of the respective 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 for each inventory file to create 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.

...

The following deployable objects are not versioned:

Versioning includes means that after deployment of a new version of the an object, the previous version remains 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 to manage 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 to cancel submitted orders for a given date or date ranges and to submit to be cancelled and the submission of new orders for the same dates. This allows to specify specification of the date starting from 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.

...