topic Re: Update before rollback in Application Development and Automation Discussions

Update before rollback

Former Member — Fri, 25 Sep 2009 09:44:51 GMT

Hi all,

how can I save some data in a Z table before rolling back a transaction?

the order is something like this:

transaction start

do something

update, modify etc

...

error

update ZTABLE

rollback.

end of transaction.

obviously in the order mentioned also the update of ZTABLE will be rolled back, my need is to save it and roll back everything else.

thanks

Stefano Cattaneo

Re: Update before rollback

rvinod1982 — Fri, 25 Sep 2009 10:05:43 GMT

Hi Stefano,

Check the value of sy-subrc when you are updating your primary table. If sys-subrc ne 0, then you update the ZTABLE.

Regards,

Vinod

Re: Update before rollback

Former Member — Fri, 25 Sep 2009 10:18:30 GMT

Hi Vinod,

the problem is that I'm working on a FM called from a standard program.

The standard program make some update (without commit) and after this calls my FM.

In my function module I make some checks and if necessary, i raise an error.

The error cause the standard program to rollback everything.

What I want to do is to change a Ztable before raising the error. The problem is that I cannot make a commit work at this point to prevent that all the changes previously made will also be commited. I can't neither make a rollback because I'm not supposed to control the rollback event in my function module. What I'm looking for is a way to manage my update in a different LUW or to postpone my update after the rollback.

Thanks

Stefano

Re: Update before rollback

Former Member — Fri, 25 Sep 2009 12:03:17 GMT

Hi ,

If error then you update variable as lv_error = 'Y' rollback.

After rollback you can check the lv_error = 'Y' then update your Ztable. I hope you must be storing required information to update

ztable in an internal table.

Re: Update before rollback

Former Member — Fri, 25 Sep 2009 12:18:39 GMT

Hi Narajan,

I can't insert any code after rollback since there are no exit after that.

I tried to use perform on rollback but I can't insert a commit inside of it.

any other suggestion?

Re: Update before rollback

ThomasZloch — Fri, 25 Sep 2009 12:22:13 GMT

Maybe you could register a routine in your FM with PERFORM ... ON ROLLBACK, in which this update is done. However you cannot do a COMMIT WORK inside such a registered routine, so not sure if this works.

Is there another enhancement point (or similar) after the rollback in the standard program? If yes, you could store some data in ABAP memory in your first FM which you could read in a second FM and update your table accordingly.

Thomas

Edit: sorry, all obsolete after reading your last reply...

Re: Update before rollback

Clemenss — Fri, 25 Sep 2009 23:31:55 GMT

Hi Stefano,

create a small function to do the Z-table update, make it RFC - callable and call it with addition 'DESTINATION 'NONE'.

This starts a new task and the update in the new task can only be rolled back in the new task making it independent of the calling task - that may be rolled back.

Regards,

Clemens

Re: Update before rollback

Former Member — Sat, 26 Sep 2009 05:58:10 GMT

Hi Clemens,

i have the same problem, so i hope it is OK when i join this thread.

Tthe ABAP-documention says, that the synchronous RFC triggers a database commit in the calling program:

[http://help.sap.com/abapdocu_70/en/ABAPCALL_FUNCTION_DESTINATION.htm]

How is it possbile to do it in a separate LUW without calling a COMMIT WORK?

The addition KEEPING LOGICAL UNIT OF WORK is unfortunetaly not allowed to use...

[http://help.sap.com/abapdocu_70/en/ABAPCALL_FUNCTION_DESTINATION_INT.htm]

Many greetings,

Stefan

Re: Update before rollback

former_member194669 — Sat, 26 Sep 2009 06:23:10 GMT

You may need to use

CALL FUNCTION - STARTING NEW TASK

http://help.sap.com/saphelp_nw04/helpdata/en/3d/a846df17c1014e928626637ab06838/content.htm

a®

Re: Update before rollback

Former Member — Sat, 26 Sep 2009 07:51:52 GMT

Hi a®s,

thanks, however this will call the FM as an asynchronous RFC and trigger a database commit in the calling program, too.

See the SAP ABAP-Keyword Documention under Notes:

I think it's not so easy.

Many greetings,

Stefan

Re: Update before rollback

Clemenss — Sat, 26 Sep 2009 11:00:15 GMT

Hi all,

oh yes - any RFC call (including starting new task and destination NONE) will trigger an implicit database commit.

The only way will be to put all database operations into a PERFORM ON COMMIT or write a function and call it IN UPDATE TASK. Those will be triggered only by explicit COMMIT WORK (or call of function BAPI_TRANSACTION_COMMIT).

"An SAP LUW that is not closed by COMMIT WORK, but instead by ending the current program or closing the internal session, has no effect on the registered procedures. Registered update function modules remain on the database but can no longer be executed." ([ABAP Keyword Documentation u2192 ABAP - Reference u2192 Processing External Data u2192 Data Consistency u2192 SAP LUW u2192 COMMIT WORK|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm])

Regards,

Clemens

Re: Update before rollback

Former Member — Sat, 26 Sep 2009 13:41:01 GMT

Has anybody experience with the Background Remote Function Calls bgRFC ?

In the [ABAP documentation|http://help.sap.com/abapdocu_70/en/ABAPCALL_FUNCTION_BACKGROUND_UNIT.htm] for bgRFC they say:

--- begin of copy & paste -

- If, within the same SAP LUW, bgRFC units and also updates are executed, the bgRFC units are dependent on the update. Only after the update has been processed can the linked bgRFC also be processed. When an incorrect update record is deleted, the corresponding bgRFC units are also deleted. The linkage of bgRFC with the update can be removed with the interface method IF_BGRFC_UNIT~SEPARATE_FROM_UPDATE_TASK of the bgRFC object.

- Dialog module registered bgRFCs that were not started there using COMMIT WORK are not executed by the COMMIT WORK of the caller either.

- The statements COMMIT WORK and ROLLBACK WORK may not be executed in a unit. In addition, no implicit database commit may be triggered there.

---- end of copy & paste -

This sounds for me, that some LUW-Units can linked together and proceeded separately ?!

Many greetings,

Stefan

Re: Update before rollback

Former Member — Sun, 27 Sep 2009 13:02:25 GMT

after update command..u do commit work...

and then use other statements..

and after that rollback work...

thanks and regards

Dhruv

Re: Update before rollback

Former Member — Sun, 27 Sep 2009 19:48:03 GMT

Why not write it to a log file before the rollback?

Cheers,

Julius

Re: Update before rollback

Former Member — Mon, 28 Sep 2009 08:01:55 GMT

Hi all,

I work-around my problem using a rollback followed by the update and the commit, after this the main program continue its operations...

Anyway I'm still looking for a better solution. The way suggested by Stefan Gerschler is the same I'm trying to follow. So the question is if it's possible to start a new LUW without closing the current one?

Thanks for replying.

Stefano

Re: Update before rollback

Former Member — Mon, 28 Sep 2009 08:04:32 GMT


> Why not write it to a log file before the rollback?
> 
> Cheers,
> Julius

Hi Julius,

your solution is a nice work-around that I considered but, as stated in the previous message, I choose a different one. Now I still looking for "the" solution.

Thanks.

Stefano

Re: Update before rollback

rainer_hbenthal — Mon, 28 Sep 2009 08:09:36 GMT

update the ztable after rollback.

Re: Update before rollback

Former Member — Mon, 28 Sep 2009 08:24:38 GMT


> update the ztable after rollback.

Hi Rainer,

as stated in previous messages working after standard rollback is not an option since there are no exit point.

thanks,

Stefano

Re: Update before rollback

Former Member — Mon, 28 Sep 2009 14:12:25 GMT

As a variant of the internal DESTINATION 'NONE' suggestion, you could try an R/3 connection. Create a remote enabled FM and update your ztable in the FM. If you save the logon data (which you don't have to within the same system) then take the sy-uname with as a parameter together with the other data.

A bit ugly, but might work for your requirement purposes.

Cheers,

Julius

Re: Update before rollback

Former Member — Thu, 26 Nov 2009 15:17:17 GMT

Hello,

This thread is a bit oldish but I would like to stir a little bit here...

At the first sight, it appears that the point is to break the consistency of a transaction - save some data to DB while not saving others. With regards to the fact that most developers try to stick to the ACID principle rather than break it, the task looks interesting and hard to be justified.

But on a second thought, the problem seems to me a bid to narrowly defined to me. Why have the data been put in any kind of persistency layer at all in the first place? Why the need to call the rollback?

E.g., there is a TEST switch in most BAPIs allowing to mock the processing of the data without running into risk that anything is going to be saved to DB upon commit.

All the checks and error handling should be done in the application layer rather than the DB one, shouldn't they?

Maybe the design of the solution needs some reengineering?

Kind regards

Wiktor Nyckowski