A Region Connector is a building block of the EDDIE Framework that integrates with the Permission Administrators and Metered Data Administrators of a specific region. Its main responsibility is to implement the permission process of that region and to provide access to validated energy data on behalf of the Eligible Party.

Purpose and Responsibilities

• Connect to the Permission Administrator to manage permission requests.
• Forward permission requests from the Eligible Party to the Permission Administrator for validation.
• Receive notifications from the Permission Administrator about the decision of the final customer.
• Connect to the Metered Data Administrator to access validated energy data, once consent is granted.
• Support multiple Permission Administrators and Metered Data Administrators in a single region, with one Region Connector implementation per unique process.

Context

• Eligible Party: Creates permission requests and consumes the data retrieved by the Region Connector.
• Permission Administrator: Validates permission requests, presents them to the final customer, and communicates the customer’s decision.
• Final Customer: An entity with one or more metering points (electricity, gas, etc.) that can approve or deny requests.
• Metered Data Administrator: Provides validated historical or accounting point data after verifying the customer’s consent with the Permission Administrator.

Variability Across Regions

Since each country or region may define its own processes for managing permissions and accessing data, multiple Region Connector implementations exist:

• If multiple Permission Administrators or Metered Data Administrators follow the same process and data formats, they can be covered by a single Region Connector.
• If processes differ, separate Region Connectors are required.

Interfaces

• Inbound: Accepts permission requests from the Eligible Party (via the EDDIE Core).
• Outbound: Communicates with external Permission Administrator and Metered Data Administrator APIs (e.g., REST, AS4 messaging).

Constraints

• Region Connectors must comply with the regulatory and technical specifications of the respective Permission Administrator and Metered Data Administrator.
• Eligible Parties must be registered with the Permission Administrator and Metered Data Administrator to use the interfaces.
• Sensitive information is only accessed once explicit consent has been confirmed by the Permission Administrator.

The EDDIE Framework uses several Region Connectors, each implementing the permission and data access processes of their respective infrastructures. More information about all the supported connectors can be found in Region Connectors.

Shared Components

These are the components that each region connector will have an instance of. There is a separate instance for each region connector. The following diagram shows some components that are present in all region connectors.

Event Infrastructure

This is the central communications component. It is responsible for:

1. Persisting events to the database
2. Receiving events from the event producers, which can be other components
3. Propagating events to subscribers

Permission Events

A permission event represents a change in a permission request. There are special types of permission events, which are internal events. These events will be ignored by certain event handlers. The internal events depend on the implementation of the specific region connector.

Permission Request

A permission request represents a request initiated by a final customer that is tracked via EDDIE. It is an aggregate of multiple related permission events. A new event will change the state of the permission request.

Permission Request Views

The permission request views are dedicated views in the database. They are responsible for aggregating the permission events to permission requests. Each region connector will have a dedicated view for its permission requests.

Event Handlers

There are two common shared event handlers, that are used by all region connectors to create connection status messages and permission market documents. Those documents are then propagated to the EDDIE Core. They subscribe to all events in the event infrastructure, except internal events. Since they are always present in each region connector, they will not appear in the more detailed building blocks to reduce the complexity.

Persistence

The persistence components are responsible for persisting and querying permission events. Permission events might be preprocessed in the database using the permission request view. This view aggregates related permission events into a permission request.

The persistence components also track which energy data was already received for which permission request.

The persistence components can also query and persist region connector specific components, which are not covered here.

Web Controller

Each region connector will at least have one Web Controller that is responsible for serving API endpoints to create permission requests and retrieving status updates for a specific permission request. In addition, the controllers might implement endpoints for OAuth 2.0 callbacks or similar mechanisms. They can also include other endpoints, not described here.

Providers

Providers are components that make documents produced by the region connector, such as validated historical data market documents, available to the EDDIE Core. They map the region specific data formats to data formats accepted by the EDDIE Core.

Data Needs Services in the EDDIE Core

All region connectors have access to the data needs services, which provide information about data needs. Furthermore, each region connector can configure their data needs services with its constraints to aid in creation and validation of permission requests.

Other shared components

There are shared components that are far too low-level to describe here. Please refer to the Shared Functionality section in the framework docs.