JS7 JobScheduler

Space shortcuts

Page tree

Introduction

FEATURE AVAILABILITY STARTING FROM RELEASE 2.5.6

FEATURE AVAILABILITY STARTING FROM RELEASE 2.6.3

The JITL OrderStateTransitionJob template can be used to perform transitions on orders, see JS7 - Order State Transitions. Examples for state transitions include to

  • continue orders from the FAILED state to the IN PROGRESS state and possibly to the RUNNING state in case of a JS7 - Job Instruction,
  • continue orders from the SUSPENDED state to the state they had before being suspended.
  • continue orders from the PROMPTING state to the IN PROGRESS state and possibly to the RUNNING state.

The job template makes use of the JS7 - REST Web Service API to perform JS7 - Order State Transitions.

Usage

When defining the job either:

  • invoke the Job Wizard that is available from the job properties tab in the Configuration view and select the JITL OrderStateTransitionJob and relevant arguments from the Job Wizard.

or

  • specify the JITL job class and com.sos.jitl.jobs.orderstatustransition.OrderStateTransitionJob Java class name and add arguments specifying what order states to transition..

Example

Download (upload .json): pwdOrderStateTransitionJob.workflow.json

You can use the Job Wizard like this:

Explanation:

  • Add an empty job from the instruction panel.
  • Specify a name and a label for the job.
  • Select an Agent.

In a next step invoke the Job Wizard that you find in the upper right corner of the job property editor. The Job Wizard brings up the following popup window:


Explanation:

  • From the list of available Job Templates select the OrderStateTransitionJob.

Then hit the Next button to make the Job Wizard display available arguments:



Explanation:

  • Required Arguments
    • states : Specifies the semicolon separated list of states on which the transition will be applied for example failed;scheduled
    • transition: Specifies the transition to be performed. Possible values are one of cancel, suspend, continue
    • Optional Arguments
      • workflow_folders:  Optionally the identifier of a Controller can be specified to limit results to workflows and jobs executed with the indicated Controller.
      • workflow_search_patterns:  Optionally the identifier of a Controller can be specified to limit results to workflows and jobs executed with the indicated Controller.
      • order_search_patterns:  Optionally the identifier of a Controller can be specified to limit results to workflows and jobs executed with the indicated Controller.
      • persist_duration:  Optionally the identifier of a Controller can be specified to limit results to workflows and jobs executed with the indicated Controller.
      • controller_id:  Optionally the identifier of a Controller can be specified to limit results to orders processed with the indicated Controller.
      • batch_size: Optionally limit the size of REST API requests.
  • Note that the the checkbox provided with each argument has to be selected to add the argument to the OrderStateTransitionJob template.

When hitting the Submit button, the wizard adds the selected arguments to the job which can look like this:

The job arguments can be specified:

Documentation

The Job Documentation including the full list of arguments can be found from: https://www.sos-berlin.com/doc/JS7-JITL/OrderStateTransitionJob.xml

Authentication

The Job makes use of the JS7 - REST Web Service API that is available from JOC Cockpit. 

  • The job is executed with an Agent and requires a network connection to JOC Cockpit.
  • The job has to authenticate with JOC Cockpit, for the related configuration see JS7 - JITL Common Authentication.

Arguments

The OrderStateTransitionJob template accepts the following arguments:

NameRequiredDefault ValuePurpose
statesyesn/a

Possible values: pending, scheduled, failed, suspended, waiting, inprogress, prompting. Values can be specified in uppercase, lowercase or mixed letters.

Values can be specified from a semicolon separated list. Each state in the list is handled separately, for example

  • the transition continue for prompting orders will move orders to the IN PROGRESS and possibly to the RUNNING state,
  • the same transition for suspended orders will put orders to the state they had before being suspended.

Example: failed;suspended

transition

yesn/a

Possible values are one of:

  • cancel: execute cancel operation on related orders
  • continue: execute resume operation on failed and suspended orders. Execute confirm operation on prompting orders.
  • suspend: execute suspend operation on orders that are not failed, not finished and not suspended.
workflow_foldersno/*A list of folders that hold workflows for which orders should be transitioned.

If more than one folder is specified then folders are separated by semicolon. When used with the trailing characters /* then the folder will be looked up recursively. By default all folders will be looked up recursively.

Example: /folder/sub1;/another_folder/sub2/*

workflow_search_patternsnon/a

A list of search patterns for names of workflow for which orders should be transitioned. The wildcard characters * (zero or more characters) and ? (a single character) can be used. If more than one search pattern is used then they are separated by semicolon.

Example: *myWorkflow*;my?orkflow

order_search_patternsno/n/a

A list of search patterns for order names. If more than one search pattern is used then they are separated by semicolon.

Examples: *myWorkflow*;/folder/sub1/my?orkflow

persist_durationnon/a

This argument is available for FAILED orders. It specifies the minimum duration for which the order is in the failed state.

  • A format for the duration relative to the current time, e.g. 6h, 12h, 1d, 1w that specifies the quantity followed by a qualifier.
  • Example:  
      • 2d
  • Possible qualifiers are:
    • s (seconds)
    • m (minutes)
    • h (hours)
    • d (days)
    • w (weeks)
    • M (months)
    • y (years)
controller_idnoCurrent Controller IDThe identifier of a Controller can be specified to limit the resulting list of orders to the indicated Controller.
batch_sizeno10000

The maximum number of orders that are processed in a single request.

Orders are transitioned in a single transaction. This includes that either all orders in a transaction are transitioned or none. If the number of orders exceeds the batch size then a further transaction is executed.

If the value 1 is used for the batch_size then each order is transitioned individually with a successful or failed result.

The batch size should not exceed a value of approx. 15000 in order to limit the size of requests to the Controller to approx. 4 MB which is a frequently applied limit of Proxy Servers that might be in place between the Agent running the job and JOC Cockpit.

Return Variables

The OrderStateTransitionJob template does not return variables:

Further Resources



  • No labels