timer ingress connector

Timer Ingress Connector

Version: 17.07

Supported Since: 17.01

What is Timer Ingress Connector?

The Timer Ingress Connector can be used execute any timely triggered tasks in the UltraESB engine. Timer task execution schedule can be configured using the configuration of the "Schedule" tab in the ingress connector. For each iteration of that schedule, framework will generate a new message and inject that message to your integration flow.

In order to use the Timer Ingress Connector, you must first select the Timer Task Connector dependency from the connector list when you are creating an empty Ultra project. If you have already created a project, you can add the Timer Task Connector dependency via Component Registry. From Tools menu, select Ultra Studio → Component Registry and from the Connectors list, select the Timer Task Connector dependency.
timer ingress connector 4

Out Ports

Processor

A message with an empty payload will be emitted from this port according to the configured time period

On Exception

The message will be sent to this out port if the Ingress Connector fails construct a message for the current execution iteration

Parameters

* marked fields are mandatory

Scheduler Configuration

Scheduling

Bean reference of the scheduler configuration bean which should be declared as a resource in the project.xpml file. By default there is internal scheduler configuration within the framework which will be shared by all the polling connectors. If you need to configure higher level of concurrent processing threads which will need to execute timely triggered tasks, you can configure your own thread pool configuration while declaring the parameters of the scheduler configuration bean as below.

<x:resources>
    <x:resource id="custom-scheduler-config">
        <bean id="schedulerConfigBean" class="org.adroitlogic.x.base.trp.SchedulerConfig">
            <constructor-arg name="name" value="my-custom-scheduler"/>
            <property name="schedulerThreadCount" value="4"/>
            <property name="pollingThreadCoreSize" value="4"/>
            <property name="pollingThreadMaxSize" value="10"/>
            <property name="pollingQueueSize" value="25"/>
            <property name="pollingKeepAliveTime" value="5000"/>
        </bean>
    </x:resource>
</x:resources>

In this configuration,

  • schedulerThreadCount - is the number of threads which will be used to schedule the number of threads to be used to handle scheduled timer tasks. Generally this value should be smaller value since timer threads don’t do heavy task in this, rather it is just initiating the polling task for the scheduling iteration and handover the rest of the processing to a separate executor service. This executor service can be configured by using next four parameters of above scheduling configuration bean.

  • pollingThreadCoreSize - is the core size of the timer task handing thread pool

  • pollingThreadMaxSize - is the maximum number of threads of the timer task handing thread pool

  • pollingQueueSize - is the queue size of the thread pool

  • pollingKeepAliveTime - is the keep alive time of the thread pool

Polling Cron Expression

Scheduling

Cron expression for the timer task executing schedule. Cron expression should be a valid Quartz cron expression since the Framework is underneath using Quartz to extract the schedule from the cron expression.

Polling Start Delay

Scheduling

Delay in milli seconds to start the timer task executing schedule. Any iteration which comes within this time period from the startup time of the framework, won’t be considered as a valid iteration for the timer task execution.

Polling Repeat Interval

Scheduling

Interval in milli seconds for the next iteration of the timer task execution. This will be considered if there isn’t a configured cron schedule.

Polling Repeat Count

Scheduling

Number of iterations which should go through the timer task execution schedule. If this is set to 1 which means only the first iteration of the timer task execution schedule will be considered as a valid iteration and all other iterations of the schedule will be ignored. By default, this value is set to -1 which means it will consider all the iterations of the execution schedule as a valid iteration.

Concurrent Polling Count

Scheduling

Maximum number of concurrent threads which can be used to execute the task execution schedule. By default, this value is 1.

Concurrent Execution Count

Scheduling

Maximum number of concurrent threads which can be used process the timer task after initiating it based on the timed trigger. By default, this value is 4.

Sample Use Case

Use case description

In this use case scenario, the requirement is the check the availability of a web service as a health check task periodically and if that web service is not available that should be informed to another web service via HTTP. Monitoring web service will accept text payloads and send 200 OK if it’s running without any issues. If it fails to respond with 200 OK, we can assume that it’s not available and we should inform it to the second web service, by forwarding the received response from the first web service as it is. This monitoring task should check the availability of the web service in every 1 minute intervals.

To implement above use case, first let’s create our integration flow named “integrate-timer-ingress-connector” and add a Timer IngressConnector to that. In simple use case there isn’t any mandatory parameters for the Timer Task Ingress Connector. All the timer schedule related parameters are in the Scheduling tab of the ingress connector. In our requirement, we should execute our task in every 1 minute intervals. For that we should configure "Polling Repeat Interval" to 60 and final scheduling configuration will be like below,

timer ingress connector 1

Then we should add following elements to our integration flow.

  • String Payload Setter processing element to set required payload to send to the monitoring web service. In this examples, let’s set set String Payload value as Testing Endpoint.

  • HTTP NIO Sender connector to send the message to the monitoring web service. This connector should be configured with the details of the monitoring web service details.

  • Conditions Evaluator processing element to evaluate the received response code from the monitoring web service. For that x.http.response_status_code property values should be evaluate to check whether it is 200 or not.

  • Another HTTP NIO Sender connector to send the monitoring web service’s response to the second web service. This should be configured with the details of the second web service.

  • Successful Flow End processing element to mark the flow as completed.

After adding all these elements, final flow would be like this,

timer ingress connector 2

Now if you run the flow, your should be able to see that framework is sending messages to the monitoring web service in every 1 minute intervals and based on the received response code, second web service will be invoked.

In this topic
In this topic
(c) Copyright 2016-2017 AdroitLogic. All rights reserved.
Terms of Use
Contact Us