• The JS7 inventory holds all scheduling objects for deployment and submission to one or more Controllers.
  • The inventory is the single source for management and deployment of objects.
    • JOC Cockpit stores scheduling objects in the JS7 - Database.
    • JOC Cockpit allows more than one Controller to be connected. For example, if the same JOC Cockpit instance is used for production and for non-production Controller instances, or if a number of Controllers are rolled-out for multi-client capability.

Inventory Objects

Inventory management includes tasks for creating, updating, deploying and deleting inventory objects. When invoking the Configuration view the inventory is presented like this:


  • The Configuration view shows the following panels:
    • Left Panel: The tree of folders and objects is used to store scheduling objects in folder hierarchies.
    • Middle Panel: This panel shows the inventory items, for example, a workflow or a schedule.
    • Right Panel: This panel shows object properties, for example, allowing a user to click on the job icon for a workflow to display job properties.
  • The tree allows objects to be selected and offers an action menu with operations at the relevant folder or object level. This allows, for example, the action menu of an individual object to be used to apply the Remove operation for this object. The tree can also be used at the folder level to remove any objects and sub-folders in a selected folder.
  • Additional management operations are available with the buttons:

Object Types

The JS7 inventory offers the following scheduling object types:

Object AreaObject TypeVersioningDocumentation

WorkflowyesJS7 - Workflows

File Order SourcesnoJS7 - File Watching

Job ResourcesnoJS7 - Job Resources

Notice BoardsyesJS7 - Notice Boards

Resource LocksnoJS7 - Resource Locks

Script IncludesnoJS7 - Script Includes

SchedulesnoJS7 - Schedules

CalendarsnoJS7 - Calendars


  • Controller: all objects in this area are deployed to a Controller, see JS7 - Deployment of Scheduling Objects.
    • Objects can exist:
      • as draft objects. Objects with this status are edited by the user and can be valid or invalid. Draft objects are intended for later deployment.
      • as deployed objects that are active with a Controller.
    • For Workflows and Notice Boards, versioning applies:
      • The Controller holds an active version of the object as long as a relevant Order or Notice ID is assigned.
      • Any number of active versions can co-exist. The Controller will drop earlier active versions if they are no longer assigned Orders or Notice IDs.
  • Automation: objects in this area are not deployed to a Controller, instead they are released within JOC Cockpit. Such objects are used to automate Workflows, for example by scheduling Orders. 
    • Objects can exist
      • as draft objects. Objects with this status are edited by the user and can be valid or invalid. Draft objects are intended for later releasing.
      • as released objects that are e.g. actively used by the JS7 - Daily Plan to schedule Orders for workflow execution.
    • There is no versioning for such objects as they do not represent Controller objects but are used to automate processing of Workflows with a Controller.
  • Note that Agents are not inventory items but are added when registering Controllers and Agents during JS7 - Initial Operation.

Object Areas and Object Types are represented with the folder hierarchy:

  • Users can create individual folders starting from the root folder, which is indicated by the  icon available from the topmost tree element.
  • Each individual folder is automatically populated with object folders corresponding to the above object types:

    • Scheduling objects can be created from the New operation available in the action menu of the rerelevant object folder.

Object Naming Rules

JS7 basically allows Unicode characters to be used for object names such as Workflows, Job Resources etc.

A number of restrictions apply to object names, see JS7 - Object Naming Rules.

Note: Object names in JS7 are unique across folders per object type. This is required to ensure consistent object dependencies, as described in the next section. For example, a workflow and a job resource with the same name can co-exist, two workflows with the same name are not allowed.

Object Dependencies

A number of objects include dependencies that are managed by the inventory:

AreaObject TypeRequired DependenciesOptional Dependencies

Job ResourceResource LockScript IncludeWorkflow

File Order SourceWorkflow

Notice BoardWorkflow



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 dependent 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.
  • Users can deploy objects individually, for example, first deploying the Job Resource and later on deploying Workflows using this Job Resource.

Note: For workflow dependencies, for example for the conditional execution of jobs, see JS7 - Workflow Instructions.

Object Deployment

The deployment process includes digitally signing and transferring any number of objects to one or more Controllers.

  • More than one Controller can be connected to a JOC Cockpit instance, see JS7 - System Architecture.
    • Users choose the Controllers which objects are deployed to. For a Controller cluster the deployment process includes synchronization of objects with the journals of both Controller instances.
    • Objects can be deployed to a number of Controllers at the same time. For example, if the same workflow is deployed to more than one Controller, then any Orders scheduled for this workflow will be submitted to all Controllers that hold a copy of the deployed workflow.
  • JOC Cockpit keeps track of the history of deployments, see JS7 - Deployment History.
    • Users can repeat deployments and can redeploy (recover to a previous state of deployed objects).
    • Users can select specific previously deployed versions of objects for (re)deployment.
  • For details see JS7 - Deployment of Scheduling Objects

Inventory Operations

Folder Operations

JOC Cockpit allows scheduling objects to be stored in folder hierarchies:

  • Any number of nesting levels for folders is allowed.
  • Objects can be relocated to different folders by use of the rename operation that is available from the tree.

JS7 allows any depth of folder hierarchies. Folder operations available from the tree allow:

  • creation of a folder or sub-folder,
  • reading and displaying any objects from a folder,
  • removing a folder which includes removing any objects and sub-folders contained in this folder.

Rename Operations

Rename Folder

Folders can be renamed and can be relocated.

Change Folder Name

The popup window asks for a new name of an existing folder:

  • Object references are consistently maintained.
  • Any objects that hold references to objects in a renamed folder can continue to use such references.

Change Folder Path

The popup window allows the folder's name and path to be changed:

  • Relative paths can be used and absolute paths can be used starting with a slash "/".
  • Should folders in the path not exist then they will be created.

