Using the Simple Process Definition Canvas

A process definition canvas contains steps palette and series of rows that contains process building objects.

Process Definition Steps that is Process Topology are built by dragging steps from the palette on the left and dropping them into a series of rows in the canvas. The stacking of the rows and the makeup of each row (single cell vs. multiple) define the topology of the Process Definition, whereby the process executes in the defined sequence from top to bottom.


Figure: Process Definition Canvas

Using the Simple Process Definition Canvas

The process definition canvas consists of steps palette, steps rows and delete drop area. To use the canvas, you can perform following operations:

Dragging and Dropping Steps

You can drag the step from steps palette and drop it on the process definition canvas.


Figure: Drag and Drop

New steps may be dropped before, after, left of, or right of existing steps. Steps may be re-positioned via drag and drop.


Figure: Drag and Drop Step on the highlighted Edge


Figure: Drag and Drop Step on the highlighted Edge - Parallel Task

Expanding and Collapsing Steps

Each step contains an expand arrow. Clicking the expand arrow expands the step to display its details.


Figure: Click Expand Arrow

When collapsed, an icon is displayed to identify the step type.

Deleting Steps

To delete the step, drag the step from the process diagram canvas and drop it in the Delete Drop Area. The step gets deleted.


Figure: Click Expand Arrow

Using the Steps Palette

The Step palette consist of the following elements:

User Task

User Tasks are atomic steps to be performed by users in IPP. Each user task added to the process definition becomes an activity in the model. Depending upon the implementation chosen, it could be:

Viewing and Editing User Tasks Properties

Click the expand arrow icon to view and edit the properties of user task.


Figure: User Task - Properties

  1. Name - Specify name for user task
  2. Description - Optionally add description for the user task
  3. Implementation - Contains the following:


    Figure: User Task - Implementation

  4. Conditions - For each activity, you can set preconditions. For more information, please refer to the section Setting Conditions. Note that conditions cannot be set for Start and End events.
  5. Performer - You can select the role or organization authorized to perform the user task. The drop-down list contains participants from models defined in the Modeling perspective and the Administrator role.
  6. Checker - You can select the role or organization authorized to perform quality assurance check on the user task. The drop-down list contains participants from models defined in the Modeling perspective and the Administrator role. For more information, please refer the section Viewing Implementation of Quality Assurance Activities in the Checklist Panel of the chapter Starting a Process.

Setting Conditions

To set a step condition, select the condition type from the Condition drop-down list and set the parameters as required.

Using Conditions and Repeats

By default, the Perform Always option is selected. Following options are available:

Condition Type Condition Expression Supported Description
Perform always No Task is always performed. Note that the task conditions are set to Perform always, by default.
Perform if Yes Task is performed only if the condition expression is met
Perform otherwise No Task is performed when none of its peer parallel Tasks are executed. Only one Task per horizontal block (parallel Activities) should be set to Perform otherwise. When Perform otherwise is selected for a second Task, the original Task's Condition Type is reset to the default that is Perform always.
Repeat while Yes Task is repeated while the condition expression is met. Note that this option is not available on Activity Groups when a Spawning option is selected.
Repeat until Yes Task is repeated until the condition expression is met. Note that this option is not available on Activity Groups when a Spawning option is selected.

Left side Condition

The left side condition lists the Primitive Process Data from the Process Model including:

Based on the selected condition or repeat, the options are displayed in the right side.

The right side condition can be set to evaluate against a Fixed Value or to a Primitive process data from the process model. Following options are available:

Condition Operators

The operators are consistent with the data type selected for the left side condition.

Data Type Operators
string
  • Equal
  • Not Equal
int, long
  • Less than
  • Greater than
  • Less than or equal
  • Greater than or equal
  • Equal
  • Not Equal
calendar
  • Earlier than
  • Later than
  • Earlier than or at the same time as
  • Later than or at the same time as
  • Same time as
  • Different time as
boolean Equal To

Service Task

The pre-requisite to work with service task is that the business object should be associated with non-interactive applications and process interfaces. Then, each application added to the process definition becomes an Application activity in the model. Similarly, each process interface added to the process definition becomes a sub-process activity in the model.

Implementation

The Implementation drop-down lists the following:


Figure: Service Task

Note that applications and process interfaces get displayed in the Model & Go! perspective if only they meet the following data mapping heuristics conditions.

Input and Output Data Mapping Heuristics

The external calls allowed for Application or Process Interfaces with Input Access Points:

and with Output Access Points

Implementation - Process Interface

A process interface is created only if a matching Business Object is associated with the Model & Go! Process.


Figure: Matching Business Object in simple processes

The Implementation drop-down list of a Service Task lists these Model & Go! processes as the process interface. For example, if a business object named Vendor is specified for the Model & Go! Process then its service task would display a list of Model & Go! processes that are associated with Vendor business object only. Hence, the selected process works as a sub-process at runtime.


Figure: Implementation - Available Process Interface Model & Go! Process Options

