GIREVE OCPI Testing
Validate GIREVE-facing OCPI workflows with simulated CPO, eMSP, and hub behavior before certification, partner onboarding, or production rollout.
What is GIREVE OCPI testing?
GIREVE OCPI testing focuses on validating your roaming implementation before it connects to a live hub environment. Teams usually need to test credentials exchange, endpoint discovery, locations, sessions, CDRs, tariffs, token handling, and hub-oriented flows across OCPI 2.1.1 and 2.2.1 without depending on live partner availability.
Why this matters
- Hub-facing roaming issues are hard to debug once multiple parties are involved and production timing becomes a variable.
- Pre-validating OCPI 2.1.1 and 2.2.1 flows reduces certification and onboarding risk.
- A simulated environment lets you test both CPO and eMSP perspectives before real counterparties are in the loop.
What to validate
- Credentials handshake, version discovery, and token exchange across GIREVE-facing flows.
- Locations, sessions, CDRs, tariffs, commands, and token validation for CPO and eMSP roles.
- OCPI 2.1.1 baseline interoperability plus OCPI 2.2.1 hub-oriented or extended workflows where needed.
- Error handling for malformed payloads, delayed callbacks, and hub-style async exchange patterns.
Example GIREVE-oriented OCPI validation flow
A typical GIREVE readiness test begins with version discovery and credentials exchange, then validates operational data flows such as locations, sessions, commands, and CDR settlement paths.
Party A -> Hub: GET /versions
Party A -> Hub: GET /versions/2.2.1
Party A -> Hub: POST /credentials
Hub -> Party A: token + endpoints
CPO -> Hub: PUT /locations/{country_code}/{party_id}/{location_id}
Hub -> eMSP: location update
eMSP -> Hub: POST /commands/START_SESSION
Hub -> CPO: command relay
CPO -> Hub: POST /cdrs
Hub -> eMSP: CDR deliveryGIREVE readiness proof points
GIREVE-oriented validation usually centers on proving that the roaming stack can survive real onboarding, partner exchange, and settlement paths before certification starts.
| Area | Coverage | Typical validation |
|---|---|---|
| Credentials and discovery | Version negotiation, token exchange, and endpoint setup | Validate the handshake path that everything else depends on. |
| Operational roaming exchange | Locations, sessions, tariffs, commands, and CDRs | Check the full CPO/eMSP data path before live partner traffic exists. |
| Version strategy | OCPI 2.1.1 baseline plus 2.2.1 expansion | Prepare for both current interoperability and newer hub-oriented requirements. |
Common scenarios
Pre-certification readiness
Validate your roaming flows before a formal onboarding or certification cycle begins.
Version migration
Test OCPI 2.1.1 and 2.2.1 side by side when expanding from core roaming into newer hub-oriented workflows.
Operational regression testing
Re-run locations, sessions, tariffs, commands, and CDR scenarios whenever your roaming backend changes.
Validate GIREVE-facing OCPI flows before they go live
Simulate CPO, eMSP, and hub behavior so you can find interoperability issues before certification or partner onboarding.