fix FormationViolation to FormatViolation on CallError (OCPP 2.0.1 Specification, Table B06.FR.17)

[dwibudut]

FormationViolation to FormatViolation base on OCPP 2.0.1 Specification Table B06.FR.17

[dwibudut]

Hello,

I just fix the GetInstalledCertificateIdsRequest and GetInstalledCertificateIdsResponse features based on json schema, I've also modified the test function.

Changes:

• Modify field certificateType on GetInstalledCertificateIdsRequest to array type not string (base on json schema)
• Add field certificateHashDataChain that contain array of certificateHashData on GetInstalledCertificateIdsResponse (base on json schema)

Thx

[dwibudut]

I added another fix on typeOfCertificate to certificateType according to json schema in CertificateSignedRequest feature

Thx

[lorenzodonini]

First of all thanks a lot for finding and fixing these implementation errors.

All commits except the first one LG2M (I left one minor comment).

Regarding the FormatViolation I cannot accept the change the way it is, because in v1.6 the error code is indeed called FormationViolation (for whatever reason this was changed in v2). I believe this might just be the only change between the two ocppj versions. Fixing one version would break the other. To not break anything we probably need to inject error codes from the top layer. I would suggest splitting this into 2 separate PRs.

[lorenzodonini]

In theory the certificateTypes are optional so they could be omitted from this signature (all optional values are ommitted throughout the lib as they can be added via the props variadic function). That being sad, if this leads to too many changes, we could also leave it as it is.

[dwibudut]

Hello, I've modified these changes based on your review and created a new PR on #207

[dwibudut]

First of all thanks a lot for finding and fixing these implementation errors.

All commits except the first one LG2M (I left one minor comment).

Regarding the FormatViolation I cannot accept the change the way it is, because in v1.6 the error code is indeed called FormationViolation (for whatever reason this was changed in v2). I believe this might just be the only change between the two ocppj versions. Fixing one version would break the other. To not break anything we probably need to inject error codes from the top layer. I would suggest splitting this into 2 separate PRs.

For FormatViolation, currently I have no idea, whether to just add FormatViolation type and keep both (FormationViolation and FormatViolation) maybe, but the response CallError to client will still and always use FormationViolation on your top layer ParseMessage method

ocpp-go/ocppj/ocppj.go

Lines 373 to 390 in c34f6ad

	func (endpoint *Endpoint) ParseMessage(arr []interface{}, pendingRequestState ClientState) (Message, error) {
	// Checking message fields
	if len(arr) < 3 {
	return nil, ocpp.NewError(FormationViolation, "Invalid message. Expected array length >= 3", "")
	}
	rawTypeId, ok := arr[0].(float64)
	if !ok {
	return nil, ocpp.NewError(FormationViolation, fmt.Sprintf("Invalid element %v at 0, expected message type (int)", arr[0]), "")
	}
	typeId := MessageType(rawTypeId)
	uniqueId, ok := arr[1].(string)
	if !ok {
	return nil, ocpp.NewError(FormationViolation, fmt.Sprintf("Invalid element %v at 1, expected unique ID (string)", arr[1]), uniqueId)
	}
	// Parse message
	if typeId == CALL {
	if len(arr) != 4 {
	return nil, ocpp.NewError(FormationViolation, "Invalid Call message. Expected array length 4", uniqueId)

[dwibudut]

New issue #210