Processes

A process captures an application's business logic. This business logic is represented as a process flow, consisting of any number of connected steps. It is modelled based on the Business Process Modelling Notation (BPMN) industry standard.

A process may involve subprocesses, connectors, composite APIs, and web interfaces to perform the individual activities defined by the steps. Gateways serve to split and rejoin different execution paths, which may run in parallel or be mutually exclusive.

Instances of a process, so-called process requests, are created, launched, and executed on the DigitalSuite platform in response to start events initiated by end users or systems. Technically, a process is a connector (web service) provided by the RunMyProcess Server provider. For this reason, its execution can also be triggered directly by web service calls (POST requests).

The design and configuration of a process comprises the following settings and considerations, which are described in detail in the sections below:

Process Identification

The following settings identify a process in DigitalSuite:

• Name: The name of the process, also referred to as the title.

  The name should express the purpose of the process. In process hierarchies, it is recommended that - MAIN is added as a suffix to the process that provides for the overall business logic. Subprocesses should have SUB - as their prefix. For example:

  Expense Request - MAIN
   SUB - Submit Request
   SUB - Approve Request
Get Exchange Rate

  In projects involving many processes and subprocesses, numbers could be used for ordering them instead of or in addition to prefixes and suffixes. 1 would denote the main process, subprocesses could have hierarchical numbers such as 1.1 or 2.1.1.

• ID: A generated number used to uniquely identify the process.

• Description: A short description of the process and its purpose.

• Owner: The user who is responsible for the process. By default, this is the user who created the process.

By default, process requests have the same name as their process. However, it is possible to define dynamic labels to give the process request their own specific title. Dynamic labels can be composed of static text and variables, for example, Order for ${client_name}, value USD ${amount}. The title is determined at runtime for each process request using the current values of the variables. Titles of any complexity can be generated by means of FreeMarker scripts.

Process Steps

A process is designed as a series of steps. Steps are connected by arrows to indicate the way in which work should flow through the process.

DigitalSuite distinguishes between the following step types:

• Events: Represent situations that require a response. Every process has a start event and one or more end events. The start event defines how the execution of the process is triggered. Process flow events are used to pause a process for a given time or until specific conditions are met. Intermediary events can be configured to trigger the execution of alternative process branches in response to a defined situation.

• Activities: Represent the explicit actions undertaken during the execution of a process. Different types of activity are available to support any kind of action and executor: simple, connector/composite API, email/notification, subprocess, manual, and script.

• Gateways: Represent a decision point within the process, enabling alternative execution paths to be taken depending on the situation. An Exclusive Or gateway is used to make a choice between mutually exclusive execution paths, while an And gateway is used to divide the process flow into parallel paths. Each type of gateway has a Split to create the separate paths, and a Join to bring the paths back together.

For details, refer to Process Step Types.

Accessibility

Access to a process can be set to public or private. Public processes can be called from public web pages and services without verification while users need to authenticate and have the required permissions to invoke a private process.

Pools and Lanes

In DigitalSuite, users are assigned specific roles within a project in order to give them the access rights necessary to meet their responsibilities. A user can belong to more than one role. Roles are grouped into organizations which can contain many roles. For details, refer to Roles and Access Rights.

In processes and the Business Process Modelling Notation, roles are represented as swim lanes, commonly referred to as lanes, and organizations are represented as pools.

This diagram shows the process design for a straightforward budget approval application.

Number	Description
	The pool or organization. In this example, all lanes that have responsibilities within the process belong to the same pool. Roles from different organizations can play a part in the same process, in which case the process has more than one pool.
	The lanes or roles. The process design in the diagram has three lanes, which means that users from three roles play a part in the process. Process steps that are the responsibility of a particular role are placed within the corresponding lane. This simplifies and enriches the process design by making it easier to understand the responsible person and organization for each step in the process.

In the diagram above, members of the Everybody role can trigger the process; the start event is in the Everybody lane. Users from the Team managers role can validate the initial request. Users from the Financial director role can provide further approval and notify the team member of the final decision.

Variables

A process and its steps typically require some input and produce some output. These are managed and transferred by means of input and output variables. A process can have multiple:

• Process input variables: Parameters and data that are required to launch the process.
• Step variables: Input and output variables of process activities and events.

Input variables are set and evaluated before executing the step in which they are defined. For process input variables this means before the start event. Output variables are set and evaluated after the activity or event in which they are defined has been completed. They usually store the result of the activity, and can be used as input for later steps in the process.

A parent process can pass all or some of its variables to a subprocess, and vice versa. The processes can even share the same variables, which is not recommended except for very specific situations such as using common measures.

Some variables are set automatically by DigitalSuite at runtime. The names of these variables start with P_, a prefix that is reserved for internal use.

Process Input Variables

Process input variables can be simple, fixed values or objects consisting of several values, for example, to transfer a postal address.

In addition to variables, data files can be passed to processes. The following types of file are distinguished:

• Files which are passed for use within the process without considering their contents, for example, attachments sent by email or a connector.
• Files whose content is parsed by DigitalSuite at process start according to a selected format. This is useful, for example, to pass a set of input values like a list of customers. The following formats are supported: XML, Text, JavaScript Object Notation (JSON), Comma/Semicolon/Tab Separated Values (CSV, SCSV, TSV) with or without header, Electronic Data Exchange (EDI), List of key/value pairs, URL encoding, HTML.

Step Variables

The input and output variables of process steps can have static values (e.g. john.doe@mydomain.com), dynamic values (e.g. ${P_user.login}), or values obtained by the execution of FreeMarker scripts. They can reference other variables created in any of the web interfaces associated with the process.

In specific situations, DigitalSuite creates input variables automatically. This is the case, for example, for process activities addressing connectors which require specific parameters to be passed to them. The process designer just needs to take care of the variable values.

In order to protect sensible data, any input and output variables can be explicitly excluded from reports and other representations of process requests (e.g. DigitalSuite Process Console).

Measures

Measures are variables used as columns or filters in process or web interface reports. They are based on variables or other data of a process. For example, a measure named amount_of_a_purchase_process could be based on the ${amount} variable defined in a purchase process.

Any process data items can be defined as measures. It is also possible to calculate a measure from different process data, for example, to obtain a specific key performance indicator for a report or chart.

Measures defined for a main process also need to be defined for its subprocesses. Measures that are not known to a subprocess may be deleted during its execution and thus no longer be visible in the main process. In case of parallel process branches, a measure displayed in a web interface report will use the variable values of the branch that contains the manual task associated with the web interface addressed by the report.

Measures are not versionable. When a measure is created or modified, its value is automatically calculated for every launched process request, independent of the state or version.

Like other variables, measures have a:

• Name
• Value: the value is based on process variables or data. It can be static (e.g. john.doe@mydomain.com), dynamic (e.g. ${P_user.login}), or obtained by the execution of a FreeMarker script. The maximum length of a measure's value is 4096 bytes.
• Type: Text, Date, Number, or Link. On Date and Number measures, arithmetic operations can be performed, such as sum or average.

For each process, up to 200 measures can be defined. If more are needed, collections should be used. The measures can be included in process reports and web interface reports.