how to make use of subflow parameters and retrieve the parameters to be used on decision blocks?

[Legacy User]

Hi guys, I'm new to this tool and I'm currently trying to make use of subflows in my main flow to cover certain procedures that are repetitive across different branches in my main flow.  Since subflows can have parameters, i tried to pass values from my main flow  hoping that i can retrieve it in the subflow for specific decision points but i cannot retrieve those values properly to use it in the subflow.

 

To  visualize the flow i want to accomplish, please refer to the explanation below

 

Start Main Flow

Pass A as parameter of Subflow1

Enter Subflow1 has a decision node to check if parameter is A or B, since param is A, it will execute path with A as a condition

Exit Subflow1

Pass B as parameter of Subflow1

Enter Subflow1 has a decision node to check if parameter is A or B, since param is B, it will execute path with B as a condition

End Main Flow

 

Given this explanation, i have a few more questions to ask.

Is this possible with the current features in ARD?

Am I using the subflow feature properly?

What are the best practices in using the subflows base on your experience?

Does anyone have any sample, or suggestion how the flow above can be done? 

 

All suggestions are welcome. Thanks in advance for any help on this topic.

[gilta03]

Hi Francis, 

 

I apologize for the delayed reply, but we are currently asking our SMEs on how best to answer your question. I hope to have an update later this week. 

 

Best regards,

Taylor

[Les Dover]

Hi Francis,

 

One of our Presales Consultants had this as a comment:

 ___________________________________________________________

This data driven way of using sublfows is incorrect. ARD cannot react to data like this when producing paths. There are several ways to create the behaviour you desire with subflows.

 

1. Constraints. You can apply constraints across subflows. I assume you have a decision, let’s call it X, in the parent flow which sets the parameter/test data to A or B and a similar one in the subflow, let’s call it Y. You would then add a constraint it if ( X=>A and Y ) then (Y=>A) for the first sublfow and then similarly if ( X=>B and Y) then (Y=>B).
2. Have multiple start blocks in your subflow. This means you can have different “entry points” to your subflow and then use the normal modelling techniques to describe the logic from each. This is possibly a bit better than the first approach because you don’t have to worry about adding the constraints when adding the subflows, just linking up the correct start points.
3. Storing sets of paths. You could store two sets of paths in the subflow, one where Param = A only and one where Param = B only. This is quite a tidy solution but can get a bit tiring if you had Param = A or B or C or D or …

 

 

 

A note on parameters. The parameters passed to a subflow are really just there to provide correct test data. For instance, if my subflow is the login page of my website it could have a parameter called ^HomePage^ and then you could have test data like LoginPage = ^HomePage^/login.

 

There are Boolean function in datapainter which can react to data, and can be used within ARD, but because this is done within data painter you are not applying that logic to the model so it will not generate paths to cover both true and false statements

 

Hope that helps,

 

William Sault
 ___________________________________________________________

Please let us know if this answers your questions.

 

Cheers!
Les

[Ryan Froehling]

I find myself in a similar situation to Francis, and this answer is quite helpful. Could you please expand on point #3-- what does it mean to have two sets of paths, and how would each one be associated with a specific parameter value? Is this done via the path explorer of the child flow, or somewhere else? I'd like to try out this approach but don't know how to.

Thanks!

Ryan

[Pavel Sestak]

Hi Ryan, 

1. In the subflow, you crate stored path type for every variant you want to use, do not forget you can manage your stored path types in General Config under Default Path Types tab.
2. For each stored path type you do:
   1. Use different color of pins to mark which option needs to be in the path output.
   2. optimize based on your requirements
   3. check the paths whether you have paths covering what you needed.
   4. You may delete/filter out paths that you do not need
   5. Save the paths to the stored path type
   6. You may repeat steps 1-5 to add paths with another pin (you may use add to existing paths flag to just get paths covering missing coverage)
3. When using the subflow you choose which stored path type you want to use and only these paths will be included 

Key part is to filter which paths are stored in which stored path type by the option it have.  
For some cases it may be easier to generate paths without the pins and then manually save paths to various stored path types. You can move stored paths between path types as well.

I hope this helps
Pavel

------------------------------
ARD Product Manager
Broadcom
------------------------------

[Billy Keefer]

Hello Ryan.   Maybe it would make sense to start back at the beginning.  :-).  What are you trying to achieve?
regards

[Ryan Froehling]

Hey Billy,

I am coming from an automation perspective (ie, the model must generate complete automated scripts). I am using Cucumber so all statements should be imperative without conditionals.

I have a subflow which represents a web form, and a large end-to-end flow which includes that subflow several times. Each time the web form is filled out in the E2E flow it must choose different options (which should be configurable in the parent flow).

