BAPI_TRANSACTION_COMMIT is too slow

[former_member664593]

Hi there.

I trying to create a client with class

cmd_ei_api=>maintain_bapi

After, I execute

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
      EXPORTING
        wait = 'X'.

When I execute this setence is too slow, but this happens sometimes. Are there any sentence for reduce the runtime?

[FredericGirod]

Check the SM50 transaction, maybe there is a lot of activities in the process UPD.

[former_member664593]

Maybe, but this process always would be working. It's possible make parallel processing like solution?

[FredericGirod]

Your program (in foreground) use a DIA, when it tries to save something it uses the UPD. But if you have few UPD and a lot of request, SAP creates a queue of the requests, qnd you wait.

Your Basis Admin could check this

[Dominik_Tylczynski]

Hi jimmy21

Depending on your scenario consider dropping:

      EXPORTING
        wait = 'X'.

This way data will be updated asynchronously and control will be returned to your application fast, without waiting for data update.

That's way SAP implemented UPD and UP2 processes and asynchronous updates in the first place. Try to take advantage of it.

Best regards

Dominik Tylczynski

[Former Member]

One can encounter the WAIT addition in ABAP coding way more time then necessary. There was a great article about this topic on sapinsider:

"Is It Worth Waiting for the Update Task?

When you pass a space character or an empty string to the Wait parameter, the commit BAPI executes a normal COMMIT WORK and returns control to the client application immediately. In most cases, this is what you want.

When you pass anything else to this parameter (by convention, “X” would be used), the BAPI executes a COMMIT WORK AND WAIT statement (ABAP is a verbose language). This not only causes the Update Task to commence processing the updates written to the Update Log for your session since the last commit or rollback, but it will also wait for the completion of said Update Task and report success or failure in the Return parameter.

Doesn’t that sound great? Is that what you should always use? No! Using COMMIT WORK AND WAIT slows down R/3 and should only be used when there is some justification (and paranoia does not count as justification). You might not trust the asynchronous update mechanism in R/3 and may be tempted to use COMMIT WORK AND WAIT just in case something goes wrong. But resist that temptation. In a normal production system, nothing ever goes wrong in the Update Task. This is not why COMMIT WORK AND WAIT was invented.

Only in This Special Case!
Let me give you a sample scenario in which COMMIT WORK AND WAIT should actually be used:

Your application first creates a new customer and then wants to create a sales order for that customer. It is not possible to commit these two update BAPIs in a single LUW, since the sales-order creation BAPI would come back with an error message saying that the specified customer number is wrong (remember that the application tables are not updated until COMMIT WORK). So you add the customer, commit, and then add the sales order.

In this type of scenario it makes sense to use COMMIT WORK AND WAIT. Otherwise, if you execute the sales-order creation BAPI too quickly after the customer creation, the Update Task might not be done with the changes for the customer creation, and you would get an error message.

In more general terms: only use COMMIT WORK AND WAIT if you execute more than one update BAPI, and a subsequent BAPI relies on the changes of a previous one."

[Dominik_Tylczynski]

Kudos gabmarian spot on comment!

[former_member664593]

Yes, I did it. I tried with wait = ' ' and wait 'X', but I have the same problem.

[Sandra_Rossi]

Do an ABAP trace to understand why it's "slow". What is "slow" from your point of view?

[former_member664593]

This bapi was called from web service, this response with a timeout.

[Sandra_Rossi]

A timeout after how much time? What amount of updates are you doing? What does the ABAP trace says?

[former_member664593]

Timeout occurs after 5 mins, but this happens only any hours' day. I make just a one update. Now service is working fine =/ I can't see trace. You know how can I make to work it always?

Thanks in advance.

[Sandra_Rossi]

Jimmy Arnold Moreno Nuñez I think it's very difficult to make an efficient trace for rare intermittent and non-reproducible issues. Maybe you can use a trace with no side-effect like the ABAP Call Monitor. Anyway, if it's rare, if it's a slow-down of 5 minutes, if you can't reproduce, it's not worth spending time on it.