# Flows

A ProcessMIX **flow** is a graphical diagram (flowchart) made up of interconnected nodes (steps) that contain computer instructions. The nodes are executed in an orderly fashion to run an algorithm, a decision strategy, or a sequence of tasks that achieve a specific goal. It represents a systematic, automated  and repeatable process that programmatically performs a well-defined unit of work, typically manipulating data and coordinating people, resources, and information.

A flow definition consists of two parts:

* [Settings](#flow-settings) - configuration parameters that are defined for the entire flow;
* [Flow diagram](#flow-diagram) - the actual implementation, i.e. a visual graph with various types of nodes connected by arrows. Each node will have its own settings and number of incoming/outgoing arrows, in accordance with its nature.

Here are just few examples of business logic that can be implemented with flows:

* A record creation service that validates input received from a user, formats and inserts it into a database.
* A set of business rules with various checks to automate decision-making strategy.
* A state machine implementing a business process that consists of some automated actions, as well as human tasks.
* A systems integration  process that connects to several external data sources and iterates over the results to produce an aggregated summary.

***

## Flow Settings

The flow's top-level settings define how it will be used, what data it will take as inputs, what kind of result it will produce, temporary local variables that it can utilize during the execution, and so on.

<figure><img src="https://3477030876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYK40zKr4ZyVfqCRAUI9t%2Fuploads%2FMcSYK6ElRjibqspPgeDW%2FScreenshot%202024-03-01%20at%2009.10.07.png?alt=media&#x26;token=763a9b0b-4357-4b06-b81e-90074dc6ae4e" alt="" width="375"><figcaption><p>Subflow settings</p></figcaption></figure>

### Name

Name is an identifier or label assigned to a flow. It has to be unique within a project and must adhere to restrictions listed below.

<table><thead><tr><th width="139">Type</th><th>Restrictions</th></tr></thead><tbody><tr><td>Input Text</td><td><ul><li>must consist of letters (A-Z or a-z), digits (0-9), underscores (_), or dollar signs ($). However, a name cannot start with a digit or dollar sign ($).</li><li>Unique per folder</li><li>Mandatory</li><li>Min length: 1</li><li>Max length: 255</li><li>Must not be one of the <a href="appendix/reserved-words">Reserved words</a></li></ul></td></tr></tbody></table>

***

### Initialize Variables

This parameter controls the way how the output and local variables will be initialized.&#x20;

Possible values:

<mark style="color:purple;">**True**</mark> value means that output and local variables are initialized with [default values](structures/default-structures-values).

<mark style="color:purple;">**False**</mark> value indicates that output and local variables are null. Use the [initialize](functions/node-functions/pdk.flow.any#initialize) or [initializeDeep](functions/node-functions/pdk.flow.any#initializedeep) functions to manually initialize variables.

### Local Variables

The Local Variables section can contain one or more definitions of flow's [local variables](flows/variables/local-flow-variables) - i.e. transient internal values that are written and read by the flow itself when it is executed.&#x20;

***

### Channel

This setting determines where and how the flow execution will be triggered. Some flows will be published on a network to become available externally as remote service endpoints. Others will be triggered automatically on a periodic basis. Most flows, however, will serve as internal units of work, invoked from other flows as needed. This allows splitting complex logic into smaller modules that can be easier to understand and reuse.

Possible flow channel choices are described below.

<mark style="color:purple;">**Subflow**</mark> is a type of internal flow that encapsulates a sequence of activities or tasks called from within another flow. It represents a modular and reusable unit of work that can be invoked and integrated into other flows. Subflows are commonly used to modularize complex logic, promote reusability, and simplify flow design and maintenance.

<mark style="color:purple;">**REST**</mark> is a type of flow that implements a Representational State Transfer (RESTful) web service endpoint. It defines a set of HTTP methods (GET, POST, PUT, DELETE, etc.) and corresponding request and response mappings to enable communication between client applications and the system. REST flows adhere to REST principles, such as statelessness, uniform interface, and resource-based interactions, and are commonly used for building web APIs and integrating with external systems.

<mark style="color:purple;">**SOAP**</mark> is a type of flow that implements a Simple Object Access Protocol (SOAP) web service endpoint. It defines a standardized XML-based messaging protocol for exchanging structured information between client applications and the system over the Internet. SOAP flows involve the definition of a WSDL (Web Services Description Language) contract specifying the service interface, operations, message formats, and communication protocols. SOAP flows are widely used for building interoperable and platform-independent web services.

<mark style="color:purple;">**Scheduled**</mark> is a type of flow that is triggered and executed at predefined intervals or time-based schedules. It allows for the automation of recurring tasks, periodic data processing, and scheduled maintenance activities within the system. Scheduled flows are configured to run at specific times or intervals, such as hourly, daily, weekly, or monthly, and can perform a variety of operations, such as data synchronization, report generation, or system backups, according to the defined schedule.

***

### Description

This attribute provides a textual description or additional information about a flow. Unlike the name property, which serves as a unique identifier or label for the flow, the description property offers supplementary details that help to document the purpose, functionality, or behavior of the flow.

<table><thead><tr><th width="144">Type</th><th>Restrictions</th></tr></thead><tbody><tr><td>Input Text</td><td><ul><li>Max length: 5000</li></ul></td></tr></tbody></table>

***

## Channel Settings

### Subflow Channel

<figure><img src="https://3477030876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYK40zKr4ZyVfqCRAUI9t%2Fuploads%2FMcSYK6ElRjibqspPgeDW%2FScreenshot%202024-03-01%20at%2009.10.07.png?alt=media&#x26;token=763a9b0b-4357-4b06-b81e-90074dc6ae4e" alt="" width="375"><figcaption><p>Subflow settings</p></figcaption></figure>

<mark style="color:purple;">**Inputs**</mark> - define the data that are provided to the subflow when it is invoked or executed. These properties represent the input values required by the subflow to perform its tasks. Inputs properties may include various data types such as strings, numbers, booleans, objects, arrays, etc.

<mark style="color:purple;">**Output**</mark> - specify the result generated by the subflow upon completion of its execution. These property represents the output value produced by the subflow, which may be used by other components or nodes within the larger workflow.&#x20;

***

### REST Channel

<figure><img src="https://3477030876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYK40zKr4ZyVfqCRAUI9t%2Fuploads%2FTsIAlC4OfKOAABkstB0S%2FScreenshot%202024-03-01%20at%2009.14.26.png?alt=media&#x26;token=b14db55c-53ad-4f85-9bec-92283e96b475" alt="" width="375"><figcaption><p>REST settings</p></figcaption></figure>

<mark style="color:purple;">**HTTP Method**</mark> - specifies the HTTP method used by the REST flow to handle incoming requests. Common methods include GET, POST, PUT, DELETE, etc.

<mark style="color:purple;">**Binding URL**</mark> - defines the URL endpoint at which the REST flow is exposed and can be accessed by client applications. It typically consists of the base URL followed by a path that identifies the resource or operation.

<table><thead><tr><th width="139">Type</th><th>Restrictions</th></tr></thead><tbody><tr><td>input Text</td><td><ul><li>Unique per project in combination with the method property</li><li>Mandatory</li><li>Min length: 1</li><li>Max length: 256</li><li>Valid URL</li></ul></td></tr></tbody></table>

<mark style="color:purple;">**Query parameters**</mark> - represents data parameters included in the request URL's query string sent to the REST flow. These parameters provide additional information to the flow for processing the request, such as filtering criteria or pagination settings.

<mark style="color:purple;">**Path parameters**</mark> - refers to dynamic segments of the URL path that are extracted and processed by the REST flow. Path parameters allow for parameterization of the URL and enable routing to different resources or operations based on the provided values.

Parameters types and restrictions:

<table><thead><tr><th width="241">Type</th><th>Restrictions</th></tr></thead><tbody><tr><td><ul><li><a href="../structures/pdk.core#integer">pdk.core.Integer</a></li><li><a href="../structures/pdk.core#string">pdk.core.String</a></li><li><a href="../structures/pdk.core#float">pdk.core.Float</a></li><li><a href="../structures/pdk.core#boolean">pdk.core.Boolean</a></li></ul></td><td><ul><li>Unique per flow</li><li>must consist of letters (A-Z or a-z), digits (0-9), underscores (_), or dollar signs ($). However, a class name cannot start with a digit and dollar sign ($)</li><li><a href="appendix/reserved-words">Reserved words</a></li><li>Mandatory</li><li>Min length: 1</li><li>Max length: 256</li></ul></td></tr></tbody></table>

<mark style="color:purple;">**HTTP Request**</mark>**&#x20;-** describes the structure and content of the request sent to the REST flow.&#x20;

<mark style="color:purple;">**HTTP Response**</mark> - specifies the structure and content of the response generated by the REST flow in response to client requests.

***

### SOAP Channel

<figure><img src="https://3477030876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYK40zKr4ZyVfqCRAUI9t%2Fuploads%2FNQAqimdpCJeFdiTbWZjN%2FScreenshot%202024-03-01%20at%2009.15.40.png?alt=media&#x26;token=b3a8238a-0cba-4da4-b94b-8cce0b411a70" alt="" width="375"><figcaption><p>SOAP settings</p></figcaption></figure>

<mark style="color:purple;">**SOAP Request**</mark>**&#x20;-** describes the structure and content of the request sent to the SOAP flow.&#x20;

<mark style="color:purple;">**SOAP Response**</mark> - specifies the structure and content of the response generated by the SOAP flow in response to client requests.

***

### Scheduled Channel

<figure><img src="https://3477030876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYK40zKr4ZyVfqCRAUI9t%2Fuploads%2FlQWNU9lL9Lm2U3VUO3Sg%2FScreenshot%202024-03-01%20at%2009.16.43.png?alt=media&#x26;token=a083af71-e3e0-405e-b2d0-b564d8212af8" alt="" width="375"><figcaption><p>Scheduled flow settings</p></figcaption></figure>

<mark style="color:purple;">**Schedule**</mark> - a cron expression is a string of five to six fields separated by whitespace, which represents a set of times or dates when a job or task should be executed. Each field represents a specific unit of time, such as minutes, hours, days, and so on.&#x20;

The general format of a cron expression is: \* \* \* \* \* \*

The fields, in order from left to right, represent:

1. Seconds (0-59)
2. Minutes (0-59)
3. Hours (0-23)
4. Day of the month (1-31)
5. Month (1-12 or Jan-Dec)
6. Day of the week (0-6 or Sun-Sat)

Asterisks (\`\*\`) can be used to represent all values within a field, and commas (\`,\`) can be used to separate multiple values. Hyphens (\`-\`) can be used to specify a range of values within a field, and forward slashes (\`/\`) can be used to specify step values.

For example, the following cron expression will execute a task at 12:30 PM every day: 0 30 12 \* \* ?

And this cron expression will execute a task every 15 minutes: 0 0/15 \* \* \* ?

<figure><img src="https://3477030876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYK40zKr4ZyVfqCRAUI9t%2Fuploads%2Fe20JYEMsVkOZxzyQRhyL%2FScreenshot%202024-03-01%20at%2009.17.59.png?alt=media&#x26;token=a8d095e5-e109-4e3b-88b3-d8f9e02c3883" alt=""><figcaption><p>Cron editor</p></figcaption></figure>

***

## Flow Diagram

The flow diagram (graph) is where the implementation of the flow's business logic is done.

Here is an example of such diagram:

<figure><img src="https://3477030876-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYK40zKr4ZyVfqCRAUI9t%2Fuploads%2FGGerKBvjItmUyDrhc6XS%2Fimage.png?alt=media&#x26;token=1d641768-586b-49f8-83dd-dfd78160d330" alt=""><figcaption></figcaption></figure>

There is always one starting point (the "IN" node), but there can be multiple terminating points ("OUT" nodes), with different execution paths in between with action-performing steps, as well as logical condition checks that determine which paths will be taken in a given execution.

Internal flow [nodes](flows/nodes) can be of different types, such as value assignments, condition checks, iterators (loops), integration [connectors](connectors), decision [assets](assets) (e.g. decision tables), and so on - everything that a standard business application needs. Condition checks and assignments are described using [expressions](flows/expressions), which can call [functions](flows/functions). In case of some extraordinary situation, a flow can break out of the normal processing sequence by generating an [exception](flows/exceptions).
