Hi
A good idea could be too see the unit tests of camel-hl7 which can be
of inspiration.
On Thu, Sep 5, 2013 at 10:00 PM, Dayakar Reddy
reddy.ranabo...@gmail.com wrote:
Hi,
I am new to Camel-HL7 component. It seems like you implemented this
component. can you please share me the sample code
Hi,
I am new to Camel-HL7 component. It seems like you implemented this
component. can you please share me the sample code base/ your project code?
In my case , I need to convert the java object to HL7 format and then send
those messages to an endpoint.
Thanks,,,
Hi Stan,
try this ((I assume that hl7lp, hl7Port and minaLogger are properly
set somewhere):
from(mina:tcp:// + hl7Ip + : + hl7Port +
?sync=truecodec=#hl7codecminaLogger= + minaLogger)
Registering the codec in Camel is not enough; you also need to add it
as parameter to the endpoint URI.
Thanks. I will try this. Would this automatically wrap the HL7 message in the
MLLP starting/ending characters? Or would I have to add these characters to
each message myself for the ACK/NAK response?
--
View this message in context:
I'm getting the exception below when using the HL7 component and codec
with mina to receive streamed HL7 messages. The program works find when
I send it separate messages from a 2nd program using Camel/HL7/Mina and
receives an ACK successfully. But when testing with our client we're seeing
189616968 bytes may be simply too much...
The normal (original) mode of operation in HL7 is to send one
message, receive the response, send the next message, receive the next
response and so on. Much like HTTP, however, instead of defining the
length of a request somewhere, MLLP delimits a
We're working in asynchronous mode where they send all of the messages and I
send the response back as each one is processed using ActveMQ for JMS
queuing. It worked fine in my own testing but is failing here.
What I don't understand is the length of the message: 189616968 bytes
The hex for the
