Michael A. Lowry wrote:
Pete Wirfs wrote:
I concur they are done bottom-up. In addition, if it finds a "redundant" request, it will only execute it once.
...at least in this
very simple case, wherein prompt set variables are used directly in the defaults of other fields, the Automation Engine appears to be
clever enough to determine the order in which the defaults should be resolved. It is definitely not just a simple bottom-up process.
After some initial discussion, REQ00134427 was converted to
INC00134427. In the context of this incident, I spoke with an Automic developer about how the Automation Engine evaluates prompt set defaults. The developer explained that the AE evaluates defaults
top-down, and performs
multiple passes, as many times as necessary, to ensure successful evaluation of all variables in PRPT defaults.
The results of my testing suggest that this is not a complete description of how it actually works.
- When PRPT defaults contain references to EXEC VARAs, it is possible to see exactly how many times these VARAs are evaluated, by looking at the statistics of the called executable object. These tasks also appear as child tasks of the executable object on which the PRPT is defined. When I defined these defaults in such a way that each one pointed to a different EXEC VARA, and these EXEC VARAs all had unique parameters, I never saw a case in which the called SCRI was executed more than once with the same parameters.
- Even so, the PRPT defaults wereusually but not alwaysevaluated in such a way that independent variables were evaluated first, and dependent ones later.
- I observed several cases where the data that were retrieved during evaluation of one PRPT default were mistakenly inserted into a different PRPT default (or even into multiple ones). I suspect this could be a manifestation of the bug described inPRB00134504. (See alsothis discussion.)
- I observed several instances wherein the data source VARAs were accessedbeforeall defaults had been evaluated. I am not sure why the AE would need to access the data sources before evaluating all variables in defaults; perhaps it wants to ensure that each default value is a valid value (one of the values returned by the data source). This problem happens only intermittently.
In the prompt set I am working with, although each default is specified by its on EXEC VARA, they all call the same SCRI, just with different parameters. Because I know the order in which these defaults must be evaluated, and because they all call the same SCRI, I am beginning to think that the best way forward is to hard-code the order of evaluation into the SCRI. In other words, the SCRI will test whether certain variables have values yet, and if they do not, it will look up and set their values in the correct order. This way, regardless of which PRPT default is evaluated
first, before the called SCRI actually does any of the work of evaluating
that particular element’s default value, it will look up and set the default values of all of the dependent variables. Effectively this is a way of forcing the order of evaluation. I’ll post an update later with the results.
I have also seen another problem wherein VARA object references of the form
{VARA,KEY,COLUMN} in EXEC VARA parameters are not resolved correctly. Only two of my nine EXEC VARAs are set up in such a way. I’m not sure how to work around this problem. The referenced VARA in these cases are SQL VARAs. Perhaps I can more easily track whether & how they are being accessed by using EXEC VARAs that run SQL JOBS objects instead.