How to rollback the context if a user chooses cancel on an input form

[Former Member]

Hello,

I created a view with a few input fields in display mode. The input fields are bound to a context node of the view.

When the user chooses button edit he can change the fields. Then he has the choice for saving the data or go back with the cancel button.

Now when he chooses the cancel button the data he changed in the input field stays changed... This is not the goal of a cancel button.... It should go back to the old value.

What is the correct way to build something like this in abap webdynpro?

Thx,

Jeroen

[thomas_jung · Accepted solution]

You shouldn't have to go back to the database, because if you are updating data you should have a transaction lock on the data.

In the end this isn't really so much a web dynpro abap specific question. If you look back at traditional R/3 transactions written in dynpro you will find the same challenge. Most Dynpro transactions read the data from the database one at the beginning of the application after placing their lock. They then store this data twice in memory. For instance in SD you will often find two copies of internal tables - one beginning with a x and one with a y. This way if the user chooses cancel you can restore back the original state from one set of tables. This also is used because of the SAP Change logic. If you generate a change object, then a function module is created. It expects two sets of tables - one with the state at the start of the transaction and one for the state at save. It then creates all the field level change values for you and writes them in CDHDR and CDPOS.

[Former Member · Accepted solution]

Thomas,

You're absolutely right, I didn't think that way. Indeed, the classic dynpro works the same way.

The interesting thing is that there is a context log available in webdynpro.

Is it something you would recommend?

Is it normal that the context log gets cleared/refreshed when an error message is raised via the message manager?

I tried it on SP10, maybe it's fixed by now or maybe there is a good reason in the design to clear it (but can't think of one...)

Jeroen.

[thomas_jung · Accepted solution]

I've not used the context log in such a way. Perhaps I am being to academic in my approach, but I prefer a cleaner separation along the Model View Controller lines. To me the context is too closely associated to the View and Controller to be used from an activity like this - that to me should be part of the Model or Business Logic. That fact coupled with the ability to resue the dual internal table approach within the Change Object Log is what pushes me in this direction.

[former_member515618]

Jeroen,

To maintain the data consistency, it is ideal to hit the data base for the selected record and refresh the screen fields. This would reduce complexities.

Now that the fields are bound to the context node attributes, when data is changes the context is automatially changed. So it would hold the current data. So another way is to take a backup copy of the values when screen is rendered and repopulate the same when user opts for a cancle or doesnt want to save the data.

Programatically, the preferred way it to hit the data base table.

Regards,

Sravan Varagani

[Former Member]

Hello,

Thanks for your comments. I tried the context change log and this works fine but has a few gaps, for instance when I push the save button and an error was thrown the context log discards the changes until that moment.

Can you please add an example how I can copy the context node to a 'backup' node.

Beside this what is the best practice to save or discard changes for input fields?

1. Reselect database -> ok if not much data is needed

2. copy context node to backup node

3. use context binding not directly linked to context of component controller like Aditya proposed

-->> Aditya can you add example code for mapping please? thx

4. use context change log

5. Use validate, invalidate options, does it exist?

Jeroen.

[former_member515618]

Hi Jeroen,

Data accuracy is primary requisite, then comes the performance tuning or code optimizations.

If Context log ensures both then it is the prefered one but i suppose there are some open issues in it. There is no control on the way the context logs are refreshed. So to be on a safer side and also for maintanance purpose it is ideal that we hit the data base and refresh the context node provided the data is less.

If data is more, then before rendering into the view take a back up into an internal table and refresh the nodes when cancled. Here we have an over head of updating the internal table if the save is succesfull.

Regards,

Sravan Varagani

[Former Member]

Dear Jeroen,

One solution to your problem is to have 2 seperate controller nodes :

1. 1st( N1 ) is directly bound to your screen.(cardinality 0..n)

2. 2nd ( N2 ) that send data from/to database to/from 1st Node(i.e. N1). ( cardinality 0..1)

3.initially u can get data from N1 and map it to N2 (screen).

After Editing,

1. if u press save --> map data from N2 to N1.

2.if u press calcel--> follow step 3.

is this clear....?

ANother solution to your problem could be found in the following link....(Though i havn't trie d it yet....

[http://help.sap.com/saphelp_nw2004s/helpdata/en/ae/f95e42ff93c153e10000000a1550b0/content.htm]

Regards ,

Aditya