Understanding execution modes

The Process Mode setting determines how a process will execute regarding performance and logging. It is particularly important for listener processes that are used for APIs and event-based integrations.

Process Modes

Process Mode	Description
General	Default mode for all processes. Produces a complete execution history on the Process Reporting page, including process- and document-level logs and document payloads. Used for scheduled batch processes which are longer running and do not require minimal response time.
Bridge	Provides increased performance over General mode for short-lived (less than 30 seconds) listener processes by reducing the logging level. Provides execution history on the Process Reporting page, including process- and document-level logs but does not capture document payloads. Used for high-volume, API or event-based processes that require high performance but also require individual execution history and logging, such as receiving orders or synchronizing transaction records.
Low Latency	Provides maximum performance for short-lived (less than 30 seconds) listener processes by eliminating virtually all logging. Does not provide any execution history or logging on the Process Reporting page and does not capture document payloads. Provides summarized execution activity on the Real-time Dashboard. Used for high-volume, API or event-based processes where the absolute minimum response time is required and individual execution history details are not critical, such as handling API query requests.For more information, see Low Latency processes Note: You can choose to log execution failures in Low Latency mode on the Process Options panel. .

General usage considerations

The Process Mode and the process' Start step configuration are interdependent. General mode can be used with any connector or Start step type, including listeners, however Low Latency and Bridge mode are applicable only for connector listen actions. Not all connectors with a listen action support Low Latency or Bridge mode. See the documentation for each connector for supportability.
When a process calls another process using the Process Call or Process Route step, only the Process Mode of the parent process is used. The child process’s Process Mode is ignored. For example, if a parent process set to Low Latency mode calls a child process that is set to General mode, the entire execution will run in Low Latency mode, including the steps in the child process.
When deploying a process configured as Bridge or Low Latency mode to a Runtime cloud (either Boomi's public hosted clouds or a locally hosted cloud), executions will run in an Execution worker if the given cloud attachment has been provisioned with an Execution worker. The number of concurrent executions and maximum execution duration is determined by how the Execution worker is configured.
When deploying a listener to a Runtime cloud runtime, configuring as Low Latency or Bridge mode provides the most immediate response to clients.
To assist with troubleshooting and debugging Web Services Server (WSS) and Flow Services Server (FSS) listener processes configured as Bridge or Low Latency mode, a specific parameter can be included in the request to temporarily execute the process in "Low Latency Debug" mode. This causes that single execution to run in General mode with a complete execution history, including logs and document payloads. For more information, see the "Disabling Low Latency process mode for single executions" section in Low Latency processes.

Detailed comparison

	General	Bridge	Low Latency	Low Latency Debug
Execution history available in Process Reporting	Yes	Yes	No (only for errored executions, optionally)	Yes
Executions can be retried	Yes	No	No	Yes
Generates Document Log	Yes	Yes	No (only for errored executions, optionally)	Yes
Captures document tracked fields	Yes	Yes	No (only for errored executions, optionally)	Yes
Generates Process Log	Yes	Yes	No (only for errored executions, optionally)	Yes
Generates Process State	Yes	No	No	Yes
Runs in Execution workers (Applicable only when deployed to a Runtime cloud and an Execution worker is enabled for the attachment)	No Note: There is an advanced property for Runtime cloud to force HTTP and AS2 listeners to run in an Execution worker even when set to General mode.	Yes	Yes	Yes
Supported connector actions	Any	Listen only	Listen only	Listen only
Typical use cases	Default mode for new processes. Provides full visibility of execution logging and document data capture.For example, scheduled or batch integrations such as application, data, and file data synchronizations.	High-volume, API or event-based integrations. Details of individual executions are needed, but some throughput is sacrificed.For example, receiving inbound orders or other important business transactions.	Very high volume, API event-based integrations. Details of individual executions are not needed. Maximum throughput is priority.For example, extremely high volume web requests or API lookups.	Temporary troubleshooting of Low Latency or Bridge mode processes. Runs the single execution in General mode with full execution logging and document data capture. Note: Applicable only to WSS and FSS connectors.
View Document Data	Yes	No	No	Yes
Generates Events and Alerts	Yes	No	No	Yes
Dashboard visibility	Account	Account	Real-Time	Account
Platform API object for execution history	ExecutionRecord	ExecutionRecord	ExecutionRecordSummary	ExecutionRecord

Setting the Process Mode

You can set the Process Mode in the process component. After modifying the value, you must repackage and redeploy the process for changes to take effect.

Open the process, select Process Options, and choose a different mode.
Save the process.
Create a new packaged component and deploy it to the desired environment(s).

For more information, see Setting process options.

Default Process Options per Process Mode

Several Process Options values are defaulted in the process' Start step based on the selected Process Mode.

	General	Bridge	Low Latency
Allow Simultaneous Executions	FALSE	TRUE	TRUE
Capture Run Dates	TRUE	FALSE	FALSE
Only Generate Process Log on Error	N/A	N/A	TRUE

There are some scenarios in which you might want to modify the default Process Options:

If you have a listener process but still want complete execution details, set the Process Mode to General, but set Allow Simultaneous Executions to TRUE to receive multiple concurrent requests (typical use case) and Capture Run Dates to FALSE (not applicable).

Low latency processes

The Low Latency option for processes greatly increases the speed at which a process executes by not logging every state of the process. Reduced logging allows the process to execute mainly in memory where transformations and other steps can execute quickly. The Low Latency option is recommended if you need to execute a high volume of process calls within a short period of time.

To achieve faster performance, a low latency process does not track as much information as a traditional process does:

Request or response data is not recorded. Therefore, you cannot view request or response data, and you cannot retry a low latency process.
Process metrics are not recorded in the View Process State dialog, but the process log is available.
The inbound data’s document logs are disabled.

You can set a process to use Low Latency mode in the Process Options dialog. If you use Services Enablement with a locally installed Runtime or Runtime cluster, there are no further requirements. If you use Services Enablement in Boomi’s Runtime cloud, you should contact your representative about having an Execution worker enabled in your account.

Limitations and differences in low latency processes

The following limitations apply to low latency requests:

If you are using an Execution worker in a Runtime cloud, the maximum Execution worker process execution time is 30 seconds. If you are using a local Runtime cloud, the default is 30 seconds but you can change the Execution worker Maximum Execution Time on the Attachment Quotas tab.

note
If you change the Execution worker Maximum Execution Time, you must restart before the setting change takes effect.
For Web Services Server listener processes, if you are using a Runtime cloud, the maximum input document size is 1 MB. If you are using a local Runtime, Runtime cluster, or local Runtime cloud there is no restriction, but you can use the Web Service Request Input Size property on the Attachment Quotas tab to set a limit.

You will notice some minor differences in low latency process executions:

Processes that use the Flow Control step’s multi-thread parallel processing run as usual. However, if a process uses the Flow Control step’s multi-process parallel processing, it is downgraded to multi-thread parallel processing.
Subprocesses use the same process options as the low latency process that calls them. Therefore, a subprocess that is called by a low latency process also uses Low Latency mode.
All low latency process execution results are summarized and displayed on the Real-time Dashboard. When a low latency process generates a warning or error, more detailed information about the problem is available on the Process Reporting page.
Low latency processes do not generate email alerts.

Building efficient low latency processes

It is possible to unintentionally build a low latency process that runs slowly. Avoid the following steps or behaviors within your process to make sure the low latency process executes quickly:

Too many connector calls — the most common cause for a long-running, low latency process is the number of connector calls that the process makes. When you call connectors that in turn call other web services, the timing of the process can be only as fast as the response time of the web service, including any Internet latency. Connector calls in a Map step or Decision step are not immediately visible within the Process canvas.
Too many steps — each step incurs a minimal amount of overhead. A process with hundreds of steps can be slow due to the general complexity of the process. Review the number of process calls when determining the overall size of your process.
Flow Control step — the Run Each Document Individually option within the Flow Control step slows down any process regardless of whether the process mode is set to General or Low Latency. Use this option sparingly.
Persisted process properties — persisted process properties are saved to disk each time they are stored. Saving to disk can cause file contention when iterations of the same process are trying to store the persisted process property.
Steps that write to disk — any step that writes data to disk increases processing time regardless of whether the process mode is set to General or Low Latency.
Tracking process run dates — tracking run dates slows down process executions. Do not track process run dates on any web service processes or subprocesses.

Disabling low latency Process Mode for single executions

For a process executed with its Process Mode option set to Low Latency, the presence in a web server request of the query parameter _boomi_debug=true or the HTTP header X-Boomi-Debug with a value of true has the effect of changing the Process Mode to General for the current process execution. This parameter can be useful for debugging purposes.