Introduction

Users frequently find a situation when a job creates some result that should be forwarded to subsequent jobs in a workflow.

Passing Variables

Shell Jobs

Download Example for Unix (.json upload): pdwVariablesPassingUnix.workflow.json

Download Example for Windows (.json upload): pdwVariablesPassingWindows.workflow.json

First Job: Write Variables

Shell jobs can pass results to subsequent jobs

• by creating a key/value pair with the syntax: key=value.
• The key/value pair is appended to a temporary file that is provided by JS7 and that is indicated by the JS7_RETURN_VALUES environment variable.
• The key provided is the name of the order variable that can be used by subsequent jobs.
  
  • If the variable does not yet exist then it is created on-the-fly.
  • If the variable exists then the value is overwritten

The job script implementation looks like this:

#!/bin/bash

# create results
first_result=$RANDOM
second_result=$RANDOM

# pass results from a key/value pair that is appended to a temporary file provided by JS7
echo "firstResult=$first_result" >> $JS7_RETURN_VALUES
echo "secondResult=$second_result" >> $JS7_RETURN_VALUES

@rem create results
@set first_result=%RANDOM%
@set second_result=%RANDOM%

@rem pass results from a key/value pair that is appended to a temporary file provided by JS7
@echo firstResult=%first_result% >> %JS7_RETURN_VALUES%
@echo secondResult=%second_result% >> %JS7_RETURN_VALUES%

Second Job: Read Variables

Shell jobs access order variables and order variables from a mapping to environment variables.

• The JOC Cockpit GUI offers to add the mapping per job from the right lower corner with the sub-tab Environment Variables.
• The mapping includes to freely choose the name of an environment variable that is used in the job script and to assign an existing order variable.
• The spelling of variable names is case-sensitive.
  
  

The job script implementation looks like this:

#!/bin/bash

# read results
echo "FIRST_RESULT = $FIRST_RESULT"
echo "SECOND_RESULT = $SECOND_RESULT"

@rem read results
@echo FIRST_RESULT = %FIRST_RESULT%
@echo SECOND_RESULT = %SECOND_RESULT%

Considerations

Scope of Order Variables

The above examples create order variables on-the-fly. Such variables can be overwritten by any job or instruction in a workflow.

However, if variables are declared with the workflow, then they are considered arguments that cannot be overwritten:

• When clicking to the background of the middle panel without selecting any object such as a job then the right panel shows the workflow properties.
• Workflow properties offer to add variables that
  • can carry no default value: such variables are considered mandatory and values have to be added when submitting orders.
  • can carry a default value: such variables leave it up to the order to provide a value that would overwrite the default value.

If a variable is declared at workflow level then it cannot be overwritten by subsequent jobs.

Historic Outcome of Order Variables

The above examples create order variables on-the-fly. Such variables can be overwritten by any job or instruction in a workflow..

• The JS7 keeps track of the historic outcome of variables with an order's position in the workflow and restores values if a job is repeated. You can make the second job fail and use
  • the Resume operation offered by the JOC Cockpit GUI to rerun the job with the same values of order variables as before.
  • the Resume parameterized operation offered by the JOC Cockpit GUI to modify order variable before rerunning the job.
    
    

This operation makes a popup window appear that looks like this:

• Most recent values of order variables are displayed and are offered for modification.
• The returnCode is a built-in variable that shows the historic value of the predecessor job's return code.
  
  

Modifications include to change values of order variables and to modify the order's position in the workflow:

• Drag & Drop the order by holding the red bullet of the failed order to move the order to a different position.
• Drag & Drop operations are limited within a logical scope:
  • they allow to select a position within a sequence of jobs and instructions in a workflow.
  • they do not allow to jump into a JS7 - Fork / Join Instruction or other instructions that checks an initial condition that might be met by the current order.