Integrating OSM with CRM & Inventory system

Question

Hi,
We are using OSM 7.0 in our solution, in which we need to integrate OSM with CRM and one inventory system.
We need to notify CRM at various stages during order fulfillment for e.g. after completing different milestones like Order submitted, Inventory Done and Order Completed. Among these notifications, Order Submitted notification would be a synchronous one and rest are the asynchronous notifications.
We are not using AIA for integration with CRM. How we can send notifications to CRM for the above stated scenarios?
Also, to integrate with Inventory system, we need to call a webservice exposed by that system. Could you please confirm if the below steps are correct to achieve the same or there is some other way?
1. Write Automation plug-in
2. Configure JMS queue on weblogic server
3. Post request message on JMS queue
4. Write JMS Client to get the message from the queue
5. Package the message in SOAP envelop and call the webservice API.
~RS

Answer 1

RS;
In our AIA cartridges, we make use of automated OSM notifications to send events to Siebel CRM via AIA. There are several different kinds of notifications available in OSM, the ones that we use in particular for this purpose are data-change notifications which is invoked whenever a field on the order has changed (you configure which field when you create the notification). The field that you would want to listen for changes on in your case would be the field in the OSM order that you are using to store milestone/status information. The notification plugin would then be invoked whenever this field changes and can then send a status update to your CRM system if the change is relevant.
As for your webservice integration question, first let me clarify - you are interested in invoking a web service via SOAP/HTTP instead of SOAP/JMS, is that correct?
Assuming so, your basic steps below are directionally correct, but I would offer a few additional points to consider.
Your automation plugin in step 1 would best (IMHO) be an XSLT or XQuery plugin vs. a custom java plugin. This will keep the scope of the business logic to the bare minimum of building up the SOAP message which of course XSLT and XQuery can handle with ease.
I would recommend the payload of the JMS that you create in step 3 be the entire soap:envelope, this way your client in step 4 doesn't have to parse and wrap the message. It just blindly forwards it on to the real SOAP/HTTP endpoint and waits for a response.
Your JMS client in step 4 would best be implemented by a message-driven-bean (MDB) which would be deployed to the OSM server instead of a standalone JMS client. MDB's are highly scalable JMS clients and really the way to go when you want to have some business logic be triggered based on the arrival of a JMS message.
You probably need to add steps 6 and 7 which would be to deal with the response message back to your automation plugin. This would involve the MDB getting the SOAP/HTTP response back, creating a JMS message and putting it on the response queue (which would need to be defined in step 2) and copying the JMSCorrelationID value from the request to the response JMS message to ensure it can find its way back to the task that sent it.
Now, all that being said, an alternative to all of this is to just have the automation plugin itself take care of posting the message to your SOAP/HTTP(s) endpoint. You could do this by writing a custom Java automation plugin that uses low level HTTP class libraries or uses standard WS client proxies to invoke the web service. There are pros and cons to this approach. The major pro being that it involves fewer moving pieces, the major con being that if your inventory service is not able to process requests as fast as OSM is making them (based on order volumes), then this may become a bottleneck in the OSM system. The bottlneck stems from the fact that OSM shares a pool of threads across all automation plugins. If you have one that is taking a very long time to process requests and the number of requests being processed concurrently is high, then this can lead to a situation where other automation plugins are starved. This won't result in an error, but it can result in a bottleneck which affects the overall performance of the system. This is really only a major concern if OSM is processing high volumes of orders and the inventory system is not able to keep pace.
Brian.