I am using subflow parameters to select from different options on the same step (eg, different radio buttons for a given question)--this works great. However, there is one particular step on the web form where selecting a certain option populates an additional selection to make. Thus I need to use an actual branching path in ARD and add the additional selection as a process block on this path (whereas the rest of the flow is linear).

So this is the basis for my question--I need my subflow to take one of two possible paths, depending on the configuration in the parent flow. I did implement the stored path types method suggested in this thread and that is working for me. Now it is not the case that, say, the nth instance of the subflow will always choose the option which leads to the additional question (take the branching path); my scenarios dictate that for some cases, that option should never be selected. This means that I must remove and re-add the subflow block on a case-by-case basis before outputting my scripts, which seems less-than-ideal (but still totally workable). As an ARD novice I am always looking for alternate methods/best practices.

Thanks! 

Ryan

[Billy Keefer]

Using/setting different path type is one way of achieving your end goal.   Depending on the logic in your patent flow, maybe have a look at constraints.  Within ARD you can set a constraint across Parent/child flows.  For example, only go via this subflow edge if this parent edge is taken.

[Ryan Froehling]

Thank you Pavel for the details! This approach is working for me!

Ryan

[Legacy User]

Hi Taylor, William,

 

Thanks for the help and suggestions. The explanations covered all of my questions. I'll take note of this. The explanation on constraints and multi-start nodes clarified some of the other  ideas i had in mind as a work around to this problem.

 

I would also like to ask if there are any plans in future releases to

1) have some sort of boolean functionality / add constraints directly on the nodes rather than placing them under the constraints view. The problem i see with the constraints view is that if you have multiple constraint ( atleast 20 or more ), its difficult to pinpoint exactly which one you want view or modify unless you're pretty familiar with the setup. 

 

2) Enhance subflow to behave like a programming sub procedure which can accept parameters and make use of those parameters as logical input?

 

Kindly advise, Thanks.

Francis

[Legacy User]

Francis,

 

I am doing something similar to this at a customer site. What we are doing is a bit more of a creative use than a standard one, but it may be of value to you. The key here is that you have to include the same subflow twice. When you invoke it the first time, you pass in A. When you invoke it the second time, you pass in B. You only need to expose as parameters those elements that you need to pass to the subflow. This is done through Properties -> Parameters in the subflow.

 

There are a couple of potential hazards to this approach. If you have any embedded automation and use the automation export, you will get two copies of the exported content from your subflows. This can be okay if you have designed it carefully, but it can also cause problems if you aren't expecting to get double the information. The multiplied information is appended into the output of the export. So if your export created a cmd file and you included it twice, you would get a single command file where the script appeared twice back to back.

 

Let me know if this is enough detail for you to try this out. If not, I will find some time to put together a more detailed guide.

 

Thanks,

Brian

[Legacy User]

Hi Brian,

 

That's a good suggestion, i'll definitely take note of that approach and at the same time, try to simplify the subflows to optimize the results i will be getting with the two combinations. I've encountered similar behavior you've mentioned when i tried generate the path for my main flow and it generated much more scenarios than i originally intended. Like you said information multiplies depending on the available stored paths on the subflow. As long as i can ensure that all subflow stored paths generated do not branch off into different logical breakpoints, the risk of getting duplicated or sometimes invalid  information can be minimized. 

 

Thanks,

Francis

[[e-mail]]

let's break it down into **** steps:

1. Create a Subflow:

• Imagine a subflow like a mini-task within a larger process. Define what it does and any input parameters it needs.

2. Add Parameters to Subflow:

• When setting up the subflow, specify parameters. These are like placeholders that get filled in when you use the subflow.

3. Connect the Subflow:

• In your main process, include the subflow like a building block. Connect it where you want it to run.

4. Pass Values to Subflow:

• When connecting, assign values to the parameters. This is like giving information to the subflow so it knows what to work with.

5. Inside the Subflow:

• As the subflow runs, it uses the values you passed in. It's like giving it the tools it needs to do its job.

6. Retrieve Parameters in Decision Blocks:

• After the subflow finishes, you can use the output parameters in decision blocks. It's like taking the results and deciding what to do next.

Example:

• Subflow: "CalculateTotal" with parameters "Quantity" and "Price."
• Main Process: Connect "CalculateTotal" with values (Quantity=5, Price=10).

In a decision block after the subflow, you could say:

• If "Total" > 50, do A.
• If "Total" <= 50, do B.

It's like breaking down a big task into smaller parts, passing information between them, and making decisions based on the results.

[Jhoney Bairstow]

Informative Aritcle