Last July, with a senior ABAP colleague, our goal was to insert into a java web dynpro portal application the classic “F4″search-help via web-service, without the possibility to use RFC to connect to the SAP ECC system.
I found a lot of blogs, various documentation on SVS, EVS and OVS with “OVSProvider” implementation, and also the OVS via web-service step by step. In all of this solutions the requirement was: the host webdynpro that wants to use an OVS must have the specific search-help know-how, like functions to call, or like the node context of input field, and the node for output search.
So I wanted to realize through dynamic programming a webdynpro component to call anytime I need it, by passing only the IDENTIFIER of the search-help and receiving the opportune KEY-value (e.g. I pass an identifier like “CUSTOMER” and I receive back the key value of “KUNNR” attribute, or I pass “MATERIAL” and I get back the “MATNR” code number).
In this youtube video you can see it in action: http://www.youtube.com/watch?v=SjRBxz93YVY
The pop-up search-help is a java webdynpro dc with a dynamic user interface, and it uses only two backend functions to connect to a SAP ECC system. In this implementation there are two webservices, but it works also with two normal RFC; same consideration about Netweaver version, the idea is valid also for NW 7.0
The first function gives all the necessary information to build the user-interface (the meta information of the search-help), while the other function executes the search. Both functions are implemented with ABAP dynamic programming.
These two functions use two custom tables, that need to be maintained. One containing the relative information to each SEARCH-HELP and the other containing the data for multi-language support.
Here you can download the java webdynpro sources, the ABAP implementation and an excel file with tables structure and examples of table DATA:
Integrate GOVS dc into your component with “manual” lifecycle: into one user view you can use more than one search-help.
Here follow three examples of integration of GOVS dc into the “wdDoInit” method of view user interface.
Example 1: use the context binding for the DATA
IWDComponentUsage dataCompUsageCC_GOVS1 =
},// this OVS provider works without EVENT, and need all necessary context BINDINGS// between the host webdynpro and the GOVS dc.
wdComponentAPI,//GOVS receive the context control
"CUSTOMER",//F4 identifier//node that will receive output results
wdContext.nodeMachCodeHere(),//this attribute of the node will be SET to the selected CODE
"thisAttribute",//this attribute of the node will be SET to the selected DESCRIPTION
"thisAttributeDescr",//set a DEFAULT KEY_CODE value to assign into search-help inputs
Example 2: use the EVENT callbackIWDComponentUsage dataCompUsageCC_GOVS3 =
},//This OVS provider return the search-help result with an EVENT method
"customer",//F4 identifier//set a DEFAULT KEY_CODE value to assign into search-help inputs
null);//using the GOVSProviderOnEVENT need to bind an EVENT-HANDLER of host webdynpro to GOVS EVENT//obtain the GOVS interface controller
IExternalGOVSCompInterface intGOVS3 =
this third example really uses the first OVSProvider implemented and it is a mix of the other two, basically it uses context bindings and with the last boolean parameter specifies whether to use the EVENT callback.IWDComponentUsage dataCompUsageCC_GOVS2 =
This is just one of the realization ways, I haven’t dedicated all of my time and it could be improved. It is not strongly tested, and then consider this as a functional beta release.
In any case I like this realization and I share this solution with my pleasure. Take a look inside the code, try to use it and, please, if you do any change or have any suggestions do not hesitate to contact me.