10.

Special Topics

Unit Objectives
After completing this unit, you will be able to:
 Adapt Web Dynpro applications using implicit configuration, Customizing, and personalization
 Create a configuration controller and implement explicit Configuration
 Use the ALV for Web Dynpro to display mass data
 Explain how more sophisticated ALV functionality can be implemented
 Explain how Web Dynpro applications can be integrated into the SAP Enterprise Portal
 Implement portal eventing.
 Embed Adobe form documents into Web Dynpro views

1.SAP List Viewer for ABAP Web Dynpro

Lesson Overview
This lesson discusses the integration of the SAP List Viewer (ALV) in ABAP Web Dynpro applications.
Lesson Objectives
After completing this lesson, you will be able to:
 Use the ALV for Web Dynpro to display mass data
 Explain how more sophisticated ALV functionality can be implemented.

SAP List Viewer for Web Dynpro

The Table UI element is the standard UI element in the Web Dynpro context to display mass data. Basic
functionality like selecting rows and scrolling up and down is provided out of the box. The developer can set a large
number of table properties at design time to change the visual design and the functionality offered to the user at
runtime. However, in the classical SAP GUI, the developer and the user can work with the SAP List Viewer, which
offers a much larger functionality.

Using the ALV in ABAP Web Dynpro

The SAP List Viewer is not implemented as a standard or complex UI element, but as a Web Dynpro
component. The name of this component is SALV_WD_TABLE.If the ALV is to be displayed in a view of any
component, this component has to declare the usage of the ALV component. The interface view TABLE has to be
embedded in a view container of the view that will display the SAP List Viewer.Finally, data have to be exchanged
between the main component and the ALV component using external context mapping.
The single steps of embedding are:
 Add a component usage of SALV_WD_TABLE to the list of used components (Used Componentstab).
 In the view that will embed the ALV, define a ViewContainerUIElement.
 In the window containing this view, embed the ALV interface view TABLE in the ViewContainerUIElement.
 Define an interface controller usage for the ALV component usage (from the context menu of the ALV
component usage in the object tree of the workbench).
 Edit the interface controller usage:
 Declare the component controller of the main component as a used controller.
 Define an external mapping between the data node of the interface controller usage and the node of the
main component controller containing the data to be displayed.

Having performed all of these steps, the basic functionality of the SAP List Viewer can be used. This includes:

. Sorting
. Filtering
. Selecting rows
. Scrolling up/down
. Exporting to Microsoft Excel
. Exporting to PDF

The Settings link can be used to open a dialog box, which allows you to adapt additional settings:

. Hiding columns
. Defining sorting columns and sorting direction
. Defining complex filters
. Changing table display settings
. Defining settings for PDF export

These settings can be saved and used as the user's default display variant.

Advanced ALV Functionality: Configuration Model

When instantiating the ALV component usage, a configuration model is generated automatically. The configuration
model offers a large number of methods that allow adaptation of the look and feel of the ALV. A reference to the
configuration model can be obtained by calling the interface controller method get_model( ), which is available for
all ALV component usage instances. The model reference is of type CL_SALV_WD_CONFIG_TABLE. This class
implements several interfaces, allowing changes in the following parts of the ALV:

ALV Configuration Model: Interfaces Implemented by the Model Class

Interface Name Usage
 IF_SALV_WD_COLUMN_SETTINGS Settings for the columns in the ALV output
 IF_SALV_WD_CONTROL_SETTINGS Controls which spreadsheet application is used with button
(e.g.,use Excel in Place)
 IF_SALV_WD_EXPORT_SETTINGS Settings for data export to Microsoft Excel
 IF_SALV_WD_FIELD_SETTINGS Settings for the fields of the internal data table (e.g., group
aggregation).
 IF_SALV_WD_FUNCTION_SETTINGS Settings for user-defined functions(e.g., position).
 IF_SALV_WD_PDF_SETTINGS Settings for data export to PDF (e.g.,margins)
 IF_SALV_WD_STD_FUNCTIONS Settings for generic ALV functions(e.g., hide Print Version button)
 IF_SALV_WD_TABLE_HIERARCHY Settings for hierarchical ALV list display (e.g., collapse
hierarchical view)
 IF_SALV_WD_TABLE_SETTINGS Settings for entire ALV output (e.g.,make ALV available for edit)

