diff --git a/site/docs/connectors/index.md b/site/docs/connectors/index.md index ae898cacca..33c6677390 100644 --- a/site/docs/connectors/index.md +++ b/site/docs/connectors/index.md @@ -149,10 +149,11 @@ The table below lists the repository connectors supporting the native open metad | Native Repository Connector | Description | |-------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [JanusGraph OMRS Repository Connector](/connectors/repository/janus-graph/overview) | provides a native repository for a metadata server using [JanusGraph :material-dock-window:](https://janusgraph.org){ target=janus } as the backend. | +| [PostgreSQL OMRS Repository Connector](/connectors/repository/postgres/overview) | provides a native repository for a metadata server using [PostgreSQL :material-dock-window:](https://www.postgresql.org/){ target=postgres } as the backend. | | [XTDB OMRS Repository Connector](/connectors/repository/xtdb) | provides a native repository for a metadata server that supports historical queries, using [XTDB :material-dock-window:](https://xtdb.com){ target=xtdb } as the persistent store. | | [In-memory OMRS Repository Connector](/connectors/repository/in-memory/overview) | provides a simple native repository implementation that "stores" metadata in HashMaps within the JVM; it is used for testing, or for environments where metadata maintained in other repositories needs to be cached locally for performance/scalability reasons. | | [Read-only OMRS Repository Connector](/connectors/repository/read-only/overview) | provides a native repository implementation that does not support the interfaces for create, update, delete; however, it does support the search interfaces and is able to cache metadata -- this means it can be loaded with open metadata archives to provide standard metadata definitions. | +| [JanusGraph OMRS Repository Connector](/connectors/repository/janus-graph/overview) | provides a native repository for a metadata server using [JanusGraph :material-dock-window:](https://janusgraph.org){ target=janus } as the backend. | The table below lists the repository connectors that act as an adapter for third party metadata repositories. diff --git a/site/docs/connectors/repository/postgres/overview.md b/site/docs/connectors/repository/postgres/overview.md index 17e72259a9..6532f1f580 100644 --- a/site/docs/connectors/repository/postgres/overview.md +++ b/site/docs/connectors/repository/postgres/overview.md @@ -22,25 +22,7 @@ Access to the PostgreSQL Database Schema is provided by the [JDBC Resource Conne The diagram below shows the tables used in the PostgreSQL Database Schema. -```mermaid ---- -title: PostgreSQL Repository Database Schema ---- - -erDiagram - - classification ||--o{ classification_property_value : "has properties" - classification }o--|| entity : "attached to entity" - - entity ||--o{ entity_property_value : "has properties" - - relationship ||--o{ relationship_property_value : "has properties" - relationship }o--|| entity : end1 - relationship }o--|| entity : end2 - - - -``` +![Postgres Schema](postgres-schema.png) ## Debugging diff --git a/site/docs/connectors/repository/postgres/postgres-schema.png b/site/docs/connectors/repository/postgres/postgres-schema.png new file mode 100644 index 0000000000..f7b2087772 Binary files /dev/null and b/site/docs/connectors/repository/postgres/postgres-schema.png differ diff --git a/site/docs/content-packs/index.md b/site/docs/content-packs/index.md index 36818a566d..ff6ece2d89 100644 --- a/site/docs/content-packs/index.md +++ b/site/docs/content-packs/index.md @@ -9,14 +9,19 @@ The content packs are as follows: * Technology Content Packs - * [CoreContentPack](/content-packs/core-content-pack/overview) - contains the connector definitions for the Egeria and File System connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for a new Egeria deployment. It is loaded automatically in the active-metadata-store sample server. - - * [ApacheAtlasContentPack](/content-packs/apache-atlas-content-pack/overview) - contains the connector definitions for the Apache Atlas connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for connecting Egeria to Apache Atlas. - * [ApacheKafkaContentPack](/content-packs/apache-kafka-content-pack/overview) - contains the connector definitions for the Apache Kafka connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for connecting Egeria to Apache Kafka. - * [APIsContentPack](/content-packs/apis-content-pack/overview) - contains the connector definitions for the connector the catalogs an open API through its swagger REST API. This connector is supplied in the *omag-server-platform* distribution. This content pack is designed to provide a good starting point for connecting Egeria to applications supporting the open API specification in order to build an API catalog. - * [ObservabilityContentPack](/content-packs/observability-content-pack/overview) - contains the connector definitions for the connectors that capture observations about the open metadata ecosystem. These connectors are supplied in the *omag-server-platform* distribution. This content pack is designed to load a PostgreSQL database with key observations that can be used for building a dashboard. - * [PostgreSQLContentPack](/content-packs/postgres-content-pack/overview) - contains the connector definitions for the PostgreSQL connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for connecting Egeria to PostgreSQL databases. - * [UnityCatalogContentPack](/content-packs/unity-catalog-content-pack/overview) - contains the connector definitions for the Unity Catalog connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for connecting Egeria to Unity Catalog. + * [CoreContentPack](/content-packs/core-content-pack/overview) - contains the connector definitions for the Egeria and File System connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for a new Egeria deployment. It is loaded automatically in the active-metadata-store sample server. + + * [ApacheAtlasContentPack](/content-packs/apache-atlas-content-pack/overview) - contains the connector definitions for the Apache Atlas connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for connecting Egeria to Apache Atlas. + + * [ApacheKafkaContentPack](/content-packs/apache-kafka-content-pack/overview) - contains the connector definitions for the Apache Kafka connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for connecting Egeria to Apache Kafka. + + * [APIsContentPack](/content-packs/apis-content-pack/overview) - contains the connector definitions for the connector the catalogs an open API through its swagger REST API. This connector is supplied in the *omag-server-platform* distribution. This content pack is designed to provide a good starting point for connecting Egeria to applications supporting the open API specification in order to build an API catalog. + + * [ObservabilityContentPack](/content-packs/observability-content-pack/overview) - contains the connector definitions for the connectors that capture observations about the open metadata ecosystem. These connectors are supplied in the *omag-server-platform* distribution. This content pack is designed to load a PostgreSQL database with key observations that can be used for building a dashboard. + + * [PostgreSQLContentPack](/content-packs/postgres-content-pack/overview) - contains the connector definitions for the PostgreSQL connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for connecting Egeria to PostgreSQL databases. + + * [UnityCatalogContentPack](/content-packs/unity-catalog-content-pack/overview) - contains the connector definitions for the Unity Catalog connectors and governance services supplied in the *omag-server-platform* distribution along with the valid metadata values for the technologies they support. This content pack is designed to provide a good starting point for connecting Egeria to Unity Catalog. * [CloudInformationModel](/content-packs/cim-content-pack/overview) - glossary from the Cloud Information Model's JSONLD formatted model. The content covers basic commerce concepts such as Party, Product, Invoice and Shipping. The cloud information project has been archived. However, this is a useful starter set glossary, @@ -24,29 +29,29 @@ The content packs are as follows: * [CocoComboArchive](/content-packs/coco-content-pack/overview) - supplies metadata to support the Coco Pharmaceuticals scenarios. It is a useful content pack to load when experimenting with Egeria's capabilities since it provides examples of many types of open metadata. In addition, this metadata is also available in the following archives that are used in the Open Metadata Labs where different subsets of this metadata are loading into each of the servers. - * CocoBusinessSystemsArchive provides a catalog of the business systems and the lineage between them and the load of their data into the data lake. This archive simulates the type of metadata expected from an ETL tool suite. It is intended for cocoMDS5 in the open metadata labs but can be used in any server. + * CocoBusinessSystemsArchive provides a catalog of the business systems and the lineage between them and the load of their data into the data lake. This archive simulates the type of metadata expected from an ETL tool suite. It is intended for cocoMDS5 in the open metadata labs but can be used in any server. - * CocoOrganizationArchive - provides the profiles, user identifies and team of the featured personas of Coco Pharmaceuticals. + * CocoOrganizationArchive - provides the profiles, user identifies and team of the featured personas of Coco Pharmaceuticals. - * CocoClinicalTrialsTemplatesArchive - provides the template assets used for onboarding weekly patient measurements during a clinical trial. + * CocoClinicalTrialsTemplatesArchive - provides the template assets used for onboarding weekly patient measurements during a clinical trial. - * CocoGovernanceProgramArchive - provides the metadata to describe Coco Pharmaceuticals governance program. + * CocoGovernanceProgramArchive - provides the metadata to describe Coco Pharmaceuticals governance program. - * CocoGovernanceEngineDefinitionsArchive - provides the metadata to describe Coco Pharmaceuticals three governance engines: AssetGovernance, AssetDiscovery and AssetQuality. + * CocoGovernanceEngineDefinitionsArchive - provides the metadata to describe Coco Pharmaceuticals three governance engines: AssetGovernance, AssetDiscovery and AssetQuality. - * CocoSustainabilityArchive - provides the base definitions for Coco Pharmaceutical's sustainability initiative. + * CocoSustainabilityArchive - provides the base definitions for Coco Pharmaceutical's sustainability initiative. - * CocoTypesArchive - provides additional types for Coco Pharmaceuticals. These are BiopsyScope Enum, BiopsyReport Entity, BiopsySupportingEvidence Relationship and ReviewedByClinicalTrials Classification. + * CocoTypesArchive - provides additional types for Coco Pharmaceuticals. These are BiopsyScope Enum, BiopsyReport Entity, BiopsySupportingEvidence Relationship and ReviewedByClinicalTrials Classification. * [SimpleCatalog](/content-packs/simple-content-pack/overview) - provides an example of a database, an API and an event structure linked to a glossary term. It is loaded automatically in the simple-metadata-store sample server. SimpleCatalog is also supplied as four archives for use in a demo showing 4 metadata access servers connected together in a single cohort. The archives are each loaded into a different server. It is then possible to show how the cohort integrates metadata from different catalogs. These archives are used in the Development labs which are part of the Open Metadata Labs. - * SimpleAPICatalog - API metadata typically found in an API catalog. + * SimpleAPICatalog - API metadata typically found in an API catalog. - * SimpleDataCatalog - Database metadata typically found in an Data catalog. + * SimpleDataCatalog - Database metadata typically found in an Data catalog. - * SimpleEventCatalog - Event metadata typically found in an API catalog. + * SimpleEventCatalog - Event metadata typically found in an API catalog. - * SimpleGovernanceCatalog - A glossary term linked to metadata elements in the API, Event, Data catalogs. + * SimpleGovernanceCatalog - A glossary term linked to metadata elements in the API, Event, Data catalogs. --8<-- "snippets/abbr.md" \ No newline at end of file diff --git a/site/docs/guides/developer/index.md b/site/docs/guides/developer/index.md index 42d3d54d8b..7fd670fd73 100644 --- a/site/docs/guides/developer/index.md +++ b/site/docs/guides/developer/index.md @@ -7,11 +7,6 @@ This guide supports developers wishing to customize Egeria to run in additional --8<-- "docs/guides/developer/developer-choices.md" -??? attention "REST APIs are intended for internal use" - The REST APIs are usable directly for calling from non-Java platforms; however, they are designed for the internal use of Egeria and are not guaranteed to be backwards compatible. - - The structure of the URL for an Egeria REST API varies lightly depending on whether it is a call to an [OMAG Server Platform](/concepts/omag-server-platform) service or an [OMAG Server](/concepts/omag-server) service. - ## Getting Started The developer guide is organized as follows: @@ -53,21 +48,21 @@ The Java clients for a specific platform API are located in its `-client` module Below is an example of using the [Administration Services](/services/admin-services/overview) to construct its `MetadataAccessStoreConfigurationClient` client. As the name suggests, this client is used to configure a new [metadata access store](/concepts/metadata-access-store) server. ??? example "Example: Creating the configuration client for a Metadata Access Store" -```java linenums="1" -MetadataAccessStoreConfigurationClient client = new MetadataAccessStoreConfigurationClient(clientUserId, serverName, platformURLRoot); -``` + ```java linenums="1" + MetadataAccessStoreConfigurationClient client = new MetadataAccessStoreConfigurationClient(clientUserId, serverName, platformURLRoot); + ``` Once the client is created, use it to call the API it offers which is documented using [Javadoc](https://odpi.github.io/egeria/org/odpi/openmetadata/adminservices/client/MetadataAccessStoreConfigurationClient.html){ target=javadoc }. For example, the code below sets up the descriptive properties of the server. ??? example "Example: Calling the configuration client for a Metadata Access Store" -```java linenums="1" -client.setServerDescription("Metadata Access Store called " + serverName + " running on platform " + platformURLRoot); -client.setServerUserId(serverName + "npa"); -client.setServerType(null); // Let the admin service set up the server types -client.setOrganizationName(organizationName); -client.setMaxPageSize(maxPageSize); -``` + ```java linenums="1" + client.setServerDescription("Metadata Access Store called " + serverName + " running on platform " + platformURLRoot); + client.setServerUserId(serverName + "npa"); + client.setServerType(null); // Let the admin service set up the server types + client.setOrganizationName(organizationName); + client.setMaxPageSize(maxPageSize); + ``` !!! education "Further information" diff --git a/site/docs/guides/developer/python-clients/overview.md b/site/docs/guides/developer/python-clients/overview.md index a0671f7937..564f19bce0 100644 --- a/site/docs/guides/developer/python-clients/overview.md +++ b/site/docs/guides/developer/python-clients/overview.md @@ -22,6 +22,7 @@ To make use of one of these clients, first import the client you need. The comma from pyegeria import EgeriaTech ``` + ---- The `pyegeria` functions require information about the calling user and the network location of Egeria's runtime. These are passed to the client when it is created. The CLI also needs this information and to save the caller having to supply it on every request, it supports environment variables. These same environment variables can be used with the `pyegeria` functions. diff --git a/site/docs/release-notes/roadmap.md b/site/docs/release-notes/roadmap.md index c7e576b7bb..a139a148f1 100644 --- a/site/docs/release-notes/roadmap.md +++ b/site/docs/release-notes/roadmap.md @@ -140,14 +140,14 @@ Support for docker compose was removed in [release 3.5](../../snippets/release-n ### Current status -Following is an overview of the [content status](/release-notes/content-status) of the functions in Egeria's latest release. +Following is an overview of the [content status](/release-notes/content-status) of the functions in Egeria's latest release (5.2). ![Status of functions found in each capability layer](functional-organization-showing-implementation-status-for-5.2.svg) As you can see, some progress has been made on all layers. However, since they do build on one another, most of the early work has been focused on establishing the frameworks, connector APIs and other services to provide the developer platform. The developer platform provides the libraries and interfaces to build connectors to integrate third party tools along with the runtime to host these connectors and manage the metadata exchange. -Today we have a robust [OMAG Server Platform](/concepts/omag-server-platform) and the ability to configure [OMAG Servers](/concepts/omag-server) that host specific types of connectors to third party tools. The continual development of the registered services is broadening the types of metadata, and tools, that can integrate with Egeria through the federated query mechanism that +Today we have a robust [OMAG Server Platform](/concepts/omag-server-platform) and the ability to configure [OMAG Servers](/concepts/omag-server) that host specific types of connectors to third party tools. The continual development of the registered services is broadening the types of metadata, and tools, that can integrate with Egeria through the federated query mechanism, supported by the repository services. With this expansion, more solutions are envisaged, along with a runtime environment that can be downloaded and used immediately. Many features are available through Egeria's command line interface, or through simple python scripting. Thus, a team can be up and running quickly. The dynamic configuration and Java frameworks that support new connectors and services development are still there and can be used to further expand Egeria's capabilities. ### History @@ -175,9 +175,9 @@ This new website was added to the project in 2021, and it has resulted in more i 2022 continued the focus on metadata governance. The following OMASs were refactored to call the generic handlers rather than direct calls to the repository handler. -* [Data Engine OMAS](/services/omas/data-engine/overview) -* [Asset Catalog OMAS](/services/omas/data-engine/overview) -* [Asset Lineage OMAS](/services/omas/data-engine/overview) +* Data Engine OMAS +* Asset Catalog OMAS +* Asset Lineage OMAS There was investment in both the function and performance of the generic handlers, which provide many of the metadata governance functions supported by all OMASs, such as metadata security, provenance validation, anchor management, LatestChange classifications, effectivity dating, memento management and de-duplicating query results.