Skip to main content

๐Ÿ”„ Moving legacy hub integrations to ENAPI

Seamless migration to ENAPI for streamlined operations, accurate data, and minimal downtime with dedicated support.

Jakob Kleihues avatar
Written by Jakob Kleihues
Updated over 7 months ago

Migration process for CPOs

Migrating your roaming connections to the ENAPI platform streamlines your operations and improves overall efficiency.

To migrate your roaming connections to the ENAPI platform, follow these general steps:

Pre Migration

Ensure you have set up an OCPI connection with the ENAPI platform.

Migration

  1. For each roaming agreement that needs to be migrated:

    1. Establish the roaming agreement within ENAPI.

    2. Perform a full synchronization with ENAPI to receive all tokens.

    3. At this point, you will have duplicate tokens in your system (one from the legacy hub, one from ENAPI). Sessions may start on either the legacy hub or ENAPI.

      • If you have a token prioritization system: Configure it to prioritize ENAPI tokens over legacy hub tokens.

      • If you don't have a token prioritization system:

        • Select a test token and invalidate its legacy hub variant in your CPMS.

        • Conduct a test session using this token to ensure it routes through ENAPI.

        • After successful testing, schedule the following steps during off-peak hours (preferably at night):

          • Invalidate all other legacy hub tokens

          • Remove the legacy hub connection/roaming agreement.

    4. Disable the connection with the legacy hub in your CPMS and/or in the legacy hub platform itself to prevent further updates to tokens and other OCPI objects from the legacy system.

  2. Repeat step 2 for each roaming agreement until all have been migrated to ENAPI.

Post Migration

Post-migration verification: Conduct a series of test transactions across different roaming partners to ensure all systems are functioning correctly through ENAPI.

๐Ÿ’ก Note: The exact implementation of these steps may vary depending on your specific CPMS. Consult your CPMS documentation or support team for system-specific instructions on managing OCPI connections, token validation, and session routing.

Common challenges and solutions:

  • Token synchronization issues: If you encounter discrepancies in token data, perform a manual reconciliation between your CPMS and ENAPI.

  • Routing problems: If sessions are not routing correctly, double-check the invalidation status of legacy tokens in your CPMS or the configuration of your token prioritization system.

For support during the migration process, please contact us as we're happy to help in any way.

Migration process for eMSPs

Migrating your roaming connections to the ENAPI platform streamlines your operations and improves overall efficiency. The process may vary slightly depending on whether the legacy hub changes IDs or not.

To migrate your roaming connections to the ENAPI platform, follow these general steps:

Pre Migration

Ensure you have set up an OCPI connection with the ENAPI platform.

Migration

  1. For each roaming agreement that needs to be migrated:

    1. Establish the roaming agreement within ENAPI.

    2. Perform a full synchronization with ENAPI to receive all location data.

    3. At this point, you may have duplicate location data in your system (one from the legacy hub, one from ENAPI).

      • If you have a location prioritization system: Configure it to prioritize ENAPI data over legacy hub data.

      • If you don't have a location prioritization system:

        • Either hide locations coming from ENAPI temporarily, or

        • Schedule the following steps during off-peak hours (preferably at night):

          • Set all legacy hub location EVSEs to REMOVED status in your system.

          • Remove the legacy hub connection/roaming agreement.

    4. Conduct test transactions to ensure proper routing through ENAPI.

    5. Disable the connection with the legacy hub in your system and/or in the legacy hub platform itself.

  2. Repeat step 2 for each roaming agreement until all have been migrated to ENAPI.

Post Migration

Conduct a series of test transactions across different roaming partners to ensure all systems are functioning correctly through ENAPI.

๐Ÿ’กNote:

  • If the legacy hub doesn't change IDs, ENAPI will provide operator party information even in OCPI 2.1.1. You may simply disconnect from the legacy hub after establishing the ENAPI connection.

  • Ensure you've pulled all necessary sessions and CDRs from the old connection before removing it, as you won't be able to receive this historical data through ENAPI.

  • The exact implementation of these steps may vary depending on your specific eMSP system. Consult your system documentation or support team for specific instructions on managing OCPI connections and location data.

