UM, Moving messages from One Queue to another

, ,
1

Hi,

I have a requirement, where in Error messages posted to an Error queue would need to be moved/ copied selectively to the Main Processing Queue.
option would be to view messages in the Error Queue, and those messages that can be reprocessed to be selectively marked ( which could be random in the Queue) and moved to the main processing queue for reprocessing.

Are there any built in tools in webMethods Suite to make this happen?

Appreciate your feed back in this, Thanks,

Srini

2

Hi Srini,

there are no standard tools in webMethods to do what you describe. The usual pattern for dealing with parking and resubmitting error documents is through the service auditing capabilities in Integration Server. Setting a couple of properties on a top-level service is enough to ensure that any errors are logged to the service audit database, where they can be searched and resubmitted using the service auditing UI in My webMethods Server, or using the API in the WmMonitor package. This is the way most people handle the use-case you describe.

3

Thanks Jonathan for your reply, appreciate.

So in summary we are using the service auditing capabilities to store the error messages and move the messages to the Processing Queue later.

In my case the Error Messages are in the JMS Queue, I have a Webservice/ IS service interface that allows the end system to push messages to this Queue and hence I can reuse the Auditing capabilities of this service. I would now have to correlate the message in the Audit table with the message in the Queue and would have to remove it from the Queue when the message is resubmitted for processing. it would be ideal if I was able to read from the queue and resubmit them as required - looks like this is not possible in UM.

thanks,

Srini

4

Srini,

I’m sorry but I don’t quite understand your use-case. If you have a trigger in IS which is causing a service to run when a message arrives, then you configure the auditing on the top-level service invoked by the trigger. When that service completes (either successfully or with an error), the message is removed from the queue.
The service auditing will store the service inputs in the IS database if the service fails so that you don’t lose the message. You can inspect things there and resubmit them for processing once the cause of the error has been resolved (e.g. missing master data). The resubmission does not actually go via the messaging layer - it reruns the IS service with the same data that originally came off the queue from UM.

The overall goal of this capability is the following:

  • guaranteed no loss of data, even in error conditions
  • park “problem” messages for investigation and reprocessing, without blocking other messages on the same queue
  • browse, inspect and resubmit failed messages
  • edit data in failed messages (depending on payload format)
    All of this is available without any coding being done.