All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog. This project adheres to Semantic Versioning rules, but omits the patch level in the spec version number.
For a roadmap including expected timeline, please refer to ROADMAP.md
- Added
countries
to Data Products (like for APIs, Events and Packages)
- Added
terms-of-use
as a new type for Data Product links. - Added
sap:dp:v1
policy level (beta, WIP)
- Deprecated
policyLevel
andcustomPolicyLevel
in favor of more flexiblepolicyLevels
(multiple items)- This makes the policy level concept more flexible, as more than one policy level can apply
- Policy levels are now just a Specification ID, no fixed enum + customType (for simplification)
- Removed constraint that
describedSystemInstance
MUST be same as system instance providing the ORD information - Allow apostrophe for plural proper nouns in Short Descriptions in Policy Level
sap:core:v1
, e.g.partners'
. - Added two new Entity Type
level
options:root-entity
andsub-entity
. - The alpha property
runtimeRestriction
is now just expecting a valid system namespace as value, not a fixed enum value range- This makes the property more flexible, no need for spec changes
- Added How To guide for ORD Provider adoption (as new detail article)
- Added explicit
sap:base:v1
policy level to not conflate it withnone
- So far we only had SAP to use ORD, so we assumed that
none
equals to oursap:base:v1
. By introducing this policy level, we can now keepnone
unopinionated.
- So far we only had SAP to use ORD, so we assumed that
- Allowing
disabled
as "hidden property" in Data Products for backward compatibility- The property was removed in favor of
lifecycleStatus
- This may be cleaned up / removed again in the future
- The property was removed in favor of
- Added
lifecycleStatus
to data products, which replaces the booleandisabled
property.
- Renamed some instances of
sap-csn-interop-v1
tosap-csn-interop-effective-v1
(inconsistency)- Bugfix release. So far, this was not used yet, as CSN Interop Effective is still in development.
- Removed optional
disabled
property on data products, as the newlifecycleStatus
supersedes it.
- Renamed one Data Product
type
enum value frombase
toprimary
.- BREAKING change, but introduced as a patch, as the Data Product interface is still in beta phase.
- Schemas published on NPMJS.org under @sap/open-resource-discovery package name.
- Renamed
sap:hdlf-delta-sharing:v1
implementation standard tosap:delta-sharing:v1
to be more generic and not technology specific.- Incompatible change, but part of the "beta" Data Products, so we'll introduce it as a bugfix
- added
sap-csn-interop-effective-v1
as a standardized resource definition format for API and event resources
- added optional
visibility
to Consumption Bundle- Some consumption bundle access types are only meant for internal or private purposes. Especially when we have internal APIs, their assigned Consumption Bundles are likely internal, too.
- If
visibility
is not given, default ispublic
(to ensure backward compatibility)
- Added
localId
to Packages, for consistency with other ORD resources - Added public link to the SQL interface specification for SAP ecosystem.
- Data Product
shortDescription
anddescription
are now mandatory- This is a breaking change, but as the Data Product concept as a whole is beta, we'll introduce it as a patch change.
- Added back FAQ page (can be found under "Details" navbar item)
- Added autogenerated class diagrams for ORD Documents and Configuration Interface.
- Added optional
systemTypeRestriction
toEventResourceIntegrationAspect
- This can be used to limit the event publisher system type, which can be used to setup the subscription accordingly.
- Added explicit statement that the same resource definition type MUST NOT be provided more than once.
- This was already implied, but not stated explicitly.
- Added two new (optional) SHOULD statements regarding deprecation and sunset lifecycle.
- They represent common sense / practice and help with validating a good usage of the related attributes.
- If
successors
is given, the described resource SHOULD set itsreleaseStatus
todeprecated
. - If a resource is deprecated without defining its
successors
, asunsetDate
SHOULD be provided.
- Clarification on consumer expectations toward
lastUpdate
property.
- Renamed the term application namespace to system namespace
- This is more consistent with the existing ORD terminology around system type
- As it's only used as a term and not in the interface, this is not a breaking change
- Added new (lightweight) Group and Group Type concept
- Adds a new
partOfGroups
attribute on ORD resources - Adds two new top level concepts to the ORD document: Group and Group Type
- This can be used to define custom group types and assign ORD resources to them
- With this, custom taxonomies can be built that are either centrally or decentrally defined.
- Adds a new
- Added
relatedEntityTypes
to Entity Types- This allows to define that Entity Types are related to other Entity Types (e.g. from a different namespace)
- Added clarification that an ORD Aggregator MUST bump
lastUpdated
if the provider didn't do it, but it detected a change. - Added explicit Access Strategy description for
open
, defining how local and global tenant headers can be optionally passed on. - Added new Detail Articles:
- How To Adopt ORD as a Provider detail page
- System Landscape Model detail page
- Grouping and Bundling detail page
- Providing the
sunsetDate
for a deprecated resource is now only recommended instead of mandatory (compatible change)- "If the
releaseStatus
is set todeprecated
, thesunsetDate
SHOULD be provided (if already known)." - "Once the sunset date is known and ready to be communicated externally, it MUST be provided here."
- "If the
- Accidentally exported an
x-
attribute in the ORD JSON Schema interface inDocument.schema.json
- This export is meant to be clean of such extension attributes, as validators as AJV will complain on it by default
- The
Document.annotated.schema.json
export keeps the extension attributes intact.
- Breaking: The relation of a data product input port to the integration dependency was accidentally modeled as composition, not association,
- Since the Data Product concept is still in beta, we'll ship this change as a fix and notify current adopters
- Added statement that there's a reserved
customer
vendor namespace - The
.well-known/open-resource-discovery
URI is now officially registered.
- Added Excel and CSV files export that gives a high-level overview of ORD entities and their attributes
- Removed
sap-delta-sharing-combined
API resource definition format, as it has not be specified yet.- It may be reintroduced in the future, if a specification exists and a producer for it exists.
- Fixed some ORD ID regexp, where it was still allowed to have
alpha
orbeta
instead of a major version- This affected Capability and Integration Dependency.
- Instead, the
releaseStatus
property should be used to setbeta
.
- Made
accessStrategies
optional within the ORD document.- If this property is not provided, the definition URL will be available through the same access strategy as this ORD document.
- It is RECOMMENDED anyway that the attached metadata definitions are available with the same access strategies, to simplify the aggregator crawling process.
- Minor clarification on visibility of Packages (since they don't have an explicit property for it)
- Product
title
property did not properly inherit constraints like the othertitle
attributes (min- and max-length)
- Fix: Data Products need to have at least one output port
- This is implied through the definition of a Data Product
- Breaking change that we'll push as a bugfix, as so far it was clear to have at least one output port
- Added Data Product concept.
- for the time being in beta status
- Added
runtimeRestriction
to packages - Added
responsible
to APIs, events and data products - Added
usage
to APIs - Added new
apiProtocol
s:delta-sharing
andsap-ina-api-v1
- Added new API Resource Definition
type
:sap-delta-sharing-combined
- Changed values of
supportedUseCases
on APIs- Technically a breaking change, but no consumer used it, therefore it is introduced as minor change
- Introduced a clear distinction between application namespace and authority namespace instead of "unit namespace"
- At SAP we already made that distinction.
- Having a unit-namespace as a simplification didn't work out in all cases and introduced an unnecessary new term
- This change only affects how we name things and allows us to be more precise
- For
Entity Type
its now clearly stated that they can also have an authority namespace
- Fixed type of
minVersion
property. It was accidentally set toboolean
, but is obviously meant as a (semver) versionstring
- ORD has been made public as Open Source under Apache 2 license.
- Added
eventResourceLinks
that allow to add typed links with predefined semantics- This was already available for APIs and just missing for event resources
- In both cases, they share the same interface and predefined types
- The internal interface name changed from
APIResourceLink
toAPIEventResourceLink
- This doesn't have any effect on the interface contract, but may need to be considered for internal refactoring / renaming.