SAP PO BAPI

[former_member309914]

DEAR LADIES AND GENTLEMEN,

I NEED TO CALL THE FOLLOWING BAPI IN BACKGROUND TASK,BUT THEY DON'T WORK,THAT IS TO SAY,THEY AREN'T RUNNING IN THE SAME TRANSACTION, COULD YOU PLEASE TELL ME HOW CAN I DO THAT? THANK YOU.

CALL FUNCTION 'BAPI_PO_RESET_RELEASE' IN BACKGROUND TASK

CALL FUNCTION 'BAPI_PO_CHANGE' IN BACKGROUND TASK

CALL FUNCTION 'BAPI_PO_RELEASE' IN BACKGROUND

IN ADDITION,SO FAR,OTHER BAPIS ARE FINE WITH 'IN BACKGROUND TASK'.

[former_member309914]

DEAR LADIES AND GENTLEMEN,

I NEED TO CALL THE FOLLOWING BAPI IN BACKGROUND TASK,BUT THEY DON'T WORK,THAT IS TO SAY,THEY AREN'T RUNNING IN THE SAME TRANSACTION, COULD YOU PLEASE TELL ME HOW CAN I DO THAT? THANK YOU.

CALL FUNCTION 'BAPI_PO_RESET_RELEASE' IN BACKGROUND TASK

CALL FUNCTION 'BAPI_PO_CHANGE' IN BACKGROUND TASK

CALL FUNCTION 'BAPI_PO_RELEASE' IN BACKGROUND

IN ADDITION,SO FAR,OTHER BAPIS ARE FINE WITH 'IN BACKGROUND TASK'.

[Sandra_Rossi]

What is the actual symptom, the actual issue? (I don't understand "aren't running in the same transaction", because when you run BAPI_TRANSACTION_COMMIT, all three should be started in the same LUW).

NB: please don't write all uppercase, it's considered like shouting.

[former_member309914]

normally, like you say,bapis of 'in background task' will be in the same luw,and all of them should either succeed or fail,but above three bapis can not, specially, supposing success of first bapi and failure of any back bapi,it doesn't rollback the update of first bapi, more to the point, there is a 'commit work' inside the bapi 'bapi_po_reset_release',so,can i bundle them into a single luw?

as for debug,you can use the simplest data,thank you.

[Sandra_Rossi]

Please write a "comment" instead of an "answer". As SAP says (cf text beside "Your answer" input field):

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem.

[Sandra_Rossi]

That's really a problem if, as you say, "there is a 'commit work' inside BAPI_PO_RESET_RELEASE", because you can't rollback the database updates if you need to... If you want to change this behavior, it requires a modification of the standard... I don't see any other solution. Or you should implement a custom recovery system to identify which updates have failed, to analyze and correct manually the errors, etc.

[former_member309914]

normally, like you say,bapis of 'in background task' will be in the same luw,and all of them should either succeed or fail,but above three bapis can not, specially, supposing success of first bapi and failure of any back bapi,it doesn't rollback the update of first bapi, more to the point, there is a 'commit work' inside the bapi 'bapi_po_reset_release',so,can i bundle them into a single luw?

as for debug,you can use the simplest data,thank you.

[Former Member]

..........

[Jelena_Perfiljeva]

Sorry but (1) is not a good suggestion. In general, it is not recommended copying SAP code. An explicit enhancement, while not a great idea either, would be a better option. In this case though there is most likely a good reason why it works the way it works, so simply removing COMMIT very likely won't solve anything.

Edit: for the record, the answer was edited after the comment was posted.

[gayathri_jayajeevan2]

If you analyse the code of the BAPI BAPI_PO_RESET_RELEASE, you may be able to strip out of what logic you need to put into your code part.

The main FM used in BAPI is ME_REL_RESE. Though I haven't looked into it, it looks like it returns the fields on EKKO which need to be changed as a result of the reset, and doesn't look like it commits to the database.

Suggest you give ME_REL_RESET a try.

[Jelena_Perfiljeva]

I can't know for sure what was SAP's design here (was unable to find any SAP Notes on this and FM documentation doesn't explain it either) but I recon there is a good reason why BAPI_PO_RESET_RELEASE comes with COMMIT.

It's quite possible that this particular operation must be completed before anything else can be started. This is true for many cancellation type tasks. I bet there is code that is checking in the database what the current PO status is and, if it's released, some business logic is applied. So, unless the PO is "unreleased" for reals, none of the other BAPIs would be able to do anything with it.

That's just my guess but I believe you'll have to work around this in your program.