cancel
Showing results for 
Search instead for 
Did you mean: 

Interesting problem

Former Member
0 Kudos

Hi,

I'm facing a really weird problem i.e. I'm calling a ZBAPI in R/3 4.6C from XI through RFC adapter.

My ZBAPI is a wrapper of BAPI_QUOTATION_CREATEFROMDATA.

Deep down BAPI_QUOTATION_CREATEFROMDATA, it contains a call of function RV_SALES_DOCUMENT_ADD IN UPDATE TASK. Therefore, R/3 system inserts a record in table VBMOD so that this function can run in update task & when this function is completed the row from VBMOD is deleted.

All is fine until I call my ZBAPI repeatedly through XI after short intervals i.e. a few seconds. The first call to BAPI results in success but the subsequent call results in error DBIF_RTAB_KEY_ALREADY_EXISTS until I pause for a minute or more & then again first call is success & subsequent are failure.

I used ST05 to drill down into error & came to know that my second call to BAPI was executed when the first entry in VBMOD for function RV_SALES_DOCUMENT_ADD was still there & hence the second call attempted to create a similar record & resulted in duplicate primary key error.

Furthermore, the more I dig it the more I puzzled, because I created a custom Java program using JCO which called the same ZBAPI as XI but there was no error no matter how frequently I called ZBAPI?

In ST05 it is apparent that when XI calls this ZBAPI the system takes a lot more time to run RV_SALES_DOCUMENT_ADD in update task & when the same ZBAPI is called through custom JCO program it runs a lot faster & hence no error.

Any idea?

Hashir Ahmed

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi

Also try to increase --> Maximum Connections

rgds

srini

JoelTrinidade
Active Contributor
0 Kudos

Hi Hashir,

Since you are aware of java and JCO , I can safely assume you have idea of threads and thread priorities . As you explicitly define threads in java . The server / CPU automatically determine the priority of things to be done. Moreover things on the ABAP stack take a little longer then on the java stack. This should not be a major issue as this is the way things are . As long as things work , all is well and fine.

Regards

joel.

Former Member
0 Kudos

Hi Joel,

Thanks for the reply but my problem is still there. The XI scenario is called by a submit button on UI, so can't really tell user to wait for a minute before they click the submit button again. Furthermore, the BAPI is called on ABAP stack, so there should not be any difference in its performance no matter how it was called i.e. from XI or JCO (I think XI adapter also uses JCO for RFC call).

Former Member
0 Kudos

Any body?

Former Member
0 Kudos

It might be the issue with queue in application server.

when you send it through XI/PI , monitor que in XI and R/3 servers, with this also monitor workprocess in application server .

Former Member
0 Kudos

Hi Ahmed,

Your messages are not queued up on the receiving system ERP.

You can change to a proxy write a small code to call your ZBAPI in QRFC. In this way you know each message executes on itself and will have dependency. Every message coming in is queued.

Other is to use the BAPI IDoc QUOTATION_CREATEFROMDATA201. Caution this is not released.

In this way you can better control by Idoc serialization.

For the current setup your ZBAPI should do the queuing..

Best Regards,

Former Member
0 Kudos

Hi everyone!

I've solved the problem by calling BAPI_TRANSACTION_COMMIT in ZBAPI just after BAPI_QUOTATION_CREATEFROMDATA call.

Thanks for all those replied.

Hashir Ahmed