article

A sub process flow (also called a sub flow for short) is a separate process flow that begins running when it is triggered by another activity or event in a different process flow. Think of sub flows as chunks of self-contained logic that will get executed when they are triggered by certain events in the simulation model or general process flow. If you are familiar with programming terms, you could think of a sub flow as a function or a subroutine.

You can use sub flows to perform calculations or to simulate more complex procedures that are triggered by specific activities or events in the main process flow. A sub flow could run a simple calculation to dynamically determine a processor's processing time. Or a sub flow could contain a task sequence that will be used by several different task executers at certain points during a simulation run.

For example, perhaps you want to simulate an assembly line of some sort. When items come off an assembly line they will need to go through a set of Quality Assurance procedures after which the item will either pass or fail. You could simulate this using a sub flow that is triggered once a token gets to a particular activity in the process flow.

This topic contains the following sections:

• How Sub Flows Work
• Creating Internal Sub Flows
• Creating External Sub Flows
• Linking to Sub Flows
• Multiple Start or Finish Activities
• Linking Parent and Child Labels
• Accessing Child/Parent Tokens

There are three ways of utilizing a Sub Flow:

• Run Sub Flow Activity
• Create Tokens Activity
• executesubflow() command (for more information see the Command Helper or Commands section of the User Manual)

How Sub Flows Work

The following list explains how sub flows work from beginning to end:

1. During a simulation run, a token enters a Run Sub Flow or Create Tokens activity. (See Run Sub Flow or Create Tokens for more information.)
2. The Run Sub Flow or Create Tokens activity then creates one or more child tokens on the sub flow's Start activity. (See Start for more information.) The child token is linked to its parent token, which is the original token that first entered the activity that triggered the sub flow. When a child token is first created inside a sub flow, it will be a copy of its parent token, meaning that it will inherit all of the labels and data from the parent token. (See Label Access for more information.)
3. The child token will begin to run through the activities in the sub flow. While the child token is running through the sub flow, the parent token will wait on the activity that initiated the sub flow. NOTE: A parent token can't be destroyed if it has child tokens in the model.
4. When the child tokens reach the Finish activity on the sub flow, the child tokens will be destroyed and any necessary information will be updated on the parent token. (See Finish for more information.)
5. The parent token will be released and will move to the next downstream activity in the main process flow. NOTE: You can set the Create Tokens activity to release right after creating the child tokens on the sub flow. The parent token does not necessarily have to be dependent on what happens to the child tokens in the sub flow.

Create Tokens vs. Run Sub Flow

Technically, a Create Tokens activity can send tokens to any activity in a sub flow, but a Run Sub Flow activity can only send tokens to a Start activity at the beginning of a sub flow.

Creating Internal Sub Flows

The following image shows an example of a simple internal sub flow during a simulation run:

An internal sub flow is a sub flow inside of an existing process flow. Internal sub flows are basically an independent block of activities that begin with a Start activity and end with a Finish activity. Therefore, to create an internal sub flow, simply create a block of activities that begin with a Start activity. After creating the block of activities, link it to the main process flow. See Linking to Sub Flows for more information.

How many internal process flows can be made?

There is no limit to the number of sub flows you can create inside a process flow.

Creating External Sub Flows

The following image shows an example of an external sub flow during a simulation run:

An external sub flow is a separate process flow that was assigned the Sub Flow type when it was first created. It will have its own separate window and will be listed as a separate process flow in the Toolbox.

To create an external sub flow:

1. Inside the Toolbox, click the Add button to open a menu.
2. Select Process Flow, then Sub Flow.
3. The new sub flow window will appear and you can begin adding activities to it. NOTE: Sub flows function best when they begin with a Start activity and end with a Finish activity.
4. After creating the block of activities, link it to the main process flow. See Linking to Sub Flows for more information.

Linking to Sub Flows

If you are linking to sub flow from a Create Tokens activity, you can use the sampler button next to the Destination property to select the activity (in the sub flow) where you want to create a child token.

To link to a sub flow from a Run Sub Flow activity:

1. You'll notice that when you first add a Run Sub Flow activity to the main process flow, there will be an exclamation mark to the right side of the activity. This mark means that you have not yet linked the Run Sub Flow activity to a sub flow, which is required.
2. Click on the exclamation mark to the right side of the Run Sub Flow activity to enter sampling mode. You will know you are in sampling mode because your mouse cursor will change to the sampler icon .
3. Now click on the Start activity at the beginning of the target sub flow. If you are linking to an external process flow, you can click anywhere inside a sub flow window to link to that sub flow.
4. The Destination property will update to show the sub flow to which it is now linked. You can edit this property if needed.

Link directly to Start activities when possible
If linking to an external sub flow window, the Run Sub Flow activity will search through that sub flow's list of activities and find the first Start activity. The Run Sub Flow activity will send any newly created tokens to this Start activity. If the Sub Flow Process Flow contains multiple Start activities, you should link the Run Sub Flow activity to the specific Start activity it should be sent to.

