on 02-27-2013 1:00 PM
Dear All,
My scenario is to send request from database to SAP and get the response which needs to be updated in the same table. I am using a RFC lookup for this, meaning the sender and the receiver is the same database.
The scenario is working and the table is getting updated properly
But in the moni i am getting a response from database (which is the 'UPDATE_COUNT') , as there is no mapping for this response its getting failed in moni.
I have noticed that the when the sender adapter is fetching the data the processing mode is getting changed to synchronous ( i checked in moni ) and the data base is sending the response. I have checked service interfaces, both are asynchronous. and in sender cc , QOS is exactly once. I am not sure why the interface is turning into synchronous .
When i am testing this from Integration engine, i am not getting any response from database and so it is successful in moni. We dnt find any issues
Can we use the same database as sender and recievr. Is that the issue? please help
Thanks,
Hi,
your described scenario should work in the expected way. We have an similar scenario: JDBC sender - JNDI Lookup - JDBC receiver (same database). Scenario is running asynch.
Please try to active your sender channel again. I assume, that somehow the sender channel is running with best effort.
According to SAP help:
Response documents can
only be evaluated by the Integration Server/PCK if the call is synchronous
because the content of the response document is not accessible if the call is
asynchronous.
The response is put in
a separate element <StatementName_response> for each statement element.
The structure of the
response documents is contained in the descriptions of the
statements.
Therefore the error should be created by the sender channel QOS setting.
Kind regards,
Tobi.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi all,
we have deleted the configuration objects and recreated. Its working now.
Thank you all for the replies.
Regards,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi all,
I have thousands of transactions running through these systems in a day. Does my choice of jdbc and rfc lookup arise any performance issues? Is it better to go for soap adapter at sender side. Please suggest.
Thnaks,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
if you do a lot of RFC lookups, this can be a performance issue. You have to make some tests, wether the lookups are too slowly in your case.
I had an interface, where single lookups where too slowly. In this case I made a lookup of the complete data and saved it temporary in a hashtable.
Kind regards,
Tobi.
Please check in communication channel sender Jdbc whether you configured bean modules such as requestresponse bean and onewayresponse bean on the module tab to make it to work as async to sync pattern. If so take out those changes. Also try to cache refresh of your id objects. RFC lookups does not necessary to cause performance issues. Again based on how much data lookup you go through during the mapping call. Ofcourse soap adapter can provide better performance than jdbc. We have tons of jdbc scenarios that work without issues running every day.
Hi,
I have collected the necessary informations:
Kind regards,
Tobi.
Hi,
You are getting the response message since the requesting message is making synchronous call to the database. Check you outbound & inbound Service interface, they should not be synchronous.
Also make sure the QOS in the sender system is maintianed as Exactly once & not the best effort.
alternatively Try to change/recreate the service interfaces & sender communication channels.
Hope this would help to sort out the issue
Regards,
Ashish
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
76 | |
9 | |
8 | |
7 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.