Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Hanging Path Trigger components ==> Go To components

Created: 29 Mar 2013
AnaMan's picture
1 Agree
0 Disagree
+1 1 Vote
Login to vote

This combination of components has a unpleasant restriction.

There is no easy way to implement a flow like this:

Hanging Path Trigger --> A rules dependent on component caught by trigger --> Go To Component By ID/Name

Because Hanging Path Trigger components return only variable with ID of the caugth component.
This ID is useless because it is not exposed in component configuration window. The only way to get its value is read it from internal data from model file.

Moreover, the Go To Component By Name has a nice feature allowing to provide a destination component's name as an input variable value.
But how to get the name of the component? By copying it from configuration window? This on only in-design feture.

So my proposal is to extend the Hanging Path Trigger components family by adding one more output variable with component name (like in Exception Triggers components, a class name would also be useful). This change should be painless - preserves downward compatibility.

The second option is to provide a dedicated component that can read on component's name (class name) by its ID.

I propose this because I have some clever ideas how to automate some functions in process using only one submodel and rules that can identify components which trigger have caught.