<body>Introduction
I just got back from a family vacation at Walt Disney World last week. If you have never had the opportunity to visit there, they have a cute little ride called Its a Small World. It is a boat ride though a building filled with hundreds of little dolls all singing the theme song in 20+ different languages. It is a nice ride the first few times, but when your 5 year old daughter wants to ride it over and over again... well I digress.
My point (yes I have a point) is that I have been inspired by Its a Small World. I have taken their message of hope and cooperation to heart. In that spirit I decided to write this weblog about how ABAP WebDynpro and BSP can work together to form one seamless application. And I am going to use the NetWeaver Portal to make this happen. You can almost see a little BSP doll, a WebDynpro doll, and a Portal doll all holding hands. It is enough to bring a tear to your eye.
So how exactly are we going to accomplish this magical feat; why by using Portal Eventing of course. Both BSP and WebDynpro ABAP have support for raising and catching Portal Events. Therefore we should not only be able to send events back and forth between a WebDynpro ABAP and a BSP iView, but we can also pass some data along with that event.
WebDynpro Event Sender
We will start by creating our WebDynpro Event Sender Component. Figure 1 shows the SE80 Object Navigator after we initially create the component z_portal_event_sender.
Figure 1 - z_portal_event_sender Object Overview
In our event sender application we will want to have an input field. For testing purposes we will allow the user to type whatever they want into this input field. We will also have a button. When the button is pressed we will trigger the portal event and send over whatever is in the input field with the event. We can start building our application by creating a View. I have named this view DEFAULT.
In order to have a variable to bind to the input field and to have later in our event processing, we need to create an attribute in the View's Context. This is fairly simple example so I have just created single Node that I called MAIN and a Attribute of type STRING that I named TEXT_AREA_1. The results are displayed in Figure 2.
Figure 2 - The Context of the Default View
We can now return to the Layout tab of our View and begin to design the UI for this application. We will start by creating a Label and an Input Field. We will bind the Input Field to the Attribute of the Context that we just created.
Figure 3 - Binding the Context Attribute to the Input Field.
When we create the Button UI element, there will be a property called onAction. We can hit the create button next to this property to start the Action Creation Wizard. Figure 4 shows the button properties and Figure 5 displays the Action Creation wizard. We will use the wizard to generate the action called trigger_event.
Figure 4 - Button Properties
Figure 5 - Action Creation Wizard
If you double click on the onAction Value you will be navigated to the Generated method for this Action. In this case the method name is ONACTIONTRIGGER_EVENT.
Figure 6 - OnAction Trigger_Event Method*
The Coding in Listing 1 is for the trigger_event onAction Method. The first part of the code is used to read the context and get the current value for the attribute TEXT_AREA_1. The second part of the code accesses the Portal Manager API to fire the event. However we don't have to code all of this. As Figure 7 shows, we will use the WebDynpro Code Wizard to insert the methods of the Portal Manager API.
Figure 7 - WebDynpro Code Wizard - For the Portal Manager API
method onactiontrigger_event . data: node_main type ref to if_wd_context_node, elem_main type ref to if_wd_context_element, stru_main type if_default=>
element_main ,
item_text_area_1 like stru_main-text_area_1.
navigate from <CONTEXT> to <MAIN> via lead selection
node_main = wd_context->get_child_node( name = `MAIN` ).
get element via lead selection
elem_main = node_main->get_element( ).
get single attribute
elem_main->get_attribute(
exporting
name = `TEXT_AREA_1`
importing
value = item_text_area_1 ).
data l_api_component type ref to if_wd_component.
data 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( ).
data: portal_event_parameter type string.
portal_event_parameter = item_text_area_1.
l_portal_manager->fire(
portal_event_namespace = 'com.kimball.keg'
portal_event_name = 'test_event'
portal_event_parameter = portal_event_parameter
).
endmethod.
Listing 1 - onactiontrigger_event
Now all that remains is to finish up our WebDynpro Component. We will first map our view, DEFAULT, into the generated Window for the component.
Figure 8 - View Assignment to the Window
Finally we will need to create our Application for this WebDynpro Component. Figure 9 shows the application settings.
Figure 9 - WebDynpro Application Settings
WebDynpro Event Receiver
So far we have one component that can be used to Trigger Portal Events. Now we need to create the component to receive them. We will create a second component called Z_PORTAL_EVENT_RECEIVER. In this component we will also create a single view called DEFAULT. Since this view will only receive events, all we need on the UI is a label and a text view element. However we will still need a Context Attribute to bind the text view element to. Figure 10 shows the Context Definition.
Figure 10 - Context Definition for the event Receiver View
Now we can bind the text view control to the context attribute the same way we did earlier when using the input field.
Figure 11 - Content Attribute Mapping to the Text View
The first thing this WebDynpro Component View is going to need to do is register itself with the Portal Event Framework. For this activity we will want to place our code in the View Method WDDOINIT. Once again we will use the code wizard (as seen in Figure 12). The wizard for subscribing to an event will even trigger the creation of the resulting action.
*Figure 12 - Subscribe Event Wizard (include the Action Creation)
*
Listing 2 shows you the code that is inserted by the Wizard. We only have to add in our event namespace and event name.
method wddoinit . data l_api_component type ref to if_wd_component. data 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( ). data l_wd_view type ref to if_wd_view_controller. l_wd_view ?= wd_this->wd_get_api( ). l_portal_manager->subscribe_event( portal_event_namespace = 'com.kimball.keg' portal_event_name = 'test_event' view = l_wd_view action = 'CATCH_EVENT' ).endmethod.
Listing 2 - WDDOINIT
Now we need to go to the event handler method for our Action CATCH_EVENT. The method name is ONACTIONCATCH_EVENT. Listing 3 shows the coding for this method. We will first pull the Event Parameter string from the event object. We can then place this value into our Context Attribute which is bound to the text view UI element.
method ONACTIONCATCH_EVENT . data: EVT_NAME type STRING, evt_parameter type string. EVT_NAME = WDEVENT->GET_STRING( NAME = 'PORTAL_EVENT_NAME' ). if EVT_NAME = 'test_event'. evt_parameter = WDEVENT->GET_STRING( NAME = 'PORTAL_EVENT_PARAMETER' ). DATA: node_main TYPE REF TO if_wd_context_node, elem_main TYPE REF TO if_wd_context_element, stru_main TYPE if_default=>
element_main ,
item_text_reciever LIKE stru_main-text_reciever.
navigate from <CONTEXT> to <MAIN> via lead selection
node_main = wd_context->get_child_node( name = `MAIN` ).
get element via lead selection
elem_main = node_main->get_element( ).
get single attribute
elem_main->set_attribute(
EXPORTING
name = `TEXT_RECIEVER`
value = evt_parameter ).
endif.
endmethod.
Listing 3 - ONACTIONCATCH_EVENT
Portal iViews
We are to the point where we are ready to create the Portal elements for our two WebDynpro Components. We will start by creating a SAP Web Dynpro iView.
Figure 13 - iView Wizard Template Selection
*Figure 14 - iView Wizard - General Properties
</p>
*Figure 15 - iView Wizard - Application Variant
*
We can now combine these two iViews together into a Portal Page.
Figure 16 - Portal Page Creation
As you can see from the output in Figure 17, we now have two separate iViews communicating with each other.
Figure 17 - Two WebDynpro ABAP iViews Communicating with Each Other
Adding in BSP
This is a nice example, but it just doesn't have the feeling of global unity that I was quite inspired to. I think to achieve that Its a Small World level, we really need to have our communication cross boundaries, so to speak.
Listing 4 - BSP Event Sender Layout Coding
Listing 5 - BSP Event Receiver Layout Coding
The final piece of the solution is the event handler code for the event_receiver.htm page. In our OnInputProcessing Event Handler we will place the code from Listing 6. We first test for an event_name of portalEvent, so that we know we aren't catching a normal HTMLB event. event_server_name will contain the data string that is passed along with the event. event_defined will contain the originator of the event. Finally if we split the event_id at ':', we can determine the event namespace and the event name.
data: event type ref to if_htmlb_data.data: event_dataobject type string.data: event_sourceid type string.data: event_namespace type string.data: event_name type string.event = cl_htmlb_manager=>get_event_ex(runtime->server->request ).if event is bound. if event->event_name eq 'portalEvent'. event_dataobject = event->event_server_name. event_sourceid = event->event_defined. split event->event_id at ':' into event_namespace event_name. if event_namespace = 'com.kimball.keg' and event_name = 'test_event'. event_text = event_dataobject. endif. endif.endif.
Listing 6 - BSP Event Receiver OnInputProcessing Coding
If we now create iViews for our BSP objects and then add them to our Portal Page, we have the final results from Figure 18.
19 Comments
