Summary:
In some of SAP RAP (RESTful Application Programming) scenarios, there is a need to pass a request body to an action as input, execute business logic, and return the output in the response body. While SAP RAP offers a “Deep Action” feature to facilitate such requirements, this capability is currently not supported in OData V2. As a result, developers seeking to implement this pattern must turn to OData V4, which introduces expanded support for complex actions and payload handling.
This blog will walk you through a practical, step-by-step session on how to implement request/response body handling in RAP Actions using OData V4, ensuring you can meet advanced integration and business process needs in your SAP applications. Also this blog explains how to capture your OData V4 service in TR Properly.
The Aim is to create Single Parent Entity and create Deep Action out of it which acts like same OData Deep Entity.
The Action can be exposed to interface where it can be used for POST Operations. ( GET Can be used only to get CSRF Token for security layer.
Before getting deep dive into RAP Deep Actions, first we need to understand that RAP Actions are generally function imports in OData V2 and in OData V4 it shows as Action itself in Meta Data Extension.
Now let’s start with the build.
1) Create Root View Entity
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: ‘Test’
@Metadata.ignorePropagatedAnnotations: true
define root view entity ZCDS_TEST_PARENT_ENTITY as select from ekko
{
key ebeln as Ebeln,
bukrs as Bukrs,
bsart as Bsart,
lifnr as Lifnr
}
2) Create Behavior Definition on top of Root View Entity
3) After Creating Behaviour Definition with appropriate Alias and read only properties, Add Static Action with Deep structure as per your requirement. The syntax is as below. ( Note for the deep action you must create Deep Abstract Entity which I will explain in upcoming points ).
static action TestAction deep parameter ZCDS_ROOT_ABSTRACT_TEST_API deep result[1..*] ZCDS_ROOT_ABSTRACT_TEST_API;
4) While using Deep Action, in Result [1..*] is important which indicates that Action will expand for Deep structure for Result. But for Input cardinality is not required.
5) Create Root Abstract Entity
@EndUserText.label: ‘Root Abstract’
define root abstract entity ZCDS_ROOT_ABSTRACT_TEST_API
{
key Ebeln : ebeln;
Bukrs : bukrs;
_Parenttochild : composition [1..*] of ZCDS_CHILD_ABSTRACT_TEST_API;
}
6) Create corresponding child Abstract Entity
@EndUserText.label: ‘Child Abstract’
define abstract entity ZCDS_CHILD_ABSTRACT_TEST_API
{
key Ebeln : ebeln;
key ebelp : Ebelp;
Matnr_ae : matnr;
_ChildtoParent : association to parent zcds_root_abstract_test_api on $projection.ebeln = _childtoParent.ebeln;
}
7) Create Abstract – Behavior Definition
abstract;
strict ( 2 );
with hierarchy;
define behavior for ZCDS_ROOT_ABSTRACT_TEST_API //alias <alias_name>
{
association _Parenttochild;
}
define behavior for ZCDS_CHILD_ABSTRACT_TEST_API //alias <alias_name>
{
}
😎Create Respective Service Definition and Service Binding. ( Note Service Binding to be created in OData – V4 Web API for Interface Based Requirements and OData – V4 UI for Fiori/BTP Based Requirements. Currently Im creating OData – V4 Web API since we are testing in gateway only ).
@EndUserText.label: ‘Test’
define service ZCDS_TEST_ENTITY_SRV {
expose ZCDS_TEST_PARENT_ENTITY as TestEntity;
}
9) After creating the service Binding Activate it and publish it. In this Blog we are also going to see how to save/capture V4 OData service in TR Properly.
10) Once Publishing the service, navigate to /n/iwfnd/v4_admin Transaction and find your service Group. Right click on the service and click on Transport Publishing.
11) After clicking on Transport Publishing it will ask for Customizing TR, Save the service in Customizing TR and click on LOCAL system Alias and then select Transport Routing Assignment. It will ask for Customizing TR again and save it in Customizing TR. With these steps your OData V4 Service will get properly captured in TR.
12) After capturing service in TR, click on the Service and select Service Test.
13) As Mentioned above RAP Action’s will be considered as Actions in OData V4 whereas in OData V2 it will be taken as Function Imports. Refer to screenshot below for the same which shows the Action we created as Action while loading Meta data.
14) Now let’s construct URL and Payload for OData V4 RAP Action.
URL Format :
“1” : /sap/opu/odata4/sap/zcds_test_entity_srv/….
“2”: TestEntity/
“3”: com.sap.gateway.srvd_…
“4”: .TestAction
Final URL : “1” && “2” && “3” && “4”
In simple Terms the “1” will be coming by default once you enter the gateway and “2” will be also coming by default once you add the entity. Then “3” is something which is for OData V4 and it’s schema namespace which you will find while loading meta data. Finally “4” is your Action.
URL Should look like this:
/sap/opu/odata4/sap/zcds_test_entity_srv/…./TestEntity/com.sap.gateway.. .TestAction
Note : Action should be exposed with a dot (.) after Schema Namespace
Payload;
The Payload should hold all properties from Action Parameters. It will not play any crucial role with Root CDS View Entity inputs rather static action will expect all the deep parameters to be passed to initiate POST Operation in Input payload.
For Our Scenario let’s Pass Payload like this.
{
“Ebeln”: “1050001”,
“Bukrs”: “001”,
“_Parenttochild”: [
{
“Ebeln”: “1050001”,
“Matnr”: “000000000000000001”
}
]
}
15) After passing the payload, we often do get this error while execution which is Authorization block. To resolve this we have to get appropriate authorization from BASIS for Auth objects; S_START and S_SERVICE.
16) Once Necessary Authorization is obtained we do get response like this in Deep structure in Response body.
17) Henceforth with this way we can use Deep Action and pass input in Body instead of payload as deep structure. This could be used for Interface as well as Fiori based objects. In Fiori with same way the testing can be done in Fiori Launchpad with deployed app with Action button having deep structure.
18) Static Action should hold whatever Business logic is for POST inside RAP Behavior Implementation class. The UI/3rd party system input can be read from keys parameter with appropriate %cid_ref and once all business logic is done the response can be mapped to result parameter of same action.
19) If you want to read some of the CDS View properties then instead of static action you can use normal action also with deep parameters.
20) If the requirement demands to send Deep structure as output only or vise versa means then in this case you can avoid deep structure in either parameter or response as shown below;
static action TestActionDeepInput deep parameter ZCDS_DEEP_ABSTRACT result[1]ZCDS_OUTPUT_ABSTRACT;
static action TestActionDeepOutput parameter ZCDS_INPUT_ABSTRACT deep result[1..*]ZCDS_DEEP_ABSTRACT;
Conclusive Summary
I hope this blog has clarified key concepts around OData V4, RAP Deep Actions, Deep Abstraction, and capturing V4 services in a transport request. In future posts, I’ll explore running background jobs with RAP and Application Jobs.
Thank you for reading!
Summary:In some of SAP RAP (RESTful Application Programming) scenarios, there is a need to pass a request body to an action as input, execute business logic, and return the output in the response body. While SAP RAP offers a “Deep Action” feature to facilitate such requirements, this capability is currently not supported in OData V2. As a result, developers seeking to implement this pattern must turn to OData V4, which introduces expanded support for complex actions and payload handling.This blog will walk you through a practical, step-by-step session on how to implement request/response body handling in RAP Actions using OData V4, ensuring you can meet advanced integration and business process needs in your SAP applications. Also this blog explains how to capture your OData V4 service in TR Properly.The Aim is to create Single Parent Entity and create Deep Action out of it which acts like same OData Deep Entity. The Action can be exposed to interface where it can be used for POST Operations. ( GET Can be used only to get CSRF Token for security layer.Before getting deep dive into RAP Deep Actions, first we need to understand that RAP Actions are generally function imports in OData V2 and in OData V4 it shows as Action itself in Meta Data Extension.Now let’s start with the build.1) Create Root View Entity@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: ‘Test’
@Metadata.ignorePropagatedAnnotations: true
define root view entity ZCDS_TEST_PARENT_ENTITY as select from ekko
{
key ebeln as Ebeln,
bukrs as Bukrs,
bsart as Bsart,
lifnr as Lifnr
}2) Create Behavior Definition on top of Root View Entity3) After Creating Behaviour Definition with appropriate Alias and read only properties, Add Static Action with Deep structure as per your requirement. The syntax is as below. ( Note for the deep action you must create Deep Abstract Entity which I will explain in upcoming points ). static action TestAction deep parameter ZCDS_ROOT_ABSTRACT_TEST_API deep result[1..*] ZCDS_ROOT_ABSTRACT_TEST_API;4) While using Deep Action, in Result [1..*] is important which indicates that Action will expand for Deep structure for Result. But for Input cardinality is not required.5) Create Root Abstract Entity@EndUserText.label: ‘Root Abstract’
define root abstract entity ZCDS_ROOT_ABSTRACT_TEST_API
{
key Ebeln : ebeln;
Bukrs : bukrs;
_Parenttochild : composition [1..*] of ZCDS_CHILD_ABSTRACT_TEST_API;
} 6) Create corresponding child Abstract Entity@EndUserText.label: ‘Child Abstract’
define abstract entity ZCDS_CHILD_ABSTRACT_TEST_API
{
key Ebeln : ebeln;
key ebelp : Ebelp;
Matnr_ae : matnr;
_ChildtoParent : association to parent zcds_root_abstract_test_api on $projection.ebeln = _childtoParent.ebeln;
}7) Create Abstract – Behavior Definitionabstract;
strict ( 2 );
with hierarchy;
define behavior for ZCDS_ROOT_ABSTRACT_TEST_API //alias <alias_name>
{
association _Parenttochild;
}
define behavior for ZCDS_CHILD_ABSTRACT_TEST_API //alias <alias_name>
{
}😎Create Respective Service Definition and Service Binding. ( Note Service Binding to be created in OData – V4 Web API for Interface Based Requirements and OData – V4 UI for Fiori/BTP Based Requirements. Currently Im creating OData – V4 Web API since we are testing in gateway only ).@EndUserText.label: ‘Test’
define service ZCDS_TEST_ENTITY_SRV {
expose ZCDS_TEST_PARENT_ENTITY as TestEntity;
}9) After creating the service Binding Activate it and publish it. In this Blog we are also going to see how to save/capture V4 OData service in TR Properly.10) Once Publishing the service, navigate to /n/iwfnd/v4_admin Transaction and find your service Group. Right click on the service and click on Transport Publishing.11) After clicking on Transport Publishing it will ask for Customizing TR, Save the service in Customizing TR and click on LOCAL system Alias and then select Transport Routing Assignment. It will ask for Customizing TR again and save it in Customizing TR. With these steps your OData V4 Service will get properly captured in TR.12) After capturing service in TR, click on the Service and select Service Test.13) As Mentioned above RAP Action’s will be considered as Actions in OData V4 whereas in OData V2 it will be taken as Function Imports. Refer to screenshot below for the same which shows the Action we created as Action while loading Meta data.14) Now let’s construct URL and Payload for OData V4 RAP Action.URL Format : “1” : /sap/opu/odata4/sap/zcds_test_entity_srv/….”2″: TestEntity/”3″: com.sap.gateway.srvd_…”4″: .TestActionFinal URL : “1” && “2” && “3” && “4”In simple Terms the “1” will be coming by default once you enter the gateway and “2” will be also coming by default once you add the entity. Then “3” is something which is for OData V4 and it’s schema namespace which you will find while loading meta data. Finally “4” is your Action.URL Should look like this:/sap/opu/odata4/sap/zcds_test_entity_srv/…./TestEntity/com.sap.gateway.. .TestActionNote : Action should be exposed with a dot (.) after Schema NamespacePayload;The Payload should hold all properties from Action Parameters. It will not play any crucial role with Root CDS View Entity inputs rather static action will expect all the deep parameters to be passed to initiate POST Operation in Input payload. For Our Scenario let’s Pass Payload like this.{
“Ebeln”: “1050001”,
“Bukrs”: “001”,
“_Parenttochild”: [
{
“Ebeln”: “1050001”,
“Matnr”: “000000000000000001”
}
]
}15) After passing the payload, we often do get this error while execution which is Authorization block. To resolve this we have to get appropriate authorization from BASIS for Auth objects; S_START and S_SERVICE. 16) Once Necessary Authorization is obtained we do get response like this in Deep structure in Response body.17) Henceforth with this way we can use Deep Action and pass input in Body instead of payload as deep structure. This could be used for Interface as well as Fiori based objects. In Fiori with same way the testing can be done in Fiori Launchpad with deployed app with Action button having deep structure. 18) Static Action should hold whatever Business logic is for POST inside RAP Behavior Implementation class. The UI/3rd party system input can be read from keys parameter with appropriate %cid_ref and once all business logic is done the response can be mapped to result parameter of same action.19) If you want to read some of the CDS View properties then instead of static action you can use normal action also with deep parameters.20) If the requirement demands to send Deep structure as output only or vise versa means then in this case you can avoid deep structure in either parameter or response as shown below;static action TestActionDeepInput deep parameter ZCDS_DEEP_ABSTRACT result[1]ZCDS_OUTPUT_ABSTRACT;
static action TestActionDeepOutput parameter ZCDS_INPUT_ABSTRACT deep result[1..*]ZCDS_DEEP_ABSTRACT; Conclusive SummaryI hope this blog has clarified key concepts around OData V4, RAP Deep Actions, Deep Abstraction, and capturing V4 services in a transport request. In future posts, I’ll explore running background jobs with RAP and Application Jobs.Thank you for reading! Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
