Reconsider if a centralized catalogue service is needed

[larwa99]

The proposed centralized catalogue service is a potential single point of failure and is only needed to bootstrap the lookup of the DSO start-URL. Considering how the MPID is structured (https://gs1.se/guider/kom-igang-guider/identifiera-och-marka-elanlaggningar/), it should be possible to even maintain a static file that maps the three relevant digits in the MPID to the actual DSO's start-URL. How to share that information should be doable to handle between the DSOs.

I therefore suggest that we extend the tariff API with an endpoint to lookup the start-URL for any MPID. This ensures a more robust and distributed solution that does not depend on the centralized service which can be removed. As an API user it is enough to find the start-URL for one participating DSO (e.g. from their homepage), then you can lookup and be pointed to the DSO responsible for any given MPID.

Endpoint format:
/{v}/tariffs/catalogue/{country}/{mpid}

Example lookup request:
https://api.somedso.se/public/v0/tariffs/catalogue/se/735999221123456789
(would respond with start-URL https://api.tekniskaverken.net/subscription/public/)

I don't know how the MPID is structured in other countries, but if it is not equally easy to map it to a DSO as in Sweden, a more advanced lookup (even centralized) can of course be used by the API-implementation to provide a response. To keep it simple, it should also be optional to actually handle a request for a country that is not the same as the DSO is in.

FYI: @portcallbuilder @mattiaspalmqvist

[elden1337]

As api user for single household one domain would suffice, but not for services using the structure throughout the country/ies to serve many customers.

[joachimlindborg]

Do this approach need a sync mechanisms/ upstream source? for the list to always be accurate?.
Otherwise there is a possibility that the list is different on different servers?

[larwa99]

As api user for single household one domain would suffice, but not for services using the structure throughout the country/ies to serve many customers.

Then I think you've misunderstood the proposal - each participating API provider will be aware of the other providers and be able to lookup and point to them (at least within one single country).

When scaling up to more countries it is reasonable to have some kind of lookup handling per country anyway, so it won't differ much from separate catalogue service(s).

[larwa99]

Do this approach need a sync mechanisms/ upstream source? for the list to always be accurate?. Otherwise there is a possibility that the list is different on different servers?

Yes some kind of sync is needed, but it will typically be a list where new entries are added for a while until all DSOs are represented. After that point the list will be more or less static. Maintaining and sharing such a list can be agreed between the DSOs (possibly using https://elnätsavgift.se/) and allows for a daily sync or similar.

[peterrosell]

To make it easy as a API integrator to implement the API it would be preferable to require all DSOs to serve the same API path. Using redirects might generate problems with auth/cookies, depending on what's needed.

A nice solution is to use the DSOs id as a hostname. Then you will access the DSO's service directly, like this https://735999166.eu-tariffs.net/v0/tariffs/catalogue/se/735999166123456789 . In this solution there is no need for a central registry that serves the API integrator requests. The central service will only be used by the DSOs to keep their info up to date. That data needs to include the DNS record, like a CNAME that points to api.goteborgenergi.cloud. Using CNAME will remove the need of keeping the IP numbers in the central registry.

It will make the /tariffcatalogue/lookup/ redundant.

The idea of using DNS in this way comes from EU's Peppol project for routing e-documents. In their solution they points the host to a metadata server that answers with supported documents and the corresponding URLs. That creates a very big DNS server, but for the DSOs the number of hostnames are quite few.

As mention, how other countries do the MPID to DSO mapping need to be concidered, as that logic need to be done by the API integrator before calling the API.

[naile]

it should be possible to even maintain a static file that maps the three relevant digits in the MPID to the actual DSO's start-URL

I don't think this is always possible because of how mergers and acquisitions etc of MGAs (Metering Grid Areas, elnätsområden) and DSOs have distributed MPIDs outside the DSOs initial assigned ranges. IE a range can reside with more than one DSO after such an event. From the provided GS1 link it is highlighted:

Anläggningarna behåller sin identitet även om äganderätten för anläggningen övergår till ett annat företag. Det vill säga, om ett elnätsföretag säljer en del av sitt elnät, och därmed ett antal anläggningar, ska anläggningarna behålla identiteterna i det sålda elnätet. Om ett elnätsföretag upphör att existera och helt övertas av ett annat företag ska även företagsprefixet överlåtas till den nya ägaren.