routeMessage and recursion

04-13-2012, 11:37 PM

I have a channel that uses a file reader as source and web service sender as destination. The destination uses persistent queues. In order to have more control over handling specific errors with the web service, I switched off the persistent queue (required for getting status info). After all, the files on disk already act as a queue.

In the postprocessor script I check the web service response. With specific errors I want to resend the message by rerouting it to the current channel:

But from the Enter/Exit log pattern, I can tell that this results in a recursive call. That is no problem for an error for which let says 3 retries are allowed. But what if the web service is off-line for a longer period of time? Than this solution obviously fails.

In this forum I have seen a solution in which the channel is split in a queued front-end channel and a non-queued backend channel. I guess that calling routeMessage() to route to a different channel does not result in a recursive condition. However, this solution is to complex for maintainability reasons.

As a temporary solution I have created an error channel (javascript reader/writer) that triggers every 60 seconds looking for specific errored messages in the Mirth database. However, this approach may result in an out of order message confition.

Is there really no way to get the actual web service response in a queued channel? Could this be a new feature for a future release?

Comment

Yes, I saw this thread too. But because it was about FTP writers it never occured to me that I could use the same principle for a web service sender. So the Answer is: Handle the web service call in javascript using a javascript writer and the appache axis libs and you are in full control.

We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We may share certain information about our users with our advertising and analytics partners. For additional details, refer to our Privacy Policy.

By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.