Multiple sessions in R/3 generated by RFC adapter for the same message in PI during synchronous communication

[Former Member]

Hi,

During a synchronous call from FileàRFC in SAP R/3, the RFC throws some of the following locking errors:

E, 022, The group data for the material 00309157241 is locked by MDMREMOTE;

E-031-Characteristic Characteristic SHADECODE is being processed by MDM is bein;

The RFC is a wrapper RFC that internally makes nearly 10 calls to different RFCs based on conditions. This scenario was configured to eliminate ccBPM in PI within which 10 different calls to RFCs were handled synchronously. Since then, we have been facing more problems with data being locked or used or blocked by the same user that PI uses to log in to R/3 during an RFC call.

These locking errors are not thrown for all materials but observed for many. Some locking errors have been found even in the processing of other master data using different RFCs when the R/3 server is slow.

Message processing in PI was monitored for such cases.  It was found that, during the synchronous call to RFC in SAP R/3 by PI, if the RFC does not complete/return something in a certain amount of time (2 minutes observed in the audit log of file sender  communication channel), PI opens up another session in R/3 for the same material. Either of these sessions now face the problem of objects being locked, that too by the same user and for the same material. Upto 8 sessions have been seen generated by PI for the same message. The parameters set in the communication channels were checked but did not correspond to the above.

We have been facing this problem in our Production system and it has now become a major issue.

Can someone help to understand as to why this could happen? Is it possible that some parameters or attributes in the PI server  or java engine or the RFC adapter module could be triggering another session?

Regards,

Priyanka S

[Former Member]

does RFCs you are using having table parameter, if you can submit in array this situation can be avoided,

how you have made your file to RFC synchronous (have you used bean/adapter module?)

another option is store all file records in custom table and then execute this RFC in one by one call after getting commit work for each record.

[Former Member]

Hi,

The RFC has many table paramter and we cannot change that.

The scenario has been made synchronous by using module confuguratinos in file sender communication channel where the response for the RFC is directly sent to a SOAP receiver communication channel in another business system. The following module config. is used:

1 AF_Modules/RequestResponseBean

2 CallSapAdapter

3 AF_Modules/ResponseOnewayBean

Currently one file wil contain data for only one material.

The audit log in the FILE sender communication channel is:

Delivery of the message to the application using connection RFC_http://sap.com/xi/XI/System failed, due to: com.sap.aii.af.ra.ms.api.MessageExpiredException: Sync application request expired.. Setting message to status failed.

The message status set to FAIL.

Returning synchronous error message to calling application: com.sap.aii.af.ra.ms.api.MessageExpiredException: Sync application request expired..

The audit log in the RFC receiver communication channel is:

Returning synchronous error notification to calling application: com.sap.aii.af.ra.ms.api.RecoverableException: Received HTTP response code 500 : Timeout.

Transmitting the message using connection http://apaxd:8000/sap/xi/engine?type=entry failed, due to: com.sap.aii.af.ra.ms.api.DeliveryException: Received HTTP response code 500 : Timeout.

The message status set to FAIL.

Returning to application. Exception: com.sap.aii.af.ra.ms.api.DeliveryException: Received HTTP response code 500 : Timeout

Regards,

Priyanka

[Former Member]

Okay, so your issue is ... when PI sending Synch. message to RFC, it is taking long time to execute due to lock and your adapter get Timeout, so your adapter is again trying another session.

for that change the synch timeout setting in your file adapter (parameter in CC) and in NWA  , increase as per your requirement , and it will resolve the issue.

[Former Member]

Hi,

When PI sends a sync. message to RFC, it is taking longer to respond. Since it takes longer, PI creates another session in R/3 for the same message in 2 minutes. Since both these sessions are active for the same materials, either of them face a locking/blocking issue.

I changed the synchTimeout parameter of CallSapAdapter to 3 minutes in the module configurations of the File sender communication channel. It still created a new session after 2 minutes.

Can you please guide where in NWA does this parameter needs to be changed?

Regards,

Priyanka