This is a reference application that demonstrates the implementation of Open Resource Discovery (ORD) protocol.
It consists of a backend (implemented in TypeScript / Node.js) that exposes some resources (e.g. APIs and Events). Those resources are described via metadata through ORD and the applicable resource definition formats like OpenAPI v3.0.
There is an example ./docs/http/ORD_Document_API.http file which documents the process and is executable through the REST Client VSCode Extension.
An exemplary ORD Provider implementation (ORD Endpoint API) that implements the pull transport of ORD Documents can be found at ./src/api/open-resource-discovery/v1.
Protected APIs can be accessed via BasicAuth authentication. The usernames and passwords can be found in ./src/data/user/users.ts.
The API may be tenant aware with tenant isolation. Different users may therefore get different results or API features. The tenants and their configuration be found in ./src/data/user/tenants.ts.
Some resources in the ORD Reference App are system instance aware. When fetching the metadata, we need to select for which tenant we need the information.
Therefore we defined custom Access Strategies how the ORD information and the related metadata can be accessed.
To see some examples how the access strategies are used, have a look at ./docs/http/CRM_API.http and ./docs/http/ORD_Document_API.http. They contain documented example requests and are executable through the REST Client VSCode Extension.
The metadata is openly accessible and is system instance aware. Depending on the tenant the metadata return can potentially vary (reflecting customizations). This strategy therefore only applies to multi-tenant systems.
When fetching metadata for a specific tenant, the request REQUIRES to add an additional HTTP Header sap-global-tenant-id with a CLD Tenant ID as a value.
The application internally maps from the global tenant ID to a local tenant and returns the metadata for the local tenant as requested (see ./src/data/user/tenantMapping.ts).
Therefore the application MUST support the mapping of the global tenant ID to its own tenant IDs.
If the specified header is missing the request will be identical to the open access strategy.
Whether this is supported or not is defined by additionally adding an open access strategy.
In this case metadata would be returned without considering tenant specifics.
The metadata is openly accessible, but system instance aware. Depending tenant the metadata that is return can vary (reflecting customizations).
When fetching metadata for a specific tenant, the request REQUIRES an additional HTTP Header sap-local-tenant-id with a local tenant ID (that the application locally understands) as a value.
If the specified header is missing the request will be identical to the open access strategy.
Whether this is supported is defined by additionally supporting the open access strategy.
In this case metadata would be returned without considering tenant specifics.
The CRM API can be extended with custom fields.
Each tenant can have fieldExtensions defined in their tenant configuration.
The tenants and their configuration be found in src/data/user/tenants.ts.
Install (Node.js](https://nodejs.org/en/) v20 or up
npm install
npm run dev| Feature | Status |
|---|---|
| ORD Document with open access strategy | ✅ |
| ORD Document with custom access strategy | ✅ |
| System instance aware ORD Document (optional API resources) | ✅ |
| System instance aware resource definitions (e.g. field extensibility) | ✅ |
| Protected metadata, accessible via SAP aligned Access Strategy | 🟥 |
If you miss some features or use case, please get in contact.
Copyright (c) 2023 SAP SE or an SAP affiliate company. All rights reserved. This project is licensed under the Apache Software License, version 2.0 except as noted otherwise in the LICENSE file.