Version 0.0.16

What's Changed

• fix(cdrs) #40: Use GeoLocation for coordinates by @atschabu in #41
• fix(sessions) #38: Time and EvseUid validation invalid by @atschabu in #39

Full Changelog: R-0.0.15...R-0.0.16

Version 0.0.15

Most of the developments of this version were made on branch 0.0.15, in the future, all features will be added one by one with one pull request by feature / fix / improvement. So the changelog in the future will be clearer.

What's Changed

• fix(ocpi-2.2.1): path for PATCH evse and connector by @atschabu in #25
• fix(ocpi-2.2.1) nullable return in SessionsEmspRepository.getSession by @andacata in #35
• fix(ocpi-2.2.1) use SessionPartial in SessionsEmspRepository.patchSession by @andacata in #36
• Version 0.0.15: Migrate from kapt/mpApt to ksp by @lilgallon in #31
• Version 0.0.15 by @lilgallon in #32, which includes:
  • Remove 2.1.1 and 2.1.1-gireve modules
    • closes #15
    • closes #13
    • closes #12
  • Use suspend functions for repositories
    • closes #21
  • Save credentialsRole during registration process
    • closes #27
  • Invalidate right token on unregistration instead of both of them (if partner unregisters, then invalidate clientToken, otherwise invalidate serverToken)
  • Make sure registration works when serverToken exists but not token A (it happens when a partner unregisters, then registers itself with its clientToken, which is our serverToken)
  • Use camelCase instead of snake_case. Make sure mapper serializes and deserializes data so that DTOs are in snake_case
  • Rename Platform to Partner
  • Repo changes:
    • Added contribution guidelines
    • Bump to gradle 8.4
    • Review CI / CD
    • Bump libs
    • Setup linting with ktlint
    • Contribution guidelines

Migration guide

The goal of this PR was to include most of the breaking changes that had to be done. Now we should not need any further big refactos. More breaking changes are still to be expected, but the impact should be limited.

• All ocpi fields are now written in camelCase instead of snake_case. You will have to rename them if needed. You may also have to update the data stored in your databases (or use a mapper to serialize / deserialize using snake_case)
• All references to "platform" were renamed "partner", so it has to be updated in your implementations
• Suspend functions are used for repositories now, so you have to update your implementations to support that
• Credentials object now has roles fields. You have to update your implementations to add this field (you may have to update your data stored in DB)

New Contributors

• @atschabu made their first contribution in #25
• @andacata made their first contribution in #35

Full Changelog: R-0.0.14...R-0.0.15

0.0.14 - Fixed tokens usage & headers

Available on maven central

ocpi libs: https://central.sonatype.com/search?namespace=com.izivia&q=ocpi

What's Changed

• fix(ocpi-2.2.1): Add Content-Type header on requests (if needed), on all responses & fixed headers case sensitivity by @lilgallon in #14
• fix(ocpi-2.2.1): Fixed usage of tokens & review PlatformRepository by @lilgallon in #16

Full Changelog: R-0.0.13...R-0.0.14

Issues included

• #15 (only ocpi 2.2.1)

Change notes

Only for ocpi 2.2.1

Headers

• Content-Type: application/json header is now added on requests if the body is not null
• Content-Type: application/json header is now added on all responses
• Headers are not case sensitive anymore. It means that X-Request-ID and X-Correlation-ID are properly propagated in responses even if the case does not match. Note: Authorization header was working because it also accepted authorization
• It is now possible to define how X-Request-ID and X-Correlation-ID are generated. You have to override methods in your TransportClient implementation. By default, the behaviour stays the same, it generates a random UUID.

Credentials / tokens modifications

The credentials logic completely changed. Token B and Token C were replaced by Client Token and Server Token. The Token A usage stays the same.

The Credentials Token A is used by the sender to communicate with the receiver (only when initiating registration). After registration, it is invalidated.

Then, there are two tokens, and the token to use is specified by the registration process.

• When you are the receiver during registration:
  • OCPI Token B is the client token, the one you have to use to send requests
  • OCPI Token C is the server token, the one you have to use to check if requests are properly authenticated
• When you are the sender during registration:
  • OCPI Token B is the server token, the one you have to use to check if requests are properly authenticated
  • OCPI Token C is the client token, the one you have to use to send requests

This is why we do not use OCPI's token B and token C naming. According to who you are in the registration process, you have to use a different token. Using "Client Token" and "Server Token" simplifies that process of picking the right token for the right operation.

Before these changes, the library would not work when used while being the receiver of the registration process.

PlatformRepository modifications

Unused methods are removed. Some were renamed and their signature updated to match the new credentials logic. The unregistration is now in one unique method, rather than 5 different methods.

