In order to achieve the objectives 1a-b and 2 which were stated in Part 8 of this tutorial: If a house is well-built, its details can be readily rearranged (DynamicRoadMaps:Part 8) “Complex-looking” code is sometimes the “simplest” (Dynamic RoadMaps:Part 6) “Complex-looking” code is sometimes the “simplest” (Dynamic RoadMaps:Part 6) When in doubt, de-multiplex! (Part 5 of Dynamic RoadMap Tutorial) Class-Data May be Cheating, but Who Cares? (Part 4 of Dynamic Road Map Tutorial) SAP UI Element Metadata: Gold or Fool’s Gold? (Part 3 of Dynamic RoadMap Tutorial) But how does the thermos bottle know? (Part 2 of Dynamic Road Map Tutorial) Exposing Critical SAP Code Paths as WebDynpro(ABAP) RoadMaps: One Case Where Dynamic UI Element Generation Might Be the Right Way to Go we need to create some metadata to permit the display of navigation trees like this: Figure A: and RoadMaps like this: Figure B: So to permit the display of the navigation tree in Figure A, we create the metadata table ZPRGTR_TREES: Figure C: with these rows in it: Figure D: And to permit the display of the RoadMapM in Figure B, we create the metadata table ZPRGTR_RMAPS: Figure E: with these rows in it: Figure F: Once having created and loaded these two metadata tables, we need some global itabs to store their rows in. So we type/declare these global itabs in the public section of our local copy ZCL_WDR_ALL_IN_ONE_UIELEM: Figure G1: Figure G2: and then load these global itabs in the init_meta_data method of ZCL_WDR_ALL_IN_ONE_UIELEM: Figure H: (By loading these “global” itabs in the class-method init_meta_data, we ensure that they will be available anywhere in the ZWDR_TEST_UI_ELEMENTS component that has addressability to some instance of ZCL_WDR_ALL_IN_ONE_UIELEM). Once we have the metadata available to us, we are now ready to begin the final round of code changes that will create the navigation tree shown in Figure A and the RoadMap shown in Figure B. In particular, consider the code in the original create method of CL_WDR_ALL_IN_ONE_UIELEM: Figure I: and compare it the code we now have in the create method of our local copy ZCL_WDR_ALL_IN_ONE_UIELEM: Figure J: (Note: in case anyone has forgotten, we “lifted” the “create context node” and “create data node” logic out of the original create_settings method and into our create_method because we need this code in our custom method create_lgcldb_tree as well as in the SAP-delivered method create_settings.) In Figure J, our custom method create_lgcldb_tree is used to create a “Logical Database” navigation tree like: Figure K: when a link like “Vendor Database” is selected from the lefthand library “Logical Databases”: Figure L: So inasmuch as create_lgcldb_tree is a method that already “works” satisfactorily, we know that we can easily clone this method as a new method create_prgtr_tree and modify this new method so that it creates a navigation tree from the metadata table zprgtr_trees (instead of the metadata table zldbn used to create the tree in Figure K.) And therefore, what we want to do next is: (I) add one line of code to our custom create method: (II) remove any code that has to do with the creation of navigation trees from the custom method create_settings_roadmap that we created earlier in this tutorial; (III) code up the new custom method create_prgtr_tree by cloning and modifying the existing method create_lgcldb_tree. Since this post is already a bit lengthy, we’ll defer task (III) for Part 10 of this tutorial, and close out this post by identifying the “tree-creation” code that has to be removed from our custom method create_settings_roadmap: Note: any reader who is (miraculously) still paying attention will notice that the above code only creates the root node of the navigation tree. And therefore, this reader is correct to ask why we don’t also have to remove the code that creates the lower-level nodes of the navigation tree. So, for any reader(s) wondering about this, the answer can be found earlier in this tutorial … we already removed this code from our custom method create_aggregatee_roadmap.