Calling methods defined in these interfaces is possible from the standard hook
methods wddoinit( ) and wddomodifyview( ) of a main component's controller.

Advanced ALV Functionality: Eventing

The ALV component fires a number of events to influence ALV processing. This may happen at certain points of
time (for example, before rendering a table cell) or as a reaction to a user action (for example, selecting a row or
clicking a button in a table cell). Methods, defined in the main component, can register to these events.

For example, when the user clicks on a link or on a button defined in a table cell, the ALV component fires the
event ON_CLICK. If a method of the main component has registered to this event, it will be processed after
clicking.
The event ON_DATA_CHECK is triggered after the user has changed the value of a table cell. Data checks can be
performed in the main component.

3.Adaptation of Web Dynpro Applications

Lesson Overview
This lesson covers the adaptation of applications and components. This includes implicit adaptation . which means
possibilities that are available out of the box . and explicit adaptations, where the developer has to define the kind of
additional functionality that is adaptable by certain user groups (administrators,
normal users).

1.Value Help - Advanced Topics

Object Value Selector (OVS)

There are situations when reusing existing ABAP dictionary search helps is not sufficient. Say, for example, the
value help should take into account or fill multiple input fields of your view composition. However, the different
input fields are related to different value nodes, which in turn refer to different ABAP Dictionary structures.

Object Value Selector (OVS)

A reusable Web Dynpro component is responsible for displaying the selection screen, allowing you to enter
restrictions for data retrieval and for displaying the values fitting these restrictions. The consumer of this component
(the parent component) has to care for specific tasks such as defining the selection screen setup and data retrieval.
Between the two components, data has to be interchanged.
Thus, the OVS component has to offer an interface that can:
Receive information about which input fields should be displayed on the selection screen,
Receive information about the initial values of these input fields
Hand back the user's input into these input fields
Receive the result from the data retrieval in order to display the list
Hand back the selected data set to the consumer program

The following steps must be performed in order to use the OVS concept:
 A component usage of the component WDR_OVS has to be declared by the consumer component.
 A usage of the OVS interface controller has to be declared in a controller of the consumer component for
example, the component controller or the displaying view controller).
 The input help mode Object Value Selector has to be chosen for the attribute under consideration.
 A handler method for the event OVS of the OVS component usage has to be created and implemented.
Phase Model of the Object Value Selector

After having pressed the value help button of an input field in the consumer component, the OVS
component is processed. Every time the OVS component requires information from the consumer component, the
OVS event is fired by the OVS component. An additional parameter, phase_indicator, indicates the type of
information that is requested. An event handler method of the consumer component has to subscribe for the OVS
event. Depending on the value of the phase_indicator parameter, different coding sections can be implemented to
collect the required information and hand it back to the OVS component
In order to hand back the information to the OVS component, appropriate methods of this component have to be
called. A reference to the object (ovs_callback_object) containing these methods is also provided by the OVS event.

OVS Phase Model

Phase 0 (phase_indicator = 0): This phase is also called the configuration phase. Here, the consumer can define
which texts are to be displayed by the OVS component, either on the selection screen dialog box or on the value
help list. In addition, the number of columns used to structure the selection dialogbox can be defined. To export the
information to the OVS component, the method set_configuration( )of the callback object should be called.

TYPES:
    BEGIN OF T_STRU_INPUT,
*   add fields for the display of your search input here
      EBELN TYPE EBELN,
      BUKRS TYPE BUKRS,
    END OF T_STRU_INPUT,
    BEGIN OF T_STRU_LIST,
