Hello dear friends,
I would like to hear your thoughts about my conversion with sap support about the BAPIs internal buffers.
I have opened an OSS because of a BUG that came up from an uncleaned internal data of a BAPI buffer,
after long correspondence, that was the final solution the was suggested:
Dear customer,
First of all I would like to apologize the long processing time of
this message. Your message has been forwarded to the Development
Support of EAM. Your issue describes the deliberate behavior of our
standard solution.
If you are using a sequence of BAPI such in your case BAPI
BAPI_ALM_NOTIF_CLOSE _CREATE immediately afterwards without a roll
area change it can happen, that variables or data remain and data are
posted incorrectly. In your case all BAPIs use one roll area and no
initialization will be done. If you are using these BAPIs in a
sequence you have to call them in its own internal roll area for
refreshing the internal global tables and memory. Notes 770626, 750606
are explain this technically design restrictions about using of the
BAPIs.
Generally, when calling multiple instances of the BAPI ensure that the
following points are observed.
- call each BAPI additionally with DESTINATION 'NONE'
- call after each BAPI function module 'BAPI_TRANSACTION_COMMIT' with
DESTINATION 'NONE' and EXPORT-Parameter WAIT = 'X'
- Call function 'RFC_CONNECTION_CLOSE' to refresh LUW
This is most simply achieved by calling the BAPI in destination
'NONE'. If the order is processed (commit work was deducted), the
destination must be closed again.
It has to look as follows (or similar):
Example:
CALL FUNCTION 'BAPI_ALM_NOTIF_CLOSE
DESTINATION 'NONE'
EXPORTING
.....
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
DESTINATION 'NONE'
EXPORTING
WAIT = 'X'.
CALL FUNCTION 'RFC_CONNECTION_CLOSE'
EXPORTING
DESTINATION = 'NONE'
EXCEPTIONS
DESTINATION_NOT_OPEN = 1
OTHERS = 2 .
I hope that this answer explains some additional questions and helps
to solve your issue.
Thank you for your understanding and cooperation.
Best regards
*******
SAY WHAT......?![]()
![]()
That's the answer I replayed:
Hello *****,
Thank you for the detailed answer.
I bet this solution will work - but it seems to be a very sloppy
solution that I would like to avoid from.
I have the understanding of the architecture of BAPIs so I understand the
need of saving internal data in the roll area even after the bapi ends.
But I also know that according to the BAPI architecture -
every BAPI need to subscribe "Clean up functions" that will be called by the function
BAPI_REFRESH_ALL that is executed every time BAPI_TRANSACTION_COMMIT is
executed.
The all role of those "clean up functions" is to clean ALL the data that
was globally stored in the function group at the current roll area and was
needed for 2 main reasons:
1)Update the DB only when the sap commit is executed (it will be a bummer
if the data will be committed by a DB-COMMIT that happens all the time) -
its done mostly by using the ON COMMIT event (instead of using UPDATE TASKS).
2)For some bapis, in order to enable transactions that consists of
couple bapis calls for the same object (in one commit).
However, after a sap commit-work was executed - I don't see a reason not to
clean all the internal buffers of the BAPIS in the SAME area roll.
They are definitely no longer needed since all the data is already in the database.
The idea of repeatedly opening and closing RFC connections is:
(1)have its performance impact.
(2)seems to be just the easy way and allegorized to put the head in the sand.
Thanks for the treatment,
Bar
Am I wrong? is there something that I missing?
would like to hear your thoughts 