Page History

...

The JS7 - Inventory provides the functionality to export and to import functions for exporting and importing scheduling objects such as workflows, calendars, schedules etc.

• Export and import can be used:
  • to share examples and scheduling solutions between users,
  • for migration purposes when upgrading between JS7 minor/major releases,
  • as part of a rollout strategy, for example to rollout , when rolling out from dev -> test -> prod environments. Find more details from JS7 - Rollout of Scheduling Objects.
• Export and import:
  • only include scheduling objects only, not the JS7 - Deployment History and not the JS7 - Daily Plan History,
  • is are not a replacement for backups. However, however, export/import can be used to restore a single version of any scheduling object.

...

The export operation is available from the Export button in the Configuration->Inventory view like thisas shown below:

In addition, the export function is available from a folder's action menu like thisas shown here:

The Export button is used to select scheduling objects starting from the top-level folder.

...

• File Name
  • The name and extension of the file to which the export is performed.
  • Consider that an extension has to be specified and has to match the File Format, e.g. export.zip, export.tar.gz.
• File Format
  • ZIP: This format works for most Unix operating systems and for Windows and creates an archive with a .zip extension.
  • TAR_GZ: This format works preferably for Unix operating systems and creates an archive with a .tar.gz extension.
• Filter Type
  • Controller: The export includes scheduling object types that are deployed to a Controller such as Workflows, Job Resources etc.
  • Automation: The export includes scheduling object types that are released by JOC Cockpit such as Calendars and Schedules.
• Filter
  • Valid only: JOC Cockpit does not force users to have objects in a valid status, for example during ongoing work on workflows. Invalid, i.e. incomplete, objects can be exported and imported.
  • Draft:  The export includes a single version of an object. This option specifies that the draft version of an object will be preferred for export if a draft version exists that is newer than the deployed or released version.
  • Deployed:  Specifies that the latest deployed version of an object is exported. If an object is has been deployed a number of times then JOC Cockpit holds the JS7 - Deployment History and adds the latest version to the export file. 
    • If used with the Draft option in place then this includes to prefer the draft version to will be preferred instead of the deployed version of an object, if a newer draft version exists.
    • If used without the Draft option being in place then only deployed objects only will be exported and objects for which a draft version only exists only exist as draft versions will be omitted from the export. 
  • Released: Specifies that the latest released version of an object is exported.
    • If used with the Draft option in place then this includes to prefer the draft version to will be preferred instead of the released version of an object, if a newer draft version exists.
    • If used without the Draft option being in place then only released objects only will be exported and objects for which a draft version only exists only exist as draft versions will be omitted from the export.
• Handle recursively:
  • Specifies that selection of a folder includes to export will cause any objects and sub-folders to be included in the export recursively. If objects should are to be selected individually then this options should not be used.

When hitting the Submit button the export file is created and is offered available for download.

Export File

The export file is an archive in .zip or .tar.gz format. Starting from the above example that exported example above, in which the Examples.Unix folder was exported, the root of the export file looks will look like this:

The meta_inf file includes information about the JOC Cockpit version, the inventory schema version and the version of the JS7 - REST Web Service API that were used during export. This information is important for later import with newer versions of JOC Cockpit as it triggers the migration of objects to newer inventory schema versions.

The contents of the Examples.Unix folder is the list of included sub-folders like thisas shown here:

The contents of the 05_ScheduledExecution folder is a list of objects in JSON format.

...

The import operation is available from the Import button in the Configuration->Inventory view like this:

Clicking the Import button brings forward opens the following popup windows:

Explanation:

• Folder
  • During the import the folder hierarchy inside the imported file is considered. However, users can specify a target folder as the top-level folder to which import file's folders are added, 
  • For example, if the import file's inside top-level folder inside the import file is Examples.Unix and,
    • no a Folder is not specified, then the import file's top-level folder is added to the inventory root, i.e. /Examples.Unix.
    • a Folder /TestRuns/70 is specified, then the import file's top-level folder will be added as /TestRuns/70/Examples.Unix.
• File Format
  • ZIP: This format works for most Unix operating systems and for Windows and creates requires an archive with a .zip extension.
  • TAR_GZ: This format works preferably for Unix operating systems and creates requires an archive with a .tar.gz extension.
• Overwrite
  • The JOC Cockpit inventory holds unique object names per object type. This means you can have a workflow with the name hello and a job resource, calendar, schedule etc. with the same name, but you cannot have two hello workflows with the same name. This applies to any all scheduling objects.
  • Therefore object name collisions from an import file and from the JOC Cockpit inventory can happen independent from independently of the imported folder hierarchy. The Overwrite option specifies what the title suggests: any existing inventory objects with the same name are replaced by objects from an import file of the same name and type of an import file.
• Object Name: Options in this section are available only if the Overwrite option is not in place.
  • Ignore if exists:  This option grants precedence to objects that exist in the JOC Cockpit inventory should object name collisions occur from an import file: in . In this situation the object from the import file is ignored.
  • Add Prefix: For any objects of the import file a unique prefix is used for all objects in the import file. The value of the prefix is specified by JS7 - Settings, chapter: JOC Cockpit Settings with the import_prefix setting ("imported"). If an object with this name - including the prefix - already exists then a number is added to the prefix and is incremented until a unique object name is identified.
  • Add Suffix:  For any objects of the import file a unique suffix is used for all objects in the import file.  The value of the suffix is specified by JS7 - Settings, chapter: JOC Cockpit Settings with the import_suffix setting ("imported"). If  If an object with this name - including the suffix - already exists then a number is added to the suffix and is incremented until a unique object name is identified.

The Drag & Drop zone and the Choose Files for Upload button can be used to import scheduling objects from a file.

Consider Note that any objects are put to given the not deployed and not released status statuses respectively when imported.

...

The import operation considers relational consistency:

• Assume that a workflow and a corresponding schedule that creates orders for the JS7 - Daily Plan to be is available with the JOC Cockpit inventory.
  • When updating the workflow from an import file that does not contain the corresponding schedule then the existing schedule will automatically relate to the updated workflow. This similarly applies to any object references. This operation requires the above  Overwrite option described above to be in place during import as otherwise the workflow would not be updated.
  • If the Overwrite option is not in place during import but instead one of the Add Prefix or Add Suffix options is used then during import a new workflow will be created with a unique name specified by the prefix/suffix. In this situation the imported schedule - even if not subject to object name collision - will accordingly receive the same prefix/suffix and will relate to the newly created workflow.
• Assume that a schedule to be imported that holds a reference to a workflow available with the inventory.
  • If the workflow is not included with the import file then the imported schedule will reference the existing workflow.
  • If a schedule with the same name exists in the inventory and the Add Prefix or Add Suffix options are in place then a new schedule will be created that references the existing workflow. As a result the workflow will be referenced by two schedules, the existing schedule and the newly imported schedule, that both create orders for the Daily Plan.

...

Export/import is a valid strategy to perform for performing rollout operations, for example from dev -> test -> prod environments.

At the same time, this requires some discipline about the nature of scheduling objects to be : are they local to a specific environment or to be have they been prepared for rollout across environments.

...

Export/import is used for deployment if JOC Cockpit is operated in a HIGH Security Level HIGH. The This functionality includes to export exporting scheduling objects for digital signing on an external device and to import importing the signed objects. After import the The usual deployment operation is performed after the import.

Find details from See JS7 - Deployment of Workflows for high High Security Levelfor further information.