Module hub 

Available on crate feature hub only.

A roaming hub: routing, broadcast push, open routing, GET All, and version bridging.

The four routing arrangements

A hub can tell which one it is looking at from the headers and the method alone, which is what Forwardable::scenario does:

The OCPI-to-* headers say	Method	It is
another party	any	Direct — relay it
the hub itself	GET on a Sender interface	GetAllViaHub — merge every party’s objects
the hub itself	a write on a Receiver interface	BroadcastPush — fan out to the opposite roles
nothing	any	OpenRoutingRequest — decide from the content
the hub itself	anything else	refused: OcpiError::NotRoutable, a 2001

Addressing the hub is the one ambiguous case, and two of its four combinations are not scenarios at all: a GET on a Receiver interface is not a Broadcast Push, because “GET SHALL NOT be used in combination with Broadcast Push”, and a write on a Sender interface is neither a push to the connected parties nor a read to merge. Guessing the nearest scenario would mean a hub quietly broadcasting a read, so Forwardable::scenario refuses, with the advice the specification itself gives: omit the OCPI-to- headers and make it an Open Routing Request.

The rules the hub must not break

• A new X-Request-ID, the same X-Correlation-ID. RequestIds::forwarded.
• last_updated is never touched. “When OCPI Objects are sent via Hubs, the last_updated fields SHALL NOT be updated by the Hub.” Nothing in this module writes it.
• GET is never broadcast. “GET SHALL NOT be used in combination with Broadcast Push.”
• Configuration modules are never routed. credentials, versions and hubclientinfo are platform-to-hub conversations.
• Vendor data survives. Because every object keeps its unknown fields in Extensions and every OpenEnum keeps values it does not know, a hub built on this crate forwards an extension it has never seen without damaging it. That is what OCPI 2.3.0’s extensibility chapter asks for, and it is the single most common way a hub loses data.

Version bridging

A 2.2.1 CPO and a 2.3.0 eMSP talk through the hub without either of them knowing: Forwarder translates the request body into the version the receiving platform speaks, translates the response back, and appends what the crossing cost to the status_message so the requesting party can see it. That is convert doing the work and Lossy doing the reporting; no object is ever handed to a party in a version it did not ask for, and nothing is dropped silently.

Only the 2.2.1 ↔ 2.3.0 crossing has conversions today. A message between two versions this build cannot translate is refused by default rather than relayed — see Unbridgeable for the reasoning and for how to relay it anyway. bridge exposes the same classification for a hub that wants to translate an object itself.

Spec: 2.3.0 §transport_and_format_message_routing, §status_codes_4xxx_hub_errors

Structs

BodyOwnerRouter

An OpenRouter that reads country_code and party_id out of the request body.

ConnectedPlatform

One platform connected to the hub, and the parties it speaks for.

Forwardable

What the hub was asked to relay.

Forwarder

Relays requests to the platforms in a RoutingTable.

Relayed

The outcome of relaying one request to one party.

RoutingTable

The hub’s map from party to platform.

Enums

AggregatePolicy

How a fan-out’s results become one answer for the sender.

Bridge

What a hub must do to a message crossing between two OCPI versions.

Unbridgeable

What a hub does with a message between two versions it has no conversions for — today, anything involving OCPI 2.1.1 or a version this crate does not model.

Traits

OpenRouter

Decides where an Open Routing Request should go, from its content.

Functions

aggregate

Turns the results of a fan-out into the status code the sender is told.

bridge

What the hub must do to carry a message from sender to receiver.