Introduction
The JS7 - Inventory holds objects such as JS7 - Workflows, JS7 - Job Resources, JS7 - Resource Locks etc. that 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, for example:
- If a Job Resource is created and is referenced by a newly created Workflow, then deployment of the Workflow includes to deploy the Job Resource.
- 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.
JS7 inventory operations on objects automatically consider dependencies:
- When deploying objects this considers consistent deployment of dependent objects.
- When renaming objects, for example 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.
FEATURE AVAILABILITY STARTING FROM RELEASE 2.7.2
Object Dependencies
Objects hold outgoing references to other objects and incoming references from other objects. The matrix looks like this:
Area | Object Type | Incoming References | Outgoing References | ||||||
---|---|---|---|---|---|---|---|---|---|
Controller | |||||||||
Workflow | Workflow | Schedule | Workflow | Job Resource | Notice Board | Resource Lock | Job Template | Script Include | |
File Order Source | Workflow | ||||||||
Job Resource | Workflow | ||||||||
Notice Board | Workflow | ||||||||
Resource Lock | Workflow | ||||||||
Automation | |||||||||
Schedule | Workflow | Calendar | |||||||
Calendar | Schedule | ||||||||
Job Template | Workflow | ||||||||
Script Include | Workflow |
Object dependencies work across folders that hold the objects. Object names are unique within the scope of an object type. 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 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 in a single deployment step using the Deploy operation, which is available in the 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 thousands of workflows. To this purpose the JS7 inventory offers dependency management.
Dependency Management
Updating Dependencies
The JS7 automatically keeps track of object dependencies.
- 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:
Explanations:
- Dependencies are displayed for the given Workflow.
- The Workflow holds incoming references from Referencing Objects, for example from a Schedule.
- The Workflow holds outgoing references to Referenced Objects, for example to a Job Resource, Notice Board, other Workflow etc.
Example
The example makes use of the object name pdDependencies-01 for all object types that implement dependencies. Accordingly pdDependencies-02 is the common name of a second set of objects.
Object dependencies are implemented like this:
- The pdDependencies-01 Workflow references the pdDependencies-01 Job Resource and the pdDependencies-01 Resource Lock.
- The Workflow references the pdDependencies-02 Workflow from a JS7 - AddOrder Instruction.
- The Workflow references the pdDependencies-02 Notice Board
- The pdDependencies-02 Workflow references the pdDependencies-02 Notice Board etc.
Deploying and Releasing Objects
When all objects are in draft status and the 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:
- If a Job Resource is renamed then the referencing Workflow is updated to hold the correct reference.
- Both the Job Resource and Workflow are set to draft status.
When the Job Resource is deployed then this includes deployment of the Workflow.
- The referencing 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 deployed status and are displayed but are not selected.
Revoking and Recalling Objects
When objects such as 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 are recalled, then they 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 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.
Users who accidentally removed cascading objects can restore objects from the trash, see JS7 - Inventory.