Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Committing after BAPI update.

Former Member
0 Kudos

We are running a job in PROD that is taking alot longer than anticipated and will continue to run for the next day.

We are doing a

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

EXPORTING

wait = 'X'.

ENDIF.

After every bapi call, hence every record in the input file.

Does it make sense to commit after every 1000 , if so:

1. How much time would we hope to gain (estimate)

2. what are the rollback issues?

Any ideas

15 REPLIES 15

Former Member
0 Kudos

Should have mentioned . we do the following Rollbakc or commit after every record

IF sy-subrc IS INITIAL.

CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.

RAISE update_failed.

ELSE.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

EXPORTING

wait = 'X'.

ENDIF.

sridhar_k1
Active Contributor
0 Kudos

It's recommended to have BAPI COMMIT after each BAPI call.

Check code in the bapi if it's using update task, if it's there, SET UPDATE TASK LOCAL before the bapi call, it saves some time.

Regards

Sridhar

0 Kudos

before the bapi commit call ?

0 Kudos

No, before the actual BAPI FM call, BTW what bapi is it?

Regards

Sridhar

0 Kudos

CALL FUNCTION 'BAPI_OBJCL_CHANGE'

EXPORTING

objectkey = key

objecttable = c_table

classnum = c_num

classtype = c_type

TABLES

allocvaluesnumnew = it_num

allocvaluescharnew = it_char

allocvaluescurrnew = it_curr

return = it_ret.

0 Kudos

The bapi is not using update task, instead it's using perform on commit, so you must have bapi commit after each bapi call, because, if you commit after certain number of records, only the last one is going to be commited.

Regards

Sridhar

Former Member
0 Kudos

Are you sure that's the bottleneck? Have you checked ST05?

Rob

0 Kudos

No. I am not sure. This cam second hand to me actually. I will have a look at the code.

0 Kudos

THe bottleneck is actually more the db accesses it does prior to the BAPI call. but considering the lookups are required... the only thing I can think of doing is not committing every record to try to speed this up ?

0 Kudos

Why don't you post the code of the database access. There may be issues there as well.

Rob

0 Kudos

The database accesses are so many and cascade into many different function calls that its not feasible to post or analyse at this point. I am looking at another workaround now since I know I cannot move the commit.

thanks for your effort. I would like to know how you tell the BAPI is using PERFORM on COMMIT?

0 Kudos

Here's the chain of FM calls leading to perform on commit: BAPI_OBJCL_CHANGE ->CACL_CLASSIFICATION_SAVE ->CLAP_DDB_SAVE_CLASSIFICATION -> perform insert_classification on commit (line 91).

Regards

Sridhar

0 Kudos

Just checked inside the perform insert_classification tatement, there's an update task. Use SET UPDATE TASK LOCAL before the BAPI_OBJCL_CHANGE call, saves some time.

Yo still need to have bapi commit after the bapi call.

Regards

Sridhar

0 Kudos

thanks.

waht are the implications of adding

SET UPDATE TASK LOCAL before the BAPI call. I read the documentation but not really clear on what it will add.

If I use it, do I need do do the BAPI COMMIT with a WAIT or without . I ask because the docuemtation states (see *)

The update works as before. The only difference is that it is not performed in a separate process, but in the same process as the calling program, i.e. when a COMMIT WORK occurs, processing does not continue until all the update requests have been performed. In the standard setting, the normal update task is always active.

0 Kudos

Commit work an wait, keeps the calling program work process waiting untill all update tasks complte in the update work process.

Set update task local, makes all FM calls in update task to process in the calling program work process instead of update work process.

If a program is executing in background, waiting for update process to finish for each record takes time. SO if there are few table updates, set upd task local executes faster.

I've used this statement without any complications in scenarios like this.

BAPI commit with and without WAIT works the same if set upd task locl is used, but I would use BAPI commit with wait because, some bapis calls multiple commits, which deactivates local update.

Regards

Sridhar