JMS trigger name identification by Resource Monitoring service

,
1

Hi Team,

Please provide your inputs on the below requirement.

We are having a common Resource monitoring service for JMS triggers which are checking the same End Application availability.

Example : 5 triggers having common Resource Monitoring service and all the 5 triggers are having different username and password to check the Availability of end system.

Requirement:
Whenever the trigger suspended after its retry attempts, Resource Monitoring service will be invoked. Now we have a requirement like the resource monitoring should identify by which trigger it was invoked.
For this , we are using built in service - pub.flow:getTransportInfo and checking for the protocol- transport/jms/triggerName. but it is not populating.

Can you please put your ideas on this, how the resource monitoring service will identify the trigger name by which it was invoked programmatically.

Regards,
Sree

2

You cannot get this information from “pub.flow:getTransportInfo” because the RMS is actually not being called by the trigger. This service name is just a configuration on the trigger. On failure, when RMS is kicked off, a job is scheduled in the background that runs every 60 secs to check the RMS. This job has got the details of trigger that failed and RMS. If RMS returns isAvailable “true” then the job will enable the trigger and stops the scheduler. if isAvailable is false then it will continue to run every 60 secs

3

Hi Prasad,

Thanks for your response!

Yes, after reading the documentation I understood like JMS trigger is not calling RMS directly.

SAG documentation:
Integration Server schedules a system task to execute a
resource monitoring service after it suspends a trigger.

As you said, a job is scheduled in the background which execute RMS and that Job has details of trigger.

Is there anyway to get the scheduled JOB information programmatically.

Regards,
Sree

4

Yes, Integration Server invokes the RMS periodically ( time interval defined in extended settings). Once all the resources are available to process the trigger service, it enables the trigger from suspended to enable. Hence, IS keeps a correlation between monitor service and the trigger. But I do not think this information is accessible through code.