Common challenges and solutions:

  • Data synchronization issues: If you encounter discrepancies in location data, perform a manual reconciliation between your system and ENAPI.

  • Duplicate data handling: By default, ENAPI does not send data using DE*ENA. This is an optional configuration that can be enabled if required for your specific use case. In cases where the optional DE*ENA configuration is enabled and you encounter duplicate data, follow the instructions for systems without location prioritization.

For support during the migration process, please contact us as we're happy to help in any way.

Commercials

Once CPOs and eMSPs agree on an offer via ENAPI, roaming begins (POI data and tokens are exchanged). Unlike legacy roaming hubs, ENAPI does not create a lock-in effect for marketplace participants, as roaming agreements remain bilateral.

As a result, you will now see the roaming partnerโ€™s party ID in your CDRs, instead of the hubโ€™s party ID. While this may require minor adjustments to CPOโ€™s invoicing processes, it ensures greater independence and more accurate data.

After the migration, CPOs and eMSPs benefit from faster, more reliable connections, reduced operational complexity, improved scalability, enhanced security, and overall cost savings.

How ENAPI mitigates risks through thorough testing

You can be confident that your roaming integrations will work smoothly when moving them to ENAPI due to our robust and automated technical onboarding process. This system, equipped with integrated test tooling, allows for error-free self-onboarding while minimizing the risk of manual errors. Although self-onboarding is available, we prefer to hold integration meetings to offer personalized guidance and address any specific questions or concerns.

After onboarding, we manually verify key data points and check for edge cases to ensure everything functions as expected. Additionally, partners have a dedicated point of contact for ongoing support. Our platform undergoes rigorous automated and manual testing, including end-to-end tests for OCPI and user interfaces. With a zero-downtime deployment process and frequent updates, we ensure that improvements are delivered quickly and without disruption.

FAQ

What are the main benefits of migrating to the ENAPI platform?

Migration to ENAPI streamlines operations, improves efficiency, provides faster and more reliable connections, reduces operational complexity, improves scalability, enhances security, and offers overall cost savings.

How long does the migration process typically take?

The duration can vary depending on the number of roaming agreements and the complexity of your system. It's recommended to migrate one roaming agreement at a time, and the process includes setup, synchronization, testing, and verification stages.

Do I need to set up new roaming agreements on ENAPI?

Yes, you need to establish each roaming agreement within ENAPI as part of the migration process.

What happens to my existing tokens/locations during the migration?

During migration, you will temporarily have duplicate data (tokens for CPOs, locations for eMSPs) from both the legacy hub and ENAPI. The process includes steps to manage this duplication.

What if I don't have a token/location prioritization system?

If you don't have a prioritization system, the migration process includes steps to manually invalidate legacy data and test new connections. It's recommended to perform these steps during off-peak hours.

Will there be any downtime during the migration?

The process is designed to minimize downtime. By following the step-by-step guide and performing critical steps during off-peak hours, you can maintain service continuity.

How does ENAPI handle ID changes from legacy hubs?

ENAPI's handling of IDs depends on the specific legacy hub. For example, e-clearing changes IDs in a specific way, while Hubject also changes IDs. ENAPI will manage these differences in the background.

What kind of support is available during the migration process?

ENAPI offers dedicated support throughout the migration process. You'll have a fixed point of contact, and the team is happy to help with any questions or issues that arise.

How can I ensure the migration was successful?

After migration, you should conduct a series of test transactions across different roaming partners to verify that all systems are functioning correctly through ENAPI.

Will I need to change my invoicing process after migration?

You may need to make minor adjustments to your invoicing process, as you'll now see the roaming partner's party ID in your CDRs instead of the hub's party ID.

What should I do if I encounter data synchronization issues?

If you encounter discrepancies in token or location data, perform a manual reconciliation between your system and ENAPI. Contact ENAPI support if you need assistance with this process.

Is it possible to revert to the legacy hub if needed?

While the migration process involves disabling connections with the legacy hub, it's recommended to consult with ENAPI support if you need to revert. They can guide you through the best approach based on your specific situation.

Did this answer your question?