Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BPNL Hierarchy Implementation #1181

Open
19 tasks
alexaxjonow opened this issue Feb 4, 2025 · 0 comments
Open
19 tasks

BPNL Hierarchy Implementation #1181

alexaxjonow opened this issue Feb 4, 2025 · 0 comments

Comments

@alexaxjonow
Copy link

Overview

Groups with numerous companies and subsidiaries face challenges in managing data and EDCs due to their complex structures. Instead of providing an independent EDC for each entity, a consolidated EDC is used, which complicates data requests and forwarding among companies.

Explain the topic in 2 sentences

Due to the high complexity of group structures, a single dedicated EDC is used to consolidate data for multiple companies, rather than providing an independent EDC for each entity. This results in challenges where a company must request data from another company through an intermediary EDC, which must correctly interpret and forward the data from the originating company.

What's the benefit?

Reduce complexity, and manual effort. Make intermediate EDCs and use cases like PURIS possible.

What are the Risks/Dependencies ?

Potential breaking chance

Detailed explanation

Groups have a large number of companies and subsidaries. Due to the high complexity of the group structure, an independent EDC is not provided for each company or investment, but consolidated via, for example, a dedicated EDC that is only attached to one company and forwards the data to all other participating companies. It is currently not possible to map this complexity in the Discovery Services and EDCs. This has the following consequences: For example, company x would like to receive data from company y. This is then also specified accordingly in the policies. However, when the request is made, it is noticed that there is no EDC for company y, but that the EDC of company y is attached to company z. Company x must now make the request to company z and the EDC must be able to interpret that the EDC is provided by company z, but the data originates from company y.

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.

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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Inbox
Development

No branches or pull requests

1 participant