SAP Web Dynpro ABAP Portal Integration

Web Dynpro ABAP applications can be integrated into the SAP Enterprise portal – that is, they can be bound into a portal navigation as an iView. For a description of the individual steps for integrating a Web Dynpro application, see the chapter Portal Binding: Prerequisites.

The description given in this programming manual for binding a Web Dynpro application into a portal is written for the developers of applications and is suitable for binding individual applications for test purposes. For more detailed information, refer to the appropriate sections in the Portal documentation.

In addition, it is possible to address portal functions from within a Web Dynpro application. For this purpose, you can access portal manager methods (interface IF_WD_PORTAL_INTEGRATION) as source code templates for the different functions by calling up the Web Dynpro Code Wizard. These include:

· Using Portal Events

· Navigation between Web Dynpro applications within the portal or to any other portal content.

The following navigation types are supported:

Objekt...

Object-Based Navigation

Absolute Navigation

Relative Navigation

· Using the WorkProtect mode
Examples

The following examples of Web Dynpro applications for portal integration are available in the package SWDP_TEST in the system:

· WDR_TEST_PORTAL_EVENT_FIRE

Trigger event

· WDR_TEST_PORTAL_EVENT_FIRE2

Trigger free event

· WDR_TEST_PORTAL_EVENT_REC

Receive portal event

· WDR_TEST_PORTAL_EVENT_REC2

Receive free portal event

· WDR_TEST_PORTAL_NAV_OBN

Object-based navigation

· WDR_TEST_PORTAL_NAV_PAGE

Page navigation

· WDR_TEST_PORTAL_WORKPROTECT

Security monitoring

SAP Binding to Portal: Prerequisites Web Dynpro ABAP Portal Integration

To be able to integrate a Web Dynpro application into a portal, the following prerequisites must be met.

● You have your own user in the portal and have a suitable role assigned to your user. Role Content Admin, for example, contains all the required authorizations and tools. This should always be the case; if not, contact your portal administrator.

● The ABAP system in which the application is located must be known to the portal. This should already be the case too. Since a special authorization is required for entering the System Data, also contact your portal administrator to have the ABAP system entered. In the following steps, you will need the system alias of the ABAP system that was assigned by the portal administrator in the portal concerned.

For more information on the different roles and the task areas involved, refer to the chapter Administration Guide for the Portal.

● To test the application afterwards, you also need to have a user in the ABAP system. Using User Assignment, you can link your portal user with the ABAP system user in order to avoid a separate logon when calling the application.

●

Once these technical prerequisites are met, log on to the portal and choose the Content Administration in the initial navigation screen. For a description of the subsequent steps, refer to the document Creating Web Dynpro ABAP iViews.

SAP Creating Web Dynpro ABAP iViews Portal Integration

You create iViews from Web Dynpro ABAP iViews using the SAP Web Dynpro iView template in the iView Wizard.

Although the SAP Web Dynpro iView template also supports Java, you should only use it for Web Dynpro ABAP applications. You create Web Dynpro Java iViews using the Web Dynpro Java application template.

Web Dynpro Java iViews you have created in the past using the SAP Web Dynpro iView template will continue to run.

Procedure

...

1. Start the iView wizard by right-clicking the folder in which you want to create the iView, and then selecting New ® iView.

2. In the Source Type pane, select iView template, and click Next.

3. From the iView templates, select SAP Web Dynpro iView, and click Next.

4. Enter a name and ID for the iView, and click Next.

5. For the type of Web Dynpro application, select ABAP, and click Next.

6. Select an ABAP application by specifying the following:

○ System alias

○ Namespace (set to sap)

○ Application name

○ Web Dynpro client

○ Configuration name

○ Application parameters

Click Next.

7. Click Finish.

SAP Portal Events Web Dynpro ABAP Portal Integration

In the SAP Enterprise Portal, you can process different application types in special iViews on the same portal page. Here, iViews can be included using different technologies (such as Web Dynpro ABAP, Java, or BSP). The communication between these iViews takes place through an event function – portal eventing (or client-side eventing).

