Question: connecting to a multi-CPO/multi-eMSP platforms

[andacata]

Have you taken into account the connection to a multi-CPO or multi-eMSP platforms?

As I can see, the library is using the platformUrl as an identifier for finding the platform in the repo.

If a part wants to connect to another part that is in a platform that provides a service to many CPOs or eMSPs, the platformUrl may be the same, but the identifier will be the Authorization token and the country_code and party_id fields.

[lilgallon]

PlatformRepository is only used by the ocpi-toolkit to handle credentials-related subjects (checking tokens, using tokens, handshake with a partner). In every one of these subjects, a partner is identified by its platform url. So I think it's right to identify a partner by its URL for these use cases. In the credentials object, a partner can send multiple CredentialsRole, so if a partner has differents roles, it should send all its roles through the roles fields during registration (this information will be stored in 0.0.15).

Then, it's up to the person that uses the ocpi-toolkit lib to extend PlatformRepository and add their own methods if needed. Example: searchOnePlatformByCountryCodeAndPartyId(...)

That was the initial approach, but we may be wrong. It works well in our test scenarios.

---

The case where it may not work is when a partner, let's say partner-a.com registers as CPO, and then wants to register as eMSP separately. In that case, the platformUrl will be the same.

I thought that our approach was enough given the fact that a partner can send many CredentialRole during registration. So every partner, identified by their url should register only once.

Can you describe precisely the case where our approach would not work ?

[andacata]

Forget it. I got confused with 2.1.1. In 2.2.1 it is already explained correctly in section "7.3.1. Credentials object":

A platform can have the same role more than once, each with its own unique party_id and country_code, for example when a CPO provides 'white-label' services for 'virtual' CPOs.

Thanks for your response.