Learning Hub/Scenarios

Explanations use OCPI 2.2.1. Physical and billing-system events are authored examples.

Part of the lesson OCPI charging session lifecycle

CPO completes the remotely stopped Session

Technical

5 min

OCPI 2.2.1 and 2.3.0. OCPI 2.1.1 has no counterpart for: CPO pushes the remotely started SessionTest this flow runs against a CPO endpoint you have registered.

Test this flow

Technical details off

eMSP sends a StartSession command

CPO posts the start command result

CPO pushes the remotely started Session

eMSP sends a StopSession command

CPO posts the stop command result

CPO completes the remotely stopped Session

The CPO sends the final Session update with PATCH: status COMPLETED, the energy delivered and the end time. The eMSP now holds the completed Session for billing.

The sandbox sends this exchange in a different flow, so there is nothing to run from this step.

Why this matters

The CPO owns the Session. In the push model it sends a new Session with PUT and changes with PATCH; the final status is COMPLETED.

CPO

EMSP

"When the CPO creates a Session object they push it to the corresponding eMSP by calling PUT on the eMSP's Sessions endpoint with the newly created Session object. Any changes to a Session in the CPO system are sent to the eMSP system by calling PATCH on the eMSP's Sessions endpoint with the updated Session object. Sessions cannot be deleted, final status of a session is: `COMPLETED`. When the CPO is not sure about the state or existence of a Session object in the eMSP's system, the CPO can call GET on the eMSP's Sessions endpoint to validate the Session object in the eMSP's system."OCPI 2.2.1 Sessions module · #mod_sessions_push_model

Explore the sessions module →