CAP: Consume External Service – Part 3
Built to work around CAP limitations at the time — OData-only external services, no custom headers, no complex OData queries — the post walks through cdsecdseResolves a destination from a CAP project's own configuration, then makes the outbound call with axios: the url, the method and the body are written at the call site.independent, cap, the author's own module that resolves a named destination from the CAP project's configuration and calls axiosaxiosA promise-based HTTP client for the browser and Node.js, and the client a CAP module here hands an outbound request to once the destination has been resolved. directly, so a handler reads the same way whether it is tested locally against a raw URL or deployed against SAP Cloud Platform's DestinationsDestinationsReaching a system that is not yours — an S/4HANA tenant, an on-premise service, a third-party API — without the address, the credentials or the tunnel being written into the application. The destination is the indirection, and the reason an endpoint can move without a redeploy.SAP and community, unassessed service. A 2022 update at the top of the post calls it obsolete, since the CAP framework has since addressed the limitations it set out to work around. The walkthrough of cdse resolving a destination and switching between a local credentials.url and an SCP destination, including pulling credentials from VCAP_SERVICES when the lookup fails locally, still holds as a worked example.
Where it sits
Who is behind it
In the atlas: maintains 1, contributes to 1, wrote 3@jcailanauthor
In this series
- 1
- 2CAP: Consume External Service – Part 2 ↗Not read yet
- 3CAP: Consume External Service – Part 3you are here
Properties
About this work
Details
Graph
Source
History
- Entered the atlasDiscovered via SAP Community · cap-tag.
For your agent
- Ref
content:cap-consume-external-service-part-3- JSON
- /content/cap-consume-external-service-part-3.json
- MCP
- Connecting an agent