From the tutorial I've been doing on WDR_TEST_UI_ELEMENTS:

StructuralSummary
Part10bc
Part10a
Part9
Part8
Part7
Part6b
Part6a
Part5
Part4
ThirdPost(ProceduralRecapOfParts1and2
SecondPostAndComments
FirstPostAndComments

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.