You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Introduction

The JS7 - Inventory offers objects such as JS7 - WorkflowsJS7 - Job ResourcesJS7 - Resource Locks etc. that implement dependencies. For example, a Workflow references a Job Resource and a Resource Lock.

When deploying objects then consistency is considered like this:

  • If a new Job Resource is created and is referenced by a new Workflow, then both the Workflow and 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.

JS7 inventory operations on objects automatically consider dependencies:

  • When deploying objects this considers consistent deployment of dependent objects.
  • When renaming objects, for example if a Job Resource is renamed 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:

AreaObject TypeIncoming ReferencesOutgoing References
Controller









WorkflowWorkflowScheduleWorkflowJob ResourceNotice BoardResource LockJob TemplateScript Include

File Order Source

Workflow





Job ResourceWorkflow







Notice BoardWorkflow







Resource Lock

Workflow






Automation









Schedule

WorkflowCalendar




CalendarSchedule







Job TemplateWorkflow







Script IncludeWorkflow







Object dependencies work across folders that hold the objects. Therefore 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 of objects just because dependent objects have been moved to different folders.

Object dependencies require that all referenced objects are available with a Controller. 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:

  • Users can deploy a number of objects in a common operation. For example, a Workflow and a Job Resource can be deployed with a single deployment step using the Deploy operation, which is available in the tree 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 of workflows. To this purpose the JS7 offers automated 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.

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 from 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 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.

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 the deployed status and are displayed but are not selected.

Removing Objects

If objects are removed 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 remain in draft status with the inventory.




  • No labels