...

Introduction

The JS7 - Inventory offers holds objects such as JS7 - Workflows, JS7 - Job Resources, JS7 - Resource Locks etc. that implement are related by dependencies. For example, a Workflow references a Job Resource and a Resource Lock; a Schedule references a Calendar and one or more Workflows.

When deploying objects then consistency is considered like this, for example:

• If a new Job Resource is created and is referenced by a new newly created Workflow, then both deployment of the Workflow and includes to deploy the Job Resource must be deployed.
• If a Job Resource is referenced by a deployed Workflow and should be revoked or removed, then the Workflow must be revoked or removed too.

...

• When deploying objects this considers consistent deployment of dependent objects.
• When renaming objects, for example if when a Job Resource is renamed, then this updates the referencing Workflow.
• When revoking objects, for example when Controller objects such as Workflows are revoked from the Controller but remain with the inventory.
• When recalling objects, for example when Automation objects such as Schedules are recalled from the Daily Plan but remain with the inventory.
• When removing objects, for example when a Job Resource is removed which forces to remove or to revoke referencing Workflows.

...

Object dependencies work across folders that hold the objects. Therefore object Object names are unique within the scope of an object type in JS7. This allows objects to be relocated to different folders without impact on dependencies and without the need for repeated deployment or releasing of objects just because dependent objects have been moved to different folders.

Object dependencies require that all referenced objects are available with a Controller and Daily Plan. For example, if a Workflow references a Job Resource, then the Job Resource has to be available for the Controller at the point in time of deployment of the Workflow; if a Schedule is released, then the Workflow:referenced Calendar and Workflow must be released/deployed too.

• Users can deploy a number of objects in a common operation. For example, a Workflow and a Job Resource can be deployed with in a single deployment step using the Deploy operation, which is available in the tree navigation panel at folder level and from dependencies.
• Users can deploy objects individually, for example, first deploying the Job Resource and later on deploying Workflows using the Job Resource.

The recursive nature of dependencies can cause complexity, for example if a Job Resource or Notice Board should be renamed that are used by hundreds thousands of workflows. To this purpose the JS7 inventory offers automated dependency management.

Dependency Management

...

• Though it is not required, manual invocation is offered from the action menu of the root folder in the Inventory view.
• Dependency updates are performed in background. For larger environments with thousands of workflows this can take a few minutes.
• The inventory keeps track of dependencies when users add, rename or remove objects.
  
  

Showing Dependencies

For any object users can invoke the "Show dependencies" operation from the object's action menu in the navigation panel of the Inventory view. Results will be displayed from a popup window like this:

...

• Dependencies are displayed for the given workflowWorkflow.
• The workflow Workflow holds incoming references from Referencing Objects, for example from a Schedule.
• The workflow Workflow holds outgoing references from to Referenced Objects, for example to a Job Resource, Notice Board, other Workflow etc.

...

When all objects are in draft status and the deploy Deploy operation is performed for the pdDependencies-01 Workflow, then this triggers cascading objects being added to the deployment:

• Cascading objects are preselected for deployment. Users can unselect objects if they are not required for consistent deployment.
• If a Workflow is deployed, then this requires to deploy referenced objects such as Job Resources, Resource Locks etc.
• If a Schedule is released, then this includes to deploy the referenced Workflow and related objects.
  
  

...

Renaming Objects

If objects are renamed, then references are updated in referencing objects:

...

When the Job Resource is deployed then this includes deployment of the Workflow.

• The referencing workflow Workflow is selected and cannot be unselected as both updated objects must make it for a common deployment.
• Other related objects that are not affected by the Job Resource's new name, remain in the deployed status and are displayed but are not selected.
  
  

...

Revoking and Recalling Objects

When objects such as workflows Workflows are revoked, then they will be removed from the Controller but will remain in draft status with the inventory..

Similarly when objects such as schedules Schedules are recalled, then they are will be removed from the Daily Plan but will remain in draft status with the inventory.

If objects are revoked/recalled, then referencing objects must be revoked/recalled too.

• If a Job Resource should be revoked, then the referencing Workflow will similarly be suggested for revocation.
• Cascadingly the a Schedule referencing the Workflow will be recalled.
  
  

...

Removing Objects

If objects are removed from the inventory, then referencing objects must be removed too or must be revoked/recalled.

• If a Job Resource should be removed, then the referencing Workflow will similarly be suggested for removal.
• Users can unselect the Workflow which will revoke the Workflow from the Controller. The Workflow will not be removed and will remain in draft status with the inventory.
  
  

...