Hi Quinn,
Thanks for helping me with the blueprint. Here is my java. My intent is to use
addforcedencode, as I want empty HL7 fields produced.
package net.integratix.demo;
import org.apache.camel.ExchangePattern;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.hl7.HL7DataFormat;
import ca.uhn.hl7v2.DefaultHapiContext;
import ca.uhn.hl7v2.HapiContext;
import ca.uhn.hl7v2.parser.GenericParser;
import ca.uhn.hl7v2.parser.Parser;
import ca.uhn.hl7v2.parser.ParserConfiguration;
public class OutRouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
HapiContext hapiContext = new DefaultHapiContext();
ParserConfiguration pc = hapiContext.getParserConfiguration();
pc.addForcedEncode("NK1-2-1");
pc.addForcedEncode("NK1-2-2");
pc.addForcedEncode("NK1-3-1");
pc.addForcedEncode("NK1-4-1");
pc.addForcedEncode("NK1-4-3");
pc.addForcedEncode("NK1-4-5");
pc.addForcedEncode("NK1-4-6");
pc.addForcedEncode("PID-21-1");
pc.addForcedEncode("PID-22-1");
pc.addForcedEncode("PID-23-1");
pc.addForcedEncode("PID-24-1");
pc.addForcedEncode("PID-25-1");
pc.addForcedEncode("PID-26-1");
Parser p = new GenericParser(hapiContext);
HL7DataFormat hl7 = new HL7DataFormat();
hl7.setParser(p);
from("jms:queue:in").routeId("rtOut")
.log("read ${header.CamelHL7MessageControl}")
.beanRef("CanonicalBean", "canonical2HL7")
.marshal(hl7)
.to("file:out/converted")
.end();
}
}
> Am 07.04.2016 um 17:30 schrieb Quinn Stevenson <qu...@pronoia-solutions.com>:
>
> If you can share your Java configuration, I’ll see if I can convert it to
> Blueprint.
>
> As far as the XSD change - I can’t answer that one for certain, but I’d guess
> the answer is no. Looking at the other definitions in the XSD, the
> attributes appear to be primitive types (String, boolean, etc). I didn’t
> check all of them - just gave the XSD a quick look. Since the parser and
> context on the HL7 DataFormat are not primitive types, I’d guess the XSD
> won’t change and you’d need to revert to configuring the bean - but that’s
> just my guess.
>
>
>> On Apr 7, 2016, at 8:23 AM, Walzer, Thomas <thomas.wal...@integratix.net>
>> wrote:
>>
>> I got it to work without blueprint (in java). Blueprint wiring was a bit too
>> complex for me. If anyone has a working example I will gladly add it to the
>> docs.
>>
>> Should we add those elements to the xsd?
>>
>> Cheers, Thomas.
>>
>>> Am 05.04.2016 um 16:36 schrieb Quinn Stevenson
>>> <qu...@pronoia-solutions.com>:
>>>
>>> I learned something new - I’ve never used the camel:dataFormats element
>>> before.
>>>
>>> I normally do something like this
>>> <bean id="my-data-format"
>>> class="org.apache.camel.component.hl7.HL7DataFormat" >
>>> <property name="validate" value="true" />
>>> <property name="parser" ref="my-parser" />
>>> </bean>
>>>
>>> You’d have to define “my-parser” as well, but I think this will work.
>>>
>>>
>>>
>>>> On Apr 5, 2016, at 12:03 AM, Walzer, Thomas <thomas.wal...@integratix.net>
>>>> wrote:
>>>>
>>>> When I write the blueprint xml I have a reference to camel-blueprint.xsd
>>>> in it. So that the tooling can check my xml against the xsd.
>>>>
>>>> --snip from camel-blueprint.xsd ---
>>>>
>>>> <xs:complexType name="hl7DataFormat">
>>>> <xs:complexContent>
>>>> <xs:extension base="tns:dataFormat">
>>>> <xs:sequence/>
>>>> <xs:attribute name="validate" type="xs:boolean">
>>>> <xs:annotation>
>>>> <xs:documentation xml:lang="en">Whether to validate the HL7
>>>> message Is by default true.</xs:documentation>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> </xs:extension>
>>>> </xs:complexContent>
>>>> </xs:complexType>
>>>>
>>>> --end snip ----
>>>>
>>>> From the docs it should be more like
>>>>
>>>> <xs:complexType name="hl7DataFormat">
>>>> <xs:complexContent>
>>>> <xs:extension base="tns:dataFormat">
>>>> <xs:sequence/>
>>>> <xs:attribute name="validate" type="xs:boolean">
>>>> <xs:annotation>
>>>> <xs:documentation xml:lang="en">Whether to validate the HL7
>>>> message Is by default true.</xs:documentation>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> <xs:attribute name="hapiContext" type="xs:string">
>>>> <xs:annotation>
>>>> <xs:documentation xml:lang="en">The hapiContext to
>>>> use</xs:documentation>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> <xs:attribute name="parser" type="xs:string">
>>>> <xs:annotation>
>>>> <xs:documentation xml:lang="en">The parser to
>>>> use</xs:documentation>
>>>> </xs:annotation>
>>>> </xs:attribute>
>>>> </xs:extension>
>>>> </xs:complexContent>
>>>>
>>>>
>>>> So for instance the following snippet in my blueprint
>>>> <camel:dataFormats>
>>>> <camel:hl7 validate="true" parser="hl7Parser"/>
>>>> </camel:dataFormats>
>>>>
>>>> yields:
>>>>
>>>> cvc-complex-type.3.2.2: Attribute 'parser' is not allowed to appear in
>>>> element 'camel:hl7'.
>>>>
>>>> This happens not only when validating the source but also when starting
>>>> up, as the blueprint gets validated again.
>>>>
>>>> Cheers, Thomas.
>>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Quinn Stevenson [mailto:qu...@pronoia-solutions.com]
>>>> Gesendet: Montag, 04. April 2016 17:17
>>>> An: users@camel.apache.org
>>>> Betreff: Re: [Bug?] hl7dataformat hapicontext&parser not in
>>>> camel-blueprint.xsd
>>>>
>>>> As far as I know, Blueprint uses reflection to set properties so there
>>>> wouldn’t be any need for any changes in camel-blueprint when a
>>>> component/dataformat gets new properties.
>>>>
>>>> What exactly is your issue?
>>>>
>>>>> On Apr 4, 2016, at 2:19 AM, Walzer, Thomas <thomas.wal...@integratix.net>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> is it possible that
>>>>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd does not
>>>>> contain the new properties hapiContext & parser?
>>>>> Makes it hard to use the features from 2.14.1 in blueprint ;-)
>>>>>
>>>>> Jira?
>>>>>
>>>>> Cheers, Thomas.
>>>>
>>>
>>
>
