Message routing

How the MOBI.Hub uses the OCPI routing headers to identify the source and destination of each request.

MOBI.Hub relies on the standard OCPI routing headers to identify the source and destination parties involved in each request.

The following HTTP headers, as defined by the OCPI specification, are supported:

• OCPI-to-party-id
• OCPI-to-country-code
• OCPI-from-party-id
• OCPI-from-country-code

Depending on the OCPI module and operation being performed, MOBI.Hub may use the routing headers to identify both the destination entity and the entity originating the request.

Explicit destination

For operations requiring explicit destination identification, the requesting party shall provide the destination entity through the standard OCPI routing headers.

This applies, for example, to commands initiated by an EMSP, where the target CPO must be explicitly identified:

POST /commands/START_SESSION
OCPI-to-country-code: PT
OCPI-to-party-id: ABC
OCPI-from-country-code: PT
OCPI-from-party-id: XYZ

The requesting party is expected to already possess this information based on the charging location selected by the user and the interoperability relationships configured in the MOBI.Hub platform.

Source identification

The OCPI-from-* headers are also used whenever Mobi.e needs to disambiguate the entity responsible for a request. This scenario is particularly relevant when a single technical platform represents multiple CPOs or EMSPs.

For example, when a shared platform submits a token authorization request on behalf of several CPOs, MOBI.Hub uses the OCPI-from-country-code and OCPI-from-party-id headers to identify the originating entity and validate the request against the configured interoperability relationships and authorization matrix.

Destination inferred by the platform

For specific modules, the destination party can be inferred from information already managed by the MOBI.Hub platform, and therefore no additional routing information is required beyond the standard OCPI headers.

Examples include:

• Sessions;
• CDRs;
• token-related operations.

In these cases, MOBI.Hub determines the appropriate destination based on the token associated with the transaction and the relationships configured in the platform.

Routing principles

MOBI.Hub follows the following routing principles:

• routing information is exchanged using the standard OCPI headers;
• explicit routing is only required when destination disambiguation is necessary;
• source identification may be required to correctly process requests submitted by multi-tenant platforms;
• routing decisions are constrained by the interoperability relationships configured within the MOBI.Hub platform;
• some routing decisions may rely on information already available within the platform, namely tokens, sessions and CDRs..