*   add fields for the selection list here
      EBELN TYPE EBELN,
      BUKRS TYPE BUKRS,
      BSTYP TYPE BSTYP,
      BSART TYPE BSART,
    END OF T_STRU_LIST.

  DATA: L_SEARCH_INPUT  TYPE T_STRU_INPUT,
        L_SELECT_LIST   TYPE STANDARD TABLE OF T_STRU_LIST,
        L_TEXT          TYPE WDR_NAME_VALUE,
        L_LABEL_TEXTS   TYPE WDR_NAME_VALUE_LIST,
        L_COLUMN_TEXTS  TYPE WDR_NAME_VALUE_LIST,
        L_WINDOW_TITLE  TYPE STRING,
        L_GROUP_HEADER  TYPE STRING,
        L_TABLE_HEADER  TYPE STRING.

  FIELD-SYMBOLS: <QUERY_PARAMS> TYPE T_STRU_INPUT,
                 <SELECTION>    TYPE T_STRU_LIST.

  CASE OVS_CALLBACK_OBJECT->PHASE_INDICATOR.

    WHEN IF_WD_OVS=>CO_PHASE_0.  "configuration phase, may be omitted
*   in this phase you have the possibility to define the texts,
*   if you do not want to use the defaults (DDIC-texts)

      L_TEXT-NAME = `EBELN`.  "must match a field name of search
      L_TEXT-VALUE = `PO Number`. "wd_assist->get_text( `001` ).
      INSERT L_TEXT INTO TABLE L_LABEL_TEXTS.

      L_TEXT-NAME = `BUKRS`.  "must match a field name of search
      L_TEXT-VALUE = `Company Code`. "wd_assist->get_text( `001` ).
      INSERT L_TEXT INTO TABLE L_LABEL_TEXTS.

      L_TEXT-NAME = `EBELN`.  "must match a field in list structure
      L_TEXT-VALUE = `Purchase Doc`. "wd_assist->get_text( `002` ).
      INSERT L_TEXT INTO TABLE L_COLUMN_TEXTS.

      L_TEXT-NAME = `BUKRS`.  "must match a field in list structure
      L_TEXT-VALUE = `Company`. "wd_assist->get_text( `002` ).
      INSERT L_TEXT INTO TABLE L_COLUMN_TEXTS.

      L_TEXT-NAME = `BSTYP`.  "must match a field in list structure
      L_TEXT-VALUE = `PO Category`. "wd_assist->get_text( `002` ).
      INSERT L_TEXT INTO TABLE L_COLUMN_TEXTS.
      L_TEXT-NAME = `BSART`.  "must match a field in list structure
      L_TEXT-VALUE = `Order Type`. "wd_assist->get_text( `002` ).
      INSERT L_TEXT INTO TABLE L_COLUMN_TEXTS.

*      l_window_title = wd_assist->get_text( `003` ).
*      l_group_header = wd_assist->get_text( `004` ).
*      l_table_header = wd_assist->get_text( `005` ).

OVS_CALLBACK_OBJECT->SET_CONFIGURATION(
                LABEL_TEXTS  = L_LABEL_TEXTS
                COLUMN_TEXTS = L_COLUMN_TEXTS
                GROUP_HEADER = L_GROUP_HEADER
                WINDOW_TITLE = L_WINDOW_TITLE
                TABLE_HEADER = L_TABLE_HEADER
                COL_COUNT    = 2
                ROW_COUNT    = 20 ).
Phase 1 (phase_indicator = 1): In this phase, the consumer can define which input fields are to be displayed on the
selection dialog box. To export this information back to the OVS component, the method
set_input_structure( ) of the callback object should be called.Then the selection screen can be endered.

WHEN IF_WD_OVS=>CO_PHASE_1.  "set search structure and defaults

      OVS_CALLBACK_OBJECT->CONTEXT_ELEMENT->GET_STATIC_ATTRIBUTES(
          IMPORTING STATIC_ATTRIBUTES = L_SEARCH_INPUT ).
*     pass the values to the OVS component
      OVS_CALLBACK_OBJECT->SET_INPUT_STRUCTURE(
          INPUT = L_SEARCH_INPUT ).
Phase 2 (phase_indicator = 2): This phase is processed after the user has pressed the button on the OVS selection
dialog box.Those fields information of the selection dialog box was stored in query_parameters parameter of the
callback object.To export the value list to the OVS component, the method set_output_table( ) of the callback object
has to be called. The value list will be displayed.

