Method Timeouts
Method execution duration can go from very quickly to taking quite a bit of time to process all data. To avoid that methods run too long or even indefinitely, the framework maintains a hard setting by which the execution cannot pass and the soft setting on the method configuration.
Maximum Execution Time
The maximum time a method can run is 24 hours and that is a hard limit. This means that even if it would be possible to configure a soft limit of, let's say 48 hours, the BCM service will still enforce the maximum execution time of 24 hours.
Default Timeout Setting
The default timeout (= soft limit) for new methods is 60 seconds. After 60 seconds have passed and the method is still running, the framework will cancel or interrupt the method's execution. Changing the timeout value can be done on the Main Method sub tab available in the Execution tab of a method definition:
Existing methods which still have a soft limit set to 0 or higher than 24 hours, will be patched during the setup and the setting is reset to a maximum running time of 24 hours.
Impact of Interrupted or Cancelled Methods
Depending on the method type (Action, Update, MultiRead, ...), the way of how a method is interrupted, will be a bit different:
Method Types | Impact |
---|---|
Action, Create and Update | Such methods will be disconnected from the framework, so to speak, but will keep running in the background. This has the effect that no communication is possible to the framework and any data cannot be sent back. |
SingleRead and MultiRead | These methods are effectively terminated. The execution process is stopped forcefully. |
Additionally, the execution of output data extensions, BCSP triggering and any AfterAction audit trail configuration will be skipped.
On the contrary, the post execution actions are run anyway as that way it is possible to configure an action when a main method times out.