Work Protect Mode - FPM

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 presents
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:
1. 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.
2. 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.
Now in the FPM world there is a complete separation between the frontend-side
rendering (which is done using HTML and javascript) and the backend logic
(implemented in ABAP). As a consequence the backend logic isn't capable of detecting
the client-side dirty state and can only deal with the 2nd point. Therefore we have 2
different work protect mechanisms in FPM: the client-side and the backend work
protect mode.
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 Applicationspecific 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.
Summary
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