Workflows in iPlus have a slightly different meaning than workflows described in general literature (https://en.wikipedia.org/wiki/Workflow). A workflow in iPlus is actually a program (in the developer language: "Method") that is programmed graphically, rather than textual, and quasi represents an alternative programming language in the iPlus runtime.

Just as programs can call other programs (subroutines) again, workflows can call other workflows (subworkflows). In fact, workflows are asynchronous programs because they do not end immediately after they have been started, as so-called "synchronous" programs do. This is because workflows consist of a network of workflow nodes* that have a state and remain in those states for a while.

The state machine of the workflow node is implemented according to the https://en.wikipedia.org/wiki/ISA-88 standard (idle, running, complete...). Unlike the ISA-88 standard, workflows do not necessarily require a physical model, which allows for a much more universal usability of the workflows.

Thus, physically independant workflow nodes or workflow classes can be programmed / used (e.g. waiting for e-mail input, sending data to an Internet service, waiting for delivery note confirmation...). Other .NET methods/scripts, that a developer has programmed and registered in the iPlus runtime, can be invoked as well.

* Synonyms: Operation, step, phase, actions.. 

Workflows have a so-called "method name" through which they are called or started. This method name must be unique within its class to which it belongs. For non-programmers, a class is similar to a file folder (within a just browsing) in which the file names must be unique.

Typically, workflows are created in "File Folders" at the top level of the hierarchy, called "Applicationdefinition-Projects".

The application definition project is selected using the ComboBox in the Explorer. The list then lists the existing workflows with their method names. (Developers who have access to the iPlus development environment can also add workflows to classes that are located at lower levels of the hierarchy)

A workflow always consists of
-A root-node (outermost frame A) and
-A start and end-node (short horizontal bar B, C).

Workflow nodes are connected by workflow edges, which are represented as lines with arrows (D). The arrow indicates the program flow direction.

A workflow must always be programmed in such a way that it can terminate itself. This means that the workflow nodes must be connected in such a way that the program flow ends at the last end node of the root node (F).

All workflow nodes must be placed within a root node.

Workflows are hierarchical. The hierarchy is created by the use of special workflow nodes, the group node (G). A group node consists of a start- and end node like a root node (H).
The subnodes within the group node must be connected by edges in such a way that the program flow ends at the endnode of the group node.

Workflow nodes have at least one entry- and one exit-point at which the nodes can be connected (except start and end nodes). The edges can only be connected from a entry-point to the other exit-point.

Decision nodes can also have multiple exit-points (e.g. yes or no output). If you are building loops, please make sure that no infinite loop is created!

The program flow of an active workflow is event-driven.  This means that once a workflow node is processed, a signal is sent to the entry-point of the next node (terminology: "An exit event is triggered"). You can read more about this in the chapter "Workflow processing and events".

The follow-up node only starts when all the edges on its entry-point have sent a signal - a so-called AND-operation.

The opposite of an AND-operation is an OR-Operation (I). This operation must be preceded as a separate workflow node if you want a to start a workflow node when at least one inbound event has occurred.

Entry-nodes "forgets" their signal states after they have started the workflow node. This means that when you insert loops, you must remember that all input signals must be retriggered again.
Therefore, loops are usually programmed so that the target of the edge is an OR-Node (J).

 

Workflows can be started automatically or through user interaction. This depends on the implementation of the application programmer. When using iPlus.MES, the workflow-start is automatically triggered in many application programs (e.g. in the production order, picking order, warehouse management,...).

Workflows are usually started several times when parallel processes are needed (e.g. batch operation) or the plant to be automated consists of multiple lines and machines.

In other words, if workflows are used to control production plants, the active workflows compete for shared resources (lines, production units, machines..) and must be synchronized with each other by prioritization rules. A physical resource can only be controlled by a program flow at a time.
This is regulated by special workflow group nodes, which have the property to be able to occupy a machine exclusively for itself. The machine or type of machine that a workflow group node can occupy is implicitly resolved by programming workflows at the application definition (A) level.

The application definition is a kind of template from which a iPlus application (B) is generated in the second stage. A iPlus application is usually the physical image of a production plant.

The application definition defines the types of machines, parts, and functions that will later become concrete instances in the application (C). You can create as many applications as you wish from an application definition. Similarly, there can be any number of instances that come from the types in the application definition.

When editing a workflow in the workflow editor, you get only the workflow-relevant types from the application definition displayed in the toolbar (D). These are types which are based on so-called "process modules" (E) or "functions" (F). Process modules are objects that later in the application typically represent a machine or similar, and which consists of "functions" as sub-objects that are invoked/activated by workflow nodes.

When editing the workflow and the slected type is a process module, a group node is inserted as a surrogate in the workflow (G).

If a function is used on the other hand, a workflow node is inserted as a surrogate (H), which later (if the workflow is active) can call the corresponding function at the concrete instance (physical model). These are called delegating workflow nodes.

Functions that belong to a different type of process module cannot be inserted within the same group node (J).

However, you can insert all other workflow classes that are not based on types of an application definition (K) because they do not rely on a concrete physical object later. These are called stand-alone workflow nodes.

 

 

In order to create workflows, you must perform the following work:

1. Import iPlus-compatible assemblies containing workflow classes via reflection (login by left Ctrl key). This registers these workflow classes in the class library project of the development environment.
2. Define one or more application definition projects in the development environment. If workflow nodes are required that relate to a physical model, the application definition project must be populated with the appropriate process modules and function objects. The resulting application can also be created later.