Version: 17.07
Supported Since: 17.07
For loop processor can be used to execute the same flow for a fixed number of iterations. This processor behaves similar to standard for loops which are commonly available in any programming language. Even though this processor supports only fixed number of iterations, user has the flexibility to determine the number of iterations at runtime or at design time.
This loop internally uses Java method calls (leading to recursion), hence may not be suitable for arbitrarily large loops (e.g. those spanning more than 500 cycles): |
You may run into a StackOverflowError
if the loop outgrows Java’s available stack space.
The actual limit depends on the amount of stack allocated in each cycle, comprising factors such as
number of elements in the loop body and the local (non-heap) object allocations in each cycle.
Application level resources (e.g. opened streams and file handles, file-store file entries leased for current message) allocated within the loop body may not get released until the whole loop terminates (because the same message and message context are reused across all iterations), leading to resource exhaustion.
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. |
Loop termination out |
Once the conditions are met to terminate the loop, message context will leave the loop through this port |
In loop flow port |
If the conditions are met to continue looping, message context will be passed through this port. The flow which starts from this port will act similar to the body of a standard for loop. |
On Exception |
The message context will be sent to this out port if any exception occurred while looping. However, if an exception thrown during the in loop flow, the loop will be terminated and continue through the exception flow of the corresponding element. |
Design of the flow should re connect back to the For Loop processor’s In Port in order to maintain the looping functionality. |
Fixed Counter * |
Basic |
If fixed counter is selected, loop will be iterated over a fixed number of iterations which should be defined at design time. Else processing element can be configured to extract iteration count from the payload 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. |
||
Iteration count variable |
Basic |
Variable will be created in the message context by this name, and on each iteration variable will be updated by the current iteration count. If this variable is not specified, processor will not set or update the iterations count.
|
||
Predicate Type * |
Basic |
This parameter will be available if loop is configured in Runtime iteration determination mode(Fixed Counter = false).The type of predicate to be used for the evaluation. The following predicate types are supported.
|
||
Variable Name * |
Basic |
The interpretation of this parameter’s value depends on the selected predicate type.
|
||
Namespaces |
Basic |
If the predicate type is CONTENT (where an XPath value is used for the condition), this parameter specifies an optional map (defined as a resource) with namespace prefixes (as keys) and namespaces (as values) used within the XPath expression |
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.
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.
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.
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.