A Web Dynpro ABAP application can be registered for portal events. In this way, the Web Dynpro application can react to an event that was triggered in another iView in the portal. Therefore, it does not matter what technique you used to set up the application that is the basis for the other iView. The assignment as to which event handler is to be called when this event occurs is stored In the Web Dynpro application that has registered itself on the portal event.

Similarly to registration, a Web Dynpro application can trigger any portal event. In this case, the event is passed to the portal by the respective iView. The portal passes the event to all iViews that have registered for this event. The application that finally handles this event can, in turn, have been set up with a different technique than the Web Dynpro application triggering it.

Portal eventing functions only between iViews that are on the same browser window. Events between iViews in different browser windows cannot be transported.

All participating iViews must also belong to the same domain. Otherwise portal eventing cannot work due to JavaScript restrictions.'

SAP Triggering a Portal Event Web Dynpro ABAP Portal Integration

A portal event is an event that is triggered within an iView – in this case, within a Web Dynpro application – and is then passed by the portal to one or several other iViews. The portal passes the event to all iViews that have registered for this event. In this way, events can be transported between several iViews based on different development techniques.

Portal eventing functions only between iViews that are on the same browser window. Events between iViews in different browser windows cannot be transported.

All participating events must also belong to the same domain. Otherwise portal eventing cannot work due to JavaScript restrictions.

In Web Dynpro ABAP, the Portal-Manager (interface IF_WD_PORTAL_INTEGRATION) provides the FIRE method. Using the Web Dynpro Code Wizard, you can insert this method call as a template into your source code and fill it with values in accordance with the requirements of your application.

method ONACTIONFIRE_PORTAL_EVENT . . . . data: L_API_COMPONENT type ref to IF_WD_COMPONENT, L_PORTAL_MANAGER type ref to IF_WD_PORTAL_INTEGRATION. L_API_COMPONENT = WD_COMP_CONTROLLER->WD_GET_API( ). L_PORTAL_MANAGER = L_API_COMPONENT->GET_PORTAL_MANAGER( ). L_PORTAL_MANAGER->FIRE( PORTAL_EVENT_NAMESPACE = 'my_namespace_for_Web_Dynpro_documentation' PORTAL_EVENT_NAME = 'showCustomer' PORTAL_EVENT_PARAMETER = CUSTOM_ID ). endmethod.

In addition to the mandatory parameters Namespace and Name, you can also pass on another parameter:

Namespace in which the event is stored	’PORTAL_EVENT_NAMESPACE’
Name of the event	’PORTAL_EVENT_NAME’
Parameter	’PORTAL_EVENT_PARAMETER’

You can trigger such a portal event from anywhere in your Web Dynpro application. The event is sent with the next response to the client. You can even trigger several portal events in one request-response cycle.

However, it is usual to trigger a portal event in an action handler of a Web Dynpro application. This could be the case, for example, with an action handler of a UI element (for example, a button). When a portal event is triggered, an internal application event is first passed from the iView to the portal and can e handled within one or several other iViews.

Syntax for Namespace and Names of Events

The characters permitted for the namespace and event name are restricted to the namespaces of the SAP Enterprise Portal – Client Framework.

You can only use the characters listed in the table below.

Valid Characters

Uppercase letters	"A" - "Z"
Lowercase letters	"a" - "z"
Numbers	"0" - "9"
Special character	"-" "_" "."

Also note that:

· The namespace must begin with the character string urn:

· Namespaces com.sapportals.portal.* and com.sapportals.* are reserved for SAP, and therefore you should not use them for your applications.

· Note that the namespace and the name are case-sensitive.

urn:com.sap.webdynpro.testApplications.testEvent

Example

· You can find examples in the system under the Web Dynpro applications: WDR_TEST_PORTAL_EVENT_FIRE

Trigger Event

· WDR_TEST_PORTAL_EVENT_FIRE2

This application serves as a test application. You can enter the name of an event from your own application in order to test the event separately.

SAP Registering and Handling an Event Web Dynpro ABAP Portal Integration

Registration for a Portal Event

