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.
< br>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 at - Extending Visual Composer through Web Services Vol. 1.
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.
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( ).
portal_event_namespace = 'urn:com.sap.vc:epcm'
portal_event_name = 'mdmOut'
view = l_wd_view
action = 'CATCH_EVENT'
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'
i_param_string = evt_parameter
et_params = params.
data: wa_param like line of params.
read table params into wa_param with key name = 'MDMId'.
if sy-subrc = 0.
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
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( ).
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:
Figure 7: Event Parameter String
Of course we could sit here and pick apart the string in coding, but we don't have to. Someone has already done the job for us. Scott Cairncross from the US RIG, was nice enough the share the function module that he wrote to parse out the parameter elements. Its use, seen above, shows how all the individual parameters are returned in an easy to use internal table.
*" VALUE(I_PARAM_STRING) TYPE STRING OPTIONAL
*" VALUE(ET_PARAMS) TYPE SDOKPROPTYS
l_string type string,
lt_rows type table of string,
lt_row type table of string,
lt_param type table of string,
l_row type string,
l_param type string,
l_temp type string,
ls_param type sdokpropty.
call function 'Z_BAPI_ASCII_CODE_TO_CHAR'
hex_string = i_param_string
char_string = l_string.
split l_string at 'Row' into table lt_rows.
loop at lt_rows into l_row.
if sy-tabix eq 1. continue. endif.
split l_row at space into table lt_row.
loop at lt_row into l_param.
if l_param eq space. continue. endif.
split l_param at '=' into table lt_param.
if sy-subrc eq 0.
loop at lt_param into l_temp.
ls_param-name = l_temp.
replace all occurrences of '"' in l_temp with ''.
ls_param-value = l_temp.
insert ls_param into table et_params.
*" VALUE(HEX_STRING) TYPE STRING
*" VALUE(CHAR_STRING) TYPE STRING
class cl_abap_conv_in_ce definition load.
result_wa type match_result,
l_temp type string,
l_char_string type string,
l_code(2) type x value is initial,
l_result type c,
l_offset type i,
l_place type i.
find first occurrence of '%' in hex_string results result_wa.
if sy-subrc eq 0.
l_offset = result_wa-offset.
l_temp = hex_string+l_offset(3).
shift l_temp left.
l_code = l_temp.
shift l_code right in byte mode.
call method cl_abap_conv_in_ce=>uccp
uccp = l_code
char = l_result.
l_place = l_offset + 3.
if l_result ne space.
concatenate hex_string(l_offset) l_result hex_string+l_place into char_string.
concatenate hex_string(l_offset) hex_string+l_place into char_string separated by space.
call function 'Z_BAPI_ASCII_CODE_TO_CHAR'
hex_string = char_string
char_string = char_string.
char_string = hex_string.
Capturing the Event within BSP
So what happens if you are doing development with Visual Composer, but you don't have a backend Netweav04S ABAP system yet and therefore can't do Web Dynpro ABAP Development? Well Web Dynpro ABAP isn't the only tool from the ABAP world that can also interact with Portal Eventing.
Portal Eventing works just fine from BSP applications as well. You can use the same function modules as the Web Dynpro Example to parse the Visual Composer specific event string. All you need to know how to do then is to respond to a Portal Event from BSP.
Please Note: This section is an excerpt from the SAP Press Book, Advanced BSP Programming.
<%@page language="abap" %>
<%@extension name="htmlb" prefix="htmlb" %>
<%@extension name="bsp" prefix="bsp" %>
<htmlb:page title="Portal Event Receiver">
<bsp:portalEvent name = "urn:com.sap.vc:epcm"
namespace = "mdmOut" />
These portal events can then be trapped and responded to by BSP server-side event handlers. The HTMLB event manager will return details about the Portal event. The key here is to look for any event name called portalEvent.
DATA: event TYPE REF TO if_htmlb_data.
data: parameter_string type string.
event = cl_htmlb_manager=>get_event_ex(
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.
parameter_string = event_dataobject.
This content is reposted from the SAP Developer Network.
Copyright 2006, SAP Developer Network
SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.