WHEN IF_WD_OVS=>CO_PHASE_2.
*   If phase 1 is implemented, use the field input for the
*   selection of the table.
*   If phase 1 is omitted, use values from your own context.

      IF OVS_CALLBACK_OBJECT->QUERY_PARAMETERS IS NOT BOUND.
******** TODO exception handling
      ENDIF.
      ASSIGN OVS_CALLBACK_OBJECT->QUERY_PARAMETERS->*
                              TO <QUERY_PARAMS>.
      IF NOT <QUERY_PARAMS> IS ASSIGNED.
******** TODO exception handling

        else.

       SELECT ebeln bukrs bstyp bsart INTO TABLE L_SELECT_LIST
         FROM ekko WHERE ebeln = <QUERY_PARAMS>-ebeln or
                         bukrs = <QUERY_PARAMS>-bukrs.
      ENDIF.

*     call business logic for a table of possible values
*     l_select_list = ???
      OVS_CALLBACK_OBJECT->SET_OUTPUT_TABLE( OUTPUT = L_SELECT_LIST ).

Phase 3 (phase_indicator = 3): After having selected a value from the value list,this selection has to be
transported back to the consumer component.those values are stored in the data reference variable selection
which is a parameter of the callback object.

WHEN IF_WD_OVS=>CO_PHASE_3.
*   apply result

      IF OVS_CALLBACK_OBJECT->SELECTION IS NOT BOUND.
******** TODO exception handling
      ENDIF.

      ASSIGN OVS_CALLBACK_OBJECT->SELECTION->* TO <SELECTION>.
      IF <SELECTION> IS ASSIGNED.
*        ovs_callback_object->context_element->set_attribute(
*                               name  = `COLUMN1`
*                               value = <selection>-column1 ).
*      or
        ovs_callback_object->context_element->set_static_attributes(
                               static_attributes = <selection> ).

2.Select options in web dynpro(wdr_select_options)

1) We are using the standard component WDR_SELECT_OPTIONS for creating the select options
in web dynpro ..we need to declare the usage of component in comp controller of consumer
component.

2) First we need to create the view for displaying the select options and in layout ,we need to take
the ViewContainerUIElement . then move the view into WINDOW and in view container we can
embeded the WND_SELECTION_SCREEN interface view of wdr_select_options component.

3) Then we need coded in WDDOINIT() method in view controller .we need to get the reference of
component usage by calling WD_CPUSE_<USAGE-NAME>() and inistiating the component
usage by calling CREATE_COMPONENT().

DATA: L_REF_CMP_USAGE TYPE REF TO IF_WD_COMPONENT_USAGE.

  L_REF_CMP_USAGE =   WD_THIS->WD_CPUSE_SEL_OPT( ).
  IF L_REF_CMP_USAGE->HAS_ACTIVE_COMPONENT( ) IS INITIAL.
    L_REF_CMP_USAGE->CREATE_COMPONENT( ).
  ENDIF.

4) Get the reference of interface controller of usage component bu calling WD_CPIFC_<USAGE-

NAME>( ) method and with this reference variable call the INIT_SELECTION_SCREEN( )
method .it will be return the object reference of the IF_WD_SELECT_OPTIONS interface.declare
the data range .

DATA: L_REF_INTERFACECONTROLLER TYPE REF TO IWCI_WDR_SELECT_OPTIONS .
  L_REF_INTERFACECONTROLLER =   WD_THIS->WD_CPIFC_SEL_OPT( ).
    DATA:
       L_R_HELPER_CLASS TYPE REF TO IF_WD_SELECT_OPTIONS.

L_R_HELPER_CLASS = L_REF_INTERFACECONTROLLER->INIT_SELECTION_SCREEN( ).

  wd_comp_controller->mr_Sel = l_r_helper_class.
  DATA lt_range TYPE ref to data.

