search

alex-therapeutics / diga-api-client

Production-ready java library for DiGA (Digital Health Application) manufacturers to integrate with DiGA API endpoints for code validation and billing.
https://github.com/alex-therapeutics/diga-api-client
Apache License 2.0
32 stars 13 forks source link

diga-api.tk.de/diga/api/public/rest XMLReaderException #49

Closed gtuk closed 3 years ago

gtuk commented 3 years ago

Problem

When trying to bill the "Techniker Krankenkasse" with a real code you get the following error: DigaApiExceptionError(exception=com.alextherapeutics.diga.DigaXmlReaderException: Exception thrown when trying to read XML request body: ) It's coming from https://github.com/alex-therapeutics/diga-api-client/blob/34d18ee8f6bbacf0e6fa1b78ebaa22d1a15e0cf6/src/main/java/com/alextherapeutics/diga/implementation/DigaXmlJaxbRequestReader.java#L63 and on some further investigation the underlying exception is com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence

The insurance response report seems to have an invalid character somewhere eventhough in the header the encoding is set to utf-8

Solution

A possible temporary hack/workaround for this problem, that seems to work is casting the byte array as an utf-8 encoded string and back to a byte array: Replacing this line https://github.com/alex-therapeutics/diga-api-client/blob/34d18ee8f6bbacf0e6fa1b78ebaa22d1a15e0cf6/src/main/java/com/alextherapeutics/diga/implementation/DigaXmlJaxbRequestReader.java#L62 with var bytes = new String(decryptedReport.readAllBytes(), StandardCharsets.UTF_8).getBytes();

fongie commented 3 years ago

Thanks for the issue! I recall that when I was setting this up I noticed that some APIs specified different xml character encodings (some UTF-8, others some type of ISO standard) in their <?xml version="1.0" encoding="xxx"?> header. Did you get a chance to save the XML that gave this error, so you can tell me what the encoding was?

I like your hack as a short-term solution if it works, but if it is as I suspect then we need to support multiple encodings longterm by inspecting the xml header. You can probably (?) tell JAXB which encoding to use when unmarshalling.

That can be left as an issue for future work though if it seems difficult - I am a little swamped with work right now and cant look at that. I would accept a PR with the short-term hack though :)

gtuk commented 3 years ago

The xml has utf-8 specified as an encoding. Here is a small output of the xml

<?xml version="1.0" encoding="UTF-8"?>
<rep:report xmlns:rep="http://www.xoev.de/de/validator/varl/1"
            xmlns:s="http://www.xoev.de/de/validator/framework/1/scenarios"
            varlVersion="1.0.0" valid="true">

I will prepare a PR (tomorrow morning) as soon as we talked to the technical contact person of the insurance to get more information and some clarification from their end

fongie commented 3 years ago

Okay, thanks for looking this up! It does sound like a possible error on their end, so it would be great if you asked them what's up. Let me know how it goes

gtuk commented 3 years ago

Its also possible to to get the actual encoding specified and set it manually as you said

XMLStreamReader xmlStreamReader = XMLInputFactory.newInstance().createXMLStreamReader(decryptedReport);
xmlStreamReader.getEncoding()
gtuk commented 3 years ago

50