What is the option/approach provided by the library to send the CALLERROR message from server to client with custom error information and correct messageId

[rayan99]

I have implemented a server based on the example given in ocpp-v1_6-example/json_server_example/src/main/java/eu/chargetime/ocpp/jsonserverimplementation/config/ServerCoreProfileConfig.java

I have a question regarding the following implementation as an example:

@Override public StartTransactionConfirmation handleStartTransactionRequest(UUID sessionIndex, StartTransactionRequest request) {

}

In this function, if I provide the StartTransactionConfirmation correctly everything works fine.

For negative cases where I have to provide CALLERROR as per the following OCPP format: MessageTypeId, MessageId, errorCode errorDescription, {}]

What is the option/approach provided by the library to send the error message to client with: a) Proper error code b) My own values for error description and details c) Message Id. (Currently message id is not received in handler)..

Pls Note: I explored the option of throwing runtime exception, but it has three shortcomings: 1) I am not able to send proper error code, description and details 2) I do not know the message Id which I have to send back since the function does not get it as parameter/any other way 3) The error message is printed in the server but it does not reach the client

I am using following build:

    <dependency>
            <groupId>eu.chargetime.ocpp</groupId>
            <artifactId>v1_6</artifactId>
            <version>1.1.0</version>
    </dependency>

[robert-s-ubi]

What do you consider a "negative case"? The only "negative case" in which you are allowed to reply with a CALLERROR is a malformed request, i.e. if you cannot parse the StartTransactionRequest. In that case, consider that the charge point cannot really make much of the CALLERROR. It would only help if you had a charge point developer debugging on their side, but if you're in that position, you might as well tell them directly what's wrong with their requests.

For all properly formed StartTransactionRequests, you're required to reply with a StartTransactionConfirmation.