From da7e1cb364b08b7d987e6fd4e2a3bc0c5b9128a1 Mon Sep 17 00:00:00 2001 From: "Dr. Christoph \"Schorsch\" Jung" Date: Tue, 3 Dec 2024 13:57:38 +0100 Subject: [PATCH 1/3] docs: include user and ar42 architecture documentation --- README.md | 3 +- docs/README.md | 2 +- docs/architecture/Arc42.md | 149 +++++++++++++++++++++++++++++++++++++ 3 files changed, 152 insertions(+), 2 deletions(-) create mode 100644 docs/architecture/Arc42.md diff --git a/README.md b/README.md index 82d3c40..f72b06c 100644 --- a/README.md +++ b/README.md @@ -25,9 +25,10 @@ ![GitHub all releases](https://img.shields.io/github/downloads/eclipse-tractusx/knowledge-agents-edc/total) [![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=eclipse-tractusx_knowledge-agents-edc&metric=alert_status)](https://sonarcloud.io/summary/new_code?id=eclipse-tractusx_knowledge-agents-edc) -KA-EDC is a product of the [Catena-X Knowledge Agents Kit (about to move to: Tractus-X Knowledge Agents Kit)](https://bit.ly/tractusx-agents) implementing the core "dataspace" modules of the CX-0084 standard (Federated Queries in Dataspaces). +KA-EDC is a product of the [Tractus-X Knowledge Agents Kit](https://eclipse-tractusx.github.io/docs-kits/kits/knowledge-agents/adoption-view/intro) implementing the core "dataspace" modules of the CX-0084 standard (Federated Queries in Dataspaces). * See the [User Documentation](docs/README.md) +* See the [Architecture](docs/architecture/Arc42.md) * See the [Authors](AUTHORS.md) * See the [Changelog](CHANGELOG.md) * See the [Code of Conduct](CODE_OF_CONDUCT.md) diff --git a/docs/README.md b/docs/README.md index 89bfea8..39d98f2 100644 --- a/docs/README.md +++ b/docs/README.md @@ -19,7 +19,7 @@ # Tractus-X Knowledge Agents EDC Extensions (KA-EDC) Documentation -In the Knowledge Agent Architecture, an Agent is any component which speaks and/or enacts a Semantic Web protocol, such as SPARQL. +In the [Knowledge Agent Architecture](architecture/Arc42.md), an Agent is any component which speaks and/or enacts a Semantic Web protocol, such as SPARQL. The Tractus-X Knowledge Agents EDC Extensions (KA-EDC) introduces support for these protocols (and runnable applications) into the [Eclipse DataSpace Connector](https://github.com/eclipse-edc/Connector) and [Tractus-X EDC](https://github.com/eclipse-tractusx/tractusx-edc). diff --git a/docs/architecture/Arc42.md b/docs/architecture/Arc42.md new file mode 100644 index 0000000..e7a136d --- /dev/null +++ b/docs/architecture/Arc42.md @@ -0,0 +1,149 @@ + + +## Introduction and Goals + +The main objective concerning the approach described in this section is to create a state-of-the-art compute-to-data architecture for automotive use cases (and beyond) based on standards and best practices around GAIA-X and W3C. To reach this aim, full semantic integration, search and query with focus on relations between entities and data sovereignty is focused. In contrast to a simple file-based data transfer, this shifts the responsibility for the access, authorization to the data and processing of the data from the application development to the provider and hence ultimately, the actual owner of the data. To achieve this aim, the Knowledge Agent standard shall achieve the following abilities: + +* the ability to define well-formed and composable computations/scripts (skills) which operate over various assets of various business partners. +* the ability to invoke and dynamically distribute these (sub-)skills over the relevant partners/connectors using an extensible agent interface. +* the ability to safely provide data and service assets via appropriate agent implementations which "bind" the skill to the backend execution engines (rather than mapping data). +* the ability for an agent/connector/business partner to decide + * whether to hide particular data and computations inside a sub-skill + * whether to delegate/federate particular computations/sub-skills to other agents + * whether to migrate or clone an agent/asset from a partner +* the ability to describe data and service assets as well as appropriate federation policies in the IDS vocabulary in order to allow for a dynamic matchmaking of skills and agents. +* the ability to define domain/use case-based ontologies which form the vocabulary used in the skill definitions. +* the ability to visualize and develop the ontologies and skills in appropriate SDKs and User Experience components. + +See also the KIT [Introduction](https://eclipse-tractusx.github.io/docs-kits/kits/knowledge-agents/adoption-view/intro) and the [High-Level Architecture](https://eclipse-tractusx.github.io/docs-kits/kits/knowledge-agents/development-view/architecture). + +## Constraints + +The Knowledge Agents Architecture is based on the Catena-X Dataspace Architecture with a specific focus on the Eclipse Dataspace Connector (EDC). It integrates with Catena-X Portal/Core Services & Identity Management principles and supports the typical interaction models as required by Catena-X Use Cases, such as + +* Traceability with Focus on Low-Volume Bills-Of-Material Data and Deep Supply Chains with One-Up and One-Down Visibility +* Behaviour Twin with Focus on High-Volume Telematics Data and Flat and Trustful Supply Chain   + +Furthermore, on the vocabulary/script level it utilizes and extends well-defined profiles of W3C Semantic Web Standards, such as OWL, RDF, SHACL, SPARQL. + +## Context and Scope + +The architecture is relevant for the following roles: + +* Business Application Provider +* Enablement Service Provider +* Data Consumer +* Data Provider + +The following Catena-X stakeholders are affected by Knowledge Agent approach + +* **Business Application Provider:** Applications that use KA technology on behalf of a Dataspace Participant (e.g. a Fleet Monitor, an Incident Reporting Solution). + +* **Enablement Service Provider:** Services to assist Dataspace Participants/Applications in processing data based on KA technology (e.g. a Graph Database, a Virtual Graph Binding Engine, an EDC Package). +As a second path, Companies are addressed that want to provide compute resources (for example by a server or other KA-enabled Applications or Services) based on instances/configurations of KA-enabled EDC Packages, for example a Recycling Software Specialist + +* **Data Consumer:** Companies that want to use data and logic (for example by KA-enabled Applications or Services) based on instances/configurations of KA-enabled EDC Packages, such as a Recycling Company or a Tier-2 Automotive Supplier +* **Data Provider:** Companies that want to provide data (for example by a backend database or other KA-enabled Applications or Services) based on instances/configurations of KA-enabled EDC Packages, for example an Automotive OEM. Companies that want to provide functions (for example by a REST endpoint or other KA-enabled Applications or Services) based on instances/configurations of KA-enabled EDC Packages, for example a Tier1 Sensor Device Supplier + +Content-wise the following capabilities of Catena-X are addressed: + +* Query and Search (Basic Mechanism, Integration in User Experiences) +* Services for making use of various federated data sources being part of a data space (Data & Function Provisioning, Logic Development & Provisioning) +* Semantic Modelling +* Publishing, Negotiation, Transfer Protocols and Policy Enforcement via IDS (EDC) connector + +## Solution Strategy + +Knowledge Agents regards the peer-to-peer Dataspace as one large (virtual) knowledge graph. + +A graph, because the representation of data as a set of Triples (Outgoing-Node = Subject, Edge = Predicate, Receiving-Node = Object) is the highest form of normalization to which all other forms of structured data can be abstracted. + +Virtual, because this graph is not centrally instantiated in a dedicated database, but it is manifested by a computation (traversal) which jumps from node to node (and hereby: from the sovereignity domain of one business partner to the another one including taking over authentication and authorization information).   + +Knowledge because computations and graph contents are not arbitrary, but share common meta-data (again in the form of a graph interlinked with the actual instance graph) such that the vocabulary (at least: edge names) is standardized and computations can be formulated (offered) independent of the data. + +To reach that metaphor, the Knowledge Agents Architecture uses the following specifications, some of which are standard-relevant: + +* A general description language based on the Resource Description Framework (RDF) +* A Meta-Model defined by OWL-R +* A platform Ontology (consisting of several domain ontologies) as the Semantic Model +* A description of graphs (=graph assets) which contain instance data for the Semantic Model (or: use-case driven and role-driven subsets thereof) and which may be described as SHACL constraints +* A query language to traverse the graphs in SPARQL and store these queries as skills (=skill assets) in the database + +Non-standard relevant, but provided as a best practice/blueprint architecture are + +* Bindings for relational and functional data + * [R2RML](https://www.w3.org/TR/r2rml/) or OBDA (Ontology-Based Data Access ) for relational data + * [RDF4J](https://en.wikipedia.org/wiki/RDF4J)/SAIL (Storage And Inference Layer) configuration for REST remoting +* SQL- and REST-based Virtualizers which bridge public Dataspace Operations with internal/private backend systems/data sources. + +Knowledge Agents regards the peer-to-peer Dataspace as one large federated execution engine. + +Federation means distributed that is there is no central endpoint/resource which controls the computation, but the execution may be entered/triggered on any tenant and uses a scalable set of resources which are contributed by each participant. + +Federation means independent in that there is no central authentication/authorization regime, but the computation is validated, controled and (transparently) delegated by decentral policies as given/defined be each particpant. + +See also [High-Level Architecture](https://eclipse-tractusx.github.io/docs-kits/kits/knowledge-agents/development-view/architecture). + +## Building Block View + +See chapter [Layers & Modules](https://eclipse-tractusx.github.io/docs-kits/kits/knowledge-agents/development-view/modules) of the Agents KIT. + +[![Architecture High-Level](https://eclipse-tractusx.github.io/assets/images/knowledge_agent_architecture_small-adfd1153ee8a08d5338e311a931d0f3a.png)](https://eclipse-tractusx.github.io/assets/files/knowledge_agent_architecture-3aa46110a6213138c677b339e3647703.png) + +## Runtime View + +[![Runtime View](https://eclipse-tractusx.github.io/assets/images/Runtime_View3-ffe55baacdc5171f0deaef0b987bfd0c.png)](https://eclipse-tractusx.github.io/assets/files/Runtime_View3-ffe55baacdc5171f0deaef0b987bfd0c.png) + +Sequence of actions: + +1. A data provider provides a self description of the piece of knowledge he likes to provide including the terms of conditions in his own data catalogue (Although the diagram depicts only one single instance of the Federated Datacatalog, each EDC of each participant (Provider or Consumer) runs a Datacatalog instance. Beween those synchronisation takes place) + * Graph assets describe means of domain ontologies the + * node classes + * relations (edges between nodes) + * constraints on nodes and relations (temporal, value ranges, regex patterns, ...) + * constraints on the queries/skills that may be executed on the graph (e.g. allowed and denied network connections) + * Graph policies will restrict the following operations on graphs (based on nodes and edges, given an execution context) + * selection + * traversion + * storage + * manipulation + * deletion + * delegation +2. A data provider marks particular graph assets as being visible in the federated data catalog. The federated data catalogues of the federated companies/EDCs will be automatically synchronized. +3. Any consuming app can employ an agent with a suitable skill/query (which can be provided locally or as a remote asset, too) +4. The agent will match the requirements in the skill with the offers in the federated data catalog to fill in the endpoints and usage policies from the self descriptions. +5. Agreements (between XA (5.1), XC (5.2), eventually between AB (5.3)) have to be set up in such a way that the corresponding agents are allowed to communicate through the data plane. +6. The agent delegates a sub-query/sub-skill to the respective knowledge owners (data provider C: 6.1, A: 6.2 and B: 6.3) via an instance of EDC. It annotates the sub-queries with a call context containing the EDC/agent calling sequence and the other assets to be joined with the result data. 6.3 shows that an agent can decide to delegate further down the line +7. The data plane will validate the calling context together with the claims inside the agreement token. +8. The agent executes the actual query by mapping to a backend data system and finally providing the result to the app + +Just as the Federated Datacatalog is a multi-instance-synchronised component, also the Federated Trust is an instance running on each EDC. All Federated Trust instances are synchronised with each other within the referring EDC ecosystem. + +## Deployment View + +See chapter [Deployment](https://eclipse-tractusx.github.io/docs-kits/kits/knowledge-agents/operation-view/deployment) of the Agents KIT. + +(C) 2021,2024 Contributors to the Eclipse Foundation. SPDX-License-Identifier: CC-BY-4.0 From 0f10b35c692fb4e86c08466d77998a563afcebda Mon Sep 17 00:00:00 2001 From: "Dr. Christoph \"Schorsch\" Jung" Date: Tue, 3 Dec 2024 14:26:27 +0100 Subject: [PATCH 2/3] docs: reference the leading repos openapi. --- .tractusx | 2 ++ README.md | 1 + docs/README.md | 2 ++ 3 files changed, 5 insertions(+) diff --git a/.tractusx b/.tractusx index 6efc7db..b179050 100644 --- a/.tractusx +++ b/.tractusx @@ -19,3 +19,5 @@ product: "Tractus-X Knowledge Agents EDC Extensions (KA-EDC)" leadingRepository: "https://github.com/eclipse-tractusx/knowledge-agents" +openApiSpecs: + - "https://github.com/eclipse-tractusx/knowledge-agents/blob/main/docs/api/openAPI.yaml" diff --git a/README.md b/README.md index f72b06c..2c0c320 100644 --- a/README.md +++ b/README.md @@ -29,6 +29,7 @@ KA-EDC is a product of the [Tractus-X Knowledge Agents Kit](https://eclipse-trac * See the [User Documentation](docs/README.md) * See the [Architecture](docs/architecture/Arc42.md) +* See the [OpenAPI definition](https://github.com/eclipse-tractusx/knowledge-agents/blob/main/docs/api/openAPI.yaml) * See the [Authors](AUTHORS.md) * See the [Changelog](CHANGELOG.md) * See the [Code of Conduct](CODE_OF_CONDUCT.md) diff --git a/docs/README.md b/docs/README.md index 39d98f2..fea83c5 100644 --- a/docs/README.md +++ b/docs/README.md @@ -25,6 +25,8 @@ The Tractus-X Knowledge Agents EDC Extensions (KA-EDC) introduces support for th In particular, KA-EDC implements the so-called Matchmaking Agent endpoint that is able to discover and delegate to business data & functions provided by Binding Agents such as provided by [Knowledge Agents Reference Implementations (KA-RI)](https://github.com/eclipse-tractusx/knowledge-agents). +See the [Knowledge Agents OpenAPI](https://github.com/eclipse-tractusx/knowledge-agents/blob/main/docs/api/openAPI.yaml) for a detailed description of this protocol. + In contrast to the Binding Agents which are restricted to a subset of the full SPARQL protocol called the KA-BIND profile, KA-EDC implements the KA-MATCH and KA-TRANSFER profiles. The data upon which KA-EDC operates however consists of ontology information and the data catalogue of the respective dataspace tenant. ## How it works From c238f3e6c33e13d4cfdcd41945e6a7e75415326a Mon Sep 17 00:00:00 2001 From: "Dr. Christoph \"Schorsch\" Jung" Date: Tue, 3 Dec 2024 14:40:02 +0100 Subject: [PATCH 3/3] docs: refactore deployment information into admin guide. --- README.md | 1 + docs/README.md | 162 +------------------------------------ docs/admin/README.md | 188 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 192 insertions(+), 159 deletions(-) create mode 100644 docs/admin/README.md diff --git a/README.md b/README.md index 2c0c320..eee97ff 100644 --- a/README.md +++ b/README.md @@ -30,6 +30,7 @@ KA-EDC is a product of the [Tractus-X Knowledge Agents Kit](https://eclipse-trac * See the [User Documentation](docs/README.md) * See the [Architecture](docs/architecture/Arc42.md) * See the [OpenAPI definition](https://github.com/eclipse-tractusx/knowledge-agents/blob/main/docs/api/openAPI.yaml) +* See the [Administration Guide](docs/admin/README.md) * See the [Authors](AUTHORS.md) * See the [Changelog](CHANGELOG.md) * See the [Code of Conduct](CODE_OF_CONDUCT.md) diff --git a/docs/README.md b/docs/README.md index fea83c5..1db778e 100644 --- a/docs/README.md +++ b/docs/README.md @@ -49,165 +49,9 @@ using different extensions for - Persistence of the Control-Plane-State - Persistence of Secrets (Vault) -## Connector Setup - -The two supported setups are. - -- Setup 1: PostgreSQL & Azure Vault - - [Control Plane](https://github.com/eclipse-tractusx/edc-controlplane/edc-controlplane-postgresql-azure-vault/README.md) - - [Agent Plane](../agent-plane/agentplane-azure-vault/README.md) - - [Data Plane](https://github.com/eclipse-tractusx/edc-dataplane/edc-dataplane-azure-vault/README.md) - - [JWT Auth Extension](../common/jwt-auth/README.md) -- Setup 2: PostgreSQL & HashiCorp Vault - - [Control Plane](https://github.com/eclipse-tractusx/edc-controlplane/README.md) - - [Agent Plane](../agent-plane/agentplane-hashicorp/README.md) - - [Data Plane](https://github.com/eclipse-tractusx/edc-dataplane/edc-dataplane-hashicorp-vault/README.md) - - [JWT Auth Extension](../common/jwt-auth/README.md) - -## Helm Deployment - -To install a KA-enabled EDC (Setup 1 - Postgresql & Hashicorp Vault), add the following lines to the dependency section of your Charts.yaml - -```yaml -dependencies: - - - name: tractusx-connector - repository: https://eclipse-tractusx.github.io/charts/dev - version: 0.7.0 - alias: my-connector - - name: agent-plane - repository: https://eclipse-tractusx.github.io/charts/dev - version: 1.14.24-SNAPSHOT - alias: my-agent -``` - -To install a KA-enabled EDC (Setup 2 - Postgresql & Azure Vault), add the following lines to the dependency section of your Charts.yaml - -```yaml -dependencies: - - - name: tractusx-connector - repository: https://eclipse-tractusx.github.io/charts/dev - version: 0.7.0 - alias: my-connector - - name: agent-plane-azure-vault - repository: https://eclipse-tractusx.github.io/charts/dev - version: 1.14.24-SNAPSHOT - alias: my-agent -``` - -The configuration in your values.yaml follows the [Tractux-X EDC Helm Chart](https://github.com/eclipse-tractusx/tractusx-edc/blob/main/charts/tractusx-connector/README.md). -A few sections can be copied over 1-1 to the agent-plane which we demonstrate in the following. -The agent-plane chart is documented [here](charts/agent-plane/README.md). -The agent-plane-azure-vault chart is documented [here](charts/agent-plane-azure-vault/README.md). - -```yaml -my-connector: - fullnameOverride: my-connector - # -- Dataspace Settings - participant: &dataspacesettings - id: BPNL0000000DUMMY - # -- Self-Sovereign Identity Settings - iatp: &ssisettings - id: *customerDid - trustedIssuers: - - *operatingDid - sts: - dim: - url: *dimUrl - oauth: - token_url: *customerOauth - client: - id: *customerOauthClient - secret_alias: *customerOauthSecret - postgresql: &dbsettings - jdbcUrl: *customerDbUrl - auth: - database: *customerDbName - username: *customerDbUser - password: *customerDbPass - vault: &vaultsettings - azure: *azureVault - hashicorp: *hashicorpVault - controlplane: &consumerControlPlane - endpoints: - management: - authKey: *customerApiKey - bdrs: - server: - url: *bdrsUrl - ingresses: - - enabled: true - hostname: my-connector-cp.domain - endpoints: - - protocol - - management - - api - tls: - enabled: true - certManager: - clusterIssuer: *clusterIssuer - env: - EDC_DATAPLANE_SELECTOR_AGENTPLANE_URL: http:/my-agent-agentplane:8083/api/signaling/v1/dataflows - EDC_DATAPLANE_SELECTOR_AGENTPLANE_SOURCETYPES: cx-common:Protocol?w3c:http:SPARQL,cx-common:Protocol?w3c:http:SKILL - EDC_DATAPLANE_SELECTOR_AGENTPLANE_TRANSFERTYPES: HttpData-PULL - EDC_DATAPLANE_SELECTOR_AGENTPLANE_DESTINATIONTYPES: HttpProxy - EDC_DATAPLANE_SELECTOR_AGENTPLANE_PROPERTIES: '{ "publicApiUrl": "https://my-agent.domain/api/public/" }' - EDC_IAM_TRUSTED-ISSUER_0-ISSUER_ID: *operatorDid - dataplane: - token: &tokensettings - env: - EDC_IAM_TRUSTED-ISSUER_0-ISSUER_ID: *operatorDid - -my-agent: - fullnameOverride: my-agent - participant: *dataspacesettings - iatp: *ssisettings - postgresql: *dbsettings - vault: *vaultsettings - connector: my-connector - controlplane: *consumerControlPlane - token: *tokensettings - auth: {} - ingresses: - - enabled: true - hostname: my-agent.domain - endpoints: - - public - - default - tls: - enabled: true - certManager: - clusterIssuer: *clusterIssuer - configs: - # -- An example of an empty graph in ttl syntax - dataspace.ttl: | - ################################################################# - # Catena-X Agent Bootstrap Graph in TTL/RDF/OWL FORMAT - ################################################################# - @prefix : . - @prefix cx-common: . - @prefix owl: . - @prefix rdf: . - @prefix xml: . - @prefix json: . - @prefix xsd: . - @prefix rdfs: . - @prefix bpnl: . - @prefix bpns: . - @base . - - bpnl:BPNL000000000OEM cx-common:id "BPNL000000000OEM"^^xsd:string; - cx-common:hasConnector . - agent: - synchronization: 360000 - connectors: - BPNL000000000OEM: https://partner-connector-cp.partner-domain - BPNL0000000DUMMY: https://my-connector-cp.domain - services: - # -- A regular expression which outgoing service URLs must match (unless overwritten by a specific asset property) - allow: '(https|(edcs?))://.*' -``` +## Deployment + +see the [Administration Guide](admin/README.md) ## Recommended Documentation diff --git a/docs/admin/README.md b/docs/admin/README.md new file mode 100644 index 0000000..743cb05 --- /dev/null +++ b/docs/admin/README.md @@ -0,0 +1,188 @@ + + +# Tractus-X Knowledge Agents EDC Extensions (KA-EDC) Administration Guide + +## Deployment + +Deployment can be done +* via [JAR libraries](https://github.com/orgs/eclipse-tractusx/packages?repo_name=knowledge-agents-edc&ecosystem=maven) copied into your Java runtime +* via [Docker images](https://hub.docker.com/r/tractusx) +* via [Helm Charts (Stable Versions)](https://eclipse-tractusx.github.io/charts/stable) or [Helm Charts (Dev Versions)](https://eclipse-tractusx.github.io/charts/stable) + +## Connector Setup + +The two supported setups are. + +- Setup 1: PostgreSQL & Azure Vault + - [Control Plane](https://github.com/eclipse-tractusx/edc-controlplane/edc-controlplane-postgresql-azure-vault/README.md) + - [Agent Plane](../../agent-plane/agentplane-azure-vault/README.md) + - [Data Plane](https://github.com/eclipse-tractusx/edc-dataplane/edc-dataplane-azure-vault/README.md) + - [JWT Auth Extension](../../common/jwt-auth/README.md) +- Setup 2: PostgreSQL & HashiCorp Vault + - [Control Plane](https://github.com/eclipse-tractusx/edc-controlplane/README.md) + - [Agent Plane](../../agent-plane/agentplane-hashicorp/README.md) + - [Data Plane](https://github.com/eclipse-tractusx/edc-dataplane/edc-dataplane-hashicorp-vault/README.md) + - [JWT Auth Extension](../../common/jwt-auth/README.md) + +## Helm Deployment + +To install a KA-enabled EDC (Setup 1 - Postgresql & Hashicorp Vault), add the following lines to the dependency section of your Charts.yaml + +```yaml +dependencies: + + - name: tractusx-connector + repository: https://eclipse-tractusx.github.io/charts/dev + version: 0.7.0 + alias: my-connector + - name: agent-plane + repository: https://eclipse-tractusx.github.io/charts/dev + version: 1.14.24-SNAPSHOT + alias: my-agent +``` + +To install a KA-enabled EDC (Setup 2 - Postgresql & Azure Vault), add the following lines to the dependency section of your Charts.yaml + +```yaml +dependencies: + + - name: tractusx-connector + repository: https://eclipse-tractusx.github.io/charts/dev + version: 0.7.0 + alias: my-connector + - name: agent-plane-azure-vault + repository: https://eclipse-tractusx.github.io/charts/dev + version: 1.14.24-SNAPSHOT + alias: my-agent +``` + +The configuration in your values.yaml follows the [Tractux-X EDC Helm Chart](https://github.com/eclipse-tractusx/tractusx-edc/blob/main/charts/tractusx-connector/README.md). +A few sections can be copied over 1-1 to the agent-plane which we demonstrate in the following. +The agent-plane chart is documented [here](charts/agent-plane/README.md). +The agent-plane-azure-vault chart is documented [here](charts/agent-plane-azure-vault/README.md). + +```yaml +my-connector: + fullnameOverride: my-connector + # -- Dataspace Settings + participant: &dataspacesettings + id: BPNL0000000DUMMY + # -- Self-Sovereign Identity Settings + iatp: &ssisettings + id: *customerDid + trustedIssuers: + - *operatingDid + sts: + dim: + url: *dimUrl + oauth: + token_url: *customerOauth + client: + id: *customerOauthClient + secret_alias: *customerOauthSecret + postgresql: &dbsettings + jdbcUrl: *customerDbUrl + auth: + database: *customerDbName + username: *customerDbUser + password: *customerDbPass + vault: &vaultsettings + azure: *azureVault + hashicorp: *hashicorpVault + controlplane: &consumerControlPlane + endpoints: + management: + authKey: *customerApiKey + bdrs: + server: + url: *bdrsUrl + ingresses: + - enabled: true + hostname: my-connector-cp.domain + endpoints: + - protocol + - management + - api + tls: + enabled: true + certManager: + clusterIssuer: *clusterIssuer + env: + EDC_DATAPLANE_SELECTOR_AGENTPLANE_URL: http:/my-agent-agentplane:8083/api/signaling/v1/dataflows + EDC_DATAPLANE_SELECTOR_AGENTPLANE_SOURCETYPES: cx-common:Protocol?w3c:http:SPARQL,cx-common:Protocol?w3c:http:SKILL + EDC_DATAPLANE_SELECTOR_AGENTPLANE_TRANSFERTYPES: HttpData-PULL + EDC_DATAPLANE_SELECTOR_AGENTPLANE_DESTINATIONTYPES: HttpProxy + EDC_DATAPLANE_SELECTOR_AGENTPLANE_PROPERTIES: '{ "publicApiUrl": "https://my-agent.domain/api/public/" }' + EDC_IAM_TRUSTED-ISSUER_0-ISSUER_ID: *operatorDid + dataplane: + token: &tokensettings + env: + EDC_IAM_TRUSTED-ISSUER_0-ISSUER_ID: *operatorDid + +my-agent: + fullnameOverride: my-agent + participant: *dataspacesettings + iatp: *ssisettings + postgresql: *dbsettings + vault: *vaultsettings + connector: my-connector + controlplane: *consumerControlPlane + token: *tokensettings + auth: {} + ingresses: + - enabled: true + hostname: my-agent.domain + endpoints: + - public + - default + tls: + enabled: true + certManager: + clusterIssuer: *clusterIssuer + configs: + # -- An example of an empty graph in ttl syntax + dataspace.ttl: | + ################################################################# + # Catena-X Agent Bootstrap Graph in TTL/RDF/OWL FORMAT + ################################################################# + @prefix : . + @prefix cx-common: . + @prefix owl: . + @prefix rdf: . + @prefix xml: . + @prefix json: . + @prefix xsd: . + @prefix rdfs: . + @prefix bpnl: . + @prefix bpns: . + @base . + + bpnl:BPNL000000000OEM cx-common:id "BPNL000000000OEM"^^xsd:string; + cx-common:hasConnector . + agent: + synchronization: 360000 + connectors: + BPNL000000000OEM: https://partner-connector-cp.partner-domain + BPNL0000000DUMMY: https://my-connector-cp.domain + services: + # -- A regular expression which outgoing service URLs must match (unless overwritten by a specific asset property) + allow: '(https|(edcs?))://.*' +``` +