Page History

...

• The file based configuration of JS1 is not perfectly cloud usable. This is why branch 1.13 dropped the JOE job editor and introduced browser based management of job-related configurations stored with the database. However, JS1 allows modifications of job-related configuration by files for users with access to the operating system. From a security perspective this is not a perfect design as technical permissions which allow a system administrator to modify files at operating system level are not related to role based permissions that determine who should be entitled to modify and to deploy jobs.
• JS7 follows a role based access model that excludes OS users such as a root account with technical permissions for file systems. Instead, digital signatures are used to prove to a Controller and Agent that a specific user is entitled to deploy certain workflows and jobs - see JS7 - Secure Deployment of Scheduling Objects for more information. This adds non-repudiability to job-related deployment that is not based on trust relationships for JS7 components but purely on the use of certificates. For example, an Agent does not trust a Controller or JOC Cockpit, it only trusts the available certificates.
• For lovers of the straightforward option available with JS1 to push/pull job-related configuration files to/from a version control system, the good news is: JS7 includes the JS7 - Git Repository Interface. Support for additional version control products is available from file based exports of the JS7 - Inventory Export and Import.

...

• JS1 knows Jobs and Job Chains that implement a sequence of jobs.
  • A job is an object that can be modified individually and which can be re-used with a number of job chains.
  • A job is defined to be operated standalone or as a node in a job chain.
  • Any changes to jobs and job chains are implemented immediately.
• JS7 is not limited to a sequence of JS7 - Jobs but introduces a number of JS7 - Workflow Patterns which is why the term workflow replaces job chain.
  • A job is only available within a workflow. A job is not an independent object and it cannot be re-used.
    • While users might consider this a limitation, in fact it guarantees a self-contained and consistent workflow configuration. Consider the fact that a JS1 job could be modified or removed at run-time leaving the job chain in a critical status. The JobScheduler Master had to check for updated versions of a job XML file and had to apply any modifications in good time. If modifications are not consistent, e.g. if the job parameterization was changed, then would breaks a currently running order as any changes to jobs are applied immediately.
    • Modifications to a JS7 job force a workflow to be deployed once again.
    • The JS7 - Inventory Bulk Operations for Jobs allow modification of a single job and the application of changes to a number of jobs across workflows.
  • There are no JS1 standalone jobs in JS7, instead such jobs are considered to be workflows with a single job.
    • The JS7 - Job Templates replace the JS1 standalone jobs as they allow to centrally update jobs in a number of workflows.
  • Changes to workflows take effect for newly added JS7 - Orders only. The JS7 Controller keeps track of workflow versions as long as an order is assigned the workflow.
    • At the point of time of submission an order is associated with the current version of a workflow.
    • If the workflow changes later on then this has no impact on submitted orders, but will only affect new orders that are submitted after this change.
    • This feature can be used to target changes to a workflow to a future date. Existing orders can be cancelled and re-submitted to be assigned the current version of a workflow from the Daily Plan view.

...