Connector Registration and Management Improvements

[ybidois]

Overview

Explain the topic in 2 sentences

Improve Connector Registration and Management

What's the benefit?

Reduce complexity in registering and managing Connectors

What are the Risks/Dependencies ?

No dependency

Detailed explanation

Current implementation

Current implementation leads to a lot of confusion between owned and "managed" connectors. The registration process itself is not easy for first-time participants in the dataspace.

Proposed improvements

• Improve Connector Registration and Management API endpoints
• Improve UX/UI and copywriting to better differentiate between owned and 3rd-party provided connectors
• Bring back tab for EDC providers to see connectors registered in behalf of their customers

Feature Team

Contributor

• @dhiren-singh-007
• @saadanzari
• @ybidois

Committer

User Stories

• Provider view for the connector which is provided by provider company to customer/host company portal-backend#1087
• Technical user api to link with OWN connector portal-backend#1139

Acceptance Criteria

• Great UX/UI for registering and managing Connectors
• API endpoints support registration and management of connectors both from the perspective of a Dataspace Participant and an EDC provider

Test Cases

Test Case 1: As a Dataspace Participant

1. I can register my own Connector
2. I can see the details of my own Connector
3. I can de-register my own Connector

Test Case 2: As a Dataspace Participant

1. I can see Connectors registered on my behalf
2. I can see the details of my managed Connector
3. I cannot edit the details of my managed Connector
4. I can de-register my managed Connector

Test Case 1: As an EDC Provider

1. I can register a Connector for a customer
2. I can see the details of the Connector I registered for a Customer
3. I can edit the configuration of the Connector
4. I can de-register the Connector

Architectural Relevance

The following items are ensured (answer: yes) after this issue is implemented:

• This feature aligns with our current architectural guidelines
  • Data Sovereignty: All data sharing activities across company boundaries follow the Catena-X Regulatory Framework, in particular the Data Exchange Governance, and the Dataspace Protocol via a compliant Connector (like the tractusx-edc or similar, see Connector KIT)
    • CX-0010 Business Partner Number
    • CX-0013 Identity of Member Companies
    • CX-0018 Data Space Connectivity (EDC)
    • CX-0049 DID Document Schema
    • CX-0050 Framework Agreement Credential
    • CX-0149 Verified Company Identity
  • Interoperability: Digital Twins are used (compliant to the Digital Twin KIT and the Industry Core KIT)
    • CX-0001 EDC Discovery API
    • CX-0002 Digital Twins in Catena-X
    • CX-0018 Data Space Connectivity (EDC)
  • Data Format:
    • The data model is based on a published Semantic Model
• The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
• Potential risks or conflicts with existing architecture has been assessed

Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)

Additional information

• I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)

[stephanbcbauer]

Some hints from Release Management (@ther3sa) and Tractus-X Project Lead (@stephanbcbauer)

• Status currently in Inbox. ⇾ Only features with status backlog are considered in open planning
• Please add missing sections from the feature template, or fill them out
• Please add committer

[evegufy]

Committers:
@oyo
@ntruchsess
@Phil91
@evegufy