...

• The If Instruction is used for conditional processing in a workflow. It allows to check return codes and return values of previous jobs jobs to be checked and it can be used to evaluate order variables.
• The If Instruction optionally allows to the use of an Else branch if the condition evaluates to false.
• An If Instruction evaluates an expression that includes order variables and that results in a true/false value. The following Some basic use cases are suggested:
  • check the return code (exit code) of a previous job to decide which jobs or instructions to continue with,
  • check the return value (variables returned by a previous job) to decide about further processing,
  • check order variables to determine the next instructions to process.
• The If Instruction does not modify an order's state, however, if an If Instruction fails due to an error in the expression or syntax then the order is considered being to have failed.

Syntax

• The If Instruction evaluates an expression from a predicate and returns a boolean value true or false.
• Therefore Boolean algebra is applied, e.g. to evaluate expressions such as $returnCode.toNumber == 0.

...

• The If Instruction knows of two binary operations, which are and (conjunction) and or (disjunction) with the syntax  && and ||.

  • Possible operations correspond to the following matrix:

    x	y	x && y	x || y
    false	false	false	false
    true	false	false	true
    false	true	false	true
    true	true	true	true

  • Round brackets should be used to group multiple expressions and to control the order of evaluation.
  • Conjunction beats disjunction if no grouping is used, i.e.
    •   x && y || z  is the same as (x && y) || z   
    •   x || y && z  is the same as   x || (y && z) 
  • Both operations using the basic elements true, false cover a number of algebraic laws such as associativity, commutativity and distributivity, for . For more details see Wikipedia.

...

Variables

• The predicate supports to check checking of the values of job arguments and of order variables.
•  Variables support the following data types: string, number, boolean.
• While an order passes a workflow any job can add or modify order variables.
• A number of syntactical notations for variables are supported that provide access to:
  • the current value of a variable (maybe may be modified by a previous job),
  • the value that was returned by a specific JS7 - Job Instruction,
  • the original value of the variable as carried by the order.

•  If a predicate makes use of a variable that does not exist then the order stops with a FAILED state, except in case that when a default value has been specified for the variable. 

...

• The following syntax can be used to access the current value of a variable:
  • $varName
  • ${varName}
  • variable("varName") or variable('varName')
  • variable(key = "varName") or variable(key = 'varName')
• To avoid that an order fails failing due to a non-existent variable, a default value can be specified with the following syntax:
  • variable("varName", default = "aString") or variable('varName', default = 'aString')
  • variable(key = "varName", default = "aString") or variable(key = 'varName', default = 'aString')
  •  Default values use one of the supported data types: string, number, boolean.
  • If the variable name is used with the key attribute then the order of appearance of the key attribute and default attribute  attributes is arbitrary, i.e. variable(default = "aString", key = "varName")is possible too.
  • If the variable name is used without the key attribute then the variable name has to be used as the first argument of variable(...).

...

• The following syntax can be used to access the original value of an order variable:
  • argument("varName") or argument('varName')
  • argument(key = "varName") or argument(key = 'varName')
• An argument can specify a default value too as well (see previous chapter).

Value of a variable from a specific Job Instruction

• Each label for a JS7 - Job Instruction has to be unique per in a workflow.
• The following syntax can be used to access the value of a variable as returned by a specific Job Instruction:
  • variable("varName", label = aLabel) or variable('varName', label = aLabel)
  • variable(key = "varName", label = aLabel) or variable(key = 'varName', label = aLabel)
  •  Note that the value of the label is not quoted!
• A default value can be added too as well (see previous chapter)
  • The order of appearance for label and default is arbitrary.

...

• The return code is a variable holding an object that can be converted to a number if provided from a shell job. For such jobs the operating system exit code is handed over as the return code.

• The return code is provided from the most recently executed job.

• The return code is a build-in variable that can be used in a predicate like this: $returnCode

• Hint; with the JS7 - Job Instruction the returnCodeMeaning attribute can be set that . This states the return codes (exit codes) that are considered signaling success or error of a job run. If the return code is not included with the list of successful return codes or is included with in the list of return codes signaling an error then the order fails. If you want to handle such job execution results with an If Instruction then the respective return code has to be added to the list of successful return codes or has to be exempted from the list of return codes signaling errors.

...

• Three operators are provided to compare strings. These are ==, != and matches.
  • "stringA" == "stringB" is true if stringA and stringB are equal.
  • "stringA" != "stringB" is true if stringA and stringB are not equal.
  • "stringA" matches "a regular expression" is true if stringA matches the regular expression.
    • The syntax of the regular expression is a quoted string and has to be Java compliant.
    •  It is required that necessary for an expression including matches is to be enclosed with in round brackets if it is not the only expression in a predicate:
      • (variable("myVar") matches ".*") && variable("myVar") != ""

...

• Seven operators are provided to compare numbers. These are ==, !=, <, <=, >, >= and in.
  • numberA == numberB is true if numberA and numberB are equal.
  • numberA != numberB is true if numberA and numberB are not equal.
  • numberA <  numberB is true if numberA is less than numberB.
  • numberA <= numberB is true if numberA is less than numberB or equal.
  • numberA >  numberB is true if numberA is greater than numberB.
  • numberA >= numberB is true if numberA is greater numberB or equal.
  • numberA in [numberB,numberC,numberD] is true if numberA is equal to numberB or equal to numberC or equal to numberD.
    • The in operator expects an array of numbers with a minimum of one number included. Array elements are separated by comma and are enclosed by square brackets.
    •  It is required that necessary for an expression with incliding in is to be enclosed with in round brackets if it is not the only expression in a predicate:
      • (variable("myVar").toNumber in [0,42,255]) && variable("myVar") != ""

...

• Return Codes come in two flavors:
  • for shell jobs the return code corresponds to the operating system exit code.
  • for any other job types the return code is provided by the respective job indicating success or failure.
•  The job definition specifies which return codes indicate success or failure:
  
  
   
  • For the above workflow example job1 considers the return codes 0,1,2,3,4 signaling to signal success and any other return codes indicating to indicate errors.
• Therefore a return code > 0 does not necessarily indicate failure but can be used, e.g. for workflow control, to indicate which jobs should be executed next.
• If a given return code is not present with in the list of successful return codes then the order will be considered being to have failed. However, if the return code is available with in the list of successful return codes then an If Instruction can check the return code value and can continue with specific jobs if the If Instruction evaluates to true or to false.

...

• Technically this use case is not too different from the above checking of return values use case described above. However, the focus is not on a specific job but on specific values of variables.
• Consider Note that order variables can be modified by users when adding an order. The above example therefore checks an order variable to decide which job to start a workflow for.
• In addition, Note also that the same check can be performed for any step in a workflow.

...