I know about these scripting commands:
I use a PREP_PROCESS_REPORT with a report type of ACT for my parent process flow. I then search matching for my task number and then the next U0007000 message contains (probably) my successor task. This only works reliably if there is only a single successor. It is difficult to know which to choose if there are multiples, unless you know perhaps the successor task's name. I've only used this technique for rather simple flows as activation order has always been predictable; not certain what will happen in really large and complex flows.
If you are assured that the successor task only can execute as part of the process flow and there would not be more than one active at a time and you know its name, you can use the GET_UC_OBJECT_NR. That certainly is a lot of ifs and ands, but it works fine for me when the criteria is met.
I'm guessing that the reason there is not some function that supplies this is similar to the restriction on the SYS_ACT_PREV_NAME/NR functions. What do you do if there is more than one?
Do you need
this information in the Post-Script? If so, I would write the RunID of each job
and its predecessor into a VARA (probably by an include in the Pre-Script). If a
job wants to know the ID of its successor(s), it just needs to filter the predecessor
column of the VARA by his own ID.
If you need
this information in the Pre-Script or Script, I wonder if the successors already have an RunID at activation
time. It depends on how the Automation Engine activates the sub elements of a workflow.
Probably there is also a difference if the
Job has “Activate at runtime” checked or not.
is a way get the successor(s) by an SQL query?
Mark Hadler said:I use a PREP_PROCESS_REPORT with a report type of ACT for my parent process flow. I then search matching for my task number and then the next U0007000 message contains (probably) my successor task.
I use a PREP_PROCESS_REPORT with a report type of ACT for my parent process flow. I then search matching for my task number and then the next U0007000 message contains (probably) my successor task.
Thanks, Mark. Here’s my implementation of your idea.
:SET &JOB_NAME# = UC0.MAL.SET_SYNC.J2:SET &WF_RUNID# = SYS_ACT_PARENT_NR():SET &HND# = PREP_PROCESS_REPORT(, &WF_RUNID#, ACT, "*U0007000 '&JOB_NAME#' activated with RunID '", "COL=DELIMITER", "DELIMITER=*'*"):PROCESS &HND#: SET &JOB_RUNID# = GET_PROCESS_LINE(&HND#,4):ENDPROCESS:CLOSE_PROCESS &HND#:PRINT "Run ID of job is &JOB_RUNID#."
Thanks for the feedback. We have several similar uses of this and they have not failed yet under V8 or before.
I guess that my only concern is that future releases may not activate tasks in the same currently predictable order. It is probably time to start a list of "clever" techniques that we use and ensure that we verify their continued operation as we move to newer versions.
I’ve made some more changes to my workflow, and now the above method no longer works. The problem is that the job that’s running the PREP_PROCESS_REPORT is running before the workflow has activated the successor. This means that it does not find the activation message from the workflow report. I have tried many different variations of the 'Generate at runtime' option on the jobs and worfklow, but I cannot figure out what I changed that broke it. Any ideas?
Are you saying that even with all of the tasks, including the process flow, using "Generate at runtime" (GAR) checked you are not seeing the list of activated tasks in the flow's Activation report at the time the PREP_PROCESS is executed? Or is this occurring with a mixture of GAR checked and not checked?
I have little experience with other than having the GAR attribute checked. We have very few that use this unchecked; those are mostly objects using the READ script statement. Most all of our task's scripting logic is dependent on their predecessor's results during or after their execution. However given what I understand of your description I can see the possibility of this with all or a mixture of GAR unchecked.
I assume that you are aware of script processing differences and "subtleties" between having GAR checked or not. There is a pretty good description of this under the topic of "Stage 2: Generation" in the Inside UC4 Guide. I'm only mentioning this since I sometimes get bit by these differences and I have usually found the answer to the "unexpected" behavior here.
p.s. Sorry for the delay, as I would have responded yesterday, but I was on vacation.
In my workflow, I’m using ATTACH_SYNC to attach a SYNC object to a later job in the workflow. My intent was to identify the job using your method of parsing the workflow activation log. Unfortunately, I have run into an obstacle to using this approach: ATTACH_SYNC does not work in a job or script that hasGenerate at runtime enabled. If one attempts to run ATTACH_SYNC from within a job that hasGARenabled, the following error will result:
U0020604 Runtime error in object 'UC0.MAL.SET_SYNC.J3B' line '00002': ATTACH_SYNC is not possible for 'generation at runtime', in this case the Sync checks are done before running the UC4 script.
So, here is the dilemma:
Ok, I figured it out thanks to input from a colleague. ATTACH_SYNC requires that the target task not have Generate at runtimeenabled. It does not care whether the taskwithin which it runs also has GARenabled.
I have completed my demonstration workflow, and attach it here together with its dependent objects.
Here is a description from the included DOCU object:
This workflow demonstrates 4 ways of controlling SYNC objects:1. UC0.MAL.SYNC_DEMO.J1This job uses a SYNC object in the traditional way: the SYNC object and actions are specified on the job's Sync tab.2. UC0.MAL.SYNC_DEMO.J2A, J2BThe first job (J2A) uses ATTACH_SYNC with the NEXT_OBJECT option to attach the SYNC object to the next job (J2B).3. UC0.MAL.SYNC_DEMO.J3A, J3B, J3CThe first job (J3A) parses the workflow activation log to find the run ID of the third job (J3C). It then uses ATTACH_SYNC to attach the SYNC object to that job. This approach is good if there are other jobs (J3B) between the job running ATTACH_SYNC (J3A) and the job to which the SYNC object must be attached (J3C).4. UC0.MAL.SYNC_DEMO.J4AThis job does not attach a SYNC object. Instead, it sets the state of the SYNC object directly using SET_SYNC. The SYNC object is locked in the pre-process tab, the job runs in the process tab, and the SYNC object is unlocked in the post-process tab. The while loop in the pre-process tab handles periodic checks of the state of the SYNC object if it is locked when it is first checked. The length of the time interval and the maximum number of retries are specified in variables.
Retrieving data ...