Questions on Syncrhonize Message Scenario

[amelia_li3]

We had a scenario set up for Syncrhonize Message between SAP  and  3rd Party System using ABAP Proxy and JDBC Adapter. I did couple test and really want to understand more thoroughly on this.  The message is collected from 3rd Party database by JDBC adapter then sending to SAP ECC by Proxy to process, a response message will generated and send back to 3rd Party Database through JDBC adapter.

1. On JDBC Adapter Polling Communication Channel: Both select and update statement need to be configured, at what timing the update statement will be triggered.

   The select statement is like: select  * from <table> where upd_flag is null and the update statement is like: update <table>  set UPD_FLAG = 'X' where upd_flag is null

   I did a test, if the HTTP connection from PI to SAP ECC is broken or time out, the message failed and Update statement will not be triggered. This cause the following database polling to collect the failed record ( not marked yet) and reprocess it.

2. Because of above test, I have a concern, if the process in ABAP Proxy is long enough, and when Update statement is triggered eventually, it may overwrite new records inserted into the <table> not yet polled and processed.

Let's say, record 1 being polled and passed to SAP ECC for process, meantime record 2 got inserted into <table>, by the time the Update statement is triggered, both record 1 and record 2 got updated with UPD_FLAG = 'X', the next polling will ignore record 2 which never be processed.

3. What is the communication setting between SAP ECC to PI Proxy, I believe is the SAP ECC IE configure, but I changed the central engine address to a faked one, but the response message still delivered successfully.

Anybody can help me on this, or anyone had the same type of issue before.  Your response is very appreciated.

[baskar_gopalakrishnan2 · Accepted solution]

Points to be rememebered.

a) Your sender system is JDBC. This will not support syncrhonous. So you have to design async sync pattern without bpm or with bpm

b) If you need to do without bpm, you might want to try using requestrespone bean and one way respone bean module.

c)

>On JDBC Adapter Polling Communication Channel: Both select and update statement need to be configured, at what timing the update statement will be triggered.

Jdbc adapter does update after finishing the select query. After successful select and updates, the mesg will be routed to integration engine to reach target system. In your case proxy server.  Since the sender adapter uses the single thread which locks the source database and does both select and update sequentially, you should not have this issue. I have few jdbc sender interfaces and did not face any  synch data issue so far.

d) You have to search sdn to see the configuration setting between ECC and Pi for the proxy.

You will create proxy adapter for the receiver. 

You might want to check this link for proxy configuration settings

Have you seen this wiki?

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e0ac1a33-debf-2c10-45bf-fb19f6e15...

Message was edited by: Baskar Gopalakrishnan

[amelia_li3 · Accepted solution]

For point 1, Yes, Basker, you are right. We did use responsebean to by pass BPM usage.

For point 2, Based on my test, if the message failed on delivering the select results to destination party, it will not trigger the update statement to change the flag. And this being proved several times in our case.  I would assume JDBC Adapter should update after select, but in reality this is not how it works when the QoS is set up as BE for Synchronize Message.

I will take a look into the link for proxy configuration, I tried to to change all possible RFC connection, SLD, and central engine setting, so far, not possible to block the response message sending back from SAP ECC to PI.

Thanks

[baskar_gopalakrishnan2 · Accepted solution]

>I would assume JDBC Adapter should update after select, but in reality this is not how it works when the QoS is set up as BE for Synchronize Message.

Your sender system is async mode. your QOS is EO only not BE.  The response from proxy is again configured to another jdbc receiver.

[MichalKrawczyk · Accepted solution]

hi Amelia,

have you set the isolation level to repeatable_read or serializable ?

Regards,

Michal Krawczyk

[baskar_gopalakrishnan2 · Accepted solution]

If you need more help on transaction isolation level, please refer the sap help link on this

http://help.sap.com/saphelp_nw70ehp2/Helpdata/EN/b0/676b3c255b1475e10000000a114084/content.htm

refer transaction isolation topic. 

[amelia_li3 · Accepted solution]

I was not the one who original designed this. The Sender JDBC Adapter's QoS is BE. Is this wrong, if yes, why PI allow to use BE?  Also, anything wrong with the Sender configuration below?

Sender JDBC Adapter

Receiver JDBC Adapter

[MichalKrawczyk · Accepted solution]

Hi,

1. change the quality of service to Exactly Once

>>>if yes, why PI allow to use BE

File adapter also allows BE but it does not support it

Regards,

Michal Krawczyk

[baskar_gopalakrishnan2 · Accepted solution]

From your screenshot

1) QOS to EO

2) choose strongest isolation level (if you have data synch issues)

3) You can also choose disconnect database for every processed message. This might helps database connection pool garbage issues during high volume message handling.

[amelia_li3 · Accepted solution]

Changed QoS = Exactly Once, interesting things happened.

If I break the Proxy link from PI to SAP ECC (fake the HTTP RFC connection), the record being retrieved by JDBC Adapter not get updated and there will be multiple response message created because of failure. Until I recover the connection to let the message get into the destinatio party, the flag on the record got updated.

So, even though QoS change made the delivery behavior a little bit different, it did not change the DB update which is the biggest concern.

Can you please help me verify the ResponseBean configure is correct?

Module on Sender JDBC Adapter:

1 AF_Modules/RequestResponseBean Local Enterprise Bean    1  / Parameter  passThrough = true

2 CallSAPAdapter Local Enterprise Bean 2

3 AF_Modules/RequestResponseBean Local Enterprise Bean 3 / Parameter receiverChannel, receiverParty, receiverService correctly set up

Thanks

[baskar_gopalakrishnan2 · Accepted solution]

There is a mistake on the third step. You need to reference ResponseOnewaybean.

Check this link

http://wiki.sdn.sap.com/wiki/display/XI/Using+Request+Response+Bean+Module+in+FILE+Adapter

[amelia_li3 · Accepted solution]

The 3rd step is OK and completely match with the Wiki.  

Just the update timing is not as assumed bundled together with Select. This happends in both JDBC Adapter for SQL and JDBC Adapter for DB2.

Thanks.

[amelia_li3]

I found SAP OSS Note 831162. It explains how the Sender JDBC Adapter works, the Select and Update statement are paired in one DB transaction, but if message processing timeout as addressed in another OSS Note 1500791, all DB update will rollback. The following poll will retrieve all unprocessed message again include the messages sent but timed out which in design may not be a bad thing.

If we did not experience the processing timeout because of system disruption, I would not notice this. And based on my test, EO and BE do behave quite differently on message creation but on DB update they are the same.

Thanks for all the replies I got, I will close this question.

[Former Member]

We have a Database to BAPI scenario and we are using the JDBC sender communication channel  with the Best Effort .

We are mapping a Synchronous OB interface to BAPI IB interface.

OB interface has Select structure as the output MT, Update structure as the input MT.

Request -  Select result-set to BAPI request message mapping

Response - Bapi response to Update statement to DB (using Key)

Create another JDBC channel of type receiver .

Add the bean ResponseOnewayBean on the module of the sender JDBC and set the parameter name 'receiverChannel'  value to that of the receiver jdbc channel .

Seem to be working fine .