Skip to Content

<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.

image

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.

image

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.

image

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.

image

Figure 4 – Button Properties

image

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.

*!https://weblogs.sdn.sap.com/weblogs/images/1918/pe_6.jpg|height=324|alt=image|width=469|src=https://weblogs.sdn.sap.com/weblogs/images/1918/pe_6.jpg|border=0!

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.

image

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.

image

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.

image

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.

image

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.

image

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.

image

*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.

image

Figure 13 – iView Wizard Template Selection

image

    *Figure 14 – iView Wizard – General Properties

  • </p>

image

*Figure 15 – iView Wizard – Application Variant

*

We can now combine these two iViews together into a Portal Page.

image

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.

image

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.

!https://weblogs.sdn.sap.com/weblogs/images/1918/pe_19.jpg|height=239|alt=image|width=588|src=https://weblogs.sdn.sap.com/weblogs/images/1918/pe_19.jpg|border=0!</body>

To report this post you need to login first.

19 Comments

You must be Logged on to comment or reply to a post.

  1. Tom Spishock
    Hi Thomas.
    I developed both of the apps (WebDynpro and BSP) from your weblog. They appear to be OK in the EP (6.0) .. but the eventing in both does not seem to be happening. Perhaps you can give me a few clues on why not… or what to check (as in a checklist)?
    (0) 
    1. Thomas Jung Post author
      The main reason that I have seen eventing not work is because of the domain of the two servers (or the portal) is different.  See this limitation from the online help:
      Due to JavaScript restrictions, all participants (the portal server and all used servers) must be in the same domain when client eventing is used.
      http://help.sap.com/saphelp_nw2004s/helpdata/en/79/3857422d095542e10000000a1550b0/frameset.htm

      I have had to setup DNS alias in the past to make it appear as though all severs are in the same domain.

      (0) 
  2. Hubert Wallace
    Let Say I have a BSP and WD4A in one page doing the eventing. But once the user as moved the data from the BSP to the WD4A page, I have it stored in the context, and I wish to move forward, say to another WD4A screen, replacing the entire page, is this possible? Also can the eventing be done without the 2 views being on the same page? So on the BSP page you click a button which takes you to the WD4A page.
    (0) 
    1. Thomas Jung Post author
      To your first question – Not exactly.  Once the data is in the WDA application context it is saved and you could navigate via plugs and either retain the same controller context or pass the data via the plug/component interface.  However to make the WDA application full page, you would need to be doing navigation within the portal – replace one portal page with another so you can have a different layout.  The closest I can think would be to cheat and do the navigation in WDA and throw another event to BSP, so that the application within that iView at least minimizes itself.

      Your second question – now both iviews must be within the same page.  Technical portal eventing is done via JavaScript (since it is client side based eventing) and is just cross frame communication. 

      (0) 
  3. N Kumar
    first of all thanks alott for your great Blogs!!!

    i have little query. after completing the 2 ABAP WDA’s in SE80, while deploying in the Portal, i dont know how to connect those and how to call?

    what i did is i created the 2 i views related to corresponding 2 ABAP WDA’s in the portal, BUt i dont know how to connect these and how to run in the portal…so please kindly helpme out abt this problem.

    Thanks & Regards,
    NKUMAR

    (0) 
  4. sekhar dhara
    Thomas,

    Thankyou for your nice Blog. We have a situation where eventing seems like the solution but we are not too sure.

    We have a BSP application with multiple Tabs on a tab strip control.

    On one of the tabs we wanted to invoke an iview of a WEB Dynpro ABAP application. However, we wanted to pass a parameter to the web dynpro application as we invoke the iview.

    In your example, you had both the BSP and webdynpro already deployed and existing on the same page. Here the Webdynpro app is not (yet) on the same page and not deployed yet. Do you see this as a case for eventing? If not do you have any ideas as to how we could pass the parameter to the Webdynpro app.

    Thanks in advance
    – Sekhar Dhara

    (0) 
    1. Thomas Jung Post author
      Portal eventing requires that each application is a separate iView.  It can not be used as you describe with one application imbedded within another (as in within a tabstrip). 

      If you absolutely need this kind of functionality, you would have to look at using an iFrame within the BSP application; but be careful as managing the state of the inner Web Dynpro ABAP application will not be easy.  You could always pass a parameter to the WDA application via URL parameter. 

      (0) 
    2. Chandrashekhar Mahajan
      Hi Thomas,
      Really very nice blog..
      i have implemented the communication betn 2 iView of WD application. but facing problem while communicating betn BSP iView to WD iView.

      the event from BSP is not triggering.

      Do u have any suggestion on this. please let me know.

      Regards,
      Chandra

      (0) 
  5. Chandrashekhar Mahajan
    Hi Thomas,
    Really very nice blog..
    i have implemented the communication betn 2 iView of WD application. but facing problem while communicating betn BSP iView to WD iView.

    the event from BSP is not triggering.

    Do u have any suggestion on this. please let me know.

    Regards,
    Chandra

    (0) 
    1. Thomas Jung Post author
      Are the BSP and Web Dynpro applications on the same server?  If not do they share the same domain?  After domain relaxation, they have to be in the same domain otherwise you will get a cross site scripting error in the browser.  

      If that isn’t the case, make sure your BSP application has Portal Integration selected on the Application properties.  These are the two most common problems with portal eventing and BSP.

      (0) 
  6. Lokesh Kamana
    Hi,
    ITs a very good blog.
    Nice work.
    i have the same scenarion.
    But my requirement is have web dynpro java iview & BSP Iview.
    Does portal eventing works fine between this two.
    If it works.
    Plaese give me an idea to do this

    Thanks,
    Lokesh

    (0) 
  7. Kevin Head
    Thanks Thomas. This is a very interesting read.

    Is there a similar way to have a web dynpro application iView event/call an SAP Transaction iView?

    As an example, I have a table of maintenance notifications and I want the user to be able to select a notification and click a button that launches the IW22 native R3 transaction.

    Is this possible? I can not see it within SDN.

    Thanks.

    (0) 
    1. Thomas Jung Post author
      I don’t believe that is possible.  The Portal Eventing framework is limited to JavaScript based applications, BSP, JSP, Web Dynpro ABAP and Java and Visual Composer.  There is no interface for this into the transaction iView (SAPGUI for HTML, Windows, or Java based).  You might consider using object based navigation instead.  Either that or you could have a BSP/JSP wrapper around an iView that actually housed the ITS transaction.  You could throw the portal event to the BSP/JSP and then reload the ITS WebGUI URL with new URL parameters in the iFrame.  Not quite as nice as portal eventing, but it might work as sort of “hack”.
      (0) 

Leave a Reply