Statement Timeout

To protect the Process Execution Engine against Method tasks that are not behaving as expected (such as Method with an infinite loop) and remote components, every Method has a timeout property that controls the maximum duration of Method execution. By default, this property is set to a five-minute ('5m') interval, which starts counting from the moment the Method begins to execute.

	i = 1
	while i > 0
	    // ... code here
	    i = i + 1
	end

If you run the Method as displayed above without some protection mechanism, the Method would run forever (or until the engine is shut down). Besides locking the engine, infinite Method tasks also lock the instance so that no other user is able to process it. To keep locking from occurring, the timeout property invokes and ends the Method in five minutes.

The timeout property is checked when the following conditions occur:

Method enters a loop or iteration.
A remote component is invoked.

Changing Method Timeouts

To change a Method timeout:

	// Set the maximum time the Method can run
	
	timeout = '10m'
	
	// Execute a loop or iteration for 10 minutes at most
	for each i in myArray do
	    // statements
	end

If the Method task is in an Interactive activity, consider using relay to. The relay to statement automatically ends Method execution for the activity when you expect that a user will take a certain amount of time to finish the execution. When the user finally responds, the response is routed to an alternate method designated in the relay to statement.

Relay to statements

Note: From this version onwards, consider using Screenflows instead of "relay to" invocations since Screenflows have all the benefits of relay to invocations with the simplicity of process-like design.

Controlling long running statements with relay to

When developing a Method, consider the impact the code will have on your process. For example, code in interactive activities often requires some kind of response from a human end user.

By nature, humans are unpredictable. A human end user may start his or her task in WorkSpace but then something may cause him or her to forget to complete the task until a later time.

Uncompleted tasks lock resources in the BPM Engine. Locked resources not only lock the method, but also decrease the scalability of the engine, which means that the engine cannot accommodate as many users as it can do under normal circumstances. To ensure that resources do not lock while waiting for end user input, you can use the relay to in your code.

When you use relay to in an interactive method, the engine immediately ends the execution of the method and does not wait for end user input. This frees the resources to handle new instances. When the end user finally enters his or her input, the engine routes the instance with the end user input to the method designated by relay to.

Relay to example

In the following example, a simple input is requested. The relay to statement is then invoked.

	input "Enter something in the box here: " name
	    using title = "Relay To Example"
	    relay to CilReachedFromRelayTo
	        using relayToName = name

The method in the CilReachedFromRelayTo task is as follows:

	// This is the standalone Method reached by an input 
	// statement in some Method in the process.  
	// Usually, the only Method you see in it is setting 
	// instance variable(s) from the Method's incoming
	// argument variable(s).
	
	name = arg.relayToName
	
	display "This is the standalone Method reached from another 
	     Method's input statement with a \"relay to\". 
	     You entered: " +  name

For further information, refer to Using Relay To.