A.3. Defining an EKM Process Template XML File

Engineering Knowledge Manager

User's Guide | Appendix A. Defining a Process Template Using XML |

A.2. Schema Definition for Process Templates |  | A.4. Defining Variables
Prev |  | Next

## A.3. Defining an EKM Process Template XML File

An EKM process is defined in terms of the following constructs:

Variables are used for storing the state of a process. Variables can be assigned default values in the process definition. When a task gets completed for a process that is being run in EKM, users may be prompted to enter values of output variables. Validation can be performed on variable values to ensure that only valid values are entered. The value of a variable can also be used to determine when a transition is triggered, and when an iteration gets completed.

Nodes are used to model a single step in an EKM process. The following node types are provided for modeling various conditions:

- `node`: This is the simplest node type and can be used to model a manual process. In this case, a task is assigned to a user or group and the task gets completed only when the assigned user explicitly marks it as completed. On completion, the assigned user may be prompted to enter values for some variables. These variables can then be used as inputs to other tasks for deciding the paths taken by the process.

- `auto-node`: This type of node can be used to model an automated task such as generating a report, archiving data, or performing detailed validation. When a process reaches an auto node, the node will automatically execute.

- `monitor-node`: This type of node can be used to monitor the progress of a process or an asynchronous batch task that is spawned by an auto node. When a process reaches a monitor-node, it will wait until all of the processes and tasks monitored by the node are completed before going to the next node.

- `iteration-node`: This type of node can be used to model an iterative process such as an approval or iterative simulation. This node defines an iteration condition, and iteration tasks continue while the condition holds.

- `batch-node`: This type of node can be used to model long-running automated steps such as executing external applications for preprocessing, performing simulations, and postprocessing.

  Note: Both auto nodes and batch nodes can be used to model automated steps. Auto nodes should be used for steps that can be executed quickly. Batch nodes should be used for steps that take much longer to complete.

- `workflow-reference-node`: This type of node can be used to nest another process template inside the current one by specifying the path of the process template as the value for the `wfReference` attribute. The nested process will begin automatically when a process reaches this node.

- `update-analysis-project-node`: This type of node can be used to update analysis projects (see Working With Analysis Projects) and Workbench projects (see Working With ANSYS Workbench Projects). For a Workbench Project:

  - A simulation details report will be generated for the project.

  - Metadata will be extracted from CAE files contained within the Workbench project `_files` folder and added to the Workbench project file (.wbpj) properties.

- `custom-dialog-node`: This type of node is an extension of the Node type. It can be used in scenarios when you want to have a customized single-step dialog box or a multistep wizard associated with the node. You can process variables at the start and end of each step in the dialog/wizard using the start/end macro. The task that is associated with the node can be assigned to either a user or a group and the task is completed only when the assigned user explicitly sets it to Complete.

Transitions are used to specify the path of the process. A transition is a connection between a starting node (source) and an ending node (destination). A transition can have a trigger expression associated with it. The trigger expression determines whether the transition will be triggered (or traversed) in a process. If no trigger expression is specified then the transition is always triggered.

The following rules apply to transitions:

- A process or block must have exactly one start node and exactly one end node. A start node is a node that has no incoming transitions. An end node is a node that has no outgoing transitions.

- “Orphan” node or nodes that have no incoming or outgoing transitions are not allowed.

- Apart from the start node, all other nodes can have any number of incoming transitions.

- Apart from the end node, all other nodes can have any number of outgoing transitions.

- Cycles are not allowed. For example, if you have a transition from node A to node B, then you cannot have a transition from node B to node A. Similarly, if you have defined transitions from node A to node B and from node B to node C, you cannot have a transition from node C to node A. In this way, processes are always Directed Acyclic Graphs. Because iterations are cyclical by nature, a special construct called a block is used for modeling them.

If a node has more than one outgoing transition, then depending on the trigger expression, any number of the transitions may be triggered. If more than one transition is triggered, then the tasks will be processed concurrently. If a node has more than one incoming transition, then the task corresponding to that node will wait until all of the incoming transitions have been traversed. For example, suppose a process has nodes A, B, C and D with transitions from A to B, A to C, B to D and C to D. The start node is A with two outgoing transitions, and D is the end node with two incoming transitions. In this case, the task corresponding to node D will be activated only once the tasks corresponding to both nodes B and D have been completed.

Blocks are used primarily to model iterations and can be used to avoid cycles in the process. Conceptually, a block represents the sequence of steps that are executed as part of an iteration. A block can have nodes and transitions. Variables are not defined at the block level. Variables that are defined at the process level can be accessed by any node or transition in any block.

The following rules apply to blocks:

- Blocks must contain one, and only one, start node and end node.

- A transition within a block can only use a node within the block as its source or destination. This means that you cannot define a transition from a node outside a block, to a node inside a block, or vice-versa.

- The names of all nodes and transitions specified in a process must be unique. Blocks do not act as namespaces. This means that if you have a node or transition defined elsewhere in the process, you cannot define another node or transition of the same name within a block.

Expressions are used to evaluate conditions such as whether a variable supplied in a task is valid, whether an iteration should continue, or whether a transition should be traversed. Like macros, expressions are defined in a supported scripting language in the `script` element.

Macros are used in process definitions to automate certain tasks. For example, macros can be used to define complex logic in expressions, tasks that will be executed in an auto node, and custom dialog boxes for a task. Macros are defined using a supported scripting language in the `script` element, and can be referenced in any expression in a process definition.

Now, let's look at the each of these constructs in more detail in the following sections.

Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates.

Prev | Up / Contents | Next

Release 18.2 - © ANSYS, Inc. All rights reserved.