In this blog I want to give an overview about how FPM supports work protection.
The basic requirement for work protection is very simple: Whenever the application contains unsaved data (‘is dirty’) and the user is about to leave the application present him a data-loss popup.
So although this seems to be a rather easy requirement, there is some complexity involved. This is due to the fact that 3 parties have to interact: The shell (portal or NWBC), FPM and the business logic.
Basically there are 2 reasons why an application might be dirty:
- The user entered some data on the screen but did not trigger a roundtrip. This data is then only available on the client but not in the backend.
- The user is leaving the application after having maintained a lot of data, but did not save it. In this case the backend knows all the data, because there have been several round-trips before. Nevertheless if the application is left then the data is lost as it is not getting persisted.
Client-Side Work Protect Mode
The client side work protect mode is a feature of the shell. This means it only works when the application is running in the SAP Portal or in Netweaver Business Client (NWBC). It’s quite simple: With any user interaction the dirty state is set to true and stays at this value until the next roundtrip is started. Then the control is passed to the backend and the dirty state is cleared again.
The problem here is, that there is no generic way to decide whether or not a user considers his interaction to be worth to be protected. As a consequence this type of work protection might result in unnecessary data-loss popups (one example: The user changes an entry in a drop-down list box – now it depends completely on the scenario whether this change should be work-protected or not).
In FPM the client-side work protect mode is active by default. Note 1801019 explains how to switch it off.
Backend Work Protect Mode
On the backend side the business logic has to decide whether or not the application is dirty. Normally the application’s state is set to dirty whenever the first changed data is flushed to the backend. And it is getting cleared only after the user is pressing the “Save” button (or any other interaction triggering a save).
To achieve this FPM is offering the interfaces IF_FPM_WORK_PROTECTION. There is a Web Dynpro Interface as well as an ABAP OO interface. The Web Dynpro Interface is meant to be implemented by freestyle UIBBs, Transaction Handlers or Application-specific Configuration Controller (AppCCs). The ABAP OO interface should be implemented by all relevant feeder classes.
The main method of these interfaces is called IS_DIRTY. Now during the FPM event loop on every involved component implementing IF_FPM_WORK_PROTECTION this method is called. And if at least one of them is returning true, the application’s state is set to dirty. This results in a data-loss popup when the user tries to leave the application.
Now there is one important thing: This dirty state get’s automatically cleared with the next roundtrip. So if during the next roundtrip all involved IF_FPM_WORK_PROTECTION entities are returning IS_DIRTY to be false, then there will be no data-loss popup. This implies that the involved components have to keep track of their dirty state by themselves. If they received changed data in a first roundtrip they have to return IS_DIRTY = X as long as the data isn’t persisted.
Why are there sometimes data-loss dialogs although no data was changed?
In general the FPM work protect mode is very reliable and you will always and only get data-loss popups when there is unsaved data. Nevertheless (especially when note 2155892 is in your system) you might get unexpected data-loss popups.
There are 2 reasons for that:
- The application bypasses FPM. This often happens when non-FPM components are embedded in freestyle UIBBs (e.g. there are a lot of POWLs integrated in this way). While the user interacts with this embedded component there are server roundtrips clearing the Client-Side Work Protect Mode, but the FPM isn’t informed about this. So the Backend Work Protect Mode will not work and FPM doesn’t know whether the application is dirty or not.
Since note 2155892 we are always assuming that the application is dirty in such situations.
- For some interactions (like filtering or sorting of table data) it’s not a-priori clear if this should be considered as data changes or not. Again we chose the defensive approach to bring up a data-loss popup then, but to treat it like pure client-side interaction. So these data-loss popups will only occur when client-side work protect mode is active
If you want your application to support work protection you have to
- do nothing for client-side work protect mode
- for backend work protection: implement IF_FPM_WORK_PROTECTION in those of your application’s components or feeder classes, which are responsible for the changed data