SAP CDS view自学教程之一：如何测试基于SAP CDS view自动生成的OData服务

I am a newbie of CDS view related topic and recently I have to learn it. I will write down here not only the knowledge I learned but also the way how I obtain them via self study ( debugging, or other ABAP tool ). Because it would be quite easy for us to just paste the source code of sample CDS view from other guy’s blog and activate it. The CDS view works. But what have you learned from this simple Ctrl+c and Ctrl+v? For me, I always get used to dig a little bit deeper such as “what has happened in the backend after I click the activate button in ABAP development studio? “.

In this part, I will introduce how to test the OData service generated based on my CDS view via Chrome extension – postman.

Prerequisite

I have created two simple CDS views. They are:

@AbapCatalog.sqlViewName: 'z20160310'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'consume view test '
@ObjectModel: {
  type: #CONSUMPTION,
  compositionRoot,
  semanticKey: ['Actor'],
  createEnabled,
  deleteEnabled,
  updateEnabled
}
define view Zjerrytest20160310 as select from Zjerrytest20160309 {
    key Zjerrytest20160309.carrid as Jerryid,
    key Zjerrytest20160309.carrname as name,
    key Zjerrytest20160309.cityfrom as startLocation,
    key Zjerrytest20160309.cityto as target,
    key Zjerrytest20160309.connid
}

and

@AbapCatalog.sqlViewName: 'zjerrySQL0309'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'test 233'
@ObjectModel: {
  createEnabled,
  deleteEnabled,
  updateEnabled
}
define view Zjerrytest20160309
as select from spfli association [0..1] to scarr as _scarr
on _scarr.carrid = spfli.carrid {
      key spfli.carrid,
      key _scarr.carrname,
      key spfli.connid,
      spfli.cityfrom,
      spfli.cityto
}

And create a project in tcode SEGW, import the first CDS view via context menu:

After that the project looks like below:

Generate runtime artifacts and register the odata service via tcode/IWFND/MAINT_SERVICE. Now the odata service is ready for testing.

Metadata test

Of course you can use SAP gateway client to test, however I prefer Chrome extension, postman, which can organize all my test cases in a hierarchical structure like below.

You have several ways to get the url to test metadata retrieve operation.
In tcode SEGW, you can get your service name.

Search it in tcode /IWFND/MAINT_SERVICE, click “SAP Gateway Client”,

Change the url as “/sap/opu/odata/sap/<Your service name>/?$metadata”, and then trigger request. You should see 200 return code with status OK.

Or you can also use Postman, in this case you have to paste the absolute url with host name and port number, both of which could be found in gateway client response, as marked by the black rectangle above.

Read operation test

The url I am using is:
https://<host name>:<port number>/sap/opu/odata/sap/ZJERRY20160310TRY_SRV/Zjerrytest20160310
The name “Zjerrytest20160310” is the entitySet name which you can find in SEGW.

The read operation works, see the part of response data below. But how does the read operation work under the hood?

We can ensure that the response we see are fetched from the automatically generated database view when CDS view is activated, and we would like to know which exact line of code in ABAP does this job. As introduced in my blog Six kinds of debugging tips to find the source code where the message is raised we can get the answer via tcode ST05.

Switch on SQL trace in your system via tcode ST05, and then perform the read operation again. Once finished, display the trace result with filter Object Name = “030*”. ( Since at this time I am not sure whether data comes from Z20160309 orZ20160310 ).

Only one result is found, and click the button to display ABAP code.

Then we get what we look for. The line 22 does the read operation.

This method CL_SQL_STATEMENT~EXECUTE_QUERY is quite useful and would be used in following chapters of this tutorial as well.
Now we can study the callstack in the debugger to know how our request sent in UI is parsed and handled.

Variable lv_sql_statement in line 629 contains the automatically generated SQL statement:

SELECT "Zjerrytest20160310"."JERRYID" AS "JERRYID", "Zjerrytest20160310"."NAME" AS "NAME", "Zjerrytest20160310"."STARTLOCATION" AS "STARTLOCATION", "Zjerrytest20160310"."TARGET" AS "TARGET", "Zjerrytest20160310"."CONNID" AS "CONNID" FROM "Z20160310" AS "Zjerrytest20160310" WHERE "Zjerrytest20160310"."MANDT" = '001' WITH PARAMETERS( 'LOCALE' = 'CASE_INSENSITIVE' )

The response data in ABAP format could be found in the variable et_flat_data in this callstack frame:

Filter operation test

The url I am using is:
https://<host name>:<port number>/sap/opu/odata/sap/ZJERRY20160310TRY_SRV/Zjerrytest20160310?$filter=(Jerryid%20eq’LH’)
It means I want only those records which fulfill the condition “Jerryid = LH” are returned.

This time, the automatically generated SQL statement is a little bit different from the one for read operation.
Here the “?” acts as a placeholder for parameter, whose value is specified by another variable in line 29.