5) With this reference variable call the CREATE_RANGE_TABLE( ) method for creating the range
table for VBELN and added to the screen by calling the ADD_SELECTION_FIELD( ) method.
CALL METHOD L_R_HELPER_CLASS->CREATE_RANGE_TABLE
    EXPORTING
      I_TYPENAME     = 'VBELN'
    RECEIVING
      RT_RANGE_TABLE = lt_Range
      .
  CALL METHOD L_R_HELPER_CLASS->ADD_SELECTION_FIELD
    EXPORTING
      I_ID                         = 'ORDER'
      IT_RESULT                    = lt_range
      .  
6) Later we need to get the range values for developing the biz logic .for that call the
GET_RANGE_TABLE_OF_SEL_FIELD( )method with reference of helper class.
TYPES : TY_VBELN TYPE RANGE OF VBeln.
  TYPES : ty_vbtyp TYPE RANGE OF vbtyp.
  TYPES : ty_auart TYPE RANGE OF auart.
  TYPES : ty_erdat TYPE RANGE OF erdat.

  FIELD-SYMBOLS  <FT_R_VBELN> TYPE TY_VBELN.
  FIELD-SYMBOLS  <FT_R_VBTYP> TYPE TY_VBTYP.
  FIELD-SYMBOLS  <FT_R_AUART> TYPE TY_AUART.
  FIELD-SYMBOLS  <FT_R_ERDAT> TYPE TY_ERDAT.

  DATA dref TYPE REF TO data.

  CALL METHOD WD_this->MR_SEL->GET_RANGE_TABLE_OF_SEL_FIELD
    EXPORTING
      I_ID           = 'ORDER'
    RECEIVING
      RT_RANGE_TABLE = dref
      .
  ASSIGN dref->* to <ft_r_Vbeln>.

3.Explicit Customizing and Personalization

If the functionality offered by implicit customizing and implicit personalization is not sufficient, the
developer can extend the functionality nearly arbitrarily. However, here the developer has to write the complete
source code to bring up and process the adaptation dialog. This includes:
 Defining a UI element, which is used to start the adaptation process
 Defining the source code in the related event handler method to bring up the adaptation dialog
-->Defining the dialog, which consists of the standard implicit adaptation functionality (optional) and the additional
explicit adaptation functionality
 Defining the logic to close the adaptation dialog (typically via Save and Cancel buttons).
 Defining the functional changes in the component related to the user's input in the adaptation dialog.
 Combining implicit and explicit Customizing / Personalization

To combine the functionality of implicit and explicit customizing / personalization in one dialog, the
component interface IWD_PERSONALIZATION has to be declared as a used component (interface) by the
component offering the adaptation functionality. This interface offers an interface view (imp_personalization) that
can be embedded in a view container of the main component in order to realize a layout combining implicit and
explicit customizing / personalization. Typically,a view containing a TabStrip with two tabs is used to define the
layout. One tab contains all fields that are used for explicit customizing / personalization.The other tab contains only
a ViewContainerUIElement. The view is embedded in an extra window, which is necessary to display the windows
content as a dialog box. The interface view imp_personalization is then embedded in the
ViewContainerUIElement.
In addition, the interface offers the method init_personalization( ), allowing hand over of a reference to the
UI element that is adaptable implicitly (with all of its sub-elements; this could also be the
UIElementRootContainer).

3.Portal Integration
Business Example
You have created a Web Dynpro application. Now you want to embed your application in the SAP
Enterprise Portal. In this context, your application should be able to interchange information with other portal
applications that may be non-SAP applications.
The portal offers a single point of access to SAP and non-SAP information sources, enterprise applications,
information repositories, databases, and services in and outside your organization . all integrated into a single user
experience. It provides you the tools to manage and analyze this knowledge, and to share and collaborate on the
basis of it.With its role-based content and personalization features, the portal enables users .from employees and
customers to partners and suppliers . to focus exclusively
on data relevant to daily decision-making processes.

SAP Enterprise Portal

Portal Content Structure

1.iView:Content can be integrated into the SAP Enterprise Portal by generating a related iView.An iView
(integrated view) is a logical portal content building block representing a given visual application.

