BUFFER_REFRESH when using "BAPI technology" in SAP event exits

[Former Member]

We wrote some custom function modules which are similar to the BAPI technology to maintain custom data tables.

Let's say we have

a function Z_DATA_CREATE,

a function Z_DATA_CHANGE and

a function Z_DATA_READ.

These function modules are RFC functions which can be called from outside SAP and have to reflect the transactional mechanism. That means that the caller can call any of these functions in an arbitrary sequence and has to control the commit or rollback.

E.g.

Step 1 : call function Z_DATA_CREATE

Step 2 : some external logic

Step 3 : call function Z_DATA_CHANGE

Step 4 : call function Z_DATA_CREATE

Step 5 : ...

Step 6 : call function Z_DATA_READ

....

Step X : call function BAPI_TRANSACTION_COMMIT

The data will not be written to the database until the COMMIT statement is called. Therefore all manipulated data are stored in the global memory of the function module in the meanwhile. The functions first check if there is data in the memory (prepared for SAVING) before they check the database tables. Essential for the data integrity in this model is that the memory is being refreshed when the COMMIT or ROLLBACK is fired. With BAPIs this is done by subscribing the delete functions which are called by the BUFFER_REFRESH_ALL function. BUFFER_REFRESH_ALL is called in the BAPI_TRANSACTION_COMMIT or rather BAPI_TRANSACTION_ROLLBACK function. So this works fine.

Now we want to use our function modules (Z_DATA_* ) in user exits of SAP standard processes. For example in event exits (transaction FQEVENTS ). I assume that these SAP programs only fire a COMMIT without calling the BUFFER_REFRESH_ALL .

But we have to ensure that the memory (the global data of the function modules) is being refreshed after a commit.

Do you have any idea how I could do this???

Thanks for your help!

[Former Member]

We wrote some custom function modules which are similar to the BAPI technology to maintain custom data tables.

Let's say we have

a function Z_DATA_CREATE,

a function Z_DATA_CHANGE and

a function Z_DATA_READ.

These function modules are RFC functions which can be called from outside SAP and have to reflect the transactional mechanism. That means that the caller can call any of these functions in an arbitrary sequence and has to control the commit or rollback.

E.g.

Step 1 : call function Z_DATA_CREATE

Step 2 : some external logic

Step 3 : call function Z_DATA_CHANGE

Step 4 : call function Z_DATA_CREATE

Step 5 : ...

Step 6 : call function Z_DATA_READ

....

Step X : call function BAPI_TRANSACTION_COMMIT

The data will not be written to the database until the COMMIT statement is called. Therefore all manipulated data are stored in the global memory of the function module in the meanwhile. The functions first check if there is data in the memory (prepared for SAVING) before they check the database tables. Essential for the data integrity in this model is that the memory is being refreshed when the COMMIT or ROLLBACK is fired. With BAPIs this is done by subscribing the delete functions which are called by the BUFFER_REFRESH_ALL function. BUFFER_REFRESH_ALL is called in the BAPI_TRANSACTION_COMMIT or rather BAPI_TRANSACTION_ROLLBACK function. So this works fine.

Now we want to use our function modules (Z_DATA_* ) in user exits of SAP standard processes. For example in event exits (transaction FQEVENTS ). I assume that these SAP programs only fire a COMMIT without calling the BUFFER_REFRESH_ALL .

But we have to ensure that the memory (the global data of the function modules) is being refreshed after a commit.

Do you have any idea how I could do this???

Thanks for your help!

[Former Member]

Hi Michaela

When a BAPI is called there are function modules called that store info based on the BAPI being called. The BUFFER_REFRESH_ALL fm that you reference refreshes buffers that are registered during a BAPI execution using BUFFER_SUBSCRIBE_FOR_REFRESH. This is done internally within a BAPI. I think you chould create a new fm called Z_DATA_COMMIT in the same function group as your other 3 fm's that will perform the COMMIT explicitly (or with a wait if needed) and refresh internal tables for the function group.

Hope this helps

Andy

[Former Member]

Hi Andrew,

thanks for your answer.

The problem with such a Z_DATA_COMMIT function is that I can't control when the commit is fired in case of the SAP standard programs (dunning, payment ...). There are only the exit events where I can implement own code. And I must not use a COMMIT statement in these events.

The SAP programs itself do the COMMIT.

[Former Member]

Hi Michaela - Here are a few suggestions: 1) instead of a Z_DATA_COMMIT fm then create a Z_DATA_REFRESH which will clear the internal tables - you can call this at any point 2) clear the tables in the Z_DATA_CREATE if that will be the first fm in the series 3) clear the tables at the beginning of each fm by using a flag in the function group to indicate when the clear should occur.

Andy

[Former Member]

Michaela,

There are 2 ways for that .

(1) Call you function modules from inside a form on commit ( perform name on commit). The last function module in this subroutine will be BUFFER_REFRESH_ALL .

(2) Make your function modules as UPDATE MODULE and call it with 'IN UPDATE TASK'. Write a wrapper function module with UPDATE MODULE attribute to enclode BUFFER_REFRESH_ALL and call this function module also in update task.

(3) Ideally, this development should have done using Classes where each instance would be independent of others but a object was available for change in later processes till it was in the memory.

[Former Member]

Thanks Sharad,

your ideas helped me to find a possible solution (at least for the case that I don't use SET UPDATE TASK LOCAL).

I do the buffer refresh in a form which I call on commit (dialog process). As the update task works in a separate context and doe not access the dialog buffer anymore, it doesn't matter when the refresh is called after the COMMIT has been fired.

I'm not sure if your second suggestion would work as you don't have access to the same context data in the update task. Typically the buffer data are in the dialog context which is separated from the data in update task. So the REFRESH must take place during the dialog process.

Thanks a lot for your contribution!