Migration guide

Headers

If you manually added Content-Type header & normalized headers in your Transport implementation, you can remove it.

Otherwise, you do not need to update anything. All the changes are included in the lib.

Credentials / tokens modifications

It's a breaking change, it also breaks your Platform objects.

You will have to update your PlatformRepository implementation to match the new interface. Everything is documented in the file. You have to re-register with your partners. Or you can manually update your Platform object to reflect the changes (clientToken / serverToken instead of tokenB / tokenC).

Notes

Following these developments, a lot of issues were openned to improve the library.

0.0.13 - Better credentials handshake

Available on maven central

ocpi libs: https://central.sonatype.com/search?namespace=com.izivia&q=ocpi

Activity since last version

• fix(ocpi-2.2.1,2.1.1,2.1.1-gireve): receiver should not know sender url before handshake by @lilgallon in #10

Full Changelog: R-0.0.12...R-0.0.13

Change notes

All OCPI versions are impacted. This is a breaking change that increases compatibility with partners as receiver.

Purpose

These changes prevent you, as a receiver, to ask for your partner URL before a handshake. Before these changes, you had to ask for your partner to give you their versions URL so that you can initialize a Platform object with both the url and the tokenA.

Now, as the OCPI protocol states, you just need (as a receiver), to give a tokenA to your partner.

Why these technical changes

It is now possible that a Platform object only contains a token A before handshake. So the code had to be updated accordingly. Before, it was coded following the assumption that a platform must have at least an url. On your side, only the PlatformRepository has been updated to follow these principles.

After registration, you can be sure that a Platform object has at least an url. You can code your PlatformRepository implementation following this principle.

Migration guide

• Implement savePlatformUrlForTokenA in PlatformRepository implementation. It is used at the start of POST /credentials in receiver to store the sender url that is then used to retrieve Platform object.
• Update your implementations of
  • getPlatformByTokenA to platformExistsWithTokenA, and return a Boolean whether the token A exists or not in your system
  • getPlatformByTokenB to platformExistsWithTokenB, and return a Boolean whether the token B exists or not in your system
• Rename getPlatformByTokenC to getPlatformUrlByTokenC. It has been changed for sake of readability

Example for savePlatformUrlForTokenA:

collection
    .findOneAndUpdate(
        Platform::tokenA eq tokenA,
        set(Platform::url setTo platformUrl),
        FindOneAndUpdateOptions().returnDocument(ReturnDocument.AFTER)
    )
    ?.url

Example for platformExistsWithTokenA (almost the same for platformExistsWithTokenB):

override suspend fun platformExistsWithTokenA(token: String): Boolean = collection
        .findOne(Platform::tokenA eq token) != null

0.0.12 - Support for sessions & tokens modules on OCPI 2.2.1 & suspend API

What's Changed

• Feat/add tests to locations by @LBU4SH in #4
• add token module by @LBU4SH in #5
• add session module by @LBU4SH in #6
• (ocpi 2.2.1) Suspendable API by @lilgallon in #7

New Contributors

• @LBU4SH made their first contribution in #4

Full Changelog: R-0.0.11...R-0.0.12

---

2.2.1:

• Improved server registration process
• API based on suspend functions
• Implemented sessions module
• Implemented tokens module
• Improved OCPI support

common:

• Removed baseUrl from TransportClient

For developers:

• Upgrade to gradle 8.2.1
• Upgrade to kotlin 1.8.20

---

Suspend API for 2.2.1

It is useful in different use cases:

• Coroutine contexts can store information. This information can then be used to handle multi tenants for example
• Performance: instead of blocking the current thread when a request or heavy task is done, it suspends the execution of the current code and executes something else

Migration guide:

Instead of:

val versionsServer = VersionsServer(...)
// ...
versionServer.registerOn(server)

Add org.jetbrains.kotlinx:kotlinx-coroutines-core lib, and use:

val versionsServer = VersionsServer(...)
// ...
runBlocking {
	versionServer.registerOn(server)
}

If your code is already suspendable, then, nothing changes for you on registration.

Also the implementation of repositories have to use suspendable functions.

Example:

You can add context to your coroutine by using:

withContext(...) {
	callback(request)
}

In your TransportServer#handle implementation. A useful use case, is to add context according to the HTTP headers of the received request.

R-0.0.11: Deserialization fix

All versions:

• Fixed deserialization generating LinkedHashMap instead of generic objects. The issue was happening for SearchResult deserialization, but it could happened in the future for other operations

R-0.0.10: Tokens module

OCPI 2.1.1:

• Implemented Tokens module

OCPI 2.1.1 Gireve:

• Implemented Tokens module