Page History

...

• In JS1 an Agent can be accessed by a number of Master instances.
• With JS7 Agents are dedicated to a Controller and cannot be are not shared between Controllers.

...

• For JS1 any number of Agent Clusters can be configured that reference the same Agent as they represent a logical layer on top of the installation.
• With JS7 there is a unique implements a new JS7 - Agent Cluster with unique registration of an Agent Agents during JS7 - Initial Operation.

...

Job-related Configuration Format

XML

...

Format migrated to JSON

• The JS1 stores job-related configuration in XML files. The problem with XML is that many parsers are inherently insecure due to the many capabilities of XML. One more problem is the fact that a number of XML parser projects are not actively maintained. This results in an increasing number of XML vulnerabilities and inacceptable delays for security fixes.
• The JS7 makes use of JSON as the storage format for the JS7 - Inventory Storage Format for job-related configuration. In fact Technically JSON capabilities are by far inferior to what is available from XML , e.g. when it comes to validation. At the same time JSON is more focused and offers less attack surface.

File based Configuration migrated to

...

Database

• 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 configuration 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 of 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.
• The JS7 follows a role based access model that excludes OS users with technical permissions for file systems such as a root account. 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. This adds non-repudiability to job-related deployment that is not based on trust relationships of JS7 components but on use of certificates only, e.g. for example an Agent does not trust a Controller or JOC Cockpit, it trusts available certificates only.
• For lovers of the straightforward option available from JS1 to push/pull job-related configuration files to/from a version control system, the good news is: the JS7 will include direct support for Git based repositories, see JS7 - Roadmapincludes the JS7 - Git Repository Interface. Support for additional version control products becomes is available from file based exports of the the JS7 - Inventory Export and Import.

Job Dependencies

Job

...

Dependencies migrated to

...

Workflow Patterns

• The JS1 preferably implements forward dependencies and a few options for backward dependencies by additional JITL jobs and JITL based monitors.
  • For example, the How to split and join jobs in a job chain article explains JITL job templates that have to be added to a job chain in addition to business related jobs and that are parameterized in a somewhat sophisticated way.
  • For example, the How To Synchronize Job Execution Across Job Chains article explains the JITL Job JobSchedulerSynchronizeJobChains that makes orders in a number of job chains wait for each other.
• The JS7 implements a larger number of JS7 - Workflow Patterns that are available from JS7 - Workflow Instructions.
  • For example, the JS7 includes a native JS7 - Fork / Join Instruction that does not require use of additional JITL jobs and that works without parameterization.
  • For example, the JS7 offers use of JS7 - Notice Boards with the JS7 - ExpectNotice Instruction and the JS7 - PostNotice Instruction to synchronize workflows.

Individual Implementation of

...

Dependencies moved to

...

Workflow Patterns

• Due to limited capabilities of the JS1 for backward dependencies users might have implemented dependencies at individual level, e.g. for example by scripting. the Product Knowledge Base includes a number of such examples.
• The JS7 implements a larger number of workflow patterns as stated with the previous chapter. SOS does not consider it desirable to bury the logic of job dependencies in scripts. Instead such scripts should be migrated to use JS7 - Workflow Instructions and should be part of the configuration. This is manual work and is not supported by migration tools.

...

• JS1 includes support for a number of scripting languages:
  • Shell Jobs implemented with any scripting language are supported provided that the script interpreter, e.g. Python, Ruby etc., is available from the machine on which the job is executed.
  • API Jobs are supported for a number of scripting languages to which the JobScheduler Job API is exposed:
    • JavaScript (Nashorn)
    • JScript (Microsoft)
    • Perl (PerlScript)
    • PowerShell (Microsoft)
    • VBScript (Microsoft)
  • JavaScript is available from the Java Virtual Machine (JVM) implementation provided by the Nashorn JavaScript Engine.
    • Version 15 and newer of Java remove the Nashorn JavaScript engine.
  • The scripting languages JScript and VBScript are supported by the Windows JVM on 32bit systems only, see VBScript Jobs. The ScriptControl:VBScript job type introduced with JobScheduler release 1.10 acts as a replacement for VBScript jobs.
