Devtoberfest
Find out what's happening, and when, in the Devtoberfest schedule – don't miss out!
cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

🟒 Extending your On-Premise OData Entities in CAP

Devtoberfest

In this session, "Extending your On-Premise OData Entities in CAP," we will explore a strategic approach to enhancing your existing OData services without altering the underlying backend systems. The focus will be on adding custom fields to your existing OData entities using SAP Cloud Application Programming (CAP) model while ensuring that these fields are persisted in a separate, dedicated storage layer. This approach allows for seamless integration of new data attributes, enabling you to extend functionality without impacting the core backend, thus maintaining system stability and compliance with existing processes.

Speakers: Jorg Thuijls and Katan Patel

Slide-deck: https://d.dam.sap.com/a/kbKd5MD/CAP_Week4ExtendingyourOnPremiseODataEntitiesinCAP.pdf?inline=true&rc...

Validation tutorial: https://developers.sap.com/tutorials/devtoberfest2024-week4-cap-session-validation.html



Event has ended
You can no longer attend this event.

Starts:
Ends:
5 Comments
FedericoBelotti
Explorer

Hello everyone,
regarding the production-development scope, Katan specified that you should not handle external services connection explicitly in the package.json in the way showed in the demo and that you should use a destination (which is fine).
My question is: let's say I have an OData service exposed from an SAP on-premise system that is only reachable via destination, but I (or the customer) don't have a subscription to the SAP BTP because of reasons, I want to extend it through a CAP application and I can't mock that service locally as Katan did. How can I reach that external service during design time? Are there any best practices to achieve this within the CAP framework?

Thanks

jthuijls
SAP Champion
SAP Champion

Hey Federico, 

Good question. For proof-of-concept purposes I connected it straight to the on-premise gateway. Assuming this is the way you're working now and you can reach your launchpad on gateway, you should be able to use that directly in your CAP application. Save the metadata file, import it with 

cds import metadata.xml --as cds

and fix the credentials in your package.json

You will be able to use the service on your gateway system directly, so you get real data. If it's only exposed via cloud connector and a destination in BTP but you can't actually access BTP, then that is a problem. You'll always need some sort of access in order to get to the destination. 

You could also mock it by setting up a second cap application like Katan did, but use the definitions generated by the `as --cds` import, you'll find them in `srv/external`, and set up a second CAP service that uses CSV data. All SAP examples already use mock data so that should not be tremendously difficult to replicate. 

I cannot in good conscious recommend this for productive use either, not because it's not possible but because of potential license implication in the usage of CAP.  

 

"ZYOUR_SERVICE": { "kind": "odata-v2", "model": "srv/external/ZYOUR_SERVICE", "credentials": { "url": "https://portal.url.or.ip/sap/opu/odata/sap/ZYOUR_SERVICE", "authentication": "BasicAuthentication", "username": "youruser", "password": "yourpassword" } },

 

FedericoBelotti
Explorer

Hello Jorg,
thanks for the clarifications. My concern was all about the development scope, because I wanted to find a comfortable way to quickly develop and test with real data without necessarily having to deploy the app just to have access to an external service. I guess I'll just stick to the direct gateway connection - when available - and to mocking the data locally.
If I don't have a public gateway or the external service lies behind a Cloud Connector instance, BTP is an obligated choice then?

Thanks

jthuijls
SAP Champion
SAP Champion

For development scope, hooking it up to gateway is quick and painless. It doesn't need to be public as long as you are inside the same (private) network. If you do not have a gateway the only other exposure I can think of is the OData provisioning on BTP, so yeah then you're stuck with that.  

rakeshjain
Explorer

Dear Jorg and Katan,

Thank you for the insightful demo and excellent example. It was highly relevant to the real-world challenges we frequently encounter. Your explanation was very clear and helpful.

I have a specific scenario where I need to implement bidirectional associations between two entities within the same remote service. Both entities are not persisted locally, and I am facing difficulties in achieving all the features that come with associations, such as $expand and others. The operations I need to implement include:

  • .../service/entity1('...')/entity2

  • .../service/entity1?$expand=entity2&$filter=...

  • .../service/entity1?$select=...

Could you provide an example or guidance on how to handle navigation between two remote entities within the same or different remote services, without extending the remote service on the remote server?

Your assistance in this matter would be greatly appreciated.

Best regards, Rakesh