on 09-05-2012 12:37 PM
Hi All,
My client is having JMS server and they want to interact with SAP ECC through PI. PI is having JMS adapter so we can use it.
But my client can also generates the XML file and can directly delivers the same to PI. So wanted to know the best approach to go forward should i opt for normal File adapter scenario or configure JMS adapter for this scenario??
Which option is the best one to use (in terms of performance/stability etc)
Thanks!!
Hi Vasant,
Your customer can store xml messages in jms server and using JMS adapter you can read those messages.This case one standard design works for you.(JMS server supports strong of xml/text messages and JMS adapter supports reading of both the messages)
If your customer looking for other solution then think about File Adapter or if he is ready send requent in web service format then go for SOAP.
Regards,
Raj
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Vasant,
Some questions to ask yourself because Websphere is not only capable of JMS & File communication...and because we have no business requirement context from your side...
- First qualify whether you require synchronous or asynchronous communication?
- What kind of data is being transmitted? Business critical transactional data, not critical / transactional etc.? If it's transactional, one normally opts for async reliable guaranteed delivery.
- What quality of service is required from your client (Best effort, exactly once, exactly once in order)?
- What does Websphere expect in return (i.e. response, transport ack etc.)
- If Websphere expects a response, should it be immediate or is a delayed response with correlation acceptable?
- If the response expected is immediate (i.e. sync), what happens if the call fails? Would the sending systems be able to trigger the message again?
These are some questions...and it will bring you a little closer to an answer but the most important question you should ask is:
What is the best solution for your client that is reliable, has easy monitoring, has good error handling options, is secure and can provide a full end-to-end audit trail for query resolution?
Regards, Trevor
Hi,
- First qualify whether you require synchronous or asynchronous communication?
>>It's asynchronous communication
- What kind of data is being transmitted? Business critical transactional data, not critical / transactional etc.? If it's transactional, one normally opts for async reliable guaranteed delivery.
>>not sure about this,
- What quality of service is required from your client (Best effort, exactly once, exactly once in order)?
>>Exactly once
- What does Websphere expect in return (i.e. response, transport ack etc.)
>>That i have to check
- If Websphere expects a response, should it be immediate or is a delayed response with correlation acceptable?
>>Will check
- If the response expected is immediate (i.e. sync), what happens if the call fails? Would the sending systems be able to trigger the message again?
Its a a sync process.
Depending upon the very limited answer which i have provided above, what woould you have chossen to do this?
Thanks!!
i would like to suggest you to go for JMS adapter because you have better message monitoring facility with that and also you can handle complex structure in better way.
Regards
GAgandeep
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, your MQ guys should already have a good idea of the monitoring. I don't have any specific article but here is a link to the documentation, look at the section on Monitoring and Performance.
Hi Vasant,
i worked on extensively using JMS adapter and File adapter, but never had any serious issues with JMS/File,both worked perfectly.
you no need to depend on MQ monitoring because most of the clients never give access to MQ system.
There are some limitations and Advatages with File adapter compare to MQ, but limitations are not show stopper.
your customer already had MQ application then opting for MQ right idea.
Further debate not required i beleive
Regards,
Raj
Hi Vasant,
My opinion on this...
JMS will give very good transactional support in case of issues with the network or outage of one of the two systems. You can still use XML formated messages within the MQ messages. We use this when communicating with our Mainframe system on IBM MQ. It has been rock solid for many years now. Also it can scale up nicely if your volume increases over time.
You can choose how long to persist the messages in the adapter engine or the integration engine. Then you can archive using normal PI archiving rather than going out to file system.
I like to avoid going out to the file system whenever possible to avoid issues with locked files, half processed files, sequence issues, lost files, or mysterious things happening, etc.
Message queues are designed to reliably transfer messages between systems, and IBM MQ is one of the best.
Here are some resources that will help:
http://wiki.sdn.sap.com/wiki/display/XI/FAQ++J2EE+JMS+Adapter
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
I'd go for JMS server - if it's one of the ones that work with PI - otherwise files,
Please also read about JMS problems in OSS notes for the JMS server you're planning to use,
with JMS you have a nice visibility of messages and perf should also be better,
Regards,
Michal Krawczyk
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Michal,
The client is having Webshpere MQ.
So the job of JMS server, is to only send/receive messages to/from PI. It's like any other server for example ftp/web server etc.
What do you mean by JMS have a nice visibility of messages?
And do you see any issues with Websphere MQ server?
Thanks!!
User | Count |
---|---|
83 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.