By now we assume you know that we can create OData Service from CDS view without a single line of code in SEGW. Yes we can expose CDS view as OData Service without going to t-code SEGW. Annotation @OData.publish : true does the trick. CDS is one of the most significant and powerful innovation of SAP which would be used in all future developments in S/4HANA.
Once the OData is created, it needs to be registered like any other OData Service using t-code /IWFND/MAINT_SERVICE. This is one time activity for the CDS generated OData Service.
Note: The OData Service created from CDS View can only perform ‘R’ i.e. GET operation of CRUD. It cannot do Create, Update or Delete operations of the CRUD.
The other day, we ran into a strange hiccup in our Embedded S/4HANA System. We created a CDS View and exposed it as OData Service using the @OData.publish: true annotation. The OData Service got created successfully and it worked perfectly in /IWFND/GW_CLIENT test but not in Browser mode.
Below is the CDS with @OData.publish: true.
We created the CDS and the corresponding OData Service in client 110 (development); while our test data resides in client 130 (testing client in development system). When we tested the OData Service in SAP Gateway Client 130, it worked perfectly as shown below:
But, when we tried to test the same OData Service in client 130 in Browser mode, it started pointing to the client 110. Remember, we are in 130 client but still the OData was forcing to be opened in client 110.
Our SAP Gateway is set up in S/4HANA-130 client. Since the Gateway is embedded rather than a HUB, there is no alias other than Local for OData in our S/4 environment. Therefore, the processing mode should be set to CO-DEPLOYED ONLY rather than ROUTING-BASED which should allow testing of the OData in S/4HANA-130 rather than trying to run the backend call on S/4HANA-110.
Check below, for our system, we have forced the Processing Mode to Co-deployed only in t-code /IWFND/MAINT_SERVICE.
Also check there is no System Aliases in S/4HANA test client 130. It automatically picks130 as Gateway is configured as embedded and there is no alias other than local for OData.
If you are wondering, what is Routing-based and Co-deployed only Processing Mode? Below definitions from SAP Help might give a better clarity.
Definition of OData Service Processing Mode
- Routing-based: This is the default processing mode. That means the SAP Gateway system uses the routing configuration for this service and passes the OData request via RFC to one or more remote backend systems (different backend systems are available in case of Multiple Origin Composition) or via a direct call to the local system (RFC bypassing). Till now, the RFC bypassing implementation just saves the RFC and network overhead but it is not optimized for data transfer and also for database accesses within the local system.
- Co-deployed only: The optimization for service processing in a co-deployed system is realized for a fast data transfer between the SAP Gateway system and the IW_BEP component on the local system. Using this processing mode, the routing configuration is not used and the OData request is directly passed to the IW_BEP component.
- As the routing information is not used for the processing mode “Co-deployed only”, no additional system aliases can be assigned to this service via transaction /IWFND/MAINT_SERVICE.
- When some more system aliases are added to a service via transport, they are ignored during the service processing at runtime. The transaction /IWFND/MAINT_SERVICE will show in this case a popup to inform and to require the administrators either to change the processing mode back to “Routing-based” or to remove the needless system aliases.
Use
Choose the processing mode ‘Co-Deployed only’ to improve the service processing performance if this service is registered and published in a co-deployed system only.
Our Issue: OData Service created using CDS annotation re-directs the browser to the development client. OData Service works perfectly in SAP Gateway Client test in /IWFND/MAINT_SERVICE but fails in Call Browser mode. The browser tries to call the other client 110 when being tested in 130.
Solution: The resolution was rather simple. When we created the OData Service using annotations in CDS View, the OData Service got created with the development client (110) as default. Reason being, you can create OData from CDS only in your development client.
You can check it in SICF t-code.
We removed the Client definition in SICF which magically corrected the issue.
Let us retest in our 130 client. The browser correctly asks for 130 credentials.
This is just a simple use case we encountered in our S/4HANA system. This might look too small, but when you face it, it would take few hours of your ABAP developer, SAP Basis Admin and SAP Security guy :). Everyone is learning the new tricks of S/4HANA. Although CDS is not a proprietary of HANA (CDS is database independent), but going forward, almost all SAP design architecture would involve CDS. It is high time we started embracing CDS and exploit it to our advantage.
