Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Title: A title can be added to the job that will be displayed with the respective views.
  • Job Class: 
    • Status
      colourYellow
      titleTODO
  • Compatibility: For users of JobScheduler branch 1.x a compatibility mode is available.
    • For use of environment variables compatibility enables
      • to automatically create environment variables for shell jobs from any available order variables and job arguments.
      • to use the prefix SCHEDULER_PARAM_ for any environment variable created.
    • For use of job arguments the compatibility mode offers a corresponding tab.
  • For Shell Jobs: Environment Variables Subtab
    • Any environment variables for job scripts have to be specified by a mapping:

      Image Modified

    • The mapping includes to specify a name for the environment variable that has to comply with OS requirements. Names are automatically converted to uppercase. The GUI offers the list of order variable names for the mapping to environment variables.
    • The value of an environment variable can be specified like this:
      • as a string which is a sequence of characters
        • excluding the $ character that prefixes variables.
        • or being enclosed with single quotes to allow literal use of the $ character.
      • as a reference to a variable using the syntax $variableName.
    • The advantage of the above mapping is the fact that
      • you publish environment variables only that are required by a job instead of creating an arbitrary number of environment variables from any order variables and job arguments,
      • you limit the risk to overwrite existing shell environment variables, e.g. when passing an order variable with the name "PATH" then this would overwrite a shell environment variable with the same name.

Job Options Tab

  • Job options include the following configuration items:

    Image Added

  • Task Limit: Should more than one order pass the workflow at the same time or should parallel child orders execute the same job then this setting determines the maximum number of tasks that are available for the job. This limits parallelism of tasks to the specified number. If more than the specified number of tasks is requested then orders have to wait until a task becomes free.
  • Timeout / Grace Timeout: Specifies the maximum duration that a job should run.
    • If the timeout is exceeded then the Agent will send a SIGTERM signal to a shell job. This corresponds to executing the kill -15 command in Unix environments. The purpose of the SIGTERM signal is to let the job know that it should terminate and to leave it up to the job implementation to perform some cleanup tasks such as disconnecting from a database or removing temporary files.
    • After sending the SIGTERM signal the Agent will wait for the duration of the Grace Timeout to allow the task to complete. If the Grace Timeout is exceeded then the Agent will send a SIGKILL signal that will kill the task. This corresponds to executing the kill -9 command in Unix environments.
  • Criticality: This option allows to select a level that can be used for monitoring purposes to prioritize alerts depending on a job's criticality.
  • Log Level: The log level can be used by JVM jobs to adjust their log level. This option is not applicable for shell jobs.

Node Properties Tab

  • Node properties include the list of default arguments that are available from the respective job node:

    Image Added

  • The use case for node arguments includes to use the same job for a number of times in a given workflow with different parameter sets.
    • Assume that the job requires the same parameter names to be used.
    • However, for each occurrence of the job in a workflow different parameter values should be used.
  • In this situation node arguments can be introduced that specify variables with the same name but with different values for each occurrence of a job in the workflow.
    • Names of node arguments should not interfere with order variables as otherwise the node argument values will be overwritten by order variable values.
    • For shell jobs node arguments have to be mapped to environment variables similarly to order variables. 
    • For JVM jobs node arguments are available from Java objects exposed to the job implementation.

Error Handling