Package org.odpi.openmetadata.adapters.connectors.darwin

Class DarwinProductDependencyManagerConnector

java.lang.Object
org.odpi.openmetadata.frameworks.connectors.Connector
org.odpi.openmetadata.frameworks.connectors.ConnectorBase
org.odpi.openmetadata.frameworks.integration.connectors.IntegrationConnectorBase
org.odpi.openmetadata.adapters.connectors.darwin.DarwinProductDependencyManagerConnector
All Implemented Interfaces:
AuditLoggingComponent, SecureConnectorExtension, VirtualConnectorExtension, IntegrationConnector
public class DarwinProductDependencyManagerConnector extends IntegrationConnectorBase
DarwinProductDependencyManagerConnector maintains the coarse-grained lineage that is implied by the finer-grained lineage beneath it, working upwards from the most detailed level on each refresh:
  • Schema elements to data assets. A DataMapping relationship between two schema elements shows data being copied from one to the other. Where the two schema elements belong to different data assets, data flows from the first asset to the second, so a DataFlow relationship is maintained between the assets.
  • Data assets to software servers. A software server hosts software capabilities (through the SupportedSoftwareCapability relationship), and a capability owns data assets (through the CapabilityAssetUse relationship with a useType of OWNS). Where the data lineage leads - directly or through intermediate elements - from an asset owned by one server's capability to an asset owned by another's, data flows from the first server to the second, so a DataFlow relationship is maintained between the servers.
  • Data assets to digital products. The assets that are members of a digital product (through the CollectionMembership relationship) are the start of paths followed downstream through the data lineage. A path may pass through any number of intermediate elements - processes, assets that belong to no product - but every relationship on it must belong to the same information supply chain (the iscQualifiedName of the lineage relationship). When the path reaches an asset that is a member of another product, that product depends on the product the path started from, through that information supply chain, so a DigitalProductDependency relationship is maintained between the products. The path stops there: the dependency on anything further downstream belongs to the product just reached.
The information supply chain of the finer-grained relationship is carried up onto the coarser one, and because every one of these relationship types is multi-link there is one relationship per information supply chain between the same two elements. Each level is reconciled with the relationships in the repository the same way. Relationships this connector created itself - recognized by the createdBy in their header - are removed when the finer-grained lineage no longer supports them, and missing ones are created. Relationships asserted by external users take precedence and are never removed: one whose information supply chain is not set is given the supply chain of the first finer-grained lineage that proves it.

A DigitalProductDependency asserted by an external user that no lineage path proves is recorded as an exception. The connector has its own ExceptionType, created on first use, and links it to each dependent digital product that has unproven dependencies with an Exception relationship whose affectedRelationships property lists the unproven DigitalProductDependency relationships. The exception is updated as the list changes and removed once nothing on it is left.

This connector works across the whole open metadata ecosystem rather than through catalog targets, which is why it extends IntegrationConnectorBase rather than DynamicIntegrationConnectorBase. Each refresh reconciles from a fresh snapshot, so nothing is carried between refreshes but the identity of the exception type.