How can we connect our system to ENAPI?
How can we connect our system to ENAPI?
We implement OCPI versions 2.1.1 and 2.2.1. OCPI connections can be initiated by either side, depending on your preference. We can do the integration and testing either in an integration meeting or asynchronously using our self-service integration tools, that provide you with everything needed to set up and test an OCPI connection.
How does ENAPI sync our data?
How does ENAPI sync our data?
We have implemented every OCPI method, and strongly suggest pushing data to us in real-time. To ensure we're not missing any data we perform a nightly delta sync at 01:00 UTC (1:00 AM) which retrieves only updates from the last 24 hours. A full weekly sync on Sunday 01:00 UTC (1:00 AM) is also performed as a fail-safe.
How can we discover which roaming partners will send us data on the ENAPI OCPI connection?
How can we discover which roaming partners will send us data on the ENAPI OCPI connection?
We have implemented the HubClientInfo module in OCPI 2.2.1 which can update your system in real-time when roaming agreements are made with partners.
In OCPI 2.1.1, we will by default send partner data (once a roaming agreement is in place) to URLs on your system containing the country code and party ID of the partner (e.g. DE/CPO/LOC123). This is OCPI 2.2.1 functionality which we have back-ported to version 2.1.1. If your system does not support this, we can revert to using ENAPI’s country code and party ID (DE*ENA) in URLs (e.g. DE/ENA/LOC123). Please contact us to configure your OCPI connection accordingly.
When we receive data from ENAPI, how do we know which roaming partner the data belongs to?
When we receive data from ENAPI, how do we know which roaming partner the data belongs to?
OCPI 2.2.1 natively supports country_code and party_id fields in JSON data objects, which will correspond to the owner (i.e. the roaming partner) of the data.
For OCPI 2.1.1 we have back-ported these 2.2.1 fields, and we also replace the Location operator.name and Token issuer values with the country code and party ID of the owner (i.e. the roaming partner) of the data.
We have also back-ported OCPI 2.2.1 routing headers to version 2.1.1, as another option for detecting the roaming partner that sent a request.
How will the system know when a new roaming agreement is signed?
How will the system know when a new roaming agreement is signed?
This is dependent on the supported OCPI version. For OCPI 2.2.1 connections, we have implemented the HubClientInfo module that provides this information. For users of OCPI 2.1.1, a different approach is required. We automatically push new updates to partner data once a roaming agreement is signed, this could be used as a trigger to add new partner information, if necessary.
Note that ENAPI does not currently push all partner data out upon the signing of a roaming agreement. However, if ENAPI tries to patch an object on your system and receives a 404 HTTP status code, we will send the full object.
Why is the country code and party ID of the connection different than the data?
Why is the country code and party ID of the connection different than the data?
As a hub, we mean to connect partners to each other through a single OCPI connection. As a result, when you make several roaming agreements with different partners, you will receive the data of these various partners being communicated under a single connection.