Trait ChargingProfilesSender 

pub trait ChargingProfilesSender:
    Send
    + Sync
    + 'static {
    // Required methods
    fn active_charging_profile_result(
        &self,
        unique_id: String,
        result: ActiveChargingProfileResult,
        context: RequestContext,
    ) -> impl Future<Output = Handled<()>> + Send;
    fn charging_profile_result(
        &self,
        unique_id: String,
        result: ChargingProfileResult,
        context: RequestContext,
    ) -> impl Future<Output = Handled<()>> + Send;
    fn clear_profile_result(
        &self,
        unique_id: String,
        result: ClearProfileResult,
        context: RequestContext,
    ) -> impl Future<Output = Handled<()>> + Send;
    fn put_active_charging_profile(
        &self,
        session_id: String,
        profile: ActiveChargingProfile,
        context: RequestContext,
    ) -> impl Future<Output = Handled<()>> + Send;
}

Available on crate feature server only.

The eMSP/SCSP side of the Charging Profiles module: receiving what the Charge Point decided.

Why the callback paths are three, not one

The specification leaves the response_url entirely to the Sender —

No structure defined. This is open to the eMSP to define, the URL is provided to the Receiver by the Sender.

— and that freedom is load-bearing here, because the three result bodies are not distinguishable from one another: ChargingProfileResult and ClearProfileResult have identical shapes, one result field each. A single endpoint that sniffed the body could not tell a rejected PUT from a rejected DELETE.

So OcpiRouter::charging_profiles_sender mounts one path per result kind, each ending in the Sender’s own unique id, and CallbackUrls builds the matching response_urls. The kind is then carried by the URL, exactly as the specification intends.

Spec: 2.3.0 §mod_charging_profiles_emsp_interface

Required Methods

fn active_charging_profile_result( &self, unique_id: String, result: ActiveChargingProfileResult, context: RequestContext, ) -> impl Future<Output = Handled<()>> + Send

The Charge Point’s answer to a GET of the active profile.

fn charging_profile_result( &self, unique_id: String, result: ChargingProfileResult, context: RequestContext, ) -> impl Future<Output = Handled<()>> + Send

The Charge Point’s answer to a PUT of a charging profile.

fn clear_profile_result( &self, unique_id: String, result: ClearProfileResult, context: RequestContext, ) -> impl Future<Output = Handled<()>> + Send

The Charge Point’s answer to a DELETE of a charging profile.

fn put_active_charging_profile( &self, session_id: String, profile: ActiveChargingProfile, context: RequestContext, ) -> impl Future<Output = Handled<()>> + Send

PUT {chargingprofiles}/{session_id} — the CPO volunteering a changed active profile.

The Receiver SHALL call this interface every time it knows changes have been made that influence the ActiveChargingProfile for an ongoing session AND the Sender has at least once successfully called the charging profile Receiver PUT interface for this session.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors