Execution Limits

This document outlines limitations that have been set for applications running on RunMyProcess DigitalSuite.

The DigitalSuite platform is a multitenant environment therefore several applications share computation resources during execution.

To ensure that all applications are executed in a timely manner and that each receives its share of the resources, the platform sets a number of limits and regulations, avoiding any single application dominating the resources. These limits are necessary to enable all applications to run smoothly without adversely affecting each other.

When an application reaches a limit (except for tenant limit on process variable size), the platform will force it to stop executing, and will give an error message explaining that limit has been reached. Example error message:

"Maximum time allowed for script execution has elapsed.: Maximum allowed time for script execution has been reached."

The tenant limit on process variable size is enforced to manage execution concurrency only, execution is just delayed if the limit is reached.

Execution Time Limits

Process

Each process has 10 minutes of continuous execution time.

Please note that Activity execution is not included in this limit. At each Activity (Connector, Email, Subprocess, Manual, long running Script) the process execution is suspended and the activity executes independently. The record of process execution time is paused during Activity execution.

The 10 minute limit is rarely reached - consecutive Activities are executed in a matter of milliseconds after each other.

The limit may be reached when you have multiple resource-consuming in-process scripts as these are counted as process execution time, not activity time (more details below) and many back-loops (XOR split connected to previous activity).

Child Process

A sub-process has its own execution time limit of 10 minutes, this limit is independent of the parent process's time limit.

Subcomponents of a Process

Activity duration time for a connector: 30 seconds
Activity duration time for a long-running FreeMarker script: 5 minutes
Activity duration time for a long-running JavaScript script: 1 minute
Single in-process script: 30 seconds

The above activity duration time limits refer to "execution time", not "real time". When several processes or actions run concurrently, the overall computation power is split between them and some activities might be suspended temporarily to allow others to execute. All executions are interlaced and controlled by the platform. In addition, overall concurrency of execution is managed, so there can be an additional delay before execution. This could lead to a further difference between 'execution time' and 'real time'.

"In-process script" refers to the script to generate input/output variables for each activity. A single activity can have multiple scripts, one per defined variable. The in-process script execution time is counted as process "continuous execution time", not as activity duration time.

Server APIs & Composite APIs

General Limits

Maximum Server API & Composite API request time (including all web service calls and scripts): 29 seconds
The request payload (including all headers) mast not exceed : 10 Megabytes

Composite API execution is different from Process execution. Composite APIs are executed synchronously, there are no pauses like in Processes. There is no differentiation between process time and activity time.

Note: This means that best practice for Composite APIs are different to that for Processes.
Composite API must be simple, and fast. Some examples of things to avoid: AND branches, 5+ loops, back loops, 20+ Connectors.

Usually, web service APIs do not take more than 10 seconds to respond, the 29 seconds timeout should therefore not be an issue.

If the API is custom-built, or makes a call to a local data source via DSEC, you will need to be mindful of this limit and think about using a sub-process instead of a Composite API.

Note: Complex SQL queries to a RDBMS can easily take minutes to produce a response. It will help to optimize and paginate your query/table/database.

If the time limit is exceeded, the standard timeout error is returned:

408 Request Timeout

Concurrency Governance

This is enforced by platform governor and is not configurable.

The DigitalSuite platform consists of multiple servers running in clusters. Cluster sizes are dynamically changed based on platform load. At any point in time, API call resources are evenly spread among all tenants requesting API call execution at that time, leaving a small space for new requests. If a tenant requests more that his/her portion of the resources, the Connector activity will abort with error.

Note: Cluster size is well planned and designed with plenty of resource margins to accommodate all tenants. Usually, you should not encounter this limit. In a rare instance that you do reach this limit, please do not design immediate infinite back loops to retry until you succeed - this will worsen the situation for all tenants. Place a limit on loop iteration, and also add some delay between each one.

As an app developer, you should always expect and handle this error, for example, by re-trying execution after some time. Also take into account the maximum runtime of composite APIs described above.

If a client issues too many API calls at a time, error 429 is returned:

