[CAMEL-8079] Provide possibility to delegate charset evaluation of a HL7 message to HL7DataFormat

• Type: New Feature
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.14.1, 2.15.0
• Component/s: camel-hl7
• Patch Info: Patch Available
• Estimated Complexity: Moderate
• Assignee: Claus Ibsen
• Reporter: Christian Ohr
• Created: 25/Nov/14 16:17
• Updated: 08/Dec/14 09:13
• Resolved: 08/Dec/14 09:13

Description

The HL7Codec directly creates a String from the message, using the charset hardcoded in its HL7MLLPConfig. This is too static.

• The field MSH-18 of the message may contain the charset in which the message is encoded (much like encoding=... in the XML header) and which shall be used for decoding.
• Other information nested the exchange may also be usable to derive the appropriate charset if MSH-18 is empty.

The attached patch improves the behavior in a backwards-compatible way.

• HL7MLLPCodec has a new property named "produceString" (default true). If set to false, the codec sends a byte array into the route instead of a string. In this case, no charset is evaluated yet.
• the HL7DataFormat checks the field MSH-18 for the charset to be used for marshalling and unmarshalling. If MSH-18 is empty, it uses the standard Camel charset properties/headers by default. If MSH-18 was populated, the value is copied to a new message header "CamelHL7Charset"
• the HL7DataFormat also offers an extension point in order to "guess" the charset from the byte array content (e.g. using ICU4J's CharsetDetector).