Not able to create references to external modules with Alias name

Document ID : KB000089589
Last Modified Date : 14/04/2018
Show Technical Document Details
Issue:
Not able to create references to external modules with Alias name
Resolution:


Appliesto Applications Manager version 8.0 and 7.x

Symptoms

When trying to create references to external modules that have an alias name/variable task name defined, the following error messages may appear:

'External dependency can't be created due to symbolic alias name'

when trying to create the dependency or

'ORA-20143: Cannot reference an external module with a variable task name'

when trying to apply the changes.


Cause

This is expected behavior and its implementation has been documented in a bugfix:

'The problem is that there is no good way to evaluate the other chain's runtime environment. For instance in your example, chain_id will return the jobid of the external chain. But, what if it hasn't been requested yet (the jobid won't exist), or what if there are two copies in the backlog (which jobid should be used)? The predecessor definition has to refer to the task name that will actually be used during run-time.

In the same way, A subvar is a variable. If a subvar is used in the task name for a chain, that has run and finished. Once a new chain with an external predecessor evaluates the subvar the value may have changed. For example, Lets say you have a module in a chain called Chain_A/Module_R_{#Subvar_test}. This module runs. At the time the subvar #Subvar_test evaluated to 123 and then the job is in the backlog called, Chain_A/Module_R_123. Now you have new chain with an external predecessor to Chain_A/Module_R_{#Subvar_test}. Now the subvar #Subvar_test evaluated to ABC. When you new chain goes into the backlog it will check the predecessor for Chain_A/Module_R_ABC. This module never existed and will never be set to satistfied.

This is why it is not a good idea to have an external predecessor set to a taskname that uses a wild card.'


Resolution

One workaround would be to create the modules without symbolic names in order to be able to create predecessors inside the chain.

Another workaround would be:

Add a condition on that job within the process flow where the wait needs to happen. The condition would check against a substitution variable which runs some SQL to check the backlog. If there are components from further up in the flow still running or pending regardless of which instance of the flow they belong to then delay the task.