- This topic has 28 replies, 4 voices, and was last updated 13 years, 5 months ago by
.
-
Topic
-
I would like to pass through an ACK that is coming from the destination going back to the original sender of the message instead of the sender getting an ACK from cloverleaf. Is there a way to do this? The purpose is when the destination system processes the information it may need to share critical information that the original sender needs and we send back via the ACK…
Thank you in advance for your assistance…
-
Replies
-
-
Tom,
If you are on a Cloverleaf release pre 5.8 you will need to deploy some Tcl.
What appears is that you should be able to Route Replies on the outbound thread to any other thread (including the source thread).
However, pre 5.8 that does not work.
This is where the Tcl comes in. I got this to work but I needed to make a copy of the message as data and over it then route messages on the outbound thread (once the copy is OVER’d it become an inbound message on the outbound thread).
If you do not delete the reply coming in (as you would not deltete the reply because you want to route it), under the covers (at least in Cloverleaf 5.6) the message is quietly positioned to route to the orginal source thread BUT does not recognize the TrxID settings for Route Replies nor the routing and the message errors with an invalid trxid without any notification in the log – it just appears in the Error DB.
If you want more details including the proc I wrote as an example email me.
In 5.8, it appears the Route Replies works as one would expect without the need for exceptional Tcl. I have not had a chance to actually test it (do not have 5.8) but I saw some of the configuration at one of the Regional User Conferences and at least the configuration seems to take. Hopefully the message actually gets routed.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Hello Jim,
That would be great if you could send the tcl. Do you need my email address? tgilbert@vmchealth.com.
Thanks,
Tom
Jim Kosloskey wrote:Tom,
If you are on a Cloverleaf release pre 5.8 you will need to deploy some Tcl.
What appears is that you should be able to Route Replies on the outbound thread to any other thread (including the source thread).
However, pre 5.8 that does not work.
This is where the Tcl comes in. I got this to work but I needed to make a copy of the message as data and over it then route messages on the outbound thread (once the copy is OVER’d it become an inbound message on the outbound thread).
If you do not delete the reply coming in (as you would not deltete the reply because you want to route it), under the covers (at least in Cloverleaf 5.6) the message is quietly positioned to route to the orginal source thread BUT does not recognize the TrxID settings for Route Replies nor the routing and the message errors with an invalid trxid without any notification in the log – it just appears in the Error DB.
If you want more details including the proc I wrote as an example email me.
In 5.8, it appears the Route Replies works as one would expect without the need for exceptional Tcl. I have not had a chance to actually test it (do not have 5.8) but I saw some of the configuration at one of the Regional User Conferences and at least the configuration seems to take. Hopefully the message actually gets routed.
-
What you are descibing Jim is interesting.
I had a pass through interface at one time and there was no extra tcl involved.
Just make sure outbound only is not checked, and do not await replies.
Basically Cloverleaf becomes a bridge. You still want to use the send_ok proc but that’s about it if I remember correctly.
-
Michael,
How did you achieve message pacing if you did not wait for a reply before sending the next message?
So I submit if one is going to assure message delivery by pacing ther message exchange dependent on receipt of an acknowledgment the message sent was received, then ‘Wair Replies’ and “Outbound Only” need to be on. ‘Outbound Only’ to assure the engine treats the message received from the receiving system as a Reply, and ‘Wait Replies’ to make sure the next message is not sent until the receiving system is ready.
If you have those set for that guarantee, my experience pre 5.8 is without Tcl it won’t work.
In our case (an X12 exchange) we could receive both a reply the message sent was in error (a 997 transaction Set) or a response to the X12 request (278 Transaction Set), each was treated differently and needed to be routed to different destinations. The use of the ‘Route Replies’ did not function.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
Jim,
The ack gets passed back to the source system and the source controls/ paces the messages. Obviously you lose “store and forward” fuctionality.
The source system will be evaluating the acks/naks, not Cloverleaf.
I should have added that you won’t have a “send_ack” proc in your inbound thread either.
Quote:How did you achieve message pacing if you did not wait for a reply before sending the next message?
Basically there is no “next message” to send as that is up to the source system to send it upon receipt of the target sytem’s ack.
I thought this was what Tom was asking for?
-
Hi Jim
I have run into the same issue as Tom in routing the responses back to the originating system’s inbound thread. I am creating a 270 insurance eligibity interface and the responses are landing in the error db.
I was wondering if I might also get a sample of your tcl proc.
Thanks
Marian Michniak
-
Tom, have you tried setting up your interface using my suggestions?
1) Set up interface as a normal tcpip interface.
2) Remove your send_ack/genHL7reply or what ever proc you have that generates acks in your inbound thread.
3) On the outbound thread, uncheck outbound only and uncheck await replies.
Let me know if that works.
Marion, this should work for you too.
-
Quote:
In our case (an X12 exchange) we could receive both a reply the message sent was in error (a 997 transaction Set) or a response to the X12 request (278 Transaction Set), each was treated differently and needed to be routed to different destinations. The use of the ‘Route Replies’ did not function.
Jim, were you sending back to something other than the source destination? I haven’t done X12 but the basic premise should be the same. Source A sends to Target B. Target B’s ack goes back to Source A. Source A sends next message. And so on.
-
Michael,
OK I see how you were accomplishing pacing (duh!).
Yes the inbound was not X12 so an X12 reply of any kind would not make any sense to the source system. In addition the source system’s messages were routed to multiple destinations (my project being just one) so we needed Cloverleaf to control the pacing.
As I said there were two repsonses possible – one needed to go via ODBC to an error table for auditing and the other (a real reply) needed to go to anothr ODBC Table used by the user to review the response. So neither were intended to go to the originating connection in addition to the issues in the above paragraph.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
Hello Micheal and Jim,
I am running cloverleaf 5.8
Micheal, I tried your three steps and got the following:
I tried to remove the ‘HL7RawAck’ tps that was setup on the inbound.
On the outbound I unchecked awaite replies and outbound only.
The HL7 message reaches it’s destination but the reply is failing on the outbound thread. The error is ‘101’ unsupported trxid. Do you have any thoughts? So there is no reply going back to the source and so no other messages get processed…
-
-
I did not setup a route reply in the outbound thread but I did that.
I check for the ‘Trx id Determination Format’ on the inbound tab on the outbound thread and it is set to ‘HL7’. This is under ‘Inbound Data’ in that tab.
I saved the net config and stopped and started the network monitor and it still gives me the 101 error on the outbound thread.
-
Tom,
By saying you stopped and started the NetMonitor do you mean the process in which the thread exists or just the Monitor?
Unless you stop/start the process in which the thread resides, your changes will not take effect.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Tom,
Do you have outbound only off? If so these may be coming in being treated as data not reply.
I think if you turn up the noise level on the DB Admin for the Error DB you can see the metadata (or turn up the EO noise level and check the log) on the errored message. That should tell you if these messages are being treated as DATA or REPLY. Then make sure you have the appropriate routing (message or reply).
Hopefully this is not the same issue I saw in 5.6 – I had been assured this was working correctly in 5.8.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
Here is an error I am getting in the error log file.
[pdl :PDL :ERR /0: fr_prm_orm:05/03/2011 16:07:54] read returned error 0 (No error)
[pdl :PDL :ERR /0: fr_prm_orm:05/03/2011 16:07:54] PDL signaled exception: code 1, msg device error (remote side probably shut down)
[pdl :PDL :ERR /0: fr_prm_orm:05/03/2011 16:08:19] read returned error 0 (No error)
[pdl :PDL :ERR /0: fr_prm_orm:05/03/2011 16:08:19] PDL signaled exception: code 1, msg device error (remote side probably shut down)
-
-
-
Tom,
Do you have ‘await replies’ set on the outbound thread? If so, the thread may be waiting for the reply you routed.
Do you also have ‘Outbound only’ unchecked?
To look at the pending message you can use the DB Admin tool with the noise level up.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
Tom,
On the Database Administrator tool there is a radio button for ‘Ultra Long’ set that or if you prefer command line then add the -L switch to hcidbdump.
That will turn up how much of a display you get for each message.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
-
-
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
