Extension of search function for sharing members to search for all Business Partners in the pool

[rybtim]

Overview

This feature aims to introduce enhanced search functionality for Business Partners in the CX network. It improves the current available options for identifying Business Partners in different scenarios like e.g., within the CX-onboarding process.
The benefit of the new functionality is that a member can search for a business partner based on several characteristics and receives the latest information out of the network.

Explain the topic in 2 sentences

Enhance business partner management by adding further options for searching for Business Partners in the CX Pool. The goal is to identify Business Partners which are already known in the CX network based on new search criteria which will be established in the scope of this feature.

What's the benefit?

The benefit of this functionality is that a member can search for a business partner based on several characteristics and receives the latest information out of the network.

What are the Risks/Dependencies/Restrictions ?

Dependencies:
Technical implementation of enhanced search criteria in the portal must be foreseen in a future release.

Restrictions:
As this is a base functionality and designed to use the CX Data-Pool as source, it is important that no data ownership rights/rules are violated. The privacy classification of the single fields is described below.
It is mandatory that there is no visible link between the data set and the original sharing member.

The Scope of this feature is focussing on the CX-Pool; functionality can be enhanced for the gate API at a later stage.

Detailed explanation

Current implementation

Currently, the search function for Business Partners allows only search by name / name parts and Business Partner Number (BPN). No other search criteria are supported.
It is also limited to onboarded CX members and does not contain BP which are shared by CX members
Reference :
https://github.com/eclipse-tractusx/bpdm/blob/main/docs/api/gate.yaml
https://github.com/eclipse-tractusx/bpdm/blob/main/docs/api/pool.yaml

Proposed improvements

The search can be conducted via the following fields:

Criteria	Description	Mandatory	Search Type	Comment
ID	CX-BPN (either L/S/A)	No	Exact	BPN not mandatory no wild card searches. Exact Search.
Name+Legal Form	The name of the company + Legal form of the company	No	Fuzzy	If BPN is not available at least Name + Legal form must be filled Access to ALL BP data records in CX pool
Country	Country of the company	No	Exact, based on country code list ISO 3166-1
Street	Address of the company	No	Fuzzy
Zip-Code	Zip Code of the company	No	Fuzzy	Physical address? Both?
City	City of the company	No	Fuzzy	Physical address? Both?

A combination of search criteria must be possible

The following information shall be shown for a found record:

Criteria	Description	Privacy Classification	Comment
ID	CX-BPN	Public
Name	The name of the company e.g. BMW AG)	Public
Legal Form	Legal Form of the company (e.g. Gesellschaft mit beschränkter Haftung)	Public
Country	Country of the company according to ISO 3166-1 alpha-2 country codes	Public
Street	Address of the company (e.g. Petuelring 130)	Public
City	City of the company (e.g. Munich)	Public
Zip Code	Zip number of the company (e.g. 80809)	Public
Identifier Type	EU_VAT, TAX_ID	Public
Identifier Value	DE XYZ	Public

Display Results:
There should be the functionality of filtering the search results:

• Checkboxes for the user to be able to select only
  - BPNL (Text: Show only legal Entities)
  - BPNS (Text: Show only Sites)
  - BPNA (Text: Show only Additional Addresses)
  - Combination of these checkboxes must be possible
• Limit amount of search results to 100
• Sort according best matches

Search Type Definition

Exact

The given text must match case-sensitive exactly

Fuzzy

1. Search should recognize/harmonize to find matches for spellings with

   "ü" and "ue" and similar
   "ß" and "ss"
   upper and lower case
   double spaces or double dots or similar

2. Search should be capable to deal with wildcards

   placeholders like "" and "+", like Siemen, SiemAktien, BPNAL0000000FX+++ (also repeating) where "+" represents one alphanumeric character

Feature Team

Contributor

• @AmirMattarx
• @kunyao-cofinity-x

Committer

• @nicoprow
• @SujitMBRDI

User Stories

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

Acceptance Criteria

• Different search parameters has been implemented
• Search based predefined combinations of search criteria can be peformed
• Already existing search functionality still works

Test Cases

Test Case 1

Search by address data.

Steps

1. Enter e.g. Street/City/Country
2. Peform search
3. Check results

Expected Result

1. Limit number of displayed results (max. 100)
2. Only relevant search results shall be displayed
3. Results should be shown as described

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)

[jjeroch]

Attention @rybtim : Upcoming PI Planning Preparation

As we gear up for the forthcoming PI Planning session, it is crucial that all features under consideration align with our established Feature Quality Standards and Definition of Done (DoD) guidelines. To ensure your feature is thoroughly prepared and stands a strong chance of being prioritized, please provide comprehensive documentation that includes the following components:

1. Feature Summary: An executive overview that encapsulates the essence and objectives of the feature.
2. Change Description:

• High-Level Overview: A succinct synopsis of the proposed changes and their overarching impact.
• Detailed Analysis: An in-depth exploration of the specific alterations, including a clear exposition of the anticipated impact on existing systems.

3. Impacted Components: A list identifying all system components that will be affected by the feature implementation, accompanied by a brief explanation of the nature of the impact.
4. Acceptance Criteria: A set of clearly defined conditions that must be met for the feature to be considered complete and acceptable.
5. Test Scenarios: A detailed outline of test cases that cover all functional paths of the feature to ensure robust validation and verification.
6. Risks/Dependencies

Please note that any feature submissions lacking these essential elements will not be eligible for consideration in the upcoming PI Planning. It is imperative that your documentation is both thorough and precise to facilitate a smooth and effective planning process.

Please let me know in case you have any questions

[Grand-Thibault]

@rybtim please add more to the description

[rybtim]

No implementation feature for R. 24.08. Handover to Expert Group plannend and moved to Inbox

[stephanbcbauer]

@rybtim added you as assignee because we need a contact person for every feature.

[stephanbcbauer]

Didn't think about it before, but since the feature is still in Inbox, the open decision label is not needed. Opinions?

[JulianStoll]

eclipse-tractusx/bpdm#781

[stephanbcbauer]

@rybtim if this feature is still valid, and we want to have it in the planning for 25.03, Would it be possible for you to also upgrade it to the new feature template

[maximilianong]

Hi @rybtim , I think the contributors will be @AmirMattarx / @kunyao-cofinity-x and not me :) But as a committer to support / review this you can add @nicoprow / @SujitMBRDI

[maximilianong]

Hi @rybtim , I think the contributors will be @AmirMattarx / @kunyao-cofinity-x and not me :) But as a committer to support / review this you can add @nicoprow / @SujitMBRDI

I updated it.

[zygokaktus]

As aligned during our refinement day 2 here the business requirements (draft, to be confirmed by BRE team) regarding "fuzzy search":

1. Search should recognize/harmonize to find matches for spellings with

• "ü" and "ue" and similar
• "ß" and "ss"
• upper and lower case
• double spaces or double dots or similar

2. Search should be capable to deal with

• placeholders like "*" and "+", like Siemen*, Siem*Aktien*, BPNAL0000000FX+++ (also repeating) where "+" represents one alphanumeric character

[stephanbcbauer]

As discussed, the open decision label can be removed

[stephanbcbauer]

Only backend work is described in the feature -> no frontend (portal) change is needed for 25.03 -> remove dependency portal in the description

[nicoprow]

@rybtim @ zygokaktus I have added the search type definitions into the issue description on top. Please have a look if you agree with this definition