An interesting situation arose the other day for a solution to the following requirements on WPS 18.104.22.168:
- We have a JMS queue that collects message for a web service Endpoint.
- We have a web service that is only available during business hours (say 9-5).
- If we send a request outside business hours, we will get an exception.
- During business hours, a failed transaction should be re-tried for four hours before it is recorded as a failure.
- The retries to the service should occur X minutes apart.
- The solution should have the minimum ‘moving parts’. If it requires multiple scripts and cron jobs, it’s too complicated.
If we don’t do anything special, all our transactions end up in the Failed Event Manager where someone is going to have to manually re-submit them. Manual anything is a bad solution in Integration, so we need to look for something better. Default messaging is pretty bad at the concept of “Stop picking up messages if the endpoint I’m trying to call is down”. It will pick every single message off the queue, fail, and put it into the FEM.
The solution that immediately came to mind was to leverage the JMS queues. I could put all the requests in a new queue that service requesters would place their messages.Next, I would install an MDB that enforced this policy on that request queue. If the message on the queue met the above requirements, it will be placed onto the JMS Queue for the WebService Endpoint. Basically, the MDB would act like a gatekeeper.
The problem that I ran into was how to deal with messages that the gatekeeper didn’t want YET (say outside office hours). I thought JMS message selectors would do it but they’re only static. How could I start processing messages when the office door went from CLOSED to OPEN at a specific time? I was unable to resolve this issue.
The solution that we went went involved using a Long Running BPEL process to meet all the above requirements. A short running BPEL is no good because it must run within a single transaction, meaning 180s to resolution. Increasing this to four hours is unreasonable. A Long Running BPEL is composed of multiple transactions and is not bound by this 180s limitation. It includes dynamic duration nodes that will allow it to sleep until office hours open, sleep until the next retry and calculate how long it’s been trying to send. Also, no ‘moving parts’.
It kind of sucks to use a long running BPEL process to solve a technical issue instead of a business problem, but it does what we need without exposing our WID/WPS developers to the world of RAD/WAS.