ORD Configuration
Schema Definitions
- The root schema of the document is Ord Configuration
- The interface is available as JSON Schema: Configuration.schema.json.
Ord Configuration
Type: Object($schema, baseUrl, openResourceDiscoveryV1)
| Property | Type | Description |
|---|---|---|
string | Optional URL to the ORD Configuration schema (defined as JSON Schema). If given, this enables code intelligence and validation in supported editors (like VSCode) and tools. JSON Schema Format: uri-referenceArray Item Allowed Values (extensible):
| |
string | Optional base URL that can be used to resolve the relative URLs to the ORD Documents. The baseUrl MUST NOT contain a leading slash.If you do not provide this property, the base URL is assumed to be the URL of the config endpoint without /.well-known/open-resource-discovery suffix.This implies that either a baseUrl or only absolute URLs MUST be provided when no standardized well-known URI is used.If both a baseUrl and a well-known URI is provided, the explicit baseUrl takes precedence.JSON Schema Format: uriRegex Pattern: ^http[s]?:\/\/[^:\/\s]+\.[^:\/\s\.]+(:\d+)?(\/[a-zA-Z0-9-\._~]+)*$Example Values:
| |
The existence of this version indicates that Open Resource Discovery is supported in Version 1.x |
Ord V1 Support
The existence of this version indicates that Open Resource Discovery is supported in Version 1.x
Type: Object(documents, capabilities)
| Property | Type | Description |
|---|---|---|
Array<Ord V1 Document Description> | List of all ORD documents that can be retrieved. While it is possible to describe everything in one big ORD document, for bigger services/use cases it might be preferable to split the information into multiple documents. For more details how to implement this correctly, please refer to the ORD configuration endpoint section and the considerations on the granularity of ORD documents. | |
List of capabilities that are supported by the ORD provider. |
Ord V1 Document Description
Describes an ORD Document that is available for pull transport consumption.
Type: Object(url, perspective, systemInstanceAware, accessStrategies)
| Property | Type | Description |
|---|---|---|
string | URL or relative URL to the ORD document (provided by an ORD document endpoint). It is RECOMMENDED to provide a relative URL (to baseUrl).If a baseUrl is given, the relative URLs will be resolved with it.If the URL is not relative to the system providing this information or no well-known URI is used, either the baseUrl or a full URL to the document MUST be provided. JSON Schema Format: uri-referenceExample Values:
| |
string | With ORD it's possible to describe a system from a static or a dynamic perspective (for more details, follow the link). It is strongly RECOMMENDED to mark all static ORD documents with perspective system-version.It is RECOMMENDED to describe dynamic metadata in both static system-version perspective and additionally describe the system-instance perspective where it diverges from the static metadata. If not provided, this defaults to system-instance, which is the most precise description but also the most costly to replicate.Please read the article on perspectives for more explanations. Default Value: system-instanceAllowed Values:
Introduced in Version: 1.12.0 Example Values:
| |
boolean | DEPRECATION-TEXT: Please use perspective instead and split content of different perspectives into different ORD documents.Whether the information in the ORD document is system-instance-aware. This is the case when the provided ORD document potentially differs between system instances (e.g. due to multi-tenancy, configuration or extensibility). If a document is system-instance-aware, an ORD aggregator MUST fetch it for each system instance (tenant), not just once per system type. This concept is now deprecated in favor of the more explicit perspective attribute.It is strongly RECOMMENDED to split metadata into separate documents for the different perspectives (static vs. dynamic). For a detailed explanation, see perspectives concept page or the specification section. Default Value: falseDeprecated in Version: 1.12.0 Example Values:
| |
List of supported access strategies for retrieving the metadata from the ORD provider. An ORD Consumer/ORD Aggregator MAY freely choose any of the listed strategies. Array Constraint: MUST have at least 1 items |
Ord V1 Capabilities
List of capabilities that are supported by the ORD provider.
Type: Object(selector)
| Property | Type | Description |
|---|---|---|
boolean | Whether the ORD provider supports the optional select parameter (select parameter) for retrieving the ORD config and ORD documents.Default Value: false |
Ord V1 Document Access Strategy
Defines the access strategy for accessing the ORD documents from the ORD provider.
Type: Object(type, customType, customDescription)
| Property | Type | Description |
|---|---|---|
string | Defines the authentication/authorization strategy through which the referenced ORD Documents can be accessed. Array Item Allowed Values (extensible):
Example Values:
| |
string | If the fixed type enum values need to be extended, an arbitrary customType can be provided.MUST be a valid Specification ID. MUST only be provided if type is set to custom.Regex Pattern: ^([a-z0-9]+(?:[.][a-z0-9]+)*):([a-zA-Z0-9._\-]+):v([0-9]+)$Maximum Length: 255Example Values:
| |
string | Human-readable description about how the access is set up, notated in CommonMark (Markdown). MUST only be provided if type is set to custom.Minimum Length: 1Example Values:
|
Example Values:
{
"type": "open"
}
{
"type": "custom",
"customType": "sap.xref:open-local-tenant-id:v1",
"customDescription": "Custom description how to use custom access strategy"
}