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. >>>> >>> >> >