JS7 JobScheduler

Space shortcuts

Page tree

Introduction

The JS7 - Inventory provides 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, when rolling out from dev -> test -> prod environments. Find more details from JS7 - Rollout of Scheduling Objects.
  • Export and import:

Export

Export Operation

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


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


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

The Export action menu is used to export objects starting from the given folder.

After choosing the export action the following window offers to select objects:


Explanation:

  • 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 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 draft version 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 will be exported and objects which 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 draft version 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 will be exported and objects which only exist as draft versions will be omitted from the export.
  • Handle recursively:
    • Specifies that selection of a folder will cause any objects and sub-folders to be included in the export recursively. If objects are to be selected individually then this options should not be used.

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

Export File

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

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 as shown here:

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

The object type is indicated by the respective extension such as .calendar.json, .workflow.json etc.

Import

Import Operation

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


Clicking the Import button 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 top-level folder inside the import file is Examples.Unix and,
      • 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 requires an archive with a .zip extension.
    • TAR_GZ: This format works preferably for Unix operating systems and 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. This applies to all scheduling objects.
    • Therefore object name collisions from an import file and from the JOC Cockpit inventory can happen independently of the imported folder hierarchy. The Overwrite option specifies what the title suggests: any existing inventory objects are replaced by objects from an import file of the same name and type.
  • 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 this situation the object from the import file is ignored.
    • Add Prefix: 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: 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 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.

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

Relational Consistency

The import operation considers relational consistency:

  • Assume that a workflow and a corresponding schedule that creates orders for the JS7 - Daily Plan 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 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 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 for Rollout

Export/import is a valid strategy 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: are they local to a specific environment or have they been prepared for rollout across environments.

Find details from JS7 - Rollout of Scheduling Objects.

Export/Import for Deployment

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

See JS7 - Deployment of Workflows for High Security Level for further information.



  • No labels