Multiple Start or Finish Activities

A Start activity may be connected to multiple Finish activities, as illustrated in the example sub flow in the following image:

In that same vein, multiple Start activities may share the same Finish activity. Technically, each Start activity would be the beginning of a different sub flow. The following image shows an example of this kind of sub flow:

Linking Parent and Child Labels

One of the advantages of using sub flows it that it will allow you to create links between the labels on parent and child tokens. Child tokens can possibly be set to update the labels on the parent token (and vice versa) during a simulation run.

The following image shows the label-related properties on the Create Tokens activity:

The Run Sub Flow activity's label-related properties are nearly identical to the Create Tokens activity with only two exceptions: 1) there is no Create Tokens As menu, and 2) the Copy Labels to Tokens on Create property is named Copy Labels to Children on Create instead.

• Create AsDefines the relationship of the original token to the created token(s).
  • Independent Tokens - Created tokens will have no association with the original token.
  • Child Tokens - Created tokens will be child tokens of the original token.
  • Sibling Tokens - Created tokens will be sibling tokens of the original token. In other words, they will have the same parent as the original token.
• Label Access on Parent Only By default, the Label Access on Parent Only checkbox is cleared on the Create Tokens activity and checked on the Run Sub Flow activity. When it is cleared, any activity can create, modify, or read labels on either the parent or the child tokens.
  
  When you check the Label Access on Parent Only checkbox, access to the labels on the child tokens will be restricted. In other words, activities will only be able to create, modify, or read labels on the parent token. This restriction essentially causes your parent token to be in multiple activities at the same time because child tokens will just be duplicates of the parent token (as opposed to being independent tokens). NOTE: This option is the only way a child token can add labels to its parent token.
  
  When the Label Access on Parent Only checkbox is checked, the next two properties will not be available.
• Parent Label AccessThis menu determines if and how child tokens may access labels owned by their parent. The menu has three available options:
  • None - The child tokens have no access to their parent's labels. All reading, writing and adding of labels are done on the child. Select this option if you want the child to be a completely separate entity from the parent.
  • Read - This option only allows child tokens to get information from labels on their parent; the child tokens will not be able the add or set the parent's labels. Select this option if you want to set and add labels on the child rather than the parent. If an activity in a sub flow tries to set a label on the child token that is owned by the parent token, the child will add a label to itself with the given label name and value.
  • Read / Write - This option allows child tokens to read or set the parent's labels, but the child will not be able to add labels to the parent token. Setting labels that are not on the child or parent will cause a label to be added to the child with the given label name and value.

  Parent / Child Relationships
  When accessing labels on a token, the token will first look at labels owned by itself. If the label doesn't exist and the token has read access of its parent's labels, it will try and access the label on the parent. If the label doesn't exist on the parent, it will check the parent's label access and if able, look up to the next parent's labels, and so forth.

• Copy Labels to Tokens/Children on Create By default, the Copy Labels to Tokens/Children on Create is cleared. When this checkbox is checked, the entering or parent token will copy all of its labels to the created tokens/children. On a Create Tokens activity, if the Create As is set to Sibling Tokens, only labels owned by the entering token will be copied. Otherwise, all labels from all ancestors of the token will be copied (based upon each token's label access type). The copied labels can be read or written on the child regardless of the the option you selected in the Parent Label Access menu. However, new labels added to the parent may still be read or written if the label access type allows it.
• Assign Labels to ChildrenYou can use this group of properties to set labels on the created tokens/children. Each label value will be evaluated for each created token/child. The functionality is identical to the Assign Labels activity. See the Assign Labels activity for more information about these properties.

Viewing Parent/Child Relationships

Once a parent/child relationship has been created, the parent token will display the number of children it has in the process flow view by default. You can change these settings on the Process Flow Properties page if needed. See Changing Process Flow Visuals for more information.

Viewing Labels

If you click on a child token, the Quick Properties will display all of the labels owned by the child token as well as any labels from the parent token that the child has access to, as shown in the example in the following image:

If a label is not accessible to the child, it will not display in this list.

The following table explains the meaning of the symbols on these labels:

Symbol	Meaning
(P)	The label is owned by the parent
(PP)	The label is owned by the parent's parent (grandparent), and so forth.
+	When it is next to the P, it means that the child token has the ability to write (set) the label.

For example, in the example from the image above:

• Setting the "type" label on the child would cause the "type" label to be set on the parent token.

  

• Setting the "weight" label on the child would cause a "weight" label to be added to the child. The child would no longer have access to its grandparents "weight" label as reading the label would read it off of the child.

  

Accessing Child/Parent Tokens

There are two methods of accessing a child's parent token. The first is by entering the following in a Universal Edit field:

Token: Parent

The other method is through FlexScript using the following command:

getparenttoken(token)

Child tokens can be accessed by rank through the parent using the command:

getchildtoken(token, 1)

Passing in 0 for the index or leaving off the index will return the # of children the parent has.

getchildtoken(token)