Call method on 'commit work'?

[Former Member]

I have a method that I would like to be called when I call 'commit work'. I need the method to be called before the actual commit happens. Is this possible?

I found the event CL_SYSTEM_TRANSACTION_STATE=>TRANSACTION_FINISHED but this seems to be raised when the commit is finished.

Any help would be appreciated!

- Lucas

[Former Member]

Hi

But what do you need to do?

Max

[Former Member]

It's not really relevant to the question I asked...

But I'll tell you anyway... I created a class to wrap function modules in FVD_LOAN_OL to handle conditions on a loan. The function group FVD_LOAN_OL needs you to set your changes to 'checked' and then call a function module to save them. Instead of having a method in my class to do this and calling it every time I use this class (which exposes the implementation details), I would like the method to be called automatically upon 'commit work'.

[Former Member]

Hi

What I didn't understand if you need to trigger something as soon as a COMMIT is raised or as soon as a COMMIT is raised in a particolar program

Max

[Former Member]

Ok, I understand your question now. I'm looking for a generic solution that will be easily reusable. I currently have a method that I call right before my commit statement to set the conditions to checked and save them but I would prefer to have that step included as part of the commit so other developers don't need to remember to call that method.

I would appreciate any input!

[Ruediger_Plantiko]

Idea:

Early, when the LUW of your transaction is started, register a subroutine with PERFORM ON COMMIT.-

[this is one of the reasons where subroutines are still needed, since there is no OO equivalent to PERFORM ON COMMIT]

Subroutines called with PERFORM ON COMMIT are called before the V1 and V2 modules are triggered. And they still have access to the current global data of the function modules and programs.

[Former Member]

Thanks Rüdiger,

I had thought about doing that as well... Just thought someone might know of an event that gets raised that I could register my method as a handler for...

[former_member191569]

Hello Lucas,

if you need to trigger any business logic execution when the program execution reaches a COMMIT WORK, I suggest to use function modules with the addition IN UPDATE TASK. These functions will be flagged for execution but it will execute only after a COMMIT WORK is found.

Hope it helps

[Former Member]

Thanks David for providing an alternative... I was really hoping to stick to the object oriented solution which is why I was hoping to find an appropriate event to register my method as a handler.

Thanks for your input!

[Ruediger_Plantiko]

Either way, you will probably need something non-OO at this place:

• If you need the data of the current dialog process: Work with PERFORM ON COMMIT
• If you don't need those data or can pass everything you need as parameter: Use CALL FUNCTION IN UPDATE TASK.

You can minimize non-OO parts of your code by using the function module or subroutine only as a proxy for calling OO stuff (the function/subroutine could consist of a single method call). In PERFORM ON COMMIT you have the advantage that the formerly created instances are still there.

[former_member191569]

Lucas,

I think that one of the scenarios where ABAP OO does not (still) come to rescue is this.

Actually, as far as I know, you cannot trigger an object method for processing updating stuff when a COMMIT is reached. But I prefer avoiding subroutines (FORMs), which today are absolutely dispensable and is recommendable to avoid them in new developments, and use function modules with the addition IN UPDATE TASK.

Of course you can wrap the function module inside an object method but, in the same way that dynpros and RFCs are not possible in ABAP OO, there must be an underlying FM that offers the functionality.

[Ruediger_Plantiko]

David,

the problem is: With CALL FUNCTION IN UPDATE TASK you don't get the current data of the dialog session. Only with PERFORM ON COMMIT, you are still within the current session, and can work with the data that are in memory (e.g. object instances)

The functionality of CALL FUNCTION IN UPDATE TASK and PERFORM on COMMIT are not exchangeable, they are different!

[former_member186413]

This message was moderated.

[Former Member]

Hi Hai,

This document refers to the same event as I mentioned in my original question. It does not meet my requirements as it is raised after my changes are committed to the database.

Thanks for your input.

[former_member186413]

I think It's easy to bring the full detail of  your program and application to the board. Otherwise, it's really hard to allow  others for pingpointing your problems. In the  point of my view, I don't think you have followed the right steps as the document shown. 

[Former Member]

Hi

I've tried to follow the document and the problem is the method is called after executing the updating routines:

I mean the function module called in UPDATE TASK are executed before the method, so the db will be updated when the system'll run it,

I've tried this simple code:

INITIALIZATION.

   SET HANDLER ZTEST_MAX=>AFTER_COMMIT.

START-OF-SELECTION.

   CALL FUNCTION 'ZTEST_FM' IN UPDATE TASK.

   COMMIT WORK.

After the COMMIT, The fm ZTEST_FM is executed before the method AFTER_COMMIT

Max

[former_member186413]

So , you want the handler method is executed before the ZTEST_FM?!

[Former Member]

Hi

Yes,,,,, I think so

The generic fm ZTEST_FM is like the fm where the DB updating are, I believe Lucas needs to call his method after the COMMIT, but before the fms for updating.

I don't know if it's possible by a solution valid for all transactions (like CL_SYSTEM_TRANSACTION_STATE=>TRANSACTION_FINISHED)

Max

[Former Member]

Hi

I suppose the problem is on the priority of the call, all events called after the COMMIT are placed in a queue, the sorting depends on the kind of the updating of the routine (V1, V2,....), and when the routine (of the same kind) is called: I mean the routine called before will start before.

That mean your method should be the first routine called: I don't know if it's possible to have a generic solution or a specific solution for every program: I mean it needs to check the right point where your called has to be placed.

Max