Replace the deprecated Zaehldaten service with the Commodity Layer for meter data

ID
ADR 9.5
Status
accepted
Date
2026-09-30
Deciders
KBP architect
Consulted
Commodity Layer team, EnwiCore team
Tags
integration commodity-layer enwicore zaehldaten

Context and problem statement

KBP reads meter data from the Zaehldaten service at …/microservices/commodity/zaehldaten. The service is deprecated. KBP calls it through the NuGet package EnBW.Vertrieb.ServiceConsumer.Zaehldaten and uses two endpoints, both from VertragsdatenHolenBase whenever contract data is loaded:

Endpoint Request Purpose in KBP
GET /vertraege/{vertragsnummer}/zaehler ZaehlerHolenRequest Meters and registers of a contract, for contracts that are awaiting delivery, in delivery, or ended
GET /zaehler/{marketLocationIdentifier}/metrologicalclassification GetMetrologicalClassificationRequest Whether an electricity market location has an intelligent metering system

Two replacements exist. KBP can read the data from EnwiCore directly, which it already calls through the PowerCloud client. Or it can read the data from the Commodity Layer, which it already calls through the Refit client ICommodityLayerApi for customers, contracts, readings, and relocations. Which one should replace the Zaehldaten service?

Decision drivers

  • Leave the deprecated Zaehldaten service.
  • Avoid migrating to an interface that changes again shortly after.
  • Follow the guidance of the teams that own the Commodity Layer and EnwiCore.
  • Keep the number of parallel integration paths for contract data small.

Considered options

  1. Replace the Zaehldaten service with the Commodity Layer.
  2. Replace the Zaehldaten service with EnwiCore directly.
  3. Stay on the Zaehldaten service.

Decision outcome

Chosen option: Replace the Zaehldaten service with the Commodity Layer. The Commodity Layer and EnwiCore teams recommend it. They expect changes in both EnwiCore and the Commodity Layer, and they are currently adapting the EnwiCore interfaces themselves. So there is no stable EnwiCore target to migrate to yet, and they advise KBP to keep using the Commodity Layer.

The Commodity Layer offers counterparts for both calls:

Zaehldaten service Commodity Layer
GET /vertraege/{vertragsnummer}/zaehler GET /api/contracts/{contract_id}/meters
GET /zaehler/{marketLocationIdentifier}/metrologicalclassification GET /api/contracts/{contract_id}/market-location, field is_intelligent_meter_system

Consequences

  • Good, because KBP leaves the deprecated Zaehldaten service and its NuGet service consumer.
  • Good, because meter data joins the Commodity Layer path that KBP already uses for other contract data, through the existing Refit client.
  • Good, because KBP does not build against EnwiCore interfaces that are still being adapted.
  • Bad, because the migration needs work. The Zaehldaten service looks up the metrological classification per market location and date. The Commodity Layer returns it per contract. The migration must confirm that this covers contracts that start in the future.
  • Bad, because the Commodity Layer will also change. This decision has to be revisited when its owning team announces a replacement or an end date.

Confirmation

The migration is done when EnBW.Vertrieb.ServiceConsumer.Zaehldaten and the Zaehldaten configuration are removed from KBP. Revisit this decision when the Commodity Layer team announces a stable EnwiCore target interface or a shutdown date for the Commodity Layer. A migration then needs a new record that supersedes this one.

Pros and cons of the options

Replace the Zaehldaten service with the Commodity Layer

  • Good, because the owning teams recommend it.
  • Good, because KBP already has a client, configuration, and monitoring for it.
  • Bad, because the Commodity Layer will change as well.

Replace the Zaehldaten service with EnwiCore directly

  • Good, because it removes an intermediate layer.
  • Bad, because the EnwiCore interfaces are currently being adapted. The owning teams cannot say which path is more stable.
  • Bad, because the migration effort might have to be repeated.

Stay on the Zaehldaten service

  • Good, because it needs no work now.
  • Bad, because the service is deprecated and its end date is not known.