Skip to main content

Open Resource Discovery

Open Resource Discovery (ORD) is a protocol for application / service metadata publishing and discovery and can be used as a foundation for metadata catalogs and marketplaces and to improve automation and quality of integrations.

ORD is designed to be general-purpose and to work with a wide variety of industry-standard protocols and metadata standards. It can be used for static documentation or to describe the run-time system landscape, reflecting tenant specific configuration and extensions.

It is possible to describe APIs, Events and higher-level concepts like Entity Types (Domain / Business Objects) and Data Products. The Integration Dependencies describe the use of external resources. In case that the standardized concepts or attributes are not sufficient, there are extensibility attributes and Capabilities. All of the described artifacts can share relationships, taxonomy and grouping concepts, enabling a well-connected metadata graph.

ORD Provider Overview

Technically, ORD allows applications and services to self-describe their resources and capabilities (e.g. ports and adapters). To adopt ORD, an application implements a read-only entry point (Service Provider Interface) that can be used to discover and crawl relevant metadata.

ℹ ORD is an open source standard by SAP, released under the Apache 2 license (see public announcement).

The ORD interface (JSON Schema) and TypeScript types are available via npm: @sap/open-resource-discovery.

Introduction​

Read the 📄 ORD Introduction and watch the 🎦ORD Videos.

Use Cases​

Information expressed or discovered through ORD can be used to build static metadata catalogs or do detailed runtime inspection of actual system landscapes. Based on this, many end-user use cases can be realized, e.g.:

  • API and event catalog
  • Data product directory/catalog
  • Landscape specific API/event discovery for development platforms, platform engineering and low-code/no-code development
  • Support admins in configuring services (discovery & automation)
  • AI grounding & training
  • Generic channel to describe, discover and exchange system capabilities between providers and consumers (even across vendors)

Goals​

Design Goals

  • Systems to describe themselves with a single entry-point to crawl all relevant metadata
  • Achieve a combined, machine-readable system landscape metadata view
  • Enable fully automatic of publication and discovery of metadata
  • Having one aligned standard for
    • Description of different types of resources
    • Description of both the static / generic perspective and the actual runtime perspective
    • Support of many different metadata-driven use-cases and consumer requirements
  • ORD is an open standard
    • It is open source an can be used by SAP partners and customers if they see a value in adopting it, like better integration in the SAP ecosystem
    • The specification is open for extensions via labels, custom types, spec extensions. Those don't need to go through alignment first.

Non-Goals

  • Replace industry-standard resource definition formats like OpenAPI
  • Describing resources or capabilities in extensive detail.
  • Currently it is not recommended to put fast changing information into ORD, as the current pull-based transport mechanism would be to slow and expensive to support time-critical updates.
    • This could change in the future by introducing more efficient, asynchronous transport modes.
  • Currently: Describe resources other than those that are owned and exposed by the systems directly (only self-description of systems).
    • This could be changed in the future if necessary.

Future Plans​

Now that ORD is open-source, a potential next step is to work with partners on a true industry wide standard, as ORD is currently focused on SAPs requirements. We are also part of the publicly funded IPCEI CIS project, where we also work towards this goal.

The specification itself is designed to be generic, so most SAP specific aspects are described as spec extensions. Some concepts like namespaces could be further standardized if there's a need for cross-company metadata exchange.

We are thinking about ways to make ORD publishing more efficient when there is a lot of tenant specific metadata or data changes happen frequently and replication is more time critical. There is also need to make publishing easier for simple, static providers that prefer publishing design-time information only.