2.portal page : holds iViews and other portal pages organized in a layout. This allows you to combine multiple
iViews in rows and/or columns. Each iView is placed on a tray, so it can be opened or closed when displaying the
page in the portal.

3.Worksets :let you bundle iViews and pages in folder hierarchies, for example, for roles.Worksets represent
generic, reusable structures or modules that can be added to roles. A workset may be used in any number of roles,
and a role may consist of a number of different worksets.

4.Roles :are the largest semantic unit within the content objects. A role is a folder hierarchy comprising other
content objects (worksets, pages, or iViews).
Roles are assigned to users. This means that users can only access the content that is relevant for them if they have
the appropriate role.

Integrating Web Dynpro Applications into the SAP Enterprise Portal

Web Dynpro applications can be bound into portal navigation as an iView.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. This includes:
Using portal events
Navigation between Web Dynpro applications within the portal or to any other portal content using:
 Object-based navigation
 Absolute navigation
 Relative navigation

The main steps in the process of generating an iView for aWeb Dynpro application are:

 Defining the system in the SAP Enterprise Portal system landscape

 Defining the mapping between portal users and users in the previously defined ABAP system
 Creating iViews for Web Dynpro applications in the ABAP system
 Combining different iViews that have to interact via the portal using a portal page
 Adding the portal page to a portal role to make it usable by user groups to which this role is assigned
0
Portal Integration of ABAP Web Dynpro

 Defining the system in the SAP Enterprise Portal system landscape

Creating a New System

Portal: Creating a New System (1)

To access the Web Application Server (Web AS) from the SAP Enterprise Portal, a new system has to be
defined. This is done by choosing System Administration →System Configuration → System Landscape.
On the Browse tab, you may first create a new folder to group all the systems. Choose New → Folder from
the context menu that appears when you click on the main Portal Content node or any child node.
Having selected a folder, a new system is created from the context menu by choosing New → System (from
template). In the wizard, choose SAP system using.... There are three entries allowing you to log on to an
application server, to use load balancing, and to use an SAP router string. On the next screen, enter an arbitrary
System Name and System ID. Choose Finish. On the next screen,choose Open the object for editing.

1.Choose Object from the Display dropdown box. Then choose Web Application Server (Web AS) as the Property
Category. Enter the System ID, the URL (including the port), the path to the Web Dynpro applications (default:
sap/bc/webdynpro), and the protocol http.

2.Change the Property Category to User Management. On the related screen,select Logon Method = UIDPW and
User Mapping Type = admin,user. This will allow everyone to log on, filling user and password in a logon dialog
box that appears when starting the application from the portal.

3.In the next step, an alias has to be created for the system. Choose Display =System Alias. Enter an alias and press
the Add button. Choose Save.

 Defining the mapping between portal users and users in the previously defined ABAP
system
 Portal: Defining a User Mapping

At least for testing purposes, it is easiest to map the portal user to a user in the back-end system.
1.Choose User Administration → Identity Management. Enter your portal user name in the input field and choose
Go. Your user appears in the table below.

2.Mark the related table line. Now, below the table listing your user the details of your user appear. Tabs allow to
select details of your user. Select the right most tab having the label User Mapping. Select the alias of your system
from the drop down box System. Press Modify.Enter your user and password in the appropriate fields. Choose Save.

 Creating iViews for Web Dynpro applications in the ABAP system

 Portal: iView Generation (1)
1. To start the process, choose Content Administration → Portal Content. On the right side of the browser window,
select the Browse tab. Open the Portal Content node and the sub-node you want to use to group the content you
develop (to create a new folder, select New → Folder from the context menu that appears when you click on the
Portal Content node or any child node).Select New → iView from the context of the selected node. On the right
side, select the type of iView wizard you want to use.

2. Select the iView template radio button. This opens a special wizard offering you a large set of predefined iView
patterns.

3. On the first screen of this wizard (Step 1), select SAP Web Dynpro iView.

4. Next (Step 2), enter a name and an ID for the iView.

1. On the third screen, ABAP has to be chosen as the Web Dynpro Definition Type.

