As I mentioned in my blog My CDS view self study tutorial – Part 11 CDS view test double framework, we develop CDS view on top of various database table, and CDS view test double framework extracts all involved database table names starting from CDS view source code using Visitor design pattern.
Paul Hardy has written a series of excellent blogs about Design Patterns in ABAP – Visitor. And in my blog, I will use a real example which uses this design pattern in SAP standard implementation to demonstrate the usage of this pattern.
The source code of my CDS view, where database table MARA and MAKT are used.
@EndUserText.label: 'Product Description'
define view ProductShortText
as select from makt
inner join mara on makt.matnr = mara.matnr
key mara.scm_matid_guid16 as ProductGuid,
key makt.spras as Language,
makt.maktx as ProductName,
makt.maktg as ProductNameLarge
The aim of CDS view test double framework: extract all database tables used in a given CDS view, let’s say this logic is implemented in a method.
So input of this method: CDS view name, in my example it is PRODUCTSHORTTEXT.
Output: an internal table containing used database table names. In my example it is [ ‘MARA’, ‘MAKT’ ]
How could this task be done by Visitor pattern?
Let’s first refresh our memory on typical roles involved in Visitor pattern.
Let’s categorize the real classes we see in SAP system according to this graph below.
( graph from post: http://www.cnblogs.com/zhenyulu/articles/79719.html )
You might get lost in the debugging of the tremendous code in CDS view test double framework, so in order to make your debugging and learning easier, I extract the Visitor code in SAP standard implementation and simplify it into a standalone report which only contains 139
lines of code now. The complete source code could be found here
You can simply set breakpoint on method accept in line 135 and run report to debug the Visitor behavior.
Execute the report and you will see MAKT and MARA are printed as output. The code is tested in my system with ABAP 7.52.
Of course at first you should have a CDS view to visit, you can create new CDS view by copying the source code I provided in the beginning of this blog or use your own CDS view instead.
The other steps that the CDS source code is loaded from DB and parsed via a Kernel module into an intermediate XML format and then into an AST ( Abstract Syntax Tree ) are not relevant to the topic of this blog so they will not be explained in detail.
Since I am only interested with involved table names, so in my local visitor implementation for method get_mapping, I only register corresponding concrete element’s class name and operation when this element is visited.
mapping = VALUE #( ( classname = 'CL_QLAST_TABLE_DATASOURCE' method = 'VISIT_TABLE_DATASOURCE' )
The purpose of above code: When visitor actually visits the concrete element CL_QLAST_TABLE_DATASOURCE, method VISIT_TABLE_DATASOURCE will be called to record detail information of visited database table.
Although nodes in the AST will be visited one by one, since I only registered CL_QLAST_TABLE_DATASOURCE so most of them will be filtered out via IF sy-subrc = 0 in line 10, which means no actual operation will be performed on those irrelevant nodes.
Only operations on table nodes will be performed twice, since in my test CDS view there are totally two tables MAKT and MARA used.
The requirement changes now, you are asked to also print out the annotation text specified in the header of CDS view.
The sample output should be:
1. Since now text annotation is also concerned, we have to now register its mapping with corresponding handler method name PRINT_ANNOTATION:
2. Implement PRINT_ANNOTATION, and that’s all.
The complete source code of this exercise could be found here