Bapi call in abap proxy reaching dialog timeout in async scenario

[Former Member]

Hi all,

We have an XI interface to create sales orders. Legacy app sends a soap message async to XI with a group of orders. XI sends this group of orders to an Abap proxy async on ECC side. Into this Abap proxy we have a loop to process each order received in the group with BAPI_SALESORDER_CREATEFROMDAT2. Ending the loop, abap proxy start another async process to send the response to XI with an outbound abap proxy, and the response is redirected by XI to Legacy app.

The problem is, this group of orders can have two or two thousand orders... so, the async process guarantee that no timeout limit will be reached. This is working for the whole process. But when this BAPI is creating an order, the time out of BAPIs execution seems to be the same as the timeout of dialog processes (now set to 10 minutes). This is our problem. Some orders spend more than 10 minutes to process (orders with five hundreds items, for example)... when this occurs, BAPI throws a time out reached error and the async process stops on the inbound queue with status sysfail.

We are now trying to understand why this timeout is been triggered by the BAPI. As it is running into an Async process, it should execute without any kind of timeout limits...

If anybody has any idea, please, help us.

Thank you.

regards.

roberti

[Former Member · Accepted solution]

Hi Waldemar,

The user that you have set in the SM59 destination to the ECC may be a dialog user, that's why it is taking the default time-out of a dialog process.

Maybe you can try using a service user instead of dialog user.

Regards,

Puloma

[Former Member · Accepted solution]

Thanks for your prompt response,

The user we are currently using in this connection is already typed as "service" user on XI and ECC side...

any other tip?

regards.

roberti.

[Former Member · Accepted solution]

May be I was not so clear... the total spent time in the process can be many many hours, days, etc... no timeout is reached. I can post 10.000 orders, no timeout is reached. The problem is that if the processing of only one order with BAPI_SALESORDER_CREATEFROMDAT2 takes longer than 10 minutes, then the timeout is reached. This is the strange part. The processing of the bapi seems to get the same timeout of dialog processes, we already tested increasing the dialog process timeout and the timeout of bapi execution was the same...

We already monitor on SE66 to see if it opens a dialog process to execute the bapi call function, but it does not.

If anyone has any tip, please, provide us.

Thanks!

roberti

[henrique_pinto · Accepted solution]

Hi Waldemar,

what about executing this BAPI in background process?

Call function XXXX in background task

Regards,

Henrique.

[SudhirT · Accepted solution]

the reason for time out is the dialogue process timeout either increse this limit to say many hrs or use background dialogue work process if possible.

thanks.

[Former Member · Accepted solution]

Hi Henrique,

It was already done. We tryied to run in background, in update task, in new task... all these kind of workarounds we know. No success.

Sudhir,

We know that increasing the dialog timeout it would be better, but then we will have other kind of problems on the whole system. The key is: why the bapi execution goes in dialog mode? the program is already running in background, all function calls should be executed in the same context... why this does not occur with this bapi call?

regards.

roberti

[Former Member · Accepted solution]

Hi Roberti

As per my understanding BAPI is always an RFC call to SAP system which is running in dialog workprocess. So if your BAPI can run within the limitation of dialog workprocess maximum time ( in most of the system 20 mins) there will be no issue. But yes it will occupy one dialog process .

So we need to see how long does the BAPI runs and at what frequency . 10000 lines of data not necessarily take long runtime if the BAPI itself is highly optimized but if its not we can think of creating small chunks to satisfy this before executing BAPI.

I think as request and response has been built as Aync we can think in this direction..

Thanks

Gaurav

[Former Member · Accepted solution]

Reviewing my opened questions...

Yes, the problem is the kind of RFC processing. BAPI's are always processed in dialog workprocess, so, nothing to do to solve it. We currently solve the problem redirecting this interface rfc call to an specific server node that has a bigger timeout.

Thanks for all your replies.

cheers!

roberti

[Former Member]

Hello,

Can you register the inbound queue in SMQR transaction for examcple XBTQ*.

Increase the waiting time and try.

Regards,

Sreenivas