sleep

Sleep

Version: 17.07

Supported Since: 17.07

What is a Sleep processor?

Sleep processor can be used to delay the current flow intentionally by a predetermined amount of time or by a variable time which can be resolved from a context variable. This processing element behaves exactly similar to the functionality of Java’s Thread.sleep(milis).

In order to use this processing element, you must first select the Flow Control dependency from the processor list when you are creating an empty Ultra project. If you have already created a project, you can add this dependency via Component Registry. From Tools menu, select Ultra Studio → Component Registry and from the Processors list, select the Flow Control dependency.

sleep ico labled

Out Ports

Next

Once the system wake up from the sleep, message context will be continue from this port.

On Exception

The message will be sent to this outport, if an error occurred while sleeping.

Parameters

Fixed Duration*

Basic

Determines whether processor runs in fixed duration mode or dynamic duration mode. If fixed duration is selected, flow will be slept for a pre configured duration, Else processing element will extract the duration from a scope variable at runtime.

Iterations *

Basic

This parameter will be available if loop is configured in Fixed Counter mode. This parameter determines the number of iterations of the loop at design time.

Duration Type *

Basic

Duration to sleep

Scope Variable Name *

Basic

Name of the scope variable to resolve sleep duration at runtime.

Processing element always expects a variable of type Long and processor will fail, if the specified variable can’t be casted to an Long.

Sample Use case

In the following use case, the requirement is to call a rest end point of a stock exchange. Below service is exposed by a stock broker and the flow will be initiated by a buyer by sending an initial request to the NIO HTTP Listener(of stock broker). Assume that, due to the higher demand, the stock exchange tries to perform only a limited number of operations per unit time and drops all other requests. Objective of this setup is to retry 3 times, if request dropped from stock exchange’s end, before sending status as failed to the buyer. In this case we are using a constant delay between two consecutive requests in order to create a delay between two requests.

for loop 1
for loop 2
Figure 1. Configuration of For Loop processor

For loop is configured to iterate for a fixed 3 times and to the In loop flow port, Log processor has connected in order to log every retry event. Loop termination port has connected back to the NIO HTTP Listener. So at the end of 3 retries, response with the status failed will be send back to the buyer.

for loop 3
Figure 2. Configuration of Switch processor

Response from the NIO HTTP Sender is connected to a Switch which checks status code. If the status is 200, operation has performed successfully and instead of connecting back to the for loop, case connects directly to the NIO HTTP Listener. This is similar to performing a break inside the for loop.

for loop 4
Figure 3. Configuration of Case

If the status is not 200, we feed the context back to the for loop through a Sleep processor which will create a delay of 10 seconds before performing next request, which will either stop or retry based on the current iterations count.

for loop 5
Figure 4. Configuration of Sleep processor
In this topic
In this topic
Contact Us