Posted: 24 May 2017 15:24 EDT Last activity: 26 May 2017 16:24 EDT
We tried to parameterize the value passed into a subprocess shape in order to minimize the number of shapes in our flow.
Details: we launch our application and land our dashboard which has an "addtask" button that will launch flows that allow for various items to be worked. The addtask intent selected launches a flow that verifies the intent name is legitimate and then goes into a decision table that sets the flow to launch to a property based on the relevant intent name. We then set this property value to a parameter in a connector that connects with a subprocess shape. In the subprocess we pass the parameter value. This works. *these top flows will be referred to as primary flows and *all* flows are screenflows
Within the primary flows we have similar decision shape/"out" flows that we wanted to parameterize in the same way as above. What we found is that we would consistently error out whenever we launched a primary flow that had a "nested" parameterization. If this primary flow, with the "nested" params, was called from another primary flow it worked mostly as expected (the breadcrumbs were no longer present). As it currently stands launching this flow from within another primary flow is not an option. We tried various combinations of bread crumbs on/off and functionality enabled/disabled without success. We also tried to create a wrapper flow to circumvent this issue and suddenlyno values were being passed into the subprocess even though no changes had been made regarding this.
Is there a best practice for parameterizing flows? Is this not working as expected? A known issue?
***Updated by Moderator: Marissa to update categories***
What you are doing sounds fairly sophisticated. My guess is that some necessary flow parameters are not getting set when you go through so many levels of redirection. You will probably need to trace the creation of the first subflow to figure out what is getting set under the covers and then do the same for the next layer and confirm if old values are bleeding through or something similar.
I do worry that this is fairly outside of the guardrails, and so features like the breadcrumbs might not work (or require more effort on your part) and that an update or Hot Fix might actually break your custom code since we're talking about manipulating more of the process engine internal data.
Do you have any idea or suggestions for us as to how we can dynamically call the sub flows.. from within the primary flows.
Traditionally we enter the actual subflow name in the subprocess shape but in our case the subprocess being called depends on a decision table and outcomes are numerous say 10 subflows for now but can increase in future. We tried setting the flowname in a parameter and referenced it into the subprocess shape. It works for standard flow but if we are using breadcrumbs it gets messy because GetFlowDefaults activity actually fails since it tries to fins the flowname with whatever is in the subprocess shape. If it were smart enough to check if the value is a parameter then this issue wont have arised.
if we add so many flow shapes then # of shapes would easily cross 15 beating the guardrails.
Do you have any suggestions for us as how we can implement the flows to meet our requirement and also not break any guardrails? thanks in advance