The Non-interactive Application Types Non-interactive Application Types and Process Interfaces (Sub-processes) defined in the model repository are displayed if they are compatible with the Business Object selected for the process definition.


Figure: Implementation - Non-interactive Application and Process

Service Task Implementation - Email

The Email service task enables you to send automated simple outbound emails as part of a process. You need to specify following properties to set up an email application.


Figure: Email Service Task

Viewing and Adding Email Application Properties

Click the expand arrow icon to view and edit the properties of Email service task.

Once the properties are set, the configuration variables are created automatically. These configuration variables can be modified. To edit these variables, you need to open the same model from the Modeling perspective. Then, open the properties of the same model and modify configuration variables for the following fields in the Configuration tab:

Configuration Variable Default Value
emailServer localhost
emailUser testUser
emailPassword testPassword


Figure: Configuration Variable

Service Task Implementation - Decorator Application

To view the Decorator application in the Implementation drop-down list, the following settings are needed in the Modeling perspective:

For more information on how to create the models with above settings, please refer the section Examples Examples of the chapter Decorator Application Decorator Application of the Business Process Modeling handbook.

In the Simple Modeler, you need to select the Decorator Application from the Implementation drop-down list.


Figure: Service Task - Decorator Application

In the subsequent user task, you can define the condition based on the output of the service task.


Figure: User Task - Condition

Error Task

Error Tasks support defining exception handling in simple models including the exception trigger and the exception flow.

Error tasks support error handling for service tasks only.

Note that error task can be placed only on the line immediately under a single service task. You cannot drop it under a set of parallel task. The error tasks are implicitly linked to the service task above it.

By default, a review task is associated with an error task. So when you drag and drop the error task, you can see the review task inside it.

If you associate an error task with the service task, the following data are created automatically for each service task.


Figure: Service Task - Data

Adding Exception Flows

You can drag and drop other tasks on the error tasks drop area to build exception flow.


Figure: Exception Flow

Following are the supported use cases for error tasks:

Following validations are applied when creating a new error task:

Following validations are applied when moving a created error task:

Viewing and Editing Error Task Properties

Click the expand arrow icon to view and edit the properties of user task.


Figure: Error Task - Properties

If you select an Error Flow template (process interface) from the implementation drop-down list, the drop area used for building a custom exception flow is hidden.


Figure: Error Flow Template - Process Interface

Viewing and Editing Review Task

A User Task with Implementation as Checklist is added by default as the first step in each exception flow. This is intended as a step for a user to review the service call error that triggered the exception and decide what further action is required. By default, the User Task name is "Review Task."

Click the expand arrow icon to view and edit the properties of review task.


Figure: Review Task - Properties

When the Review task is rendered in the Infinity Process Platform Portal, following fields are displayed:


Figure: Review Task - Review Task tab

General Workflow

Events

You can add an event to add a wait step to the model. In some scenarios, at one point while processing, multiple processes wait for an event to happen. For example, incoming document arrival, notification email, or a user indicating the event.

Click the expand arrow icon to view and edit the properties of event


Figure: Event

Note that auxiliary processes and activities are not displayed in the Process and Activity drop-down list of an event.

Activity Groups

Activity Groups are optional containers for nesting User Tasks, Service Tasks, Events, and other Activity Groups. Each activity group added to the process definition becomes a sub-process activity in the model.

Viewing and Editing Activity Groups Properties

Click the expand arrow icon to view and edit the properties of activity group.


Figure: Activity Group

Activity Nesting

You can drag and drop User Tasks, Service Tasks, Events, and other Activity Groups to an Activity Group itself. Gestures for building the Activity Group topology are the same as for building the top level process topology. Multiple levels of nesting is supported.


Figure: Drag n Drop to Activity Group

Tasks added to an activity group cannot be moved outside of that activity group. They can only be moved within the same activity group or deleted.

Multi-instance Processing

Activity groups should be configured to spawn a sub-process instance for each unique instance of the primary business object's referenced business object. For more information, please refer to the section Multiple Instance Model & Go! Example Multiple Instance Model & Go! Example of the Using Multiple Instance Activities Using Multiple Instance Activities chapter of the Concepts Concepts handbook.

For multi-instance processing, create a relationship between two business objects. Then, add activity group in the process and use the relationship to spawn a process. In the activity group, you need to select the same relationship in the Spawn Processing option. For more information, please refer to the example Working with Activity Groups and Spawning a Process.

Starting a Process

Supports starting process instances for selected business object instances and applying their data. It displays the processes that are configured to use the selected Business Object are listed in the Startable Processes table.

To start process for business object instances, perform the following steps:

  1. In the My Processes panel, click the Start Process option


    Figure: Start Process

  2. Select Business Object from the drop-down list


    Figure: Select Business Object

  3. Select the business object instance for which you want to start the process. The startable processes for the selected business object instance gets displayed.


    Figure: Startable Processes - ACME Instance

  4. Click Start Process to start Process Instances in that Process. The confirmation message gets displayed.


    Figure: Confirmation Message - Process Start

Note that you can start a process without a benchmark, if no benchmark is configured.