To register your Web Dynpro application for a portal event, you have the method SUBSCRIE_EVENT available in the interface IF_WD_PORTAL_INTEGRATION.

To delete your registration for the portal event, use the method UNSUBSCRIBE_EVENT in the portal manager.

Registration or deletion of registration must be performed individually for each view in the respective method WDDOINIT.

Generate yourself a suitable template using the Web Dynpro Code Wizard. You can then fill this with values.

method WDDOINIT . data: L_API_COMPONENT type ref to IF_WD_COMPONENT, L_PORTAL_MANAGER type ref to IF_WD_PORTAL_INTEGRATION, VIEW type ref to IF_WD_VIEW_CONTROLLER. L_API_COMPONENT = WD_COMP_CONTROLLER->WD_GET_API( ). L_PORTAL_MANAGER = L_API_COMPONENT->GET_PORTAL_MANAGER( ). VIEW ?= WD_THIS->WD_GET_API( ). L_PORTAL_MANAGER->SUBSCRIBE_EVENT( PORTAL_EVENT_NAMESPACE = 'my_namespace_for_Web_Dynpro_documentation' PORTAL_EVENT_NAME = 'showCustomer' VIEW = VIEW ACTION = 'RECIEVE_CUSTOMER_ID' ). endmethod.

Enter the namespace and the name of the event. The combination of namespace and event name must be unique. In addition, enter the name of the action that is to be triggered if exactly this portal event is to be received. The corresponding action handler is then called automatically.

The action, in this case RECEIVE_CUSTOMER_ID, is not created automatically. Therefore, create the action explicitly on the tab page Actions in the view.

Handling a Portal Event

The parameters of a portal event are passed to the action parameter WDEVENT using its method GET_STRING. With the help of the optional parameter PORTAL_EVENT_PARAMETER, you can have application-dependent information passed to the handler method. In the following example, this is the ID of a particular customer whose value is passed to the SHOWCUSTOMER method of the component controller called afterwards.

method ONACTIONRECIEVE_CUSTOMER_ID . data: EVT_NAME type STRING, CUST_ID type SCUSTOM-ID. EVT_NAME = WDEVENT->GET_STRING( NAME = 'PORTAL_EVENT_NAME' ). if EVT_NAME = 'showCustomer'. CUST_ID = WDEVENT->GET_STRING( NAME = 'PORTAL_EVENT_PARAMETER' ). WD_COMP_CONTROLLER->SHOWCUSTOMER( CUSTOMER_ID = CUST_ID ). endif. endmethod.

Example

You can find examples in the Web Dynpro applications in the system:

· WDR_TEST_PORTAL_EVENT_REC

Receive portal event

· WDR_TEST_PORTAL_EVENT_REC2

This application also serves as a test application. You can enter the name of an event from your own application in order to test the event separately.

SAP Portal Navigation Web Dynpro ABAP Portal Integration

The SAP Enterprise Portal supports navigation between various types of portal content. For example, a Web Dynpro application can navigate to the portal content as well as to another Web Dynpro application that is set up differently. Portal content can be, for example, a BSP or an ITS application.

As well as being object-based, page navigation can be absolute or relative.

SAP Object-Based Navigation (OBN) Web Dynpro ABAP Portal Integration

The structure of SAP Enterprise Portal content is based on roles. You can browse through the user-specific navigation structures using the top-level navigation and the detailed navigation. Portal navigation allows you to navigate between different iViews or pages in any application running as a portal content (that is, any page or iView).

In many cases it is sufficient to use either relative or absolute navigation to navigate to a specific iView or page. However, sometimes more flexibility is required. For this purpose, you have Object-Based Navigation, which allows you to define navigation steps at a higher semantic level. Instead of defining a concrete target URL, you call a particular operation of a particular Business Object.

You configure in the portal which concrete iView (or which page) is to be used for executing this operation. This configuration can be role-specific or user-specific. The Web Dynpro application itself passes on solely the name of the business object and the operations linked to it.

