This topic discusses about the upper limits set by krewData.
There is an upper limit to the number of records that the following input commands can read when executing the data editing flow.
Count of Processed Records | ||
---|---|---|
Manual Execution | Schedule Execution | |
Evaluation version | 50,000 records | 50,000 records |
Product version | 50,000 records | 200,000 records |
※ If multiple input app commands are placed in a data editing flow, the total number of records in each input command app are counted as processed records.
※ The above mentioned upper limit is also applicable when creating records using the following output commands.
You can check the number of records that a data editing flow loads in Flow Setting tab of the Plug-in Settings page. In addition, you can check the number of records that were actually processed on executing a data editing flow in the Schedule Execution tab of the Plug-in Settings page or in execution logs of the krewData app. |
There is an upper limit on the number of schedules that can be set for each domain.
Schedule Count | |
---|---|
Evaluation version | 3 |
Product version | 3~100 (depending on the purchased license) |
You can check the available number of schedules in your kintone environment on the Schedule Execution tab of the Plug-in Settings page.
There is an upper limit to the number of records that the following input commands can read when executing the data editing flow.
Count of Processed Records | ||
---|---|---|
Manual Execution | Real Time Execution | |
Evaluation version | 10,000 records | 10,000 records |
Product version | 10,000 records | 10,000 records |
※ If multiple input app commands are placed in a data editing flow, the total number of records in each input command app are counted as processed records.
※ The above mentioned upper limit is also applicable when creating records using the following output commands.
You can check the number of records read by the created data editing flow on the Flow settings tab of the Plug-in settings screen. In addition, you can check the execution log of the log output destination app for the number of records that were actually processed by executing the data editing flow. |
There is an upper limit on the number of real time execution flows that can be set for each domain.
Count of Real Time Execution Flows | |
---|---|
Evaluation version | 3 |
Product version | 3~100 (depending on the purchased license) |
In real time execution, all the data editing flows in the execution unit are locked at run time to prevent calling of the same execution unit by other real time execution (exclusive control). There is an upper limit to the number of executions per minute in the same execution unit.
If "Concurrency Behavior" is set to "Cancel The Request" in the execution unit settings, execution requests beyond the upper limit will wait for execution.
There is an upper limit to the waiting time, and a timeout error occurs after a certain time. |
The following image demonstrates an example when the same execution unit is executed by 7 users at the same time. In that case, the five execution requests (① to ⑤) are executed in sequence, but the limit on the number of executions per minute (5 times/minute) has been reached. So, the remaining two execution requests (⑥ and ⑦) do not start immediately after the execution of ⑤ is completed. It starts one minute after the start of the first execution.
If "Concurrency Behavior" is set to "Waiting the execution" in the execution unit settings and a user executes the execution unit which is already running, an error is thrown immediately and execution is not performed.
For information regarding exclusive control, see "Exclusive Control" section in Executing Execution Unit.
Maximum number of records that can be generated simultaneously if there are multiple executions units running at a time:
Example) When there are 3 execution units running at the same time:
As total of output records in Execution Unit 1 and Execution Unit 2 reaches the maximum limit (20,000 records), Flow C of the Execution unit 3 will wait and will generate the records after process of Execution Unit 1 and Execution Unit 2 has completed.