EDDIE Architecture

Appearance

Runtime View

Overview ​

The EDDIE Framework implements a set of core workflows that define how Eligible Parties and customers interact during the lifecycle of data access and sharing. These workflows describe how permissions are created, managed, and terminated, as well as how customer data is transmitted and retransmitted through the system. The following subsections describe these workflows in detail, each illustrated with sequence diagrams.

This section hides the behavior of individual region connectors and outbound connectors. Specific documentation can found on the respective building block pages.

The Eligible Party requests and the customer grants permission to access data ​

This diagram illustrates the complete workflow of how an Eligible Party requests and obtains permission from a customer to access their energy data through the EDDIE Framework. It covers both the setup phase, where a Data Need is created and the EDDIE Popup is embedded into the EP’s website, and the interactive permission flow between the customer, the EDDIE Popup, and the corresponding Region Connector. Once the customer grants consent, the framework establishes a secure data exchange channel that allows the EP to retrieve validated data through the EDDIE Core.

  1. The Eligible Party defines a new Data Need using the API or the Admin Console.
  2. The EP embeds the EDDIE Popup on their website and configures it with the created Data Need.
  3. The Customer visits the EP Website and clicks the EDDIE Popup to begin the permission process.
  4. The EP Website opens a Permission Dialog with the EDDIE Popup.
  5. The EDDIE Popup requests the available Data Needs from the EDDIE Core.
  6. The EDDIE Popup requests the available Permission Administrators from the EDDIE Core.
  7. The EDDIE Popup requests the available Region Connector metadata from the EDDIE Core.
  8. The Customer reviews the Data Need, selects their country and Permission Administrator.
  9. The Customer selects their country and Permission Administrator.
  10. The EDDIE Popup retrieves the appropriate Region Connector element for the selected PA.
  11. The Customer interacts with the RC element (e.g., enters metering point ID, access token).
  12. The EDDIE Popup sends the permission request to the Region Connector based on the customer’s input.
  13. The EDDIE Popup subscribes to updates on the permission status from the EDDIE Core.
  14. The EDDIE Core forwards the permission request to the relevant Region Connector.
  15. The Region Connector redirects the Customer to their Permission Administrator’s portal to approve the request.
  16. The Customer reviews and accepts the permission request in the PA portal.
  17. The Region Connector notifies the EDDIE Core that the permission has been accepted.
  18. The EDDIE Core informs the EDDIE Popup about the confirmation.
  19. The EDDIE Popup displays a confirmation or success page to the Customer.
  20. The Eligible Party sends request to retrieve validated energy data to the EDDIE core.
  21. The EDDIE Core communicates with the Region Connector to access the data.
  22. The Region Connector provides validated energy data.

The customer revokes a previously granted permission ​

  1. The Customer accesses the Permission Administrator’s portal and logs in to manage their existing permissions.
  2. The Customer performs an action in the portal to revoke a previously granted permission.
  3. The Permission Administrator processes the revocation request and confirms that the permission has been revoked.
  4. The Permission Administrator notifies the corresponding Region Connector within the EDDIE Framework that the permission has been revoked.
  5. If no explicit revocation notification is received, the Region Connector may attempt to retrieve data from the Permission Administrator. In this case, the Permission Administrator typically responds with an HTTP 403 or 401 error, indicating that access is no longer permitted.
  6. Upon receiving this error, the Region Connector infers that the permission has been revoked and sends a revocation notification to the EDDIE Core. Alternatively, if no data updates are received for a certain period, the EDDIE Core can also detect the revocation indirectly.
  7. The EDDIE Core updates the permission status in the Database to mark it as revoked.
  8. Finally, the EDDIE Core instructs the Region Connector to stop retrieving and transmitting data related to the revoked permission.

The Eligible Party collects customer data via message broker (Kafka, AMQP, MQTT) ​

  1. The Region Connector collects energy data from the respective regional data source and sends it to the EDDIE Core, formatted either in CIM or in a non-standardized EDDIE format. (Prerequisite: The Eligible Party has configured the EDDIE Framework and ensured that at least one Outbound Connector is enabled.)
  2. The EDDIE Core forwards the received data to all active Outbound Connectors.
  3. The Outbound Connector publishes the data to the configured message broker (Kafka, AMQP, or MQTT).
  4. The Eligible Party subscribes to the relevant topics on the message broker and consumes the transmitted customer data.

The Eligible Party collects customer data via HTTP ​

  1. The Region Connector collects customer data from the Regional Data-sharing infrastructure. (Prerequisite: The Eligible Party ensures that the REST Outbound Connector is enabled in the EDDIE Framework.)
  2. The Region Connector sends the collected data to the EDDIE Core.
  3. The EDDIE Core forwards the data to the REST Outbound Connector.
  4. The REST Outbound Connector temporarily stores the data in the Database.
  5. The REST Outbound Connector makes the data available via an HTTP endpoint.
  6. The Eligible Party requests the data via HTTP Client.
  7. The HTTP Client sends an HTTP GET request to the REST endpoint.
  8. The REST Outbound Connector retrieves the requested data and returns it to the Eligible Party in the response.

The Eligible Party terminates a customer’s permission ​

  1. The Eligible Party initiates a termination of a customer’s permission, either by sending an HTTP request to the EDDIE API, or by clicking a button in the Admin Console.
  2. The EP interface (HTTP client or Admin Console) sends the termination request to the EDDIE Core.
  3. The EDDIE Core routes termination request to the correct Region Connector.
  4. The EDDIE Core updates the Database, marking the permission status as TERMINATED.
  5. The EDDIE Core terminates permission request via Permission Administrator if possible.
  6. The EDDIE Core updates the Database to delete credentials if needed.
  7. The Region Connector confirms the termination with the EDDIE Core.
  8. The EDDIE Core acknowledges the result of the termination process to the EP interface (success or failure).

The Eligible Party retransmits already published customer data (historical data) ​

  1. The Eligible Party initiates retransmission of previously published data by either sending an HTTP request to the API, or by clicking a button in the Admin Console.
  2. The EP Website sends the retransmission request to the EDDIE Core.
  3. The EDDIE Core routes the retransmission request to the correct Region Connector.
  4. The Region Connector retrieves the re-requested historical data from the Metered Data Administrator.
  5. The Metered Data Administrator returns historical data to the Region Connector.
  6. The Region Connector acknowledges the retransmission request to the EDDIE Core (success or failure).
  7. The Region Connector sends the historical data to the EDDIE Core.
  8. The EDDIE Core transmits the data through all enabled outbound connectors (e.g., Kafka, AMQP, MQTT, HTTP).