Provide request context to services about ocpi-toolkit HOT 9 CLOSED

We have this issue in our platform, and we will address it in the coming week (or the next one in the worst case). The idea will be to use coroutines' context and put all the information inside. It will be easily extensible and will almost not impact the existing code.

We have some experience in putting information in coroutine contexts. It works well in a production environment

cc @xhanin - just so you have the information - we spoke about it yesterday

from ocpi-toolkit.

Sounds good .. I was hoping there was a more "Kotlin way" to achieve this. This might also be useful for sake of instrumentation and monitoring.

from ocpi-toolkit.

I will start to work on it today

from ocpi-toolkit.

Just to clarify, for this issue, I will implement this part of the OCPI spec: https://github.com/ocpi/ocpi/blob/develop-2.2.1/transport_and_format.asciidoc#message-routing-headers

It requires adding:

• OCPI-to-party-id
• OCPI-to-country-code
• OCPI-from-party-id
• OCPI-from-country-code

from ocpi-toolkit.

that be great ... we currently have some custom logic to extract those headers, but I'd rather see it done in the lib. Here some excerpts, hoping that might help as inspiration ;)

object OcpiRoutingHeader {
    const val FROM_COUNTRY_CODE = "OCPI-from-country-code"
    const val FROM_PARTY_ID = "OCPI-from-party-id"
    const val TO_COUNTRY_CODE = "OCPI-to-country-code"
    const val TO_PARTY_ID = "OCPI-to-party-id"
}

fun HttpRequest.routingHeaders() = RoutingHeaders(
    fromCountryCode = getHeader(OcpiRoutingHeader.FROM_COUNTRY_CODE),
    fromPartyId = getHeader(OcpiRoutingHeader.FROM_PARTY_ID),
    toCountryCode = getHeader(OcpiRoutingHeader.TO_COUNTRY_CODE),
    toPartyId = getHeader(OcpiRoutingHeader.TO_PARTY_ID),
)

data class RoutingHeaders(
    val toCountryCode: String?,
    val toPartyId: String?,
    val fromCountryCode: String?,
    val fromPartyId: String?,
) {
    fun validate() {
        validate { validateLength(OcpiRoutingHeader.TO_COUNTRY_CODE, toCountryCode ?: "", 2) }
        validate { validateLength(OcpiRoutingHeader.TO_PARTY_ID, toPartyId ?: "", 3) }
        validate { validateLength(OcpiRoutingHeader.FROM_COUNTRY_CODE, fromCountryCode ?: "", 2) }
        validate { validateLength(OcpiRoutingHeader.FROM_PARTY_ID, fromPartyId ?: "", 3) }
    }

    val from
        get() = PartnerId(
            countryCode = fromCountryCode ?: "",
            partyId = fromPartyId ?: "",
        )

    val to
        get() = PartnerId(
            countryCode = toCountryCode ?: "",
            partyId = toPartyId ?: "",
        )
}

data class PartnerId(
    val countryCode: String,
    val partyId: String,
)

from ocpi-toolkit.

beside those routing headers, will you also add the partnerUrl to the context? For several use cases (especially command response) we need to know the partner that called, so we can create a proper authenicated client for the response

from ocpi-toolkit.

I am almost done, it looks like I did the right thing because my code looks a lot like yours :)

Concerning partnerUrl, how should we retrieve it from the HttpRequest? What is your idea for that?

Anyway, even if not done in this PR, you will be able to use a custom coroutine context to include the information you need.

from ocpi-toolkit.

it looks like all I need to do is adjust my implementation of TransportServer. I'll just have secureFilter return the partnerUrl instead of Unit, and throw that in the context. (now that I know how that works ;) ). So most of the logic would be in the sample code + another context object

Because currently I need a custom implementation of the server, and have to read the authorization header a second time (which is one of the reasons the #26 is coming along so slowly, as it still seemed to hacky ... using the context could solve this issue)

from ocpi-toolkit.

Oh okay I understand, I was confused on how to retrieve the partnerUrl as it requires using partnerRepository. It makes sense now

from ocpi-toolkit.