How to view workflow variable values during workflow execution in RSA Identity Governance & Lifecycle

[#1]

Article Number

000037882

Applies To

RSA Product Set: Identity Governance & Lifecycle
RSA Version/Condition: 7.x
 

Issue

When trouble-shooting RSA Identity Governance & Lifecycle workflows, the contents of the workflow variables may need to be viewed to verify behavior. This RSA Knowledge Base Article describes how to view workflow variable values in a live workflow, i.e. the processing workflow off of an existing request.

Resolution

To view the variable values in a processing workflow, go to the change request and click on the Processing Workflow link. This opens the processing workflow in the workflow editor. When viewing the main request workflow or one of the sub-workflows (approval and fulfillment workflow(s)) and without any nodes selected, the variables defined for that specific workflow may be viewed on the Job Properties sidebar under the Variables header. These variables include things like SQL node variables, submission values, form values, and Out-of-the-box (OOTB) information regarding the change request.
 

 Image description

The dynamic workflow variables, i.e. the ones you access from the context-sensitive right-click pull-down menu, the ones that look like ${variable_name}, are as their name implies, dynamic, so their value is relative to where they are called and do not appear in this list by default. If you are trying to trouble-shoot the values of dynamic variables, you can use a SQL Select node to capture the output in the VARIABLES section.

EXAMPLE: 

Let's say you have the below provisioning nodes defined in a workflow and you would like to make sure the correct values are being set.
 

Image description

 

Image description

 

Dynamic variable explanation:

First, to understand dynamic workflow variables, the structure needs to be explained. In this example, the following workflow variables are being validated:

• ${access_request_cri_meu_userId}  
• ${access_request_cri_meu_title}  
• ${access_request_cri_acc_cas9}  
• ${access_request_cri_grp_cas9}  

${} denotes a workflow variable
access_request_cri = Access Request Change Request Item. This means we are pulling a value from one of the items in the change request, such as an individual add, remove or change.

meu = Master Enterprise User. This means we are pulling a user attribute from the change request item.

userId = the User ID User Attribute which is pulled from the USER_ID column value in the T_AV_MASTER_ENTERPRISE_USERS table.

acc = Account. This means we are pulling an account attribute from the change request item.

cas9 = the External Id Account Attribute which is pulled from the CAS9 column value in the T_AV_ACCOUNTS table.

grp = Group. This means we are pulling a group attribute from the change request item.

cas9 = the External Id Group Attribute which is pulled from the CAS9 column value in the T_GROUPS table.

 

Capturing the variable values

For testing purposes you can put the SQL Select nodes anywhere in the specific workflow that you are troubleshooting. In this case, the nodes have been added directly before the specific provisioning node being troubleshooted.

The SQL syntax is as follows:
 

SELECT 
${access_request_cri_meu_userId} as TEST_userid, 
${access_request_cri_meu_title} as TEST_title
FROM DUAL

and
 

SELECT 
${access_request_cri_acc_cas9} as TEST_aname,
${access_request_cri_grp_cas9} as TEST_gname 
FROM DUAL

By selecting these values into alias names (as <alias-name>), they will show up on the Job Properties sidebar under the VARIABLES section.
 

Image description

 

Image description

Note the alias names in the below processing workflow:

Image description