This content has been marked as final. Show 2 replies
Hi Naveen;1 person found this helpful
Can you clarify the following please?
1. Look at Design Studio->Preferences->Oracle Design Studio->Order and Service Management preference screen. Is the value for "Automation plug-in Build And Deploy Mode" set to "Optimized"? (This is available on 7.0.3 and later). It's fine if it is, and I'm assuming that's the case, just need to understand this setting as it affects how external messages are routed to plugins.
2. What is the correlation logic for A and B. Is it correlating on the same value? Most likely it is.
The reason why these two questions are pertinent, is that with Optimized build-and-deploy mode, we now have the ability to have multiple plugins listen on the same queue without requiring special selectors in order to discriminate/route messages to the correct plugins. Prior to 7.0.3 (or if you have chosen to use legacy mode), then selectors were absolutely required to be used if you had multiple plugins listening on the same queue. This was because there was a 1:1 relationship between the MDB that OSM generates for the external receiver plugin, and the business logic (XSLT, XQuery or Java automator) that gets executed when we receive a message on that JMS destination and correlate it to the task. With legacy mode, if you have two automated tasks with external receivers listening on the same queue that don't have selectors that uniquely select/route messages to one task or the other, then the MDBs listening on that queue are both eligible to receive the message and it will be non-deterministic as to which one receives it at any given moment. As a result, with legacy mode you have no choice but to use selectors to ensure messages arriving on the same queue are routed to the right plugin.
With Optimized mode, we simplified that. External receiver plugins deployed in optimized mode that are listening on the same queue do not require selectors to discriminate/route messages to one task or another. OSM will automatically route the message to the right task based on correlation information extracted from the incoming message.
You can verify this by switching to legacy mode and see if that resolves your problem. I would caution you though against just relying on using legacy mode and instead you should consider a different approach that ensures correlation id's are used properly. The rule on correlation id's is that they are unique in the system (i.e. only point to one task) at a given point in time. Since an external message arrives with a valid correlation id for Task A, it will get routed to Task A. If you don't want this to be the case, then choose a different correlation vale for A and B. Or alternatively, have A receive the message and functionally reject it since it was sent out of order anyway.
Sorry I posted wrong content.
Edited by: tarini.samal on Jan 25, 2013 9:53 AM