As of Part 9 of this "event-driven" tutorial on the WD-ABAP component WDR_TEST_UI_ELEMENTS: An Archaeological "Dig" into SAP Metadata (Part 9 of "Event-Driven" Tutorial on WD-ABAP Component WD... When Presentation and Business Logic are Jumbled, Even Minor Housekeeping is Trickier Than It Should... Sieving Presentation from Business Logic When the Business Application Area is Software Development ... Apache Struts/M2 and SAP WebDynpro/MVC: Can these paradigms alone guarantee separation of business a... 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 ... 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-A... 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. we had modified our clone component ZWDR_TEST_UI_ELEMENTS so that when a lower-level node of an Logical Database is selected from the right-hand tree-view, the middle detail view displayed these three trays: 
If SAP always used explicit columns in the WHERE and SELECT clauses of the "PUT" SELECT associated with any node "NodeX" of a Logical Database, then the information in the first two of these trays would tell anyone writing back-end retrieval web-services a whole lot about what particular SAP logical metadata are critically associated with NodeX. But sometimes (often?), the SELECT and WHERE clauses of "PUT" selects contain variable lists of columns determined by the customer at run-time. And in such cases, no useful information about SAP logical metadata can be gained from the SELECT and WHERE clause columns of a "PUT" select. (Of course, I will refrain from editorializing on the headaches that this practice also causes Basis Admins and developers, who have to figure out exactly what kind of machine-thrashing run some customer has just thrown in the queue, and then explain to him or her that CPU cycles and memory are not yet available in infinite quantities.) To help ameliorate this problem in the component under development, we can add a fourth tray to the three we already have. When some lower-level node NodeX is selected from the treeview on the right, e.g. the node LFA1 of the Vendor Logical Database KDF, this fourth tray will show all of the columns of LFA1 that: a) participate in some index on LFA1 (including primary key); b) have not already been listed in the first two trays. 
By providing this fourth tray as shown above, at least our new component is providing some useful information on what columns SAP thought would be important enough to pre-index for everyone. (More - lots more - about this point when we eventually get to the "Programming Trees" library displayed in the lefthand tray view of our new component. To make this fourth tray appear, we need only do what we did in Part 9: modify the protected section in the implementation of the class ZCL_WDR_ALL_IN_ONE_UIELEM and also modify the on_select_view_element method of this class. In the excerpts below, I've bolded the new code we have to add. ******************************* protected section: . . . constants MC_WHERE_ID type STRING value 'WHERE'. "#EC NOTEXT constants MC_FTCHD_ID type STRING value 'FTCHD'. "#EC NOTEXT constants MC_USED_ID type STRING value 'USED'. "#EC NOTEXT constants MC_INDEX_ID type STRING value 'INDEX'. "#EC NOTEXT . . . data M_WHERE_TRAY type ref to CL_WD_TRAY . data M_FETCHED_TRAY type ref to CL_WD_TRAY . data M_USED_TRAY type ref to CL_WD_TRAY . data M_INDEX_TRAY type ref to CL_WD_TRAY. . . . ******************************* on_select_view_element method . . . idf type string, idw type string, idu type string, idx type string, . . . * remove the old trays lt_children = m_parent_container->get_children( ). loop at lt_children into lr_child. * if lr_child->id cs mc_settings_id or lr_child->id cs mc_events_id. if lr_child->id cs mc_where_id or lr_child->id cs mc_ftchd_id or lr_child->id cs mc_used_id or lr_child->id cs mc_index_id m_parent_container->remove_child( id = lr_child->id ). endif. endloop. clear m_where_tray. clear m_fetched_tray. clear m_used_tray. clear m_index_tray. . . . text = text-020. m_used_tray = add_tray_to_container( i_id = idu i_parent_container = m_parent_container i_header_text = text ). concatenate text-021 ` ` v_ldbnode into text. m_index_tray = add_tray_to_container( i_id = idx i_parent_container = m_parent_container i_header_text = text ). ENDIF. (Note that we also have to add the new text-element text-021 with the text: Other Columns in Indices on Node.) ******************************* Having made these revisions to the middle detail view that will display when a Logical Database node is selected from the righthand tree-view, we can now create and load a custom metadata table to fill these trays. First, we have to create and activate a custom table zldbm with the following columns: Key: ldbname (data element ldbnam) nodename (data element ldbnode) infotype (data element char2) colname (data element char0016) Non-Key: text (data element char0032) indexname (data element char0032) Next, we have to create (manually or via Excel) a "csv" file with the following data: ldbname, nodename,infotype,colname,text,indexname KDF,LFA1,WE,LIFNR,Vendor/Creditor Account Number, KDF,LFA1,WE,LAND1,Country Key, KDF,LFA1,WE,KONZS,Group Key, KDF,LFA1,WE,VBUND,Trading Partner Company ID, KDF,LFA1,WV,lfa1_where,Variable (customer-chosen), KDF,LFA1,SE,MANDT,Client, KDF,LFA1,SE,LIFNR,Vendor/Creditor Account Number, KDF,LFA1,UE,LIFNR,Vendor/Creditor Account Number, KDF,LFA1,IX,CONFS,(Central) Chng Auth Status,Confirm Indicators for Changes KDF,LFA1,IX,SORTL,SortField,Sort Field KDF,LFA1,IX,FISKN,Fiscal Addr Mstr Rec Acct No,Fiscal Address KDF,LFA1,IX,MCOD3,Term for matchcode search,MC Search Field 3 KDF,LFA1,IX,MCOD1,Term for matchcode search,MC Search Field 1 KDF,LFA1,IX,MCOD2,Term for matchcode search,MC Search Field 2 KDF,LFA1,IX,PSTLZ,Postal Code,Postal Code KDF,LFA1,IX,ESRNR,POR Subscriber Number,POR Subscriber Number KDF,LFA1,IX,LAND1,Country Key,Country Key KDF,LFB1,WE,LIFNR,Vendor/Creditor Account Number, KDF,LFB1,WE,BUKRS,Company Number, KDF,LFB1,WE,AKONT,GL Reconciliation Account, KDF,LFB1,WE,BUSAB,Accounting Clerk, KDF,LFB1,WV,lfb1_where,Variable (customer-chosen), KDF,LFB1,SV,lfb1_fields,Variable (customer-chosen), KDF,LFB1,IX,CONFS,(Central) Change Auth Status,Confirm Indicators for Changes KDF,LFB1,IX,ALTKN,Previous Master Record Number,Old Account Number (KREDN) KDF,LFB1,IX,PERNR,Personnel Number,Personnel Numbers KDF,BSIK,WE,LIFNR,Vendor/Creditor Account Number, KDF,BSIK,WE,BUKRS,Company Number, KDF,BSIK,WE,GJAHR,Fiscal year, KDF,BSIK,WE,BUDAT,Document Posting Date, KDF,BSIK,WE,ZUONR,Assignment Number, KDF,BSIK,WE,UMSKZ,Special G/L Indicator, KDF,BSIK,WE,SHKZG,Debit/Credit Indicator, KDF,BSIK,WE,BSCHL,Posting Key, KDF,BSIK,WV,bsik_where,Variable (customer-chosen), KDF,BSIK,SV,bsik_fields,Variable (customer-chosen), KDF,BSIK,IX,UMSKS,Special G/L Transaction Type,Primary Key KDF,BSIK,IX,AUGDT,Clearing Date,Primary Key KDF,BSIK,IX,AUGBL,Doc Nr of Clearing Document,Primary Key KDF,BSIK,IX,BELNR,Accounting Document Number,Primary Key KDF,BSIK,IX,BUZEI,Line Item Number within BELNR,Primary Key KDF,BSIK,IX,CPUDT,Accounting Document Entry Date,BW Extract Index (In the "Infotype" field, the meaning of the values are as follows: WE: explicit where clause column WV: where clause variable SE: explicit select clause column SV: select clause variable UE: "used lower-down" column IX: column not mentioned as WE/WV/SE/SV/UE column, but used in some SAP-delivered index on table.) Finally, we have to load the new zldbm table from this csv file via an upload/insert program: REPORT Z_FILL_ZLDBM. * TYPES: t_row_data(100) TYPE c, t_data TYPE TABLE OF t_row_data INITIAL SIZE 0. DATA: i_data TYPE t_data, wa_data TYPE t_row_data, v_path LIKE rlgrap-filename, wa_zldbm TYPE zldbm, i_zldbm TYPE STANDARD TABLE of zldbm, splitsep(1) VALUE ',', v_level(2) TYPE n, v_cntr TYPE i, v_root(24) TYPE c, v_cnc(4) TYPE c, v_inc(4) TYPE c, v_cnt TYPE i. DELETE FROM zldbm WHERE ldbname <> ''. COMMIT WORK. v_path = 'C:zldbm.csv'. CALL FUNCTION 'UPLOAD' EXPORTING filename = v_path TABLES data_tab = i_data EXCEPTIONS conversion_error = 1 invalid_table_width = 2 invalid_type = 3 no_batch = 4 unknown_error = 5 gui_refuse_filetransfer = 6 OTHERS = 7. LOOP AT i_data INTO wa_data. SPLIT wa_data AT splitsep INTO wa_zldbm-ldbname wa_zldbm-nodename wa_zldbm-infotype wa_zldbm-colname wa_zldbm-text wa_zldbm-indexname. INSERT INTO zldbm VALUES wa_zldbm. ENDLOOP. COMMIT WORK. (Note that this program does not expect a header line to be in the csv file, so the csv header line shown above should NOT be in the csv file which this program acutally reads.) Once these three steps have been completed, we are ready to make the metadata in zldbm available to the on_select_view_element method of ZCL_WDR_ALL_IN_ONE_UIELEM, which is where Part10b of this tutorial will begin.
If SAP always used explicit columns in the WHERE and SELECT clauses of the "PUT" SELECT associated with any node "NodeX" of a Logical Database, then the information in the first two of these trays would tell anyone writing back-end retrieval web-services a whole lot about what particular SAP logical metadata are critically associated with NodeX. But sometimes (often?), the SELECT and WHERE clauses of "PUT" selects contain variable lists of columns determined by the customer at run-time. And in such cases, no useful information about SAP logical metadata can be gained from the SELECT and WHERE clause columns of a "PUT" select. (Of course, I will refrain from editorializing on the headaches that this practice also causes Basis Admins and developers, who have to figure out exactly what kind of machine-thrashing run some customer has just thrown in the queue, and then explain to him or her that CPU cycles and memory are not yet available in infinite quantities.) To help ameliorate this problem in the component under development, we can add a fourth tray to the three we already have. When some lower-level node NodeX is selected from the treeview on the right, e.g. the node LFA1 of the Vendor Logical Database KDF, this fourth tray will show all of the columns of LFA1 that: a) participate in some index on LFA1 (including primary key); b) have not already been listed in the first two trays. By providing this fourth tray as shown above, at least our new component is providing some useful information on what columns SAP thought would be important enough to pre-index for everyone. (More - lots more - about this point when we eventually get to the "Programming Trees" library displayed in the lefthand tray view of our new component. To make this fourth tray appear, we need only do what we did in Part 9: modify the protected section in the implementation of the class ZCL_WDR_ALL_IN_ONE_UIELEM and also modify the on_select_view_element method of this class. In the excerpts below, I've bolded the new code we have to add. ******************************* protected section: . . . constants MC_WHERE_ID type STRING value 'WHERE'. "#EC NOTEXT constants MC_FTCHD_ID type STRING value 'FTCHD'. "#EC NOTEXT constants MC_USED_ID type STRING value 'USED'. "#EC NOTEXT constants MC_INDEX_ID type STRING value 'INDEX'. "#EC NOTEXT . . . data M_WHERE_TRAY type ref to CL_WD_TRAY . data M_FETCHED_TRAY type ref to CL_WD_TRAY . data M_USED_TRAY type ref to CL_WD_TRAY . data M_INDEX_TRAY type ref to CL_WD_TRAY. . . . ******************************* on_select_view_element method . . . idf type string, idw type string, idu type string, idx type string, . . . * remove the old trays lt_children = m_parent_container->get_children( ). loop at lt_children into lr_child. * if lr_child->id cs mc_settings_id or lr_child->id cs mc_events_id. if lr_child->id cs mc_where_id or lr_child->id cs mc_ftchd_id or lr_child->id cs mc_used_id or lr_child->id cs mc_index_id m_parent_container->remove_child( id = lr_child->id ). endif. endloop. clear m_where_tray. clear m_fetched_tray. clear m_used_tray. clear m_index_tray. . . . text = text-020. m_used_tray = add_tray_to_container( i_id = idu i_parent_container = m_parent_container i_header_text = text ). concatenate text-021 ` ` v_ldbnode into text. m_index_tray = add_tray_to_container( i_id = idx i_parent_container = m_parent_container i_header_text = text ). ENDIF. (Note that we also have to add the new text-element text-021 with the text: Other Columns in Indices on Node.) ******************************* Having made these revisions to the middle detail view that will display when a Logical Database node is selected from the righthand tree-view, we can now create and load a custom metadata table to fill these trays. First, we have to create and activate a custom table zldbm with the following columns: Key: ldbname (data element ldbnam) nodename (data element ldbnode) infotype (data element char2) colname (data element char0016) Non-Key: text (data element char0032) indexname (data element char0032) Next, we have to create (manually or via Excel) a "csv" file with the following data: ldbname, nodename,infotype,colname,text,indexname KDF,LFA1,WE,LIFNR,Vendor/Creditor Account Number, KDF,LFA1,WE,LAND1,Country Key, KDF,LFA1,WE,KONZS,Group Key, KDF,LFA1,WE,VBUND,Trading Partner Company ID, KDF,LFA1,WV,lfa1_where,Variable (customer-chosen), KDF,LFA1,SE,MANDT,Client, KDF,LFA1,SE,LIFNR,Vendor/Creditor Account Number, KDF,LFA1,UE,LIFNR,Vendor/Creditor Account Number, KDF,LFA1,IX,CONFS,(Central) Chng Auth Status,Confirm Indicators for Changes KDF,LFA1,IX,SORTL,SortField,Sort Field KDF,LFA1,IX,FISKN,Fiscal Addr Mstr Rec Acct No,Fiscal Address KDF,LFA1,IX,MCOD3,Term for matchcode search,MC Search Field 3 KDF,LFA1,IX,MCOD1,Term for matchcode search,MC Search Field 1 KDF,LFA1,IX,MCOD2,Term for matchcode search,MC Search Field 2 KDF,LFA1,IX,PSTLZ,Postal Code,Postal Code KDF,LFA1,IX,ESRNR,POR Subscriber Number,POR Subscriber Number KDF,LFA1,IX,LAND1,Country Key,Country Key KDF,LFB1,WE,LIFNR,Vendor/Creditor Account Number, KDF,LFB1,WE,BUKRS,Company Number, KDF,LFB1,WE,AKONT,GL Reconciliation Account, KDF,LFB1,WE,BUSAB,Accounting Clerk, KDF,LFB1,WV,lfb1_where,Variable (customer-chosen), KDF,LFB1,SV,lfb1_fields,Variable (customer-chosen), KDF,LFB1,IX,CONFS,(Central) Change Auth Status,Confirm Indicators for Changes KDF,LFB1,IX,ALTKN,Previous Master Record Number,Old Account Number (KREDN) KDF,LFB1,IX,PERNR,Personnel Number,Personnel Numbers KDF,BSIK,WE,LIFNR,Vendor/Creditor Account Number, KDF,BSIK,WE,BUKRS,Company Number, KDF,BSIK,WE,GJAHR,Fiscal year, KDF,BSIK,WE,BUDAT,Document Posting Date, KDF,BSIK,WE,ZUONR,Assignment Number, KDF,BSIK,WE,UMSKZ,Special G/L Indicator, KDF,BSIK,WE,SHKZG,Debit/Credit Indicator, KDF,BSIK,WE,BSCHL,Posting Key, KDF,BSIK,WV,bsik_where,Variable (customer-chosen), KDF,BSIK,SV,bsik_fields,Variable (customer-chosen), KDF,BSIK,IX,UMSKS,Special G/L Transaction Type,Primary Key KDF,BSIK,IX,AUGDT,Clearing Date,Primary Key KDF,BSIK,IX,AUGBL,Doc Nr of Clearing Document,Primary Key KDF,BSIK,IX,BELNR,Accounting Document Number,Primary Key KDF,BSIK,IX,BUZEI,Line Item Number within BELNR,Primary Key KDF,BSIK,IX,CPUDT,Accounting Document Entry Date,BW Extract Index (In the "Infotype" field, the meaning of the values are as follows: WE: explicit where clause column WV: where clause variable SE: explicit select clause column SV: select clause variable UE: "used lower-down" column IX: column not mentioned as WE/WV/SE/SV/UE column, but used in some SAP-delivered index on table.) Finally, we have to load the new zldbm table from this csv file via an upload/insert program: REPORT Z_FILL_ZLDBM. * TYPES: t_row_data(100) TYPE c, t_data TYPE TABLE OF t_row_data INITIAL SIZE 0. DATA: i_data TYPE t_data, wa_data TYPE t_row_data, v_path LIKE rlgrap-filename, wa_zldbm TYPE zldbm, i_zldbm TYPE STANDARD TABLE of zldbm, splitsep(1) VALUE ',', v_level(2) TYPE n, v_cntr TYPE i, v_root(24) TYPE c, v_cnc(4) TYPE c, v_inc(4) TYPE c, v_cnt TYPE i. DELETE FROM zldbm WHERE ldbname <> ''. COMMIT WORK. v_path = 'C:zldbm.csv'. CALL FUNCTION 'UPLOAD' EXPORTING filename = v_path TABLES data_tab = i_data EXCEPTIONS conversion_error = 1 invalid_table_width = 2 invalid_type = 3 no_batch = 4 unknown_error = 5 gui_refuse_filetransfer = 6 OTHERS = 7. LOOP AT i_data INTO wa_data. SPLIT wa_data AT splitsep INTO wa_zldbm-ldbname wa_zldbm-nodename wa_zldbm-infotype wa_zldbm-colname wa_zldbm-text wa_zldbm-indexname. INSERT INTO zldbm VALUES wa_zldbm. ENDLOOP. COMMIT WORK. (Note that this program does not expect a header line to be in the csv file, so the csv header line shown above should NOT be in the csv file which this program acutally reads.) Once these three steps have been completed, we are ready to make the metadata in zldbm available to the on_select_view_element method of ZCL_WDR_ALL_IN_ONE_UIELEM, which is where Part10b of this tutorial will begin.
