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


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.


Fixed Duration*


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 *


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 *


Duration to sleep

Scope Variable Name *


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.