A customer recently asked my how they could keep track of everything that goes through Sonic. He spoke of logging time, sender and receiver information, in addition to saving the message contents itself in a persistent storage. He wanted this to be able to document a a later time what they had actually handled through their system. I guess an ESB service could do this kind of thing, but it would require a lot of reconfiguration/redesign - a whole new way of looking at messaging in the JMS context. My question is: Is there a way to easily achieve this? Is this in line with JMS as a concept?
This is an interesting and dependent on the messaging model that is being used. If you are using a topic then adding a new subscriber that can store the message is possible, although you have to ensure that the subscriber storing the message can perform this at minimally the same rate as the other consumers otherwise it could slow the performance of your application.
Unfortunately if you are using queues there is no easy way to perform this out of the box.
If this is really an ESB deployment you can use the wiretap configuration to route a message to a separate storage process. In fact all this would minimally require a configured XCBR or Branch with a process and a file drop service to complete. (See http://www.psdn.com/library/entry!default.jspa?categoryID=1892&externalID=4316&fromSearchPage=truefor more information).
Another approach would be to use Actional as this can capture payload at message part 0 through it's interceptors.
David
David,
I tried the Wire Tap example in the link.
How do I make sure that the wire tap step is atomic? There can more than one rule in this step. If the 3rd rule fails, is there a way to :
1. continue with the rest of the rules?
2. re-run using the first 2 rules?
Thanks,
--Subbu
Not entirely sure of the scenario here, but I would place a wiretap router as a separate step in the itinerary to any other router that is used, this would then ensure one has to follow the other and will only happen if successfulDavid
Thanks David.
One more question: Why is the output in the example sending out a multi-part message to the second channel? Can I enforce an XML message instead?
--Subbu