BUFFER_REFRESH when using "BAPI technology" in SAP event exits

Question

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!

Answer 1

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!