From the tutorial I’ve been doing on WDR_TEST_UI_ELEMENTS: The 25-Word-Or-Less “un-un-tutorial” on WDR_TEST_UI_ELEMENTS Learning what you don’t need is as important as learning what you do (Parts 10b-c) of “Event-Driven” Tutorial on WDR_TEST_UI_ELEMENTS) As James Carville said to Bill Clinton in 1992: “It’s the indices, stupid” (Part 10a of “Event-Driven” Tutorial on WDR_TEST_UI_ELEMENTS) An Archaeological “Dig” into SAP Metadata (Part 9 of “Event-Driven” Tutorial on WD-ABAP Component WDR_TEST_UI_ELEMENTS) When Presentation and Business Logic are Jumbled, Even Minor Housekeeping is Trickier Than It Should Be (Part 8 of Event-Driven Tutorial on WDR_TEST_UI_ELEMENTS) Sieving Presentation from Business Logic When the Business Application Area is Software Development (Part 7 of “Event-Driven” Tutorial on SAP-Delivered WDABAP Component WDR_TEST_UI_ELEMENTS) Apache Struts/M2 and SAP WebDynpro/MVC: Can these paradigms alone guarantee separation of business and presentation logic? (Part 6b of Tutorial on WDR_TEST_UI_ELEMENTS) Part 6a of Event-Driven Tutorial on WDABAP Component WDR_TEST_UI_ELEMENTS If you’ve written something in SAP from scratch, you (probably) haven’t bothered to understand what someone else has already done (Part 5 of “Event-Driven” Tutorial on WD-ABAP Component WDR_TEST_UI_ELEMENTS) Part 4 of “Event-Driven” Tutorial on the WD-ABAP Component WDR_TEST_UI_ELEMENTS. “Procedural” Recap of What’s Been Learned So Far in “Experiential” (“Event-Driven”) Tutorial on WD-ABAP component WDR_TEST_UI_ELEMENTS The class infrastructure of WDR_UI_TEST_ELEMENTS is exquisite for lazy cloning and change-ups. Experiential vs Procedural Tutorials: “Breaking” WDR_TEST_UI_ELEMENTS to Learn From It. it should be clear that very few structural changes have to be made to the SAP-delivered component WDR_TEST_UI_ELEMENTS in order to revise it into a custom component ZWDR_TEST_UI_ELEMENTS that displays an “SAP Logical Database Metadata” tray-view and tree-view like this: instead of the original kind of “SAP UI Element Metadata” tray-view and tree-view like this: As one can see by comparing this flow chart of the original WDR_TEST_UI_ELEMENTS component: with this flow chart of the revised ZWDR_TEST_UI_ELEMENTS component: all we really did in the tutorial was: a) remove the original methods that created a view element and its settings and events trays (e.g. the create_settings method); b)replace these methods with some code that just added four kinds of trays to the middle detail view, and then added appropriate links within these trays. But as noted at the beginning of the tutorial on WDR_TEST_UI_ELEMENTS, we want the revised component ZWDR_TEST_UI_ELEMENTS to do more than just display some useful information about the nodes of SAP Logical Databases. We also want the revised component to be able to display some useful information on what I originally called “Programming Trees” when constructing the metadata to display in the lefthand side Libraries view of the revised component: And it’s pretty clear that some of the information we want to display on these so-called Programming Trees is best displayed using RoadMap UI Elements. To see why this is so, consider the Programming Tree action link that I’ve called Document Numbers by Cost Center in the snapshot above. When this action link is clicked, I’d like the component to display the basic steps required to pre-fetch bkpf document numbers (belnrs) by cost centers (kostls), i.e. the steps that are incorporated into this form and the function it calls: FORM prefetch_kostl_belnrs. PERFORM get_kostls. CLEAR i_cobk. CLEAR i_coep. CALL FUNCTION ‘Z_GET_COSTCTR_BELNRS’ EXPORTING awtyp = v_bkpf TABLES i_kostl_range = i_kostl_range i_cobk = i_cobk i_coep = i_coep. LOOP AT i_cobk into wa_cobk. CLEAR wa_belnr_mstr. READ TABLE i_belnr_mstr INTO wa_belnr_mstr WITH TABLE KEY refbn = wa_cobk-refbn. IF sy-subrc = 0. v_work_len22 = wa_belnr_mstr-pattern_include. WRITE v_work_len22 to v_work_len4 RIGHT-JUSTIFIED. IF v_work_len4+0(1) = ‘1’. CONTINUE. ELSE. wa_belnr_mstr-pattern_include = wa_belnr_mstr-pattern_include + 1000. MODIFY TABLE i_belnr_mstr FROM wa_belnr_mstr. ENDIF. ELSE. wa_belnr_mstr-refbn = wa_cobk-refbn. wa_belnr_mstr-awtyp = wa_cobk-awtyp. wa_belnr_mstr-gjahr = wa_cobk-gjahr. wa_belnr_mstr-pattern_include = wa_belnr_mstr-pattern_include + 1000. INSERT wa_belnr_mstr INTO TABLE i_belnr_mstr. ENDIF. ENDLOOP. ENDFORM. FUNCTION Z_GET_COSTCTR_BELNRS. *”———————————————————————- *”*”Local Interface: *” IMPORTING *” REFERENCE(AWTYP) TYPE AWTYP *” TABLES *” I_KOSTL_RANGE STRUCTURE CSKS *” I_COBK STRUCTURE COBK *” I_COEP STRUCTURE COEP *”———————————————————————- CONSTANTS: c_ks(2) TYPE c VALUE ‘KS’, c_kokrs_len3(3) TYPE c VALUE ‘XXX’, c_lednr(2) TYPE c VALUE ’00’. DATA: wa_kostl_range LIKE LINE OF i_kostl_range, wa_cobk LIKE LINE OF i_cobk, wa_coep LIKE LINE OF i_coep, v_objnr(16) TYPE c, v_kostl_len11(11) TYPE c. LOOP AT i_kostl_range INTO wa_kostl_range. v_kostl_len11 = wa_kostl_range-kostl. SHIFT v_kostl_len11 RIGHT BY 1 PLACES. CONCATENATE c_ks c_kokrs_len3 v_kostl_len11 INTO v_objnr. SELECT objnr belnr gjahr kstar buzei INTO (wa_coep-objnr, wa_coep-belnr, wa_coep-gjahr, wa_coep-kstar, wa_coep-buzei) FROM coep * to get good read on index 1 WHERE lednr = c_lednr AND objnr = v_objnr. APPEND wa_coep TO i_coep. ENDSELECT. ENDLOOP. LOOP AT i_coep INTO wa_coep. SELECT SINGLE belnr gjahr refbn awtyp INTO (wa_cobk-belnr, wa_cobk-gjahr, wa_cobk-refbn, wa_cobk-awtyp) FROM cobk WHERE kokrs = c_kokrs_len3 AND belnr = wa_coep-belnr. APPEND wa_cobk TO i_cobk. ENDLOOP. ENDFUNCTION. Using the righthandside navigation tree that our component already displays, we can display the basic operational logic of this form and function as a hierarchical tree of tasks and subtasks. But to keep this tree simple and understandable, it would be nice if we could display the more detailed operational logic of this form and function using RoadMap UI elements that display when a particular node of the navigation tree is selected. So, the question then becomes: how should we incorporate a RoadMap display into the logic of our revised component? Following the example provided by SAP in DEMO_ROADMAP: we could hard-code each RoadMap we need. Or, following the example provided by SAP in WDR_TEST_EVENTS: we could be a little more dynamic. Or finally, following the example provided by SAP in WDR_TEST_UI_ELEMENTS: we could be a LOT more dynamic. Some folks will say that this is a standard decision-scenario of the type that used to be called the “Cold War Scenario”: “nuke ’em, negotiate, or surrender”. That is, some folks will argue that the middle road is the best one to take – to follow the example set by SAP in WDR_TEST_EVENTS. But what I’d like to do in the upcoming installments of this tutorial on dynamic road-maps is: i) explain in detail how SAP dynamically generates a RoadMap in WDR_TEST_UI_ELEMENTS using a whole bunch of complicated UI Element metadata; ii) try to show why this completely dynamic approach is exactly what we might want to emulate if we wish to have a robust component for displaying SAP critical code paths as Web Dynpro RoadMaps.