Skip to Content

Combining ABAP and Visual Composer


Wouldn’t it be nice to combine the output from the quick design and code free modeling environment of Visual Composer with the output from a full coding environment like Web Dynpro ABAP or BSP? Actually you can do just such a thing thanks to Portal Eventing.

Let’s take a look at just such an example.


Figure 1 – Sample Application

What you see in Figure 1 is the final application running within the SAP NetWeaver Portal. There are two separate iViews within this page. The top iView is a Visual Composer created report. It is displaying summarized data from SAP NetWeaver Business Intelligence combined with some details from SAP NetWeaver Master Data Management.

If you are interested in the inner workings of this Visual Composer report and how it is accessing SAP NetWeaver MDM via the Java APIs, you can find a break down of this part of the application here – Extending Visual Composer through Web Services Vol. 1  (The specified item was not found.).

The second iView is actually a Web Dynpro ABAP Component. The purpose of this iView is to show additional details about the selected record. It reads these details from SAP MDM using the ABAP APIs.

For the purpose of this weblog however we are less concerned about the inner workings of each iView and more focused on how to use Portal Eventing to connect the two.

What we want to accomplish is that when the user selects a record in the Visual Composer report, that an event is raise. This event should send across the MDM ID corresponding to the selected customer line. The second iView needs to respond to this event by pulling out the MDM ID from the event parameters and using it to display the correct details.

Triggering the Event from VC

Let’s start by taking a look at our Visual Composer application and seeing what must be done to trigger the Portal Event.

First we take a look at the VC Model.


Figure 2 – Visual Composer Model with Output Port

You can see in Figure 2 that we have defined an output port and that there is a single field, MDMId, attached to this port.

If we drill into our model we can see the tableView visualization of our data.


Figure 3 – Table Outbound Event

Figure 3 shows us that we have a single event coming out of the tableView which leads us to the mdmOut Output Port.

Finally in Figure 4 we see the details of the Output Signal itself. This is where we can choose what fields should be included as event parameters. Also note the full name of the EPCM event in the property box. We will need that event name later when setting up the Event Handler logic in Web Dynpro ABAP.


Figure 4 – Details of the Output Signal

Capturing the Event within Web Dynpro ABAP

From the Web Dynpro Component side, up to a point we are going to follow the normal process of setting up to receive a portal event. Although I will cover these steps in detail here, you may also want to refer to some additional reading on the subject of Portal Eventing in Web Dynpro ABAP:

On-line Help for Web Dynpro ABAP and Portal Integration

Portal Eventing; A Solution for Global Peace and Harmony?

In general Portal Events are nicely integrated into the Web Dynpro ABAP as Actions. We need to start the process of adjusting our Web Dynpro Component by creating an Action that we will designate as our Event Catcher.


Figure 5 – Web Dynpro Action for Portal Event

Now if we go to the methods screen we can see that we have a new event handler method that has been generated for our action.


Figure 6 – Web Dynpro Portal Event Handler

We first need to tell the Portal that our Web Dynpro View wants to receive this event. We can do this within the WDDOINIT method of our View with a small snippet of coding. You can even use the Web Dynpro Code wizard and it will generate all the following coding except the actual event names for you.

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 = ‘’      portal_event_name      = ‘mdmOut’      view                   = l_wd_view      action                 = ‘CATCH_EVENT’         ).endmethod.

Notice the Event Namespace and Name. These are the values from earlier that we saw in the Output Signal. Just be sure to append ‘urn:’ to the front of the EPCM Event name that you used in the VC Output Signal.

Now all we need is the coding in our ONACTIONCATCH_EVENT that will respond to the event. Mostly this logic will take the input parameter, WDEVENT, and extract the event name and event parameter string from it. Then we want to set the MDMId back into our controller context and then call the controller methods that read the detailed information from MDM.

method onactioncatch_event .  data: evt_name type string,        evt_parameter type string.  evt_name = wdevent->get_string( name = ‘PORTAL_EVENT_NAME’ ).  if evt_name = ‘mdmOut’.    evt_parameter = wdevent->get_string( name = ‘PORTAL_EVENT_PARAMETER’ ).    data params type sdokproptys.    call function ‘Z_BAPI_PARSE_VC_PARAMS’      exporting        i_param_string = evt_parameter      importing        et_params      = params.    data: wa_param like line of params.    read table params into wa_param with key name = ‘MDMId’.    if sy-subrc = 0.      data:         node_importing                      type ref to if_wd_context_node,         elem_importing                      type ref to if_wd_context_element,         stru_importing                      type if_v_mdm_cust_dtls=>

element_importing ,

         item_mdm_id                         like stru_importing-mdm_id.

  •   navigate from <CONTEXT> to <IMPORTING> via lead selection

      node_importing = wd_context->get_child_node( name = if_v_mdm_cust_dtls=>wdctx_importing ).

  •   get element via lead selection

      elem_importing = node_importing->get_element(  ).

  •   get single attribute



          name =  `MDM_ID`

          value =  wa_param-value ).

      data: l_ref_mdm_api_call_read_de type ref to ig_mdm_api_call_read_de .

      l_ref_mdm_api_call_read_de =   wd_this->get_mdm_api_call_read_de_ctr( ).

      l_ref_mdm_api_call_read_de->execute_z_rfc_mdm_teched_rec_r( ).




After studying the code, you might be asking yourself what the call to Z_BAPI_PARSE_VC_PARAMS is needed for. Well the event parameter string that is created by Visual Composer is a little complicated. It has the potential to carry a lot of information. Even in our case where we only have the MDMId as a parameter, the string looks like this:


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