Change Object Names in Folder

The popup window allows the names of objects available with the indicated folder to be changed:

  • A Search and Replace operation is offered that replaces any occurrence of the string searched for in object names.
  • This operation is case-sensitive and acts on any position of the string searched for in object names.

Rename Object

Objects can be renamed:

  • from the Name input field in the right upper corner of the properties editor in the right panel,
  • from the object action menu in the tree in the left panel.

An object's name and path can be changed when renaming an object from its action menu.

Change Object Name

The popup window asks for the new name for an existing object:

  • Object references are consistently maintained.
  • For example, if a Job is assigned a Job Resource and the name of the Job Resource is changed then references of Jobs to the Job Resource are updated accordingly.

Change Object Path

The popup window allows an object's name and path to be changed:

  • Relative paths can be used and absolute paths can be used starting from a slash "/".
  • Should folders in the path not exist then they will be created.

Copy / Cut / Paste Operations

Copy / Cut / Paste Job

Note that jobs are not objects but are available within a workflow from the JS7 - Job Instruction.

Jobs can be copied by using the job's action menu like this:


  • The job icon offers a context menu for copy / cut operations.
  • Having copied a job then the toolbar in the middle panel activates the  icon that allows drag & drop for the copied job.
  • Drag & drop of jobs can be performed both within a workflow and across workflows.

Copy / Cut / Paste Object

Objects can be copied or moved to the same folder or to a different folder.

  • Copy / Cut operations are available from an object's tree action menu.
  • The Paste operation is available from the action menu of the object folder that is to receive the target object. 

When pasting an object then a new object name has to be specified. Object names in JS7 are unique across folders - for details see chapter Object Naming Rules. Pasting an object invokes the following popup window:


  • Pasting an object requires specification of a new object name using one of the options offered:
    • Specify Name: the name of the original object is displayed for modification by the user to specify the unique target object name.
    • Add Prefix: the target object name is created from the object's original name that will be prefixed by user input.
    • Add Suffix: the target object name is created from the object's original name that will be suffixed by user input.
  • Default values for prefix and suffix ("copy") can be specified from the JS7 - Settings.

Deep Copy and Shallow Copy of Objects

Note the wording used with JS7:

  • A Deep Copy includes an object and any dependent objects and allows, for example, a Workflow and the Resource Locks used by the workflow to be copied together.
  • A Shallow Copy only includes an object, and allows, for example, a Workflow to be copied and any references to dependent objects such as references to Resource Locks to be preserved.

The handling of Deep Copy and Shallow Copy is performed like this:

  • When copying objects individually using an object's action menu then a Shallow Copy is created.
  • When copying objects by folder then the folder's action menu offers the (Deep) Copy and the Shallow Copy operations.

Rollout Operations

Such operations are used for JS7 - Rollout of Scheduling Objects across environments.


Export operations include exporting scheduling objects starting from the relevant folder level.

Find details from JS7 - Inventory Export and Import.


Repository operations include storing, updating and deleting scheduling objects from a Git repository.

Find details from JS7 - Inventory Git Integration

Deployment Operations

The operations in this section are related to JS7 - Deployment of Scheduling Objects.

The operations work recursively for all sub-folders.


This operation transfers scheduling objects to Controllers and respective Agents.


This operation allows the deletion of previously deployed objects from Controllers and respective Agents.

The objects in question are not removed from the inventory.


Any objects that have been previously deployed are deployed once again. This operation is based on the history of previous deployments to a Controller.

This operation can be applied for example after the loss of Controller journals.


In a situation when objects become invalid, for example if Agent references changed, then they can be validated once again.

The operation will update the status of objects being valid or invalid in the JS7 inventory. The operation does not repair invalid objects but brings in sync the objects' validity status. The result of the operation will be displayed like this:

  • The resulting category Validity denied shows inventory objects that previously have been considered valid and now are considered invalid.
  • The resulting category Validity approved shows inventory objects that previously have been considered invalid and now are considered valid.
  • The resulting category Validity not verifiable holds inventory objects that could not be parsed, for example empty draft workflows that hold no objects.


This operation retrieves the deployment status for each object by synchronizing the status in the Controller and the inventory.


This operation is available for Automation objects that are not deployed to Controllers and Agents but which are used by the JOC Cockpit.

For example, if a Schedule is released, then it will be considered by JOC Cockpit when creating the Daily Plan.

  • A Schedule that has never been released will not be considered.
  • A draft is created for a Schedule which has previously been released and which has been changed later on. Such drafts are not used by the Daily Plan unless they have been released. The Daily Plan will use the previously released version of such Schedules for the lifetime of the drafts.


This operation is available for Automation objects that have previously been released. In fact it is an "undo" operation that reverts the release operation:

  • When an object such as a Schedule is recalled then it is no longer considered by the Daily Plan.
  • There is no versioning in place when recalling objects, instead the object's status is set to draft and the object can be released at a later point in time.

Trash Operations

Note the wording for JS7 inventory operations:

  • Remove: moves an object to the trash. The trash allows removed objects to be restored and therefore any remove operations can be undone.
  • Restore: makes a removed object available from the trash.
  • Delete: permanently erases an object. This operation cannot be undone.

The trash is available from an icon with the topmost level of the inventory tree:

The  icon indicates the trash. When clicking this icon then the tree switches to display objects available with the trash:

In trash mode the inventory allows objects from the trash to be Restored or to permanently Deleted.

  • Restore operations can be performed for individual objects and for any objects stored within a folder hierarchy.
  • Restore operations include restoration of an object with its original name or restoration using a prefix/suffix should an object with the same name exist.

JSON based Operations

The JS7 stores scheduling objects in JSON notation.

Further Resources

  • No labels