Skip to Content

SAP has  introduced support for search help as a data source since version SAP NetWeaver Gateway 2.0 SPS 08. This blog servers as a step by step guide to implemented an Odata service for elementary search help using service builder.

Before we being with the steps for creation, below are some of the limitations for this service as noted on the help.sap portal page for gateway development.

  • Only elementary search helps are supported. Collective search helps are not supported.
  • Search helps that call UI in their exit function are not supported, as this cannot be validated by the Service Builder.
  • At runtime, a query operation that is based on a search help data source can retrieve a maximum of 9,999 entries.

For this blog i am going to use a simple, custom search help with two input and out parameters. The hitlist upon execution displays the equipment type code and description. The search help interface is shown in the figure attached belowShlp_interface.png

  1. Create a new project and select Data Model>Import>Search Help to bring up the entity creation wizard. On step 1 of the wizard choose ‘Search help’ from the Data Source Attribute> Type dropdown and enter or select the search help for which you need to create oData service. Click Next when done.

Step1_1.png

Step1_2.png

2.     In step 2 of the wizard, select the structures from search help result table that you want to use for modeling your entity. On the next screen set the properties you want as keys and click finish. As a rule of thumb you should select all properties that have ‘IMP’ flag set in the search help definition as your keys of the entity type definition ( only properties marked as ‘Key’ can be used to import values from the consumer client ).

Step2_1.png

Step2_2.png

     Check your service for consistency.

Step2_3.png

3.     Create EntitySet for the entity type created in previous step.

Create_entity_set_1.png

4.     Map the datasource (Searchelp) to the Read and Query operations of the Entity Set created in previous step. All Entity type properties marked as Key in step2 have to be mapped ( in addition to proposed mapping ) as import parameters when mapping datasource for Read query.

          * Only the Query and Read operations can be mapped for entity sets derived from the search help data source

Step4_1.png

Step4_2a.png

Step4_3a.png

5.     Generate the runtime artifacts by clicking on the ‘Generate Runtime Objects’ button and check the project consistency by clicking the check button.

Step5_a.png

6.     Register your service on all systems which have the GW_CORE component installed. Remember that the External service name will be default to the technical service name.

Step6.png

7.     Using the netweaver gateway client ( on your gateway hub system or local – depending on architecture) you can test the service to ensure it works as expected.

successful gateway query.png

8. If you leave development at this stage  you will notice that filtering ( using $filter ) will not work. I think this is a bug, if someone notices differently please leave a comment and I will remove the portion hereon.

To enable filtering for Entity set data, the ‘EnttitySetName_GET_ENTITYSET’ method of the Data provider class extension class (ZCL_ZCA_TEST_EQUIP_TYP_DPC_EXT->EQUIPMENTTYPECOL_GET_ENTITYSET for this example) is redefined and the following code needs to be added in.

To redefine the method copy code from the data provider class and modify it with the following code snippets.

In the data declaration section :

Filter_enh1.png

****** Added to handle missing code for filter functionality *********

  DATA: ls_filter_select_options LIKE LINE OF lt_filter_select_options.

  DATA: ls_select_option_values  TYPE /iwbep/s_cod_select_option.

Just before the call for search help values is made using method 

me->/iwbep/if_sb_gendpc_shlp_data~get_search_help_values( )

Filter_enh2.png

**** Add missing code to allow for filtering of records **********

  IF NOT lt_filter_select_options[] IS INITIAL.

    LOOP AT lt_filter_select_options INTO ls_filter_select_options.

      ls_seloptshlpname  = ‘ZPMH_TAR_EQART’.

      ls_seloptshlpfield = ls_filter_select_optionsproperty.

      LOOP AT ls_filter_select_optionsselect_options INTO ls_select_option_values.

        ls_seloptsign     = ls_select_option_valuessign.

        ls_seloptoption   = ls_select_option_valuesoption.

        ls_seloptlow      = ls_select_option_valueslow.

        ls_selopthigh     = ls_select_option_valueshigh.

        APPEND ls_selopt TO lt_selopt.

      ENDLOOP.

      CLEAR ls_selopt.

    ENDLOOP.

  ENDIF.

Now if you try filtering the oData result set you will get only relevant response as shown in the figure below.

/wp-content/uploads/2015/04/filter_enh_result_690666.png

To report this post you need to login first.

3 Comments

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

    1. Vivek Priyadarshi Post author

      Hi Pavan,

      The search help exit (ZPMH_EXIT_EQUART) is a function module with has the same interface structure as FM: F4IF_SHLP_EXIT_EXAMPLE. Search help exit can be used when the selection logic for processing is more complex than just a direct select from a single database table. For more information refer this link.

      In my example the search help is not doing much, it is just appending some tags and formatting the output result before it is displayed to the user.

      Hope this helps

      Regards,

      Vivek

      (0) 
      1. Pavan Golesar

        Hi Vivek,

        Can we say to ease the data extraction from db we can have serarch help.

        For example: XD02, , If based on Company code

        we can have sales area options populated.

        and yes, Your blog is Cool, Its really quite helpful !! 🙂

        Esp. The documentation is too clean and tidy. 😎

        Regards,

        Pavan G

        (0) 

Leave a Reply