Service integration

Using a service that runs somewhere else as if it were one of your own: its API imported into the model, a proxy that turns a local query into the remote protocol, and a mock that stands in for it on a laptop. Distinct from destinations, which is how the address and the credentials are found, and from replication, which is holding the data locally.

Overview

SAP SHIPSby design
Node.js →

@sap/cds-dk The command line client and development toolkit for CAP projects, with the commands cds build, cds deploy, cds watch and cds add among them.

@sap/cds Builds a remote proxy with cds.connect.to for any imported service, translates a local query into OData V4, OData V2 or HCQL against the remote entity, and mocks the imported service in process until a binding is configured; outbound calls use the SAP Cloud SDK client when installed, else the native fetch client.

Java →

com.sap.cds:cds-feature-remote-odata A CAP Java feature for consuming remote OData V2 and V4 services as Remote Services, translating CQN queries into OData requests against a destination or a service binding.

Not covered: At the single remote entity. An expand or a navigation between a local and a remote entity is integration logic the application writes, per the feature matrix in the Consuming Services guide, and transient access cannot filter on local and remote fields in one request: that is where replication begins. The channel itself, authentication, destination and user propagation, is the connectivity component's and is read under destinations.

Built into @sap/cds
THE COMMUNITY ADDS

Artifacts5

5 of 5 artifacts
ArtifactSignals
CDS plugins1
cds-data-federationData federation for CAP via delegation, caching and replication
Signals
none
CLI tools1
@sap/cds-dkCommand line client and development toolkit for CAP
Signals
none
Packages3
@sap/cdsCAP Node.js runtime
Signals
none
capire/s4Prebuilt SAP S/4HANA integration package for CAP projects
Signals
none
com.sap.cds:cds-feature-remote-odataRemote Services for consuming OData V2 and V4 APIs in CAP Java
Signals
none

Tasks2Beta

Covers, under conditionsNot assessed
Receive SAP Document AI's extraction results in an application1 under conditions

The fields SAP Document AI extracted from a document reach an application of the reader's own, pushed by an outbound channel when the document reaches a step, so the application can map them and post them on.

Ends at the results in the application's hands. Posting them to SAP S/4HANA or another system is the application's or the flow's own work and is not assessed here. The service posting directly to a target system's REST API involves no application of the reader's and is the design's first route, not a contribution. Sending the document in the first place is the sending use case, assessed on its own.

Covers, under conditions@sap/cdsThe posting page's third route: a CAP service receives the extraction notification, maps the fields and posts on, to SAP S/4HANA Cloud over OData or to an on-premise system through the Cloud Connector.

Conditions: An outbound channel in Document AI set to notify the application when documents reach the step, with the extraction results.

Remaining work: The endpoint that receives the notification, the field mapping and the posting call are the application's own code; the runtime serves the endpoint over HTTP and no package for Document AI is in the graph.

Open artifact →

Send a document to SAP Document AI1 under conditions

A document that arrived somewhere an application or a flow can reach is uploaded to SAP Document AI for classification and extraction.

Ends at the upload. What the service's own intake does, an inbox or a folder it reads itself, its workspace UI and the SAP Joule Work mobile app, is the service's interface and not a contribution. The extraction is document extraction, and what happens to the results afterwards is the receiving use case, assessed on its own.

Covers, under conditions@sap/cdsThe ingestion page places a CAP application on the API route: it uploads documents the service's own channels do not reach, keeps track of what was processed and offers its own UIs. Its example is a CAP service that subscribes to Ariba invoice events, fetches the PDFs and uploads them.

Conditions: A document source the service's own intake channels do not cover, or routing and transformation the channels cannot do; the page places the API route there.

Remaining work: The upload call against the Document AI API, the record of processed documents and any UI are the application's own code; no CAP package for Document AI is in the graph, and the page names no client.

Open artifact →

Content11

Group by11 of 11 pieces
Piece, what it offers
The ECC-to-CAP Starter Kit
YouTube — SAP Developers playlists, Sebastiano Marchesini, Talk
#BTP #SAPCAP: Quirky Nuggets (N05-N06)
SAP Community, Lukas Schwabe, Blog
CAP Service to Fetch + Create Sales Order in S4 HANA Public Cloud
SAP Community, Mujeeb, Blog
Show 6 more
Extend SAP SuccessFactors on SAP BTP with CAP - Create the CAP Service
SAP Community, Alessandro Biagi, Blog
Extend SAP SuccessFactors on SAP BTP with CAP - Import SAP SuccessFactors OData Services definitions
SAP Community, Alessandro Biagi, Blog
SAP CAP: Consume SAP API Hub Sandbox Data as an external service Part- 1
SAP Community, DebashishDas, Blog
SAP CAP Adapter to expose OData as custom REST Service
SAP Community, Former Member, Blog
Event-driven Extensions for SAP SuccessFactors on SAP BTP – Connecting the Dots
SAP Community, Former Member, Blog
CAP: Consume External Service - Part 1
SAP Community, Jhodel Cailan, part 1 of 3, Blog
Federating, Replicating, and Caching Remote Data in CAP — Part 2
SAP Community, Mike Zaschka, part 2 of 2, BlogThe reasoningA recipeRunnable code
The Full Picture: Federating, Replicating, and Caching Remote Data in CAP — Part 1
SAP Community, Mike Zaschka, part 1 of 2, BlogThe reasoning

Seen working7

ArtifactSignals
Samples7
auth-samplesCAP services and a UI for trying role restrictions with mock users
No license
cap-external-northwindCAP service serving Northwind's external OData Products as its own
none
cap-java-resilienceCAP Java service consuming a Business Partner API mocked in Node.js
No license
cap-openaiCAP service actions calling OpenAI chat completions two ways
No license
cap-principal-propagationOn-premise ABAP OData V2 service read from CAP over Connectivity
No license
xflightsCAP reuse package serving Airlines, Airports and Flights data
none
xtravelsCAP travel-booking app built on xflights master data
none

Details

Coverage
statecore and community, CAP
assessed
relationshipnarrow by design
Comparison properties1

These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.

Protocols
For your agent
Ref
capability:service-integration
JSON
/capabilities/service-integration.json
MCP
Connecting an agent