Load default prompt set values from a VARA object using {VARA,KEY,COLUMN} references

[Michael Lowry]

Has anyone tried to create a prompt set whose default values come from a VARA object? I thought this might be a nice way to store and recall each user’s most recently used values. Here is what I have in mind:

The &$USER# variable is resolved to the ID of the executing user; then the enclosing VARA object reference (in the format {VARA,KEY,COLUMN}) is resolved.

The only problem with this approach is that if the specified VARA object, key, or column does not exist, the VARA object reference will not be resolved at all, and this may not be desirable.

[Legacy User]

Hi Michael

We do use this feature very heavily with various variables - some are internal, some are calculated during runtime.

If the {} notation does not resolve the vara or key wasn't found - this seems to be very relieable, in about all cases it was either a typo or the key was forgotten to add. It can also be added when the prompt is open and when it's being submitted it will resolve. We did only use this feature with STATIC VARAs, I don't know how it behaves with SQL VARA / other types.

Hope this helps, regards
Joel

//Edit: AE 10.0.7

[Michael Lowry]

The only problem with this approach is that if the specified VARA object, key, or column does not exist, the VARA object reference will not be resolved at all, and this may not be desirable.

It occurred to me that I could use an EXEC VARA as a wrapper between the prompt set and the actual the static VARA where previously used settings are stored. The EXEC VARA would check to see if values already exist, and automatically fill in initial values if there are none present.

Because an EXEC VARA can have only one result column though, I would have to create a separate wrapper EXEC VARA for each prompt set value whose default I want to load this way.

[Legacy User]

I agree with that. I guess this has been done to provide backwards compatibility.

By the way.. we use this feature also for environment-specific values.

VAR:
CONFIGKEY          |{VAR,CONFIGKEY/&$CLIENT#}
CONFIGKEY/0010 |PROD
CONFIGKEY/0020 |TEST

If you put {VAR,CONFIGKEY} into your promptset it will resolve to PROD / TEST depending on whether the solution run's on client 0010 or 0020. Very useful for transportable solutions.

[Michael Lowry]

The Automation Engine apparently does not like it when the default value of a prompt set element contains a curly-brace reference to an EXEC VARA. Running such workflow hangs the Java GUI completely. If I kill the associated java process and log in again, I see that the workflow is in the Waiting for user input status. If I select the workflow and choose Modify task parameters, the GUI hangs again.

I also tried submitting the workflow in the Automic Web Interface. The web UI does not hang, but the prompt set “Request” never appears, and the workflow remains in the Waiting for user input status.

The EXEC VARAs work fine on their own. This seems like a bug.

Oh, and the AWI lacks the Modify task parameters function. I added this to the list of missing AWI features.
Update: This function was added in v12 and is called Open User Input Dialog.

[Michael Lowry]

Because an EXEC VARA can have only one result column though, I would have to create a separate wrapper EXEC VARA for each prompt set value whose default I want to load this way.

I thought I might have found a clever way around this, by creating a data sequence containing multiple columns in the SCRI called by the EXEC VARA.

! Read values from a static reference VARA, addding keys that do not exist.
! It is a bit like NOTFOUND=IGNORE, but for curly-brace VARA object references.

! Read input parameters from calling EXEC VARA 1: user, 2: VARA value column
:READ &Ref_VARA_Name#,,
:READ &Ref_VARA_Key#,,
:PRINT "Reference VARA name   : &Ref_VARA_Name#"
:PRINT "Reference VARA key    : &Ref_VARA_Key#"
:SET &Value_1# = GET_VAR(&Ref_VARA_Name#,&Ref_VARA_Key#,1,)
! If GET_VAR returns a single space, it usually means the key was not found.
:IF &Value_1# = " "
:  PRINT "Creating initial user defaults."
:  PUT_VAR &Ref_VARA_Name#, &Ref_VARA_Key#, "", "", "", "", "", ""
:ENDIF
:SET &Value_2# = GET_VAR(&Ref_VARA_Name#,&Ref_VARA_Key#,2,)
:SET &Value_3# = GET_VAR(&Ref_VARA_Name#,&Ref_VARA_Key#,3,)
:SET &Value_4# = GET_VAR(&Ref_VARA_Name#,&Ref_VARA_Key#,4,)
:SET &Value_5# = GET_VAR(&Ref_VARA_Name#,&Ref_VARA_Key#,5,)

:SET &ProcHnd# = CREATE_PROCESS(NEW)
! Write column headings
:PRINT "Writing column headings to data sequence."
:SET &RC# = PUT_PROCESS_LINE(&ProcHnd#,"Value 1;Value 2;Value 3;Value 4;Value 5",";")
! Write row of 5 values from reference VARA
:PRINT "Writing values to data sequence:"
:PRINT "&Value_1#;&Value_2#;&Value_3#;&Value_4#;&Value_5#"
:SET &RC# = PUT_PROCESS_LINE(&ProcHnd#,"&Value_1#;&Value_2#;&Value_3#;&Value_4#;&Value_5#",";")
! Send result back to calling EXEC VARA
:PSET &Result# = SAVE_PROCESS(&ProcHnd#)

The variables &Ref_VARA_Name# and &Ref_VARA_Key# are passed to the SCRI by the calling EXEC VARA. The idea is that the &Ref_VARA_Name# is the name of a static VARA that might be missing some keys. Curly-brace-style VARA object references would resolve to null values in cases where the key is missing. I’m not sure what key to reference in the curly-brace-style VARA reference though, and the bug is preventing much progress anyway.