...

• In the JS7 - System Architecture:
  
  • workflows Workflows and related objects are deployed to a Controllerone or more Controllers,orders
  • Orders are submitted to a Controller,. This operation is available from the JS7 - Daily Plan view.
  • Calendars calendars and schedules are released for use with the JS7 - Daily Plan.
• Wording
  • Deployment includes forwarding to forward objects to Controllers and Agents that are stored with the store deployed objects with their respective journal.
  • Submission includes adding to add orders to Controllers and Agents that . Submitted orders can be cancelled , or suspended and removed..
  • Releasing includes tmaking a calendar or schedule available to make JS7 - Calendars and JS7 - Schedules available for processing by the Daily Plan.
• The JOC Cockpit holds the inventory of all 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 operating to operate separate Controllers e.g. for "dev", "inttest" and "prod" environments with the same JOC Cockpit instance and to deploy objects individually or in batches to one or more Controllers.

Configuration View

Deployment

The Configuration->Inventory This view allows management of any deployable objects.

Explanation:

• Deployment operations are available:
  • from the tree panel at any folder level, with objects being deployed recursively,
  • from the detail panel that allows deployment with a single click.
• Redeplyoment Redeployment is available at folder level and allows deployment of the same versions of objects that previously had been deployed to a the given Controller.
  • This operation can be used if the Controller's journal had to be renewed and inventory objects have to be deployed once again.
• For a number of objects deployment includes to digitally sign the object:
  • JS7 - Workflows
  • JS7 - File Watching
  • JS7 - Job Resources
• Deployment is performed asynchronously.
  • This translates to the fact that the deployment result being successful or not might not become immediately visible.
    • 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 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.
  • The JS7 - Audit Log includes the information about the deployment request.

Deployment History

The JS7 - History view offers the Deployment sub-tab to verify past deployments.

Image Added

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 of Objects

Digital signing is required for Workflows, for File Order Sources and for Job Resources. 

• This process includes to create a signature from the JSON representation of the respective 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 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 a signature file with the same name and the extension .asc.
    • 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

• File Order Sources
• Job Resources
• Locks

Versioning includes that after deployment of a new version of the object the previous version remains 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 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 given dates or date ranges and to submit new orders for the same dates. This allows to specify the date starting from 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.