Skip to content

Latest Release

Release 5.1 (October 2024)

Release 5.1 builds on the simplification theme from release 5.0. This include

Open Metadata Types
  • The ConnectorType entity type has a new attribute called supportedDeployedImplementationType which replaces deployedImplementationType to separate the technology it supports from other uses of deployedImplementationType* that identify its implementation technology.
  • The CatalogTarget relationship is now multi-link which means it is possible to have multiple instances of this relationship between the same two entities. It also has two new attributes: permittedSynchronization and deleteMethod.
  • The DataAssetEncoding classification, that attaches to a DataAsset, replaces the DataStoreEncoding classification. The DataStoreEncoding is deprecated.
  • There is a new type of entity called VirtualRelationalTable for representing virtualized tables.
  • There are two new relationships relating to governance actions. TargetForActionType and TargetForActionProcess allow targets for action to be pre-defined for a governance action type or governance action process respectively. The GovernanceActionProcessFlow relationship receives a new property called requestParameters. Finally, there is a new entity type called GovernanceActionProcessInstance that represents a running instance of a Governance Action Process. It captures the start and end time of the process's execution.
Unity Catalog Support

There are new survey services and integration connectors to support the new open-source Unity Catalog (UC).

New content packs for connectors, templates amd reference data

This release creates specialized content packs for different types of technologies. Within the content pack are the connector and governance service configurations, plus templates and reference data to be able to survey, synchronize metadata and govern that type of technology. The content packs are as follows:

New View Service: Runtime Manager OMVS

Runtime Manager OMVS is a new view service that enable the user to retrieve reports from different OMAG Server Platforms and OMAG Servers on their configuration and runtime status. It is also possible to perform specific types of actions on these systems depending on their type. For example, it is possible to start and stop servers on a platform, load archives into a metadata access store, restart integration connectors on an integration daemon, refresh the engine configuration in an Engine Host server.

Technology type for file directories changed from "FileFolder" to "File System Directory

Automated Curation OMVS provides methods to query the connectors and templates for different types of technology types. The names of the technologies come from the Deployed Implementation Type reference values. The value for a directory (folder) in a file system was "FileFolder" in earlier releases which is the name of the open metadata type used to catalog these types of resources. The technology name has been changed to "File System Directory" to better reflect the name of the technology.

Smarter integration daemon

In addition to the regular refreshes, the integration daemon will refresh an integration connector whenever a new catalog target is attached.

Extensions to the Open Integration Framework

The OIF includes a RequestedCatalogTargetsManager class plus new base class methods for integration connectors that support dynamic configuration through catalog targets. This means the specialized implementation for processing a single catalog target can be implemented in a simple class, and the IntegrationConnectorBase will handle the changing list of catalog targets.

Open Lineage Connectors now work with catalog targets

The Open Lineage Connectors now support dynamic configuration through catalog targets. This means that new Kafka Topics supplying open lineage events can be dynamically configured and new publishing destination APIs and folders can be added to the running connectors.

Changes to the default Configuration Document Store

The Google Tink methods used in the encrypted config document store have been deprecated for some time. This connector was written (and used as the default) at a time when certificates and passwords were a part of the configuration document. With the introduction of the secrets connector, these are now stored in protected areas outside the configuration document so that an encrypted store is not necessary. This PR switches the default config store to the clear-text file implementation. In a later release, the encrypted file version of the connector will probably be removed unless updates to it to replace the deprecated methods are contributed to the project by an interested party.

If you are currently using the encrypted file configuration document store, you can continue to use it by setting the platform.configstore.provider value in the platform's application.properties file.

platform.configstore.provider=org.odpi.openmetadata.adapters.adminservices.configurationstore.encryptedfile.EncryptedFileBasedServerConfigStoreProvider

Alternatively, if you with to switch to the clear-text version, use the administration services getStoredConfiguration() method to extract the JSON for your each of your server's configuration document while the encrypted configuration document file store is in place. Then delete the encrypted files from platform/data/servers and restart the platform with the clear-text configuration document store in place. Use the administration services setOMAGServerConfig() method to add your saved JSON back into the configuration document store.