Everything you need to know about OCPI 2.1.1 and the ENAPI platform

The ENAPI Transaction Broker fully supports OCPI 2.1.1.

However, where necessary the schema has been extended to:

• Implement the "hub" topology which is not natively supported by version 2.1.1

• Provide added-value functionality seen in other OCPI versions and protocols

• Ensure smooth operation for partners on their OCPI version of choice

Roaming on 2.1.1 with a partner that implements OCPI 2.2.1+ has the biggest impact. Similarly, it is important to be aware of the limitations when roaming with a 2.1.1 partner on OCPI 2.2.1+ connections.

This document outlines all additions made and the caveats when roaming across OCPI versions.

🔌 Roaming Partners

ENAPI's Credentials

As part of the Credentials handshake, ENAPI will provide your system with its own hub credentials: DE*ENA.

Receiving Roaming Partner Credentials

In OCPI 2.1.1 there is no way for ENAPI to share the list of roaming partners from which you will receive requests on the ENAPI platform. You must prepare your platform for this before roaming with a partner.

Data received from roaming partners via ENAPI will have the country_code and party_id of the roaming partner in the URL. If your platform does not support this, ENAPI can use its own credentials in the URL.

If the ENAPI credentials are used in the URL, data such as locations and tokens that need to be mapped internally to an operator must be done so via other means. ENAPI modifies the Location operator and Token issuer in OCPI 2.1.1 for this reason. How this is done is outlined in the Version Interoperability section below.

🌐 Version Interoperability

OCPI 2.1.1 features the most changes of all OCPI versions implemented by ENAPI. This section contains information for partners that support OCPI 2.1.1, or which roam with OCPI 2.1.1 partners.

Roaming using OCPI 2.1.1

Common Changes

Each top-level OCPI object (Location, Tariff, Token, Session, CDR) contains the country_code and party_id to help with identification of the operator, for billing purposes. They are not required to be set by the sending 2.1.1 party. They are added by ENAPI (2.1.1 receivers can opt-out).

New Functionality in OCPI 2.2.1+

You will not receive fields and enumeration values added in OCPI 2.1.1 unless explicitly back-ported by ENAPI. Where necessary, ENAPI maps the incompatible values to OCPI 2.1.1 compatible values.

Locations

• The operator.name field is also set to the country_code and party_id of the Location owner, in case the above values are not supported. For example, if the Location has country_code=DE and party_id=CPO, the value of the operator's name will be DE*CPO.

• Postal code is optional in OCPI 2.2.1+. If receiving a Location from a 2.2.1+ partner that does not include the postal_code, this value will be an empty string.

• Connectors that have incompatible standard, format and power_type values (i.e. introduced in subsequent OCPI versions) are omitted in OCPI 2.1.1. They will not be shared with OCPI 2.1.1 roaming partners.

• If a 2.2.1+ roaming partner assigns multiple Tariff IDs to a Connector, ENAPI will attempt to infer the correct Tariff ID for OCPI 2.1.1 partners., based on the Tariff type. If no tariff ID can be selected, it is omitted.

• The max_electric_power field was back-ported to OCPI 2.1.1 (see below).

Connector Object

Made available to OCPI 2.1.1 receivers when roaming with 2.2.1+ partners.

Tokens

• The issuer field is also set to the country_code and party_id of the Token owner, in case the above values are not supported. For example, if the Token country_code=DE and party_id=MSP, the issuer value will be DE*MSP.

Sessions and CDRs

• In OCPI 2.1.1, ENAPI uses PENDING as a fallback session status, in case of receiving e.g. the RESERVATION status value in 2.2.1 or 2.3.0.

• The FLAT CDR Dimension was removed from subsequent OCPI versions. CDR Dimensions with this type are filtered out in version 2.2.1+.