In Web Dynpro for ABAP, the integration of object-based navigation is very similar to the integration of Portal Eventing. To trigger the navigation itself, the Web Dynpro Framework provides a service that can be called from the application. This service, like Portal Eventing, is part of the portal manager.

Triggering Object-Based Navigation

You can activate object-based navigation of the portal in Web Dynpro ABAP by calling the method NAVIGATE_TO_OBJECT of the portal manager (interface IF_WD_PORTAL_INTEGRATION). You can generate an appropriate template using the Web Dynpro Code Wizard, in which you then enter values.

● data lr_componentcontroller type ref to ig_componentcontroller . ● data l_api_componentcontroller type ref to if_wd_component. ● data lr_port_manager type ref to if_wd_portal_integration. ● ● lr_componentcontroller = wd_this->get_componentcontroller_ctr( ). ● l_api_componentcontroller = lr_componentcontroller->wd_get_api( ). ● lr_port_manager = l_api_componentcontroller->get_portal_manager( ). ● ● call method lr_port_manager->navigate_to_object ● exporting ● system = navigation_data-system ● object_type = navigation_data-object ● operation = navigation_data-operation ● object_value_name = navigation_data-object_value_name ● object_value = navigation_data-object_value ● business_parameters = bus_parameter_list ● forward_obn_metadata = navigation_data-forward_obn_metadata. ●

Only two parameters are required for the navigation:

● SYSTEM

Specify the system (or the system alias) the business object is assigned to.

● OBJECT_TYPE

Specify the business object you are using.

All other parameters are optional.

● OBJECT_VALUE

There are usually a large number of different instances for a single business object, as is the case for the business object Customer for example. You use this parameter to specify which specific customer (for instance, use the customer number) is to be used for the object-based navigation step.

● OPERATION

You use this parameter to specify which operation is to be used for the object-based navigation step.

● OBEJCT_VALUE_NAME

The specified object value is transferred as a URL parameter to the OBN step. The standard name of this parameter is ObjectValue. You can change this name if you want.

● BUSINESS_PARAMETERS

As well as specifying the object value, you can define other parameters that are to be forwarded by the OBN step. An example of a parameter string you could define is: Mode=Edit&ShowHeader=false.

