We haven't done much MSMQ work with Siebel until recently as there wasn't much documentation on the MSMQ transport. However, given the potential, we recently invested the time and effort to make this happen.
These are the requirements that the middleware imposed:
- have one inbound queue on our Siebel application server
- this one inbound queue would be the channel for multiple message types that might require different processing in Siebel.
- once processing is complete (or an exception takes place) processing status for the inbound message needs to be echoed back to the middleware server to a specific message queue
The diagram above illustrates the components and the flow of control and data.
- The MSMQ Receiver is configured as Receive and Dispatch and not Receive, Dispatch and Send as I wanted to specify a different response queue depending on the situation.
- Using the EAI Dispatcher allows the design to accommodate multiple workflow processes based on incoming data. It also allows for parameter injection into the invoked workflow process. (I've found other methods of making workflows environment agnostic, but this is great!)
- Sending acknowledgement using an asynch server request is key so that the original message can be committed off the queue - this took me a long time to figure out.
Getting the right xml converter configured on the MSMQ Receiver was important for the dispatcher so that the (quasi) xpath rules would function properly. In this case the following search expression worked.
/*/SiebelMessage/ListOfShippingHistoryIOThe "/*/" at the beginning accomodates the Siebel-Property-Set root node.
This setup is working well - it's high performance and outage resilient. Just remember to set a reasonable Time-to-recieve on the MSMQ message so that if there is a problem on the Siebel side, the message will bounce back to the sender.