I do not think that this can be done out of the box. Do you talk about external dependencies set in a workflow?Regards,Juergen
1. Polling from successor system
2. Trigger from predecessor system
Did I overlook anything? Thanks in advance for additional feedback and suggestions.
There are several solutions to the parallel jobs run.1. Modify the Alias and add the RunID to the Alias in the pre processing2. When triggering the job, add the RunID as Key and the job name as value to a VARA. The status checker checks the VARA and deletes the entry when the job is finishedWe are using both (regarding to the usage) successfully since years.Regards
All of the checks up to and including the check for same logical date are working. The remainder are yet to be implemented, and may not be depending on how many people are actually using these options today.And speaking of that, here's a little SQL query I wrote that lists all but the most commonly used types of external dependencies in the AE DB.
SELECT OH_Name, JPP_Object, JPP_ParentObject, JPP_Alias, JPP_ParentAlias, JPP_ExtWhen, JPP_ExtSLTType, JPP_ExtSLTWithin,JPP_ExtElse, JPP_ExtElseAlarm, JPP_ExtTimeout, JPP_ExtTimeoutE, JPP_ExtTimeoutA, JPP_ExtExecute, JPP_PreCntExtFROM OH LEFT JOIN JPP ON OH_IDnr = JPP_OH_IDNRWHERE OH_CLIENT = 100AND OH_DeleteFlag = 0AND ( JPP_ParentObject IS NOT NULL OR JPP_ParentAlias IS NOT NULL OR JPP_ExtElse <> 0 OR JPP_ExtElseAlarm <> 0 OR JPP_TimeoutFlag <> 0 OR JPP_ExtExecute IS NOT NULL )ORDER BY OH_Name, JPP_ParentObject
Here are a couple more SQL queries.Populate the Check expected status pick list
SELECT ZUTYP_STATUSFROM UC_ZUTYPWHERE ZUTYP_ISALIVE = 0ORDER BY ZUTYP_STATUS ASC
Fetch the list of status codes for a given ZUTYP_STATUS
SELECT ZUTYP_STATUSRANGEFROM UC_ZUTYPWHERE ZUTYP_STATUS = ?
The JOBI that expands this into a full comma-delimited list has already been posted to another thread.More to come.
I'd like to know how the Automation Engine uniquely identifies external dependencies to ensure that subsequent instances of the same external dependency are not resolved by the same external task.I'm guessing it's something like the combination of the OH_Name of the workflow plus the EJPP_Lnr of the external dependency task.Can someone confirm this, or if it's not correct, let me know what the unique identifier is?
In some quick tests, I found some evidence to support my hunch about the unique ID the AE uses for external dependency matching:
U00011574 External dependency: 'EBM.DUMMY_TASK.SCRI(EBM.DUMMY_WORKFLOW.JOBP)' / Lnr: '00002' satisfied by Workflow RunID: '0434586903' / task RunID: '0434564643' / Lnr: '00002'.
AFAIK, there is no predefined variable for the Lnr of a task, so I use this SQL query to look up the Lnr of a workflow task based on its run ID.
SELECT EH_EJPP_Lnr FROM EH WHERE EH_AH_IDNR = ?
I'm using this in an SQLI VARA in the process tab of the workflow.
:SET &INPUT_RUN_ID# = &$RUNID#
:PSET &STATUS_CHECKER_LNR# = GET_VAR(EBM.GET_WF_TASK_LNR.VARA_SEC_SQLI)
(The SQLI VARA uses the script variable &INPUT_RUN_ID# in the bind parameter.)