Hi,
Do we have facility in webMethods to enable and disable the trigger automatically based on some events in webMethods IS itslef ?.
If we have any service which does that then it could be one possible way of doing it through the service.
Do you want to really disable a trigger or are just trying to quiesce the queue? There are a couple of services in the WmPublic(Look under triggers, IS 6.0.1 sp3 or later) which allow you to quiesce individual queues and then reenable them. This would in affect keep the trigger from firing but would still allow the messages to be placed on the queue.
I really want to disable the trigger through a service - disconnect the client completely, the intention is that it won’t consume messages (greyed out in developper). Then the same, but for enabling it again.
If you don’t want it to consume messages then you should use a trigger filter instead of trying to disconnect it. If you have requirements to completely disconnect the client and not process any messages for certain time periods I would go back and look at my architecture and see if you really have it laid out in the best fashion for what you are trying to accomplish.
Probably some other ways to accomplish what you want without disabling the trigger. Or maybe the broker is not needed at all since you don’t have full time persistence requirements.
Even me too have same scenario like,would like to disable the trigger and enable after some time.
My requirement is something like this,if end systems(for eg Oracle) are down I dont want to receive any documents from broker and once end systems are up,the triggers should get enable automatically with out any manual interaction.Endsystems can be down for 1-2 hours as well and it is happening during weekends.So need to automate this.
Is it possible to ping the DB at a paticular period of time and check for the status?Based on that response can we make it enable? how can we implement this?Is this way of implementation is good approach? or any other suggestions?
Catch the oracle unavailable exceptions and throw the service for retry(system exceptions will trigger a retry, service exceptions will not), this is explained in the docs. Your service will retry based on the interval and number you specify in the trigger properties. You don’t need to disable triggers to account for maintenance windows, system can handle it for you if coded correctly. That way it will handle maintenance windows as well as unplanned outages.
Mark - Just out of curiosity, are you suggesting one should not use the pub.trigger:suspendRetrieval/Processing and pub.trigger:resumeRetrieval/Processing services in WmPublic? If so, why is this?
Well you can use them for maintenance activities or other planned outages but the built-in retry mech. works just as well and can handle the unplanned stuff as well. In addition the connection pools don’t always behave properly ie the first transaction through can cause a failure with subsequent transactions being okay. The built in retry feature does not have this issue.
If it works for you I’d keep using it. My preferences is to have the built-in stuff do the work for me. I don’t have to worry about how long the outage is or when it comes back, the retry will automatically kick it through. The same error handling can also handle HTTP retries, ftp, JDBC, MQ etc. The key is just throwing the system.exception and not the service.exception.
Makes sense. I too like the automatic retry capability, but I think based on our requirement, throwExceptionForRetry won’t help us. I just wanted to make sure there weren’t any “gotchas” with respect to using the built-in pub.trigger services. Thanks!