This document outlines limitations that have been set for applications running on RunMyProcess DigitalSuite.
- 1 Overview
- 2 Execution Time Limits
- 3 Variable Size Limits
- 4 API Calls Limit
- 5 File Upload Limits
- 6 Process Instance Lifespan
- 7 Collection Limits
- 8 Email Recipient Limit
- 9 Summary of Limits
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.
2 Execution Time Limits
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).
2.2 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.
2.3 Subcomponents of a Process
- Activity duration time for a connector: 30 seconds
- Activity duration time for a long running FreeMarker script: 5 minutes
- 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.
2.4 Composite API
- Composite API overall time (including all web service calls and scripts): 30 seconds
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 30 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
3 Variable Size Limits
3.1 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), and additional memory space needed to execute the process scripts must not exceed 10 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.
3.2 Tenant Limit
- At any point in time the sum of memory occupied by processes concurrently executed by a single customer cannot exceed 25 MB
This limit is enforced on execution concurrency only - execution will not be stopped, just delayed.
4 API Calls Limit
4.1 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.
4.2 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.
4.3 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.
5 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.
6 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.
7 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
8 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 send an email to more than 50 recipients, split your recipient list into groups of 50 or less, and send separate emails to each group.
9 Summary of Limits
|Process Execution Time||10 minutes|
|Sub-process Execution Time||10 minutes|
|Activity Execution Time||5 minutes|
|In process Script Execution Time||30 seconds|
|Composite API Execution Time||30 seconds|
|API Call Frequency||Configurable in Provider Configuration|
|Process data size||10 MB|
|Composite API data size||10 MB|
|Single Tenant Memory Usage||25 MB|
|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|