Too Many Requests (429)

Variable Size Limits

Process Instance Data Size Limit

Process data cannot exceed 10 MB
The sum of all variables saved as process variables (accessible from process reports - parameters tab) between process steps must not exceed 10 MB (including metadata).
Main memory space needed to execute the process scripts must not exceed 25 MB.

The same is true for Composite APIs.

Note: This limit will become relevant when dealing with CSV files, Collections, or external databases. Iterate with loop, or use Subprocesses as needed.
File attachment to a web form and passing the file to the next screen, or passing the file to external storage service via Connector is not a problem, because the file content doesn't have to be extracted into process variable in these cases.

Tenant Limit

At any point in time the sum of memory occupied by processes concurrently executed by a single customer cannot exceed 50 MB
Short burst within reasonable beyond this limit may be tolerated, but this is not supported nor guaranteed

Query String Limits

Query string size limit

16384 bytes (16KB)

The size (length) of query string must NOT exceed the above limit size when you access the URL of the RunMyProcess platform. HTTP requests result in HTTP 403 error when the query string is greater than the limit size.

Connector Calls Limit

Tenant Level Frequency Limit of Connector Calls

This is configurable rule in the Provider configuration, Usage rules tab.

Example error message:

"Call frequency is too high."

This configuration is available for controlling the load to the connector. The Connector activity will abort with an error message if the frequency limit is reached. Additionally, all Providers that are set to 'Authentication scheme: None' will have 10 ms Usage rule enforced in the backend (it will not appear in the configuration). This is to avoid the anonymous sending of a heavy load to an endpoint.

Note: If you are working with a SOAP web service that doesn't use HTTP headers for authentication, and is encountering this restriction as an issue, you may want to try setting it to 'Authentication scheme: Login/Password' and send a dummy login and password.
If this additional header is ignored at the endpoint, you should be able to successfully workaround this Usage rule.

File Upload Limits

The maximum file size that an end user can upload to the DigitalSuite platform is 25 MB.
The maximum size of all files that single end user can upload to the DigitalSuite platform is 1 GB. (*)
The maximum size of all files in an account is calculated as number_of_users x 1 GB. (*)

(*) Specific custom contract terms may apply

Process Instance Lifespan

TEST and ACCEPTANCE mode process instances, along with their data, are automatically deleted after a period of two months.
LIVE process instances and data are kept indefinitely.

MongoDB Collection Limits

The following limits are set for MongoDB collections:

Maximum number of MongoDB collections allowed per account: 20
Maximum size of all MongoDB collections allowed per account - minimum: 500MB, 25MB per collection (*)
Maximum size of an object ("row") in a MongoDB collection: 50 KB

(*) Specific custom contract terms may apply

Email Recipient Limit

When using the default mail provider of DigitalSuite, the number of recipients per email is restricted to 50, including all addresses in the To, Cc, and Bcc fields.

If it is required to email to more than 50 recipients, you will have to split your recipient list into groups of 50 or less, and send separate emails to each group.

Summary of Platform Limits

Description	Limit	Configurable
Process Execution Time	10 minutes	No
Sub-process Execution Time	10 minutes	No
Activity Execution Time	5 minutes	No
JavaScript Execution Time	1 minute	No
In process Script Execution Time	30 seconds	No
API & Composite API Execution Time	29 seconds	No
Process data size (persisted)	10 MB	No
API & Composite API request data size	10 MB	No
Concurrent Memory (RAM) Usage	50 MB	No (short bursts may be tolerated)
Single Request Memory (RAM) Usage	25 MB	No (short bursts may be tolerated)
Query string size	16 KB	No
File upload size	25 MB	No
Uploaded files data size per user	1 GB	No
Uploaded files data size per account	number_of_users x 1 GB	Yes (contract)
Process Instance Lifespan	2 months in TEST and ACCEPTANCE	No
Number of collections	minimum: 20	Yes (contract)
Collection data size	minimum: 25MB, total: 500MB	Yes (contract)
Object size in collection	50 KB	No
Email recipient limit	50	No