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 trailing 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, 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). An ORD provider that describes a system SHOULD publish static metadata using system-type, system-version, or both.Static ORD documents MUST NOT contain tenant context or tenant-specific customizations. Providers SHOULD publish version-independent metadata through system-type and metadata that differs between versions through system-version.Distinct system-version values MUST be used when multiple versions of the same application are deployed at the same time in one environment tier, such as production.A continuously delivered system MAY instead publish all static metadata through system-type or through system-version with a fixed describedSystemVersion.version.When using the fixed-version approach, the version MUST remain unchanged so each release replaces the previously published system-version perspective.Each ORD ID published in a static perspective MUST have a complete representation. The effective static view looks up an ORD ID in the applicable system-version layer first and then in system-type.If both contain the ORD ID, the complete system-version representation takes precedence and properties MUST NOT be merged across the layers.Systems with dynamic metadata MUST be described in a complete system-instance perspective and SHOULD additionally be described in at least one static perspective. 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:
| |
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"
}