Health checks
Readiness and liveness that mean something for a service — is the database reachable, are bindings resolved, is the message broker connected — rather than merely whether the process is up.
Overview
Readiness and liveness that mean something for a CAP service — is the database reachable, are bindings resolved, is the message broker connected — rather than merely whether the process is up.
Not covered: It stops at whether the process is up. Nothing checks whether the service can actually serve — database reachable, bindings resolved, broker connected — so the endpoint stays green while the application is unable to do its job.
Built into @sap/cds
No community artifact is documented here.
Artifacts
Content
Group by
Piece, what it offers
#BTP #SAPCAP: Quirky Nuggets (N05-N06)#BTP #SAPCAP: Quirky Nuggets (N05-N06)On SAP BTP, Cloud Foundry Runtime, a one-shot PostgreSQL db-deployer app can be restarted by the platform's default port-type health check inside its 60-second timeout, re-running the deploy and duplicating data in the PostgreSQL database; setting health-check-type to process or http, via cf commands or the app's mta.yaml parameters, avoids it. In CAP, a remote service's entities are imported and consumed through cds.connect.to and queried via a projection, but its functions and actions cannot be projected: they must be redefined in the consuming service's own interface, with the handler forwarding the call to the remote proxy.published 2023-07-27
Details
Coverage
For your agent
- Ref
capability:health-checks- JSON
- /capabilities/health-checks.json
- MCP
- Connecting an agent