2. Finally, on screen four, application parameters have to be provided as follows: The system alias has to be entered
in the System field. SAP is the default Namespace. This value will be added to the path to the Web Dynpro
application. The Web Dynpro application name has to be entered in the Application Name field. Optionally, the
name of an application configuration and/or application parameters can be added (for example, sap-config-
mode=X).

3. After having finished the iView generation, the result can be checked by choosing Preview from the context menu
of the iView.
 Combining different iViews that have to interact via the portal using a
portal page
Multiple iViews can be arranged on one visible page using a portal page object.
1. To create a page and its content, first choose Content Administration →Portal Content. On the Browse
tab, localize the node that should be used as the page's parent node. Create a portal page from the context of
the node (chooseNew → Node).

2. On the following screen, enter name and ID of the page.

3. The next page offers two page templates: Default Page Template and Web Dynpro Proxy Page. Choose
the Default Page Template, since Web Dynpro Proxy Page only works for Java Web Dynpro.

4. Next, the page layout has to be defined. To display two iViews, one below the other, choose 1 Column
(Full Width). Choose Add, then Next.

5. To adjust the properties of the page and to assign the iViews, select Open the object for editing on the next
screen. Choose OK.
1. On the right side, a list of the iViews that are already embedded in the portal page appears. To add another
iView to the page, choose Add iView to Page→ Delta Link from the context menu of the iView to be
embedded.

2. By switching from Page Content to Page Layout, the resulting structure of the page can be analyzed.
The last step in creating the page is to adapt the page's properties. There are properties related to the page object and
there are properties related to the embedded iViews.

1. An important group of properties is the Property Category - Appearence Size. For the portal page, the
Height Type should be adjusted to Full Page. For the single iViews, this property should be adjusted to
Automatic so the iView's height depends on the space the Web Dynpro application occupies.

2. You can test the result by choosing Preview, which can be found on top of the tab page.
Portal Eventing
If one Web Dynpro application needs to interact with another Web Dynpro application, it can declare the
usage of the other component. This type of coupling is called tight coupling.
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 asWeb Dynpro or Business Server
Pages). The communication between these iViews takes place through an event function called portal eventing(or
client-side eventing).

A Web Dynpro application can register for portal events. In this way, the Web Dynpro application can react to an
event that was triggered in another iView in the portal. The assignment of which event handler is to be called when
an event occurs is stored in the Web Dynpro application that has registered itself on the portal event.
Similar 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.
 Caution: 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.

Raising a Portal Event from an ABAP Web Dynpro Application:

Portal events have to be fired from a controller method of a view.Before a portal event can be fired, the reference to
the portal manager has to bedetermined. Three parameters must be exported when firing an event:
 portal_event_namespace
In each event namespace, each event name is unique. The event namespace is an arbitrary string.
 portal_event_name
Name of the fired event (arbitrary string). The combination of event namespace and event name identifies
an event uniquely.
 portal_event_parameter
This string contains all data that will be exchanged between the application firing the event and the application
that registered for the event.
 Firing a Portal Event
Thus, to be able to interact via portal eventing, the application firing the event and the application registering for
the event have to use the same names for the event name space and for the event name. In addition, the method of
extracting the information from the event parameter must be known to the application that registered for the portal
event.

Registering for a Portal Event in an ABAP Web Dynpro Application

The source code for registering for a portal event can also be generated using the Web Dynpro Code
Wizard. Only a view can register with an action handler method for a portal event. Registering for the portal event is
to be implemented in the standard hook method wddoinit( ) of the view. The name of the action whose related
method will handle the portal event has to be exported.
 Registering for a Portal Event
In the event handler method, information about the portal event can be extracted from the interface
parameter WD_EVENT. The attribute WDEVENT->PARAMETERS is an internal table containing name/value
pairs in each row. In the portal event context three lines are filled containing the event namespace, the event name,
and the event parameter. Extracting the event parameter can be implemented by reading the related table line using
the key name= 'PORTAL_EVENT_PARAMETER'. Since the value field of the corresponding table line is of type
ref to data, dereferencing the value using a field symbol (of type string) is necessary.
Handling the Portal Event