Season 4 Episode 14
Its taken us a little while after SAPPHIRE to get our schedules to align enough to be able to record a podcast, but in this episode we look back at the event and share some of our experiences. Keep in mind we aren’t the typical attendees, since both Craig and I worked extended times on the show floor pods. We therefore share some of the common questions we were hearing from attendees.
Craig also breaks down the new Developer License which was announced at SAPPHIRE. Finally free, perpetual click-through developer licenses – something many in the development community have been requesting for a long time.
As we prepare for a summer break we also look ahead to upcoming events over the summer (like the fact that Rich, Craig and I will all be in Walldorf at the end of June) and even preparations for TechEd. Believe it or not, we are already in full content creation mode for TechEd and we have some amazing new content already being cooked up.
Running Time: 39:42
If you have questions, suggestions, or topic ideas for future episodes, give us a shout here.
Hi all. Some of you already know from having talked to you this week at SAPPHIRENOW in Orlando, but I just wanted to put out a note to the rest of the community as well, and tell you that I am transferring from the EPM CSA(Enterprise Performance Management Customer Solution Adoption) group into the HANA Product Management group where I will be working along side my friend, fellow egeek, and colleague, Thomas Jung. I’ve been working on BPC NW since joining SAP back in 2007, and I have always wanted to work on the technology side of the house rather than on a specific application, so this new role will give me a chance to dig deep into the technology platform, and of course HANA specifically. My focus will be on HANA development tools, SQLScript, ABAP on HANA, etc., so I plan to get back in touch with the developer community very soon with more content on SCN, as well as here on enterprisegeeks.com. My disconnect from the developer community in the last 5 years is something that has always bothered me on some level, so I am very excited to re-engage.
It has been a great ride working with the EPM team. From the BPC architecture team where I started, through BPC solution management, and finally the EPM CSA team, I’ve worked with some of the best people on the planet, and I am grateful for it, and humbled by it. We’ve done some incredible things in the last 5 years with BPC and it will only get better in the future. So my best wishes to all my colleagues in the EPM solutions area.
So thanks and see ya later to the EPM group, and hello to the HANA Product Management team. I can’t wait to get started, lets push in-memory computing to its limits and beyond!
In the last blog, I discussed techniques for accessing the HANA Catalog information from ABAP and how to create an ABAP internal table from a HANA object without a matching data dictionary object. You can probably tell that I’m building up to a tool which can function as a generic HANA catalog viewer, showing both metadata about HANA database objects and a content preview. Before I build that tool, I want to make selection of the catalog objects as simple as possible. Therefore I would like to implement an ABAP Search Help which gets its data from HANA instead of the underlying ABAP database. Ultimately I want it to work in the UI like the following video. Please note: I’m running NetWeaver 7.31 so I have the SuggestValues feature which was new in NetWeaver 7.02. However ultimately the solution here is a normal Data Dictionary Search Help which could be used on any ABAP release level.
The source code for this example can be downloaded here. It contains the Search Help defintion, the Function Module/Group for the Search Help exit implementation and the DDic Structure with the search help binding which allows the connection between the importing parameters. Please note that you will also need to download the source code content from my previous blog as well.
Search Help Exit
Normally when an ABAP developer implements a Search Help, they only supply the name of the underlying table or view and all the selection work is done for them by the Search Help framework. In this case, however, I needed complete control over the selection logic so that I could use ADBC and my HANA Catalog Utility class from the previous blog in order to query the HANA database for available objects.
The definition of the Search Help itself isn’t all that special in this case. I need to know the currently selected Database Connection, Schema, and Object Type (Table or View) in order to perform a query. Therefore I map these fields as my importing parameters for the Search Help.
The major difference comes in the fact that the selection method is blank in this search help. Instead I supply the name of a function module – ZHANA_OBJECT_SEARCH as the Search help exit. This function module must have a pre-defined interface, but can then function as the implementation of my search help.
Search Help Exit Function Module
All search help exit function modules, must have the same function interface so that it can be called by the search help framework.
function zhana_object_search. *"---------------------------------------------------------------------- *"*"Local Interface: *" TABLES *" SHLP_TAB TYPE SHLP_DESCT *" RECORD_TAB STRUCTURE SEAHLPRES *" CHANGING *" VALUE(SHLP) TYPE SHLP_DESCR *" VALUE(CALLCONTROL) LIKE DDSHF4CTRL STRUCTURE DDSHF4CTRL *"----------------------------------------------------------------------
There are various control steps in the processing of the search help exit which can be used to over ride processing of the various search help events. The only one which we need to implement in this case is the callcontrol-step of SELECT. This is the primary query event of the search help. From this event we can read the current importing values from the shlp-selopt table.
if callcontrol-step = 'SELECT'. data lr_model type ref to zcl_hana_catalog_utilities. data ls_search type zhana_obj_search. field-symbols <ls_selopt> type ddshselopt. data lx_root type ref to cx_root. read table shlp-selopt with key shlpfield = 'CON_NAME' assigning <ls_selopt>. if sy-subrc = 0. ls_search-con_name = <ls_selopt>-low. endif. read table shlp-selopt with key shlpfield = 'SCHEMA' assigning <ls_selopt>. if sy-subrc = 0. ls_search-schema = <ls_selopt>-low. endif. read table shlp-selopt with key shlpfield = 'OBJ_TYPE' assigning <ls_selopt>. if sy-subrc = 0. ls_search-obj_type = <ls_selopt>-low. endif. read table shlp-selopt with key shlpfield = 'OBJ_NAME' assigning <ls_selopt>. if sy-subrc = 0. ls_search-obj_name = <ls_selopt>-low. endif.
Now that we have all of our search input criteria, we can use the HANA Catalog Utilities class from the previous blog to search for all tables or views which match those criteria. Here is a subset of that logic. See the downloadable source code sample for complete implementation.
create object lr_model exporting iv_con_name = ls_search-con_name. if ls_search-obj_type = 'T'. "table data lt_tables type zhana_tables. field-symbols <ls_table> like line of lt_tables. lv_table = ls_search-obj_name. lt_tables = lr_model->get_hana_tables( iv_schema = lv_schema " Schema iv_table = lv_table " Table (can be wildcard with %) iv_max_rows = callcontrol-maxrecords ). " Maximum Number of Rows ****Map to LT_SHLP loop at lt_tables assigning <ls_table>. append initial line to lt_shlp assigning <ls_shlp>. <ls_shlp>-con_name = ls_search-con_name. <ls_shlp>-obj_type = ls_search-obj_type. <ls_shlp>-schema = ls_search-schema. <ls_shlp>-obj_name = <ls_table>-table_name. endloop. else.
The final activity is to place the query results back into the search help. This is done by calling the function module F4UT_RESULTS_MAP.
call function 'F4UT_RESULTS_MAP' exporting source_structure = 'ZHANA_OBJ_SEARCH' * apply_restrictions = abap_true tables shlp_tab = shlp_tab record_tab = record_tab source_tab = lt_shlp changing shlp = shlp callcontrol = callcontrol exceptions illegal_structure = 1 others = 2. if sy-subrc <> 0. endif.
Structure for Parameter Mapping
The final step in order to get the input parameter mapping shown in the video to work within Web Dynpro is to map the search help into a data dictionary structure and the use that structure for the basis of the Web Dynpro Context Node. The importing parameters from other attributes in this Context Node will then be transferred automatically by the framework (even for Suggest Values).
You can make the explicit assignment of the new search help to the OBJ_NAME field and then use the Generate Proposals button to automatically map the input fields of the search help to the corresponding fields of the structure.
The final step is to use this structure as the source Dictionary structure of the Context Node and you have the Value Help working as described in the video at the opening of this blog.