These parameters can be used by the target of the OBN if the operation of the business object has been prepared accordingly (see below under the section Maintaining the Target Application in the Portal.

● FORWARD_OBN_METADATA

It is sometimes useful if OBN target receives more details about the current navigation step. For instance, if you implement an application that serves for implementing different operations performed on a business object, the application must know which operation was triggered by the OBN step. Therefore, you can pass on the following parameters:

○ obn.system

The system the business object is assigned to.

○ obn.bo_type

The business object itself

○ obn.operation

The respective operation If the default operation is used, the value is _default_.

Maintaining the Target Application in the Portal

The target application is maintained in the portal for the respective operation of the business object. This is usually done in by the portal administrator.

For business parameters of a WDA target application you use the Application Parameters defined for the Web Dynpro ABAP application. If you want to assign application parameters in the startup plug of the application dynamically, you can find them in the documentation for the application.

Example

You can find an example in the system in the Web Dynpro application, WDR_TEST_PORTAL_NAV_OBN.

Role-Based Authorization Check

Execution of the navigation is thus dependent on the customizing for the role settings in the portal. For example, the user of a role could have the authorization for displaying and editing the content of a page, while the users of another role might only be allowed to display the content. If a user triggers object-based navigation, but does not belong to a role that has authorization for the respective operation, an appropriate error message will appear. So as to make the user interface as user-friendly as possible, it is a good idea – from the very start – not to provide this operation for the user in question. For this purpose, however, the information for the authorization of the respective operation must be got by the portal. This can be done using a Web service that is called from the Web Dynpro ABAP application using the class CL_WDR_PORTAL_OBNWEB_SERVICE.

SAP Absolute Navigation Web Dynpro ABAP Portal Integration

You can activate absolute path navigation for the portal in Web Dynpro ABAP using the portal manager (interface IF_WD_PORTAL_INTEGRATION, method NAVIGATE_ABSOLUTE). You can generate a template using the wizard, in which you then enter values.

With the absolute navigation tool, you must know the name of the page to be displayed in order to pass it to the method.

data lr_componentcontroller type ref to ig_componentcontroller . data l_api_componentcontroller type ref to if_wd_component. data lr_port_manager type ref to if_wd_portal_integration. lr_componentcontroller = wd_this->get_componentcontroller_ctr( ). l_api_componentcontroller = lr_componentcontroller->wd_get_api( ). lr_port_manager = l_api_componentcontroller->get_portal_manager( ). call method lr_port_manager->navigate_absolute exporting navigation_target = navigation_data-target navigation_mode = navigation_data-navigation_mode window_features = navigation_data-window_features window_name = navigation_data-window_name history_mode = navigation_data-history_mode target_title = navigation_data-target_title context_url = navigation_data-context_url post_parameters = ABAP_FALSE use_sap_launcher = abap_true business_parameters = bus_parameter_list launcher_parameters = launcher_parameter_list.

The navigation target is the only parameter required here. It stands for an absolute address in the portal. The other parameters are used for controlling the navigation and are optional. You can set business parameters and parameters for the respective application launcher in the portal. To transport business parameters correctly to the target application, you have to set the parameter USE_SAP_LAUNCHER. If it is an SAP application (for example, BSP Web Dynpro, and so on), you have to set the switch to TRUE.

Overview of Parameters

Name	Optional	Possible values			Description
NAVIGATION_TARGET		Address, for example ROLES://portal_content/ web_dynpro_abap/ web_dynpro_abap_tester/ portal_integration/ portalNavigation/ portal_navigation_target			Absolute address, path for page or iView in the portal content directory. This path is displayed in the portal catalog – for instance, when you edit a page or an iView.
NAVIGATION_MODE	√	″INPLACE″		Displays the navigation target on the same page	Navigation mode
		″EXTERNAL″		Displays the navigation target on a new page, but only as an iView, without the portal
		″EXTERNAL_PORTAL″		Displays the navigation target on a new portal page.
WINDOW_FEATURES	√	″TOOLBAR″		Displays the standard toolbar	Additional JavaScript parameters for the external window – for example, character set or size specification, such as width=300 or height=250 These parameters are separated by commas. Spaces are not permitted.
		″LOCATION″		Displays the Web address
		″DIRECTORIES″		Displays the directory buttons of the browser
		″STATUS″		Displays the status bar
		″MENUBAR″		Displays the menu bar of the browser
		″SCROLLBARS″		Displays the scroll bar
		″RESIZABLE″		Windows can be resized
		″WIDTH″		Width of the window
		″HEIGTH″		Height of the window
WINDOW_NAME	√	String			Title of the target page in the external browser. The specified Web address is loaded into a window of this name – for instance, MyWindowName. This name is used to access the address.
HISTORY_MODE	√	″ALLOW_DUPLICATIONS″		A navigation entry can be listed more than once in the history.	Specifies whether the visited Web address should be listed in the navigation history.
		″NO_DUPLICATIONS″		A navigation entry can be listed only once in the history.
		″NO_HISTORY″		No navigation entry in the history
TARGET_TITLE	√	String			Title of the portal page
CONTEXT_URL	√	String			Determines the navigation context used
POST_PARAMETERS	√	″TRUE″	Transfer parameters as a POST request		Transfer options for parameters
		“FALSE” (default value)	Transfer parameters as a GET request
USE_SAP_LAUNCHER	√	“TRUE” (default value)		Target is called using the SAP launcher – for example, BSP	SAP launcher is used
		″FALSE″		Target is not called using the SAP launcher
BUSINESS_PARAMETERS	√	See structure WDR_NAME_VALUE_LIST with name and value pairs			Transfer parameters for navigating to the target application (Web Dynpro or other Web application), for example, a specific customer number. These parameters are transferred by URL. See also URL Parameters Keep in mind the transfer restrictions – for example, a parameter cannot be larger than 1 KB.
LAUNCHER_PARAMETERS	√	See structure WDR_NAME_VALUE_LIST with name and value pairs			Parameter list for the application launcher, parameter list – for example, WebDynproNamespace=myNamespace

If you define BUSINESS_PARAMETERS as application parameters in your Web Dynpro application and the parameter names start with ″APP″, they will automatically be forwarded to the startup plugs of the Web Dynpro application – provided they are marked as startup parameters. In this case, keep in mind that the iView/page used as the navigation target must be assigned to the user role. If it is not, navigation cannot be triggered.

Example

You can find an example in the system in the Web Dynpro application, WDR_TEST_PORTAL_NAV_PAGE.

SAP Relative Navigation Web Dynpro ABAP Portal Integration

several directories.

To activate relative path navigation for the portal in Web Dynpro ABAP, use the portal manager ( IF_WD_PORTAL_INTEGRATION, method NAVIGATE_RELATIVE).

You can generate a template using the wizard, in which you then enter values.

call method lr_port_manager->navigate_relative exporting base_url = navigation_data-base_url levels_up = levels_up path = pathlist navigation_mode = navigation_data-navigation_mode window_features = navigation_data-window_features window_name = navigation_data-window_name history_mode = navigation_data-history_mode target_title = navigation_data-target_title context_url = navigation_data-context_url use_sap_launcher = abap_true business_parameters = bus_parameter_list launcher_parameters = launcher_parameter_list.

Relative navigation can be used from the defined starting point.

Overview of Parameters

Name	Optional	Possible values	Description
BASE_URL	√	Path name	Starting point for relative navigation
LEVELS_UP		Numeric value	Number of navigation steps upwards in the navigation structure
PATH		Path name	Relative path list for the target application

You use the remaining parameters in the same way as for Absolute Navigation.

BASE_URL : pcd:role1/folder1/folder2/fodler3/workset1/page1

LEVELS_UP: 3

PATHLIST: folder4/workset2/page2

The target is: pcd:role1/folder1/folder2/folder4/workset2/page2

The BASE_URL does not have to be specified. If it is not, the current URL is used. PATH is a list of the nearest nodes. In this case, these would be:

folder4

workset2

page2

Example

You can find an example in the system in the Web Dynpro application WDR_TEST_PORTAL_NAV_PAGE.

SAP Resume Plugs and Portal Navigation Web Dynpro ABAP Portal Integration

For every interface view, you can flag exactly one inbound plug as a resume plug. When navigating in the portal, the existence of a resume plug results in the following behavior: If the Portal Navigation recognizes such a plug in the running application, the latter is not exited when navigating away but is instead transferred to a suspend mode. The session ID and contents of the context are retained and a new application is started. If a user then goes back to the original application via the navigation menu of the portal, it can be processed in exactly the same state in which it was left. Note the following:

If an application features a resume plug, the corresponding session is retained when navigating away in the portal. However, in many cases it may be sensible or even absolutely necessary to close the application completely. In such cases, you must not implement a resume plug for the interface view.

Method WDDOAPPLICATIONSTATECHANGE

The method WDDOAPPLICATIONSTATECHANGE is a method of the component controller. It is processed whenever the status of an application changes – that is, precisely when the application is transferred from running to suspend mode and when it is subsequently restarted via the resume plug. This method thus replaces the WDDOEXIT method in the phase model.

Application development can – but does not have to – add code to the method WDDOAPPLICATIONSTATECHANGE. However it can be useful, for example, to delete database locks in this method that are not be in place during the resume state.

While your applications are running within a portal, the portal navigation takes care of the suspend step without you having to implement it at design time. The mere existence of a resume plug ensures that an application is only interrupted and not exited in the case of a portal navigation. However, this does not take place if the application is not running in the portal and can thus not make use of the portal navigation mechanism.

Resume and Suspend Plugs Outside the Portal

If you want to interrupt an application and retain the session in the context of a pure Web Dynpro navigation, you must create a suspend plug for the interface view of the relevant window and fire it at an appropriate time. Every interface view can have several outbound plugs flagged as suspend plugs. Firing a suspend outbound plug also results in the method WDDOAPPLICATIONSTATECHANGE being called instead of WDDOEXIT. The URL of the suspended application is automatically passed to the subsequent application, so that it is possible to navigate back to the original application.

If an outbound plug is flagged as a suspend flag in a Web Dynpro ABAP application, this can lead to errors when the application is executed in the portal. If you are not completely sure that your application is executed solely outside a portal, you should avoid the use of suspend plugs.

SAP Work Protect Mode Web Dynpro ABAP Portal Integration

The work protect mode provides the infrastructure for handling unsaved data in SAP Enterprise Portal. An application is called “dirty” if the entered data has not yet been saved. Normally data is lost when the user navigates to another application without having first saved the data. To prevent this from happening, the client framework of the portal monitors the current status of all the applications in the portal.

Example of dialog box showing the work protect mode:

The application must define a special status (dirty flag), which tells the portal when there is unsaved data.

You can set and cancel this status (TRUE, FALSE) using method SET_APPLICATION_DIRTY_FLAG in interface IF_WD_PORTAL_INTEGRATION. If the dirty flag is set to TRUE, each navigation step is automatically executed in a new window. The unsaved data is retained in the original window. This means the user can switch to the original application and save the data afterwards.

The following source text shows how to set the dirty status:

data L_COMPONENTCONTROLLER type ref to IG_COMPONENTCONTROLLER . data L_API_COMPONENTCONTROLLER type ref to IF_WD_COMPONENT. data L_PORTAL_MANAGER type ref to IF_WD_PORTAL_INTEGRATION. L_COMPONENTCONTROLLER = WD_THIS->GET_COMPONENTCONTROLLER_CTR( ). L_API_COMPONENTCONTROLLER = L_COMPONENTCONTROLLER->WD_GET_API( ). L_PORTAL_MANAGER = L_API_COMPONENTCONTROLLER->GET_PORTAL_MANAGER( ). call method L_PORTAL_MANAGER->SET_APPLICATION_DIRTY_FLAG exporting DIRTY_FLAG = TRUE | FALSE .

Web Dynpro supports the work protect mode in three different ways (method SET_WORK_PROTECT_MODE in the interface IF_WD_PORTAL_INTEGRATION):

· NONE

This value means that the work protect mode is not used by the Web Dynpro application. If you navigate to another application in the portal, unsaved data is lost, even if you set the dirty flag.

· APPLICATION_ONLY

This value means that the Web Dynpro application itself decides if there is still unsaved data – that is, whether the application is dirty. This is why the “dirty” status is only monitored by the server. With this value you cannot ensure that data that has not yet been transferred to the server will not be lost.

· BOTH

This value means the client also checks the “dirty” status. This ensures that no user input that has not yet been transferred to the server will be lost. This is done by setting the dirty status of the application in SAP Enterprise Portal as soon as the user has entered data.

The modes described above can be changed as often as required during runtime of a Web Dynpro application. For example, you can change the mode when a user navigates from one view to another. For one view, it may make sense to save data that is entered in an input field. In this case you define the value BOTH or APPLICATION_ONLY. For another view this protection mode may not be necessary. In this case you define the value NONE.

The source text below shows how the work protect mode can be set:

data L_COMPONENTCONTROLLER type ref to IG_COMPONENTCONTROLLER . data L_API_COMPONENTCONTROLLER type ref to IF_WD_COMPONENT. data L_PORTAL_MANAGER type ref to IF_WD_PORTAL_INTEGRATION. L_COMPONENTCONTROLLER = WD_THIS->GET_COMPONENTCONTROLLER_CTR( ). L_API_COMPONENTCONTROLLER = L_COMPONENTCONTROLLER->WD_GET_API( ). L_PORTAL_MANAGER = L_API_COMPONENTCONTROLLER->GET_PORTAL_MANAGER( ). call method L_PORTAL_MANAGER->SET_WORK_PROTECT_MODE exporting MODE = NONE | APPLICATION_ONLY | BOTH .

Example

You can find an example in the system in the Web Dynpro application WDR_TEST_PORTAL_WORKPROTECT.