Set up access to ALL BP data records in CX-Pool

[zygokaktus]

Overview

Establish a technical access via API to all BP data records in the CX Pool ("BP look-up"), not only the BP data records for companies which are onboarded CX-member. This shall apply to the BP data of all three levels: L/S/A. The content of the found BP data record shall be displayed.

What's the benefit?

Establishing an access to the whole CX BP data records would be an enabler for an improved BP data maintenance processes of a CX-member.
With this function it will be possible to search for BP in the CX Pool, no matter if they are onboarded yet or not, and use the content of the found data record for further usage (e.g. creating the BP in the own Master Data Management System (MDM) of a CX member).

What are the Risks/Dependencies ?

No bulk look-up shall be allowed in order to prevent a "download" of the whole CX BP Pool.
This risk needs to be technically mitigated in the course of the API development (data sovereignity / data security aspects)
It is important that no data ownership rights/rules are violated.
It is mandatory that there is no visible link between the data set and the original sharing member.

Detailed explanation

The idea here is that a CX-member has the option to initiate an automated, API-based BP-look-up in the CX-Pool, based on current selection criteria (For the future more selection criteria are planned, see eclipse-tractusx/bpdm#781 and #603). In case there are matches in the CX BP Pool the data record content shall be retrievable. In case there is more than a single match all corresponding matches shall be provided as a result. An option to control/limit the number of provided matching data records needs to be foreseen (e.g. relevant if the selection criteria is a widely uses name part, like a string starting with "A".
In case there is no match a corresponding info message shall be set up.
No bulk BP-look-up shall be foreseen, it is always based on a single BP-lookup request.

The results of the BP-look-up shall comprise of all three levels of a BP, as long ase they fulfill the selection criteria.

Current implementation

Proposed improvements

Feature Team

Contributor

• Contributor 1
• Contributor 2

Committer

• Committer 1
• Committer 2

User Stories

• Issue 1, linked to specific repository
• Issue 2, linked to another specific repository

Acceptance Criteria

• Criteria 1
• Criteria 2
• Criteria 3

Test Cases

Test Case 1

Steps

1. Do something
2. Click something
3. Add something

Expected Result

1. Expectation
2. Expectation
3. Expectation

Architectural Relevance

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

In the context of the standards 126 and 127, typically only one is applicable, depending on the specific use case. Please cross out one of the two standards that does not apply.

• 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)
    • CX-0126 Industry Core: Part Type 2.0.0
    • CX-0127 Industry Core: Part Instance 2.0.0
  • 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)

[zygokaktus]

This issue is derived from the existing Sig-relase issue: Extension of BP search function #603, but just focusing on the aspect of automated retrieval of ANY BP data record from the CX-Pool, no matter if this BP is member of CX network or not (shared BP data).

It pays into the roadmap item:
https://github.com/catenax-eV/sig-roadmap/issues/38

[Sebastian-Wurm]

Note that there is a sig-release portal issue that deals with hiding technical user profiles for subscribers of the existing services / consumers of BPDM assets. When implementing this sig-release issue, we would have to add the corresponding technical user profile for the "all business partners" service / asset to the list of hidden technical user profiles, see #987 (comment)

[JulianStoll]

contact person/Lead from EG Data sovereignty: [email protected]

[Sebastian-Wurm]

contact person/Lead from EG Data sovereignty: [email protected]

^(fixed the email address)

Next step is here to connect to the data sovereignty expert group and ask for help regarding the BPDM purposes in the Catena-X ODRL Profile: https://github.com/catenax-eV/cx-odrl-profile/blob/main/profile.md.

Either the current cx.bpdm.pool:1 purpose needs to be adapted or a new purpose, that allows access to the whole BPDM Pool needs to be created. Data sovereignty expert group can also help in getting contact to the required lawyers to formulate the purpose.

@DanielaWuensch : FYI