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
Runtime for a 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

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

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.

API Calls Limit

Tenant Level Frequency Limit of API 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 API. 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.

Platform Level Concurrency Governance of API Calls

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.

Rate Limiting for Composite API Calls

This is calulated at runtime and not configurable.

The number of simultaneous calls to Composite APIs is limited to prevent the server from overloading by unintentional app behavior or malicious attacks. The rate limit is calculated dynamically at runtime depending on the platform load.

If an app issues too many Composite API calls at a time, error 429 is returned:

Too Many Requests (429) - The server is refusing to service the request because the user has sent too many requests in a given amount of time ("rate limiting")

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.

File Upload Limits

The maximum size of files that an end user can upload to the DigitalSuite platform is 25 MB.
The maximum size of all files that an end user can upload to the DigitalSuite platform is 1 GB.

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.

Collection Limits

The following limits are set for collections:

Maximum number of collections allowed per account: 200
Maximum size of all collections allowed per account: 4 GB
Maximum size of an object in a collection: 50 KB

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 Limits

Description	Limit
Process Execution Time	10 minutes
Sub-process Execution Time	10 minutes
Activity Execution Time	5 minutes
JavaScript Execution Time	1 minute
In process Script Execution Time	30 seconds
API & Composite API Execution Time	29 seconds
API Call Frequency	Configurable in Provider Configuration
Process data size (persisted)	10 MB
API & Composite API request data size	10 MB
Concurrent Memory (RAM) Usage	50 MB
Single Request Memory (RAM) Usage	25 MB
Query string size	16 KB
File upload size	25 MB
Uploaded files data size	1 GB
Process Instance Lifespan	2 months in TEST and ACCEPTANCE
Number of collections	200
Collection data size	4 GB
Object size in collection	50 KB
Email recipient limit	50