timer ingress connector

Timer Ingress Connector

Version: 17.01

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.

The sample use cases below depict an integration flow with Timer IngressConnector.

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’s failed 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’s. This monitoring task should check the availability of the web service in every 1 minute intervals.

Prerequisite

In order to implement above use case you must first select following dependencies when you are creating an empty Ultra project

  • Timer Task Connector and HTTP NIO Connector dependencies from the connector list.

  • Payload Setter and Flow Control dependencies from the processor list.

If you have already created a project, you can add above dependencies via Component Registry. From Tools menu, select Ultra Studio → Component Registry and from the Connectors list and Processors list, select above dependencies

Implementation

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

After filling out the required parameters, this configuration can be saved by clicking the Save button at the bottom of the configuration pane of the SFTP IngressConnector.

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’s 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.

Out Ports

Processor

The message received to the Ingress Connector will be emitted through this out port

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>

You can declare this bean from the user interface as well. For that you can open the project.xpml he project.xpml under Design view, and go to the Add Bean option of the design view. Then you can load the SchedulerConfig class by typing class name and using the "Load" option of the UI. Once you click the Load button, UI will be loaded with the existing properties of that class. You can configure required properties as below, and click the Save button to save the resource configuration. Now you should be able to see same bean definition under the resources section of the XML view of the project.xpml

timer ingress connector 3

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’s 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.

Timeout

Advanced

Timeout in millis, to be used while connecting to the remote SFTP server. If it couldn’t establish a connection with the SFTP server within this time period, it will be considered as a connection failure and notify to the user. By default, this value is 60000.

In this topic
In this topic
Contact Us