This document outlines limitations that have been set for applications running on RunMyProcess.
- 1 Overview
- 2 Execution Time Limits
- 3 Variable Size Limits
- 4 API calls limit
- 5 File Upload Limit
- 6 Process Instance Lifespan
- 7 Secure Enterprise Connector (SEC)
- 8 Summary of Limits
The RunMyProcess 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 as 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 Sub-components of Process
- Activity duration time (Connector, Email, long running Script): 5 minutes
- Single in-process script: 30sec
The above time limits are "execution time", not "real time". When several processes or actions run concurrently, the overall computation power is split between them and some 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 additional delay before execution, which could lead to a further difference between 'execution time' and 'real time'.
"In-process script" is the script to generate Input/Output variables for each Activity. A single Activity can have multiple scripts, one per variable defined. In-process script execution time is counted as process "Continuous execution time", not Activity duration time.
2.3 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 SEC, you will need to be mindful of this limit.
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.
3 Variable Size Limits
3.1 Process instance data size limit
- Process data cannot exceed 10Mb
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 25Mb
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 RunMyProcess 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.
5 File Upload Limit
The maximum file size that an end user can upload to the RunMyProcess platform is 25 Mb.
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 Secure Enterprise Connector (SEC)
The SEC cannot process more than 1 Mb of raw information at any one time. If you are using adapters the infomation is transformed to base64 which may make the package a little bigger. A good rule of thumb is to keep the returned data under 800 Kb.
Transactions should be completed within a 60 second timeframe. If transaction take longer than 60 seconds to respond you will see a timeout error in RunMyProcess even though the process is still running.
8 Summary of Limits
|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|
|Process Instance Lifespan||2 months in TEST and ACCEPTANCE|
|SEC data size||800 Kb|
|SEC transaction timeout||60 seconds|