Idea Details

Predefined read buffer variables for EXEC VARA tasks

Last activity 06-13-2019 09:20 AM
Michael Lowry's profile image
07-18-2018 04:30 AM

In several situations, a task can be started without having a workflow or schedule as its parent.

  • Tasks started by ACTIVATE_UC_OBJECT,
  • Notification/alert tasks started due to abnormal workflow end, reaching maximum run time, etc.
  • Tasks started by the execute object action in a task pre- or post-condition, or
  • Tasks executed by an EXEC VARA object.

 

  When such tasks are started, the Automation Engine automatically sets four predefined read buffer variables:

  • &UC_CAUSE_NAME: The name of the calling task

  • &UC_CAUSE_NR: The run ID of the calling task

  • &UC_CAUSE_STATE: The status of the calling task

  • &UC_CAUSE_RETCODE: The return code of the calling task

 

The task can use these variables to learn information about the calling task. In this way, the called executable object can be generalized to perform the correct actions based on execution context. For example, a Notification (CALL) object started due to abnormal workflow end can look up the details of the failed workflow.

 

When a task is started by an EXEC VARA, there are some additional pieces of information that would be useful to the called task. Below are the proposed new predefined read buffer variables.

 

Predefined read buffer variableDescriptionExample
&UC_CAUSE_VARA_NAMEThe name of the calling EXEC VARAWP_STATUS.VARA_EXEC
&UC_CAUSE_VARA_KEY
The key requested via GET_VAR or a {VARA,KEY,COLUMN} reference a task called by an EXEC VARA.WP1
&UC_CAUSE_VARA_COLUMNThe column requested via GET_VAR or a {VARA,KEY,COLUMN} reference a task called by an EXEC VARA.2
&UC_CAUSE_PRPT_NAME
The name of the prompt set, for a task called by an EXEC VARA used in a prompt set element data source or default.USER_INPUT.PRPT
&UC_CAUSE_PRPT_VAR_DATASOURCEThe name of the prompt set variable for a task called by an EXEC VARA used as a data source of a prompt set element (e.g., a combo box).USER_INPUT_1#
&UC_CAUSE_PRPT_VAR_DEFAULTThe name of the prompt set variable for a task called by an EXEC VARA evaluated via a  {VARA,KEY,COLUMN} reference in a prompt set default value.USER_INPUT_2#

With the benefit of these pieces of information, the called task could be designed to work more intelligently and efficiently, collecting and returning:

  • only the information requested (because the requested key & column are known)
  • the specific information relevant to the context (because the calling EXEC VARA, prompt set, variable, and type of reference are known).

 

This would make EXEC VARAs much more powerful and versatile. Here are a couple of examples::

  1. An SQL job run by an EXEC VARA accessed via GET_VAR or a {VARA,KEY,COLUMN} reference could, based on knowing the requested key & column, run a much more specific SQL query that executes more quickly, consumes fewer resources, and returns only the requested information.
  2. An SCRI run to set the default value of a prompt set element could generalized to be reused in many similar prompt sets and elements, loading the correct default value needed for each specific context.

 

One could also expand this idea to include additional predefined read buffer variables for tasks started by task pre- and post-conditions. E.g., the task could learn whether it was started by an execute object action in the pre-conditions or post-conditions.


Comments

08-14-2018 11:11 AM

I did a bit more testing and discovered that the four predefined read buffer variables are not set in tasks called by EXEC VARA objects. I’m not sure if this is a bug or not.Upon further reflection, I think the following statement from my original post may need to be amended. One or more of these situations may not set the four predefined read buffer variables.

In several situations, a task can be started without having a workflow or schedule as its parent.

  • Tasks started by ACTIVATE_UC_OBJECT,
  • Notification/alert tasks started due to abnormal workflow end, reaching maximum run time, etc.
  • Tasks started by the execute object action in a task pre- or post-condition, or
  • Tasks executed by an EXEC VARA object.

 

In any event, there is a straightforward work-around.

:SET &Activator_runID#   = FORMAT(&$ACTIVATOR_RUNID#)
:SET &Activator_status#  = GET_STATISTIC_DETAIL(&$ACTIVATOR_RUNID#,STATUS)
:SET &Activator_status#  = FORMAT(&Activator_status#)
:SET &Activator_retcode# = GET_STATISTIC_DETAIL(&$ACTIVATOR_RUNID#,RETURN_CODE)
:SET &Activator_retcode# = FORMAT(&Activator_retcode#)
:PRINT Activator          : &$ACTIVATOR#
:PRINT Activator type     : &$ACTIVATOR_TYPE#
:PRINT Activator run ID   : &Activator_runID#
:PRINT Activator status   : &Activator_status#
:PRINT Activator retcode  : &Activator_retcode#
:PRINT In workflow?       : &$IN_PROCESSFLOW#

I also found a reasonably acceptable way to tell the called task the name of the calling EXEC VARA: a new parameter.

(This example is a modified version of one of my General purpose EXEC VARAs.)