ybidois commented 4 weeks ago

Overview

Explain the topic in 2 sentences

We need to develop an API in portal-backend to get data from partner-network-pool instead of calling business-partner-pool service directly from the portal-frontend.

What's the benefit?

To have a consistency to call business-partner-pool services from backend side and this could also avoid firewall issues if we put business-partner-pool service is behind the firewall.

What are the Risks/Dependencies ?

Detailed explanation

We need to develop an API in portal-backend to get data from partner-network-pool instead of calling business-partner-pool service directly from the portal-frontend. This approach will make it consistent and secure, as we are already been calling business-partner-pool service from portal-backed to get legal-entity data by BPN.

API: https://business-partners-pool.example.com/v6/members/legal-entities/search?page=0&size=10

Current implementation

Currently frontend is been calling business-partner-pool directly to get Partner Network data.

Proposed improvements

Feature Team

Contributor

@tfjanjua

Committer

@ntruchsess
@oyo

User Stories

https://github.com/eclipse-tractusx/portal-backend/issues/1079

Acceptance Criteria

[ ] Develop a portal-backend API that facilitates secure access to the endpoint of business-partner-pool and respond data to portal-frontend.
[ ] The portal-backend API should be authenticated first and then route to the business-partner-pool service internally.
[ ] The API should handle errors gracefully and returns appropriate HTTP status codes.
[ ] Expected config change: [PORTAL - BPN] Get data from partner network pool by portal backend portal#457
[ ] Add respective test cases in portal-backend repo.
[ ] Changes should be communicated to the front-end to make appropriate changes over there as well.

Test Cases

Functionality and Test Cases should work as they are working right now because with this change, portal-frontend would be getting partner-network data from portal-backend instead of getting data directly from business-partner-pool and portal-backend would be calling business-partner-pool service internally and responding data to frontend.

Expected Result

Frontend would be getting Partner Networks data from backend directly instead of calling business-partner-pool service directly.
Backend API would be responding more or less the same data as it has been responded by business-partner-pool service.

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 commented 1 week ago

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 contributor and committer

ybidois commented 1 week ago

In review based on comments from @ntruchsess and @oyo during refinement. May not be implemented in this form, depending on feedback from Cofinity-X infrastructure team.