My CDS view self study tutorial – Part 4 how does annotation @OData.publish work
- Part1 – how to test odata service generated by CDS view
- Part2 – what objects are automatically generate after you activate one CDS view
- Part3 – how is view source in Eclipse converted to ABAP view in the backend
- Part4 – this blog
- Part5 – how to create CDS view which supports navigation in OData service
- Part6 – consume table function in CDS view
- Part7 – unveil the secret of @ObjectModel.readOnly
- Part8 – my summary of different approaches for annotation declaration and generation
- Part9 – cube view and query view
- Part10 – How does CDS view key user extensibility work in S4/HANA
- Part11 – CDS view test double framework
- Part12 – CDS view source code count tool
- Part13 – CDS view authorization
In part1 of this tutorial, the old way to create OData service on top of CDS view is introduced.
In SAP Help Generate Service Artifacts From a CDS View a new annotation is described:
Just add this annotation to your CDS view and the odata service is automatically created, no need for you to go to code SEGW any more.
Once activated, the odata service with naming convention “<your CDS view name>_CDS” is available for registration in tcode /IWFND/MAINT_SERVICE:
Metadata retrieval test ok:
So the question here is: How does this annotation work? How can we research the service generation process through debugging?
Here below is how I figure it out.
First check what objects have been generated: three additional artifacts are highlighted below.
- IWMO: SAP Gateway Business Suite Enablement – Model
- IWSV: SAP Gateway Business Suite Enablement – Service
- CLAS: provider class ZCL_ZJERRYTEST20160311 is generated
If I remove the annotation, or change the annotation to @OData.publish: false, and the two are gone:
So it means the annotation @OData.publish: true will trigger table entry insertion for type IWMO, IWSV and CLAS during view activation. Then again I switch on ST05 trace and easily find the ABAP code where the table insertion is done.
Set breakpoint on the code and observe the callstack in the runtime.
The highlighted callstack frames are essential for odata service generation.
Let’s have a deep look at stack frame 21:
It will first identify which objects must be created based on delta state.
For example, if I add @OData.publish: true to an existing CDS view and activate it, the corresponding entry will have flag N ( New ) while other existing annotation has type “U” ( Unchanged ).
Inside this method, if annotation ODATA.PUBLISH is found,
and the annotation value is true, then it is considered that the odata service must be created.
The odata service creation is implemented in CL_SADL_GTK_ODATA_SERVICE_GEN~CREATE_VIA_EXPOSURE below.