• JS7 includes support for the following scripting languages:
  • The option to run Shell Jobs for any scripting language for which the interpreter is available remains unchanged.
  • Later JS7 release will include support for API Jobs for scripting languages available with the GraalVM such as
    • JavaScript (Node.js)
    • Perl
    • Python
    • Ruby
  • At the same time JS7 API JVM Jobs do not provide the same capabilities as API Jobs for JS1. JS7 API JVM Jobs are by design limited to receive arguments and to return result objects. Actions on inventory objects such as adding orders, stopping jobs etc. are available from the the JS7 - REST Web Service API (see below).

Job API migrated to REST Web service

• The functionality of the JobScheduler Job API has been migrated to the JS7 - REST Web Service API.
• However, a number of differences have to be considered:
  • The JS1 Job API allows to modify objects of the current job such as the current task or order.
  • The JS7 REST Web Service API allows modification of any objects , but requires to identify objects such as jobsat configuration level that includes to deploy modified objects.
  • A number of operations of the JS1 Job API are not available, for example to modify the job configuration on-the-fly, e.g. by adding/dropping a setback configuration. This is not considered good practice as such changes to the configuration are deeply buried in script code and are not evident from configuration.
• A REST Client has to be used by jobs that access the JS7 REST Web Service API.

...

• JS1
  • The JS1 makes use of Orders that include a run-time definition. This means the order recalculates its next start time after execution. At the same time this includes that e.g. suspended orders will not calculate a next start time and will not be executed for future dates as long as they are suspended or blocked, e.g. by stopped jobs or job nodes.
  • JS7 cyclic orders are represented as a single order that recalculates its next start time after completion of the last cycle. This includes to use a relative cycle interval that counts from the completion of a previous order run to the start of the next order run.
  • JS1 orders can use Schedules that present run-time definitions shared by a number of orders and jobs
  • JS1 orders carry Parameters. If a parameter is changed then the order has to be changed, i.e. the change is valid for any future executions of an order starting from the point in time of the change.
• JS7
  • The JS7 creates individual JS7 - Orders for each execution of a workflow.
    • This allows to modify orders individually from the JS7 - Daily Plan, for example to modify the start time and parameters for individual days only.
    • Assume a daily order with a single start time: it will execute each day at the given time independently from the fact if the order for the previous day has been completed or is suspended or blocked.
  • A JS7 cyclic order is presented from the Daily Plan view as a single order, however, the cyclic order is submitted to a Controller as an individual order per cycle. This includes that each execution of an order cycle is independent from its predecessor and it includes that there cannot be a start time relative to completion of the predecessor cycle.

  • JS7 - Schedules correspond to JS1 Orders: a schedule combines a workflow reference, a run-time definition and variables (parameters). From a given schedule the Daily Plan generates individual orders for each day and start time.

  • The start time times and variables of a JS7 order orders can be modified individually for each order from the Daily Plan view. If the start time or variables from a schedule are changed then this applies to any future orders created with the schedule, it does not apply to existing orders.
    • Note that orders can be submitted days or weeks in advance of their start time by use of the JS7 - Daily Plan Service.
    • This allows to target changes to a schedule for a specific date. Users can cancel and re-submit existing orders or re-create the Daily Plan if they want changes to a schedule to be in effect starting from a specific date.

...

The JobScheduler and YADE products are available under a dual license model that gives that offers customers the choice between open source licenses and commercial licenses.

• JS1
  • The license model includes to run any number of parallel jobs with Masters and Agents if used with the commercial license.
  • Users of the open source license can run any number of parallel jobs with Masters and are limited to run one task at a time with Agents.
• JS7
  • JS7 introduces a new license model, for details see JS7 - License.
  • Users of the open source license can run any number of parallel jobs with JS7 Agents.
  • The same source code and therefore the same feature functionality is available with both license models. The one exception is the operational feature to cluster the JS7 components for high availability which is a commercially available feature for enterprise customerslicense holders.
• JS1 + JS7
  • The SOS is committed to open source . Open source which is about free software, in the sense of freely available source code.
  • Customers with commercial licenses benefit from additional Support Options and Services.

...