Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member181923
Active Participant
0 Kudos
Part 2 of this tutorial (But how does the thermos bottle know? (Part 2 of Dynamic Road Map Tutorial)) took us one-third of the way toward the objective stated in Part 1 of this tutorial (Exposing Critical SAP Code Paths as WebDynpro(ABAP) RoadMaps: One Case Where Dynamic UI Element Gene...). In particular, our modified component ZWDR_TEST_UI_ELEMENTS now behaves in two different ways depending on which Library tray an action-link is selected from. If an action link is selected from the Logical Database tray, the component will display a navigation tree on the right and four detail trays in the middle (once a lower-level Logical Database node is selected from the navigation tree) But when an action link is selected from the Programming Trees tray, the component will behave AS IF the RoadMap action link had been selected from the Standard tray in the original SAP-delivered component WDR_TEST_UI_ELEMENTS. In particular, it will display this RoadMap navigation tree on the right and this sample RoadMap view in the middle (plus two trays for RoadMap settings and events). (Note: snapshot has been truncated on the right.) So the next tasks we have to accomplish are pretty obvious. First, when the Document Numbers by Cost Center action-link is selected, we want the righthand side navigation tree to display the basic steps involved in pre-fetching bkpf belnrs by kostl (document numbers by cost center), e.g. a tree with a hierarchical structure like this: Pre-Fetch BKPF Document Numbers by Cost Center 1. Get an itab of cost centers 2. Find belnrs in the coep table for each cost center. 2.1 Construct object number for each cost center 2.2 Look up belnrs for each object number 3. Find the refbn in the cobk table for each coep belnr Second, when some node of this tree is selected, we want the component to display a roadmap that provides more detail. For example, if node "2.1" is selected, we want the component to display a road-map with a set of steps like: 2.1.1 Determine kokrs value to be used 2.1.2 Concatenate kokrs to constant 'KS' 2.2.3 Concatenate kostl to kokrs+'KS' But if node "1" is selected from the navigation tree, we want the component to display a road-map with a set of steps like: 1.1 Read selection-options table 1.2 Transform any ranges to 'EQ' lists 1.3 Place results in an itab. Finally, we want to use the settings and events trays of the SAP-delivered display for other purposes that we'll get to later on in this tutorial. To accomplish these three goals, it's clear that the best way to proceed is to learn exactly how the original SAP component builds a RoadMap view (plus its associated settings and events trays) using the three methods create_settings, create_events, and create_aggregations of the class CL_WDR_ALL_IN_ONE_UI_ELEM. Once having learned what SAP does, we can not only modify the SAP code to do what we want, but we've also learned the general way in which SAP builds any kind of UI Element from scratch. And this is the kind of knowledge that can come in handy on many different kinds of WebDynpro ABAP applications. But in order to learn what's going in the create_settings, create_events, and create_aggregations methods of the class CL_WDR_ALL_IN_ONE_UI_ELEM, we have to learn a lot more about the init_meta_data method of this class and how it uses five SAP UI Element metadata tables: wdy_ui_elem_def wdy_ui_prop_def wdy_ui_event_def wdy_ui_evpar_def wdy_ui_aggr_def So to make this learning process simpler, this post will conclude by displaying all the rows from these five tables that have anything to do with the UI elements ROAD_MAP and ROAD_MAP_STEP. The reason for doing this is to show (in the next post of this tutorial) how the metadata in these rows can be used to "cut-down" the amount of analysis we have to perform in order to understand what SAP is doing in the init_meta_data, create_settings, create_events, and create_aggregations methods of the class CL_WDR_ALL_IN_ONE_UI_ELEM. In particular, we can make a "workcopy" of each of these methods and cut out from these copies all the conditional "IF/ELSEIF/ELSE" legs that execute for metadata properties which the ROAD_MAP and ROAD_MAP_STEP UI ELEMENTS do NOT have. The result will be versions of these four methods that will tell us everything we need to know about dynamic RoadMaps, and nothing else we don't want to know (yet ...). ******************************************** ROAD_MAP: rows in wdy_ui_elem_def ******************************************** ******************************************** ROAD_MAP: rows in wdy_ui_prop_def ******************************************** ******************************************** ROAD_MAP: rows in wdy_ui_event_def and wdy_ui_evpar_def ******************************************** ******************************************** ROAD_MAP: rows in wdy_ui_aggr_def ******************************************** ******************************************** ROAD_MAP_STEP: rows in wdy_ui_elem_def ******************************************** ******************************************** ROAD_MAP_STEP: rows in wdy_ui_prop_def ********************************************