In the Process Flow tool, an instance is a single occurrence of a sub flow, fixed resource process flow, or task executer sub flow. Usually, you'll create one of these kinds of process flows to act as a basic template. When an object (such as a fixed resource or task executer) uses the process flow during a simulation run, it will become a separate instance of that process flow. For that reason, there might be multiple instances of the same process flow running at the same time during a simulation run.
The concept of instances is somewhat abstract. For that reason it might help to compare it to something concrete, such as cooking with a recipe. When you build any kind of process flow other than a general process flow, it's as though you are creating a basic recipe for a particular meal. Individual chefs can then make that recipe on their own. Each time someone makes the recipe, they are making an instance of that recipe. Several individuals might be cooking the meal using the recipe at the same time. But they are all using the same basic recipe as their starting point. Also, if you change the recipe, you will change all instances that use that recipe from that point forward.
In that same vein, when you build a process flow, you are building a "recipe" for the basic logic that will control the objects in your simulation model. During a simulation run, many different objects could use the same process flow logic (the recipe), but each one would be a separate instance. If you change the main process flow (the recipe) process flow, it will change all the instances of that process flow as well.
The Task Sequence Tutorial provides a useful example of process flow instances. In this tutorial, you create a sub flow containing a simple task sequence for loading and unloading flow items from a processor. The model has two processors, each with its own operator. Both operators use the task sequence in the main process flow to load and unload the flow items. The following image shows what happens during a simulation run:
In this case, the main process flow is the recipe because it contains the basic task sequence that will be used by both operators. Because of the way the general properties were defined on the main process flow, each operator that runs the task sequence in the sub flow will be considered a separate instance of that process flow. During a simulation run, each token in the main process flow represents one of the operators, as shown in the following image:
The following image shows what it would look like if you were viewing the main process flow and each individual instance at the same time:
If you were to make a change to the task sequence in the main process flow, it would immediately update all the instances of that process flow as well.
There are a two advantages in using process flow instances:
Each of these concepts will be explained in more detail in this section.
The most important reason for understanding and using process flow instances has to do with managing shared assets across instances. As a reminder, a shared asset is a special type of process flow object that functions differently from other activities in a process flow. There are three types of shared assets:
|Resource||Represents a limited supply of some resource that can be acquired and released. It can be used to simulate a supply of goods, services, time, materials, employees, etc.|
|List||Allows you to push or pull tokens, flow items, task executers, numbers, strings, etc. to a list. This is a useful asset for syncing multiple tokens within a process flow or as a more dynamic resource. Process flows can use a list that is local to the process flow itself or could be tied to a Global List in the simulation model.|
|Zone||Can collect statistical information not available for standard activities. It can also restrict access to a section of the process flow based on certain statistics or other criteria.|
Whenever a process flow can have multiple instances, you can determine how any shared assets are distributed among the instances of that process flow. For example, imagine you build a sub flow that uses a Resource with a count of 3. The Resource can be managed one of two ways:
You can change these settings on each shared asset you add to your process flow. Each shared asset has a Type menu in its Quick Properties. You can use this menu to control whether shared assets are global or local to instances. Note that this setting is only available if the process flow type is not general. For general process flows, there is always just one instance, so shared asset access is always global.
Another advantage of using process flow instances is that you can easily reference the
object associated with the instance. When using Process Flow instances, the
current keyword gives a reference to the token's instance object. Technically,
this is not a critical feature because you can always store labels on the token that point
to the object that you would otherwise use as the instance object. Nevertheless, using
current can be more intuitive.
When referencing the
current in picklists and code editors, an instanced
process flow defaults to the Object class type. This allows you easy access
to the methods and properties of the Object class. You can change the object class of the
instanced process flow in the quick properties. Changing the object class to a different
class type, for example a Dispatcher or TaskExecuter
will update all of the code headers through the process flow and give you access to the
new object class methods and properties. For a complete list of available classes see the
FlexScript Class Reference.
The properties that affect instances depend on what type of process flow it is:
See Process Flow Types for more information.
Additionally, you can use the Type menu on Shared Assets objects (Resource, List, and Zone) to determine whether these assets are global or local to an instance.
To view an instance of a process flow: