Skip to main content

FAQ

How does ORD relate to other API standards like OData and OpenAPI?​

ORD is not meant to replace existing metadata standards that describe APIs or Events in detail. Such metadata standards, OpenAPI or EDMX for OData APIs are often protocol specific.

The role of ORD is to standardize the high-level, lifecycle related, more semantic and shared attributes of APIs and pass along such detailed schema level metadata definition files. Therefore, ORD is not a substitution to such standards, its meant to actually aid the discoverability of them. Consumers that need to understand an API or Event resource in detail still need to understand those metadata standards.

Q: Do you have a library for ORD for language XYZ?​

Since adopting ORD is mostly about creating ORD documents correctly, the main challenge is usually how the information can be provided in the first place. A library can not solve this problem for you, only frameworks which have a rich internal meta model (like the CAP framework) can automatically generate an ORD description of the application.

That leaves the main challenge to create the ORD documents correctly. Two things are usually helpful here:

  • Use a validator to ensure that the ORD Documents are correct and compliant, ideally as CI/CD step or test cases.
  • Implement against a generated (ideally type safe) ORD document interface.
    • ORD comes with a JSON Schema definition, which can be converted into interfaces / clients for most programming languages. This can be done with converters like quicktype.

Is ORD already used outside of SAP?​

Not that we are aware of. But it it designed in a way that this is possible.

In a first step, we released ORD as open source under the Apache 2 license (see public announcement).

Currently, we're in discussion with other companies to form a community around the standard.

How long does it take for metadata changes to reflect in the Aggregators?​

This depends on the configuration and implementation of an ORD aggregator. The aggregation can be fully automated, but currently ORD has only defined a pull transport mode, which relies on periodic fetching (similar as a search engine indexes the web). As a consequence, metadata changes need a while to be replicated. We're aware that some use-cases require faster metadata updates and the ORD spec is designed to support other transport modes (like push or event based), to make faster and more efficient replication possible.

Q: Does ORD work for On-Premises Software?​

ORD does not make a distinction between on-premises or cloud software. However On-premises software has implications on how (and whether at all) the ORD information can be accessed. Effectively, whether on-premises is supported or not depends on whether the connectivity between the the ORD aggregators (the system that are collecting the information) and the On-premises ORD providers can be established. In SAP context, we support including On-Premises software through Cloud Connectors.

Q: What does "Open" in ORD stand for?​

The Open in ORD refers to the protocol itself and that it is published publicly under a permissive license. It can therefore be freely implemented by SAP partners or customers.

A public version of the standard is published here: https://sap.github.io/open-resource-discovery.

The governance and the actual development will remain fully at SAP for now. In the long term, we can imagine to contribute ORD to an open governance body if there is an interest by other companies to drive the specification together.

Please note that the fact that ORD is an open protocol, does not imply that the resources and information that are described through it are "open". They can be categorized explicitly, e.g. through visibility.

🎧 Checkout the openSAP podcast The Open Source Way - Open Resource Discovery.

ORD at SAP​

Q: How does ORD relate to the Open Discovery API / API Event Discovery?​

The Open Discovery API standard is the predecessor of Open Resource Discovery. It was developed by Harsh Jegadeesan and Divya Mary. The old Open Discovery API has been implemented (in different variants / states) by some SAP Applications, e.g. by the API Hub or S4/Hana.

It's adoption by LoBs was however not mandated by the corresponding Technology Guideline TG03.

With Open Resource Discovery, the scope of the specification has widened and changed a bit.

  • There is a distinction between the API that a LoB needs to provide (simplified API) and the API that an ORD aggregator (like API Hub) needs to provide
    • The goal is to simplify the adoption for SAP applications
  • ORD is not specifically about APIs and Events anymore but is meant to express all kind of system resources (therefore the name change)
  • A new goal is to have a decentralized implementation with full automation around discovery. ORD Providers and ORD aggregators should not have to create explicit integration between them. Instead we aim for a plug-and-play architecture.
  • ORD also considers additional use cases of the Unified Customer Landscape

An implementation of the legacy Open Discovery API will provide most, but not all of the ORD information. Since there is no standardized state of it, it needs to be integrated individually and explicitly (no plug-and-play automated discovery). It was mainly used as a publication channel of system instance unaware information to the API Hub.