none
HL7 Solicit Response ACK back into my orchestration RRS feed

  • Question

  • Hi,

    I'm implementing a HL7-HL7 orchestration that receives a HL7 2.31 message on a two-way receive port and then sends it to a one-way send port which send location has been configured as solicit response ACK that sends the ACK to a one way receive port. In my orchestrationI then have a one-way receive port that is directly bound to my reveice shape.

    I want to be able to generate a ORM message back to the original sender with different status codes depending on the MSA.2 field in the ACK received from the receiving application. I got a good result with a two-way send port that sent the ACK back as the response into my orchestration. I can then convert it to an ORM using the original request message and the ACK in a map.

    The problem is that with a two-way send port, only a positive ACK is returned as a response. AE and other negative ACKs are not returned as a response. This I'm guessing from the congifuration of the MLLP configuration in the send port where you can only choose AA and CA as acceptable ACK codes for connections that doesn't implement solicit response. With a solicit response configuration you can receive any types of ACK codes.

    Therefore I tried the setup described above. The problem I'm having now is that the ACK recevied cannot be correlated with the ORM sent. Therefore it is being suspended. 

    Am I thinking wrong? How can I correlate a ORM sent with and ACK received when using a one way send port with a solicit response to a receive port? Neither MSH.10 nor MSA.2 (Message Control ID) is available as correlation properties.

    Regards

    Arvid

    Friday, March 7, 2014 3:12 PM

All replies

  • Its wrong to say that with two-way send port, only a positive ACK is returned as response. If you select in the
    "Acceptable ACK codes" drop down "All Ack Codes" or Ack Code you want to accept, you will get the acknowledgment accordingly. You should not need to change it to one way port for that.

    With one way send port, you may want to use a correlation on a unique id such as message control id. In acknowledgment message, send message's message control id is returned in MSA2, you can promote this in your solicit response receive location (via a custom pipeline) to route this message back to orchestration.

    Monday, March 10, 2014 3:14 PM
  • Hi,

    like I wrote: the possiblitiy to select "All Ack codes" in the MLLP adapter is only there if you choose the "Solicit response enabled" option.

    What will besent as the response message on a two-way send port with solicit response enabled? Will the ACK be routed both to the solicit response location and into my orchestration through the send port response?

    The problem with correlation on MSH.10/MSA.2 is that none on those are available as correlation types. I cannot promote them as those schemas (MSH and ACK) aren't available in my solution, but referenced from a common project.

    I haven't investigated the option of customizing the send or receive port as you suggested. how would that work? would I have to extract the Message control ID from the XML representation of the outgoing and ingoing messages in order to promote them?

    Regards

    Arvid

    Tuesday, March 11, 2014 7:59 AM
  • Which version of BizTalk Server you are using? In BizTalk 2010, I have option to select All Ack Codes. presumably you are using 2009 or earlier that's why probably you are not seeing the option.

    For two way send port, solicit response enable will be ignored.

    You can create a property schema with one property, name it as messagecontrolid. Change its property type to MessageContextPropertyBase, deploy the schema.

    In your orchestration on outgoing message initialize a correlation using the context property you created. Make sure you set the value of context property. Message(PropertyNamespace.Propertname) = MSH10 value

    In your orchestration wait for Receive with follow correlation on the same property

    create a custom pipeline component (IComponent interface) and promote the property (messagecontrolid) with message control id value.

    Use this pipeline component in a receive pipeline and use this on your ACK receive location.

    ACK Receive location will publish the ack with messagecontrolid propertied and orchestration will subscribe to it.


    Tuesday, March 11, 2014 2:15 PM
  • The All Ack Codes option should also be available in BizTalk 2009 after installing all MLLP hotfixes (quite a few). See below (that's a solicit/response in our BTS 2009 Test environment). 

    We also use an orchestration on outbound ports on some systems to be able to inspect an acknowledgement more thouroughly and do something with it if it's a NAck, works a charm. If All Ack Codes is selected all acks should be available in your orchestration and there's really no need of promoting any property.

    Thursday, March 13, 2014 9:30 AM
  • I'm actually using BizTalk 2010. This is the message I get when trying to click "OK" after choosing the "All ACK Codes" option: "For solicit response value 'No', the only possible value of "Acceptable ACK Codes is AA and CA""

    When I tested again however, the AE ACK seems to be returned into my orchestration. So the main workflow works fine now. The problem I'm now experiencing is when I try to implement a timeout logic. If I don't receive an ACK at all I want to create an ACK message in the orchestration, setting the code to AE. I use a long running scope and set the send port property "Delivery Notification" to "Transmitted" and add an exception handler to create the fake ACK.


    I didn't get the TimeOutException to fire and neither the DelivertFailed exception, so I caught a general exception.

    Now my main flow has stopped working. An ORM message gets suspended, which seems strange since it gets sent to the reciver OK and the receiver ACKs it ok. This in the application log:

    A response message sent to adapter "MLLP" on Receive Location: "RS.BizTalk.RISOrder.SendPort_RISOrder_GERoskilde" with URI:"172.16.1.70:19257" is suspended. 
     Error details: The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.  
     MessageId:  {B53FA566-A48D-439B-A54A-9B7DE03038D1}
     InstanceID: {CDF14DFC-A34C-4513-BFAE-BC2B6361BCF1}

    Not sure what to do next...

    Thursday, March 13, 2014 1:39 PM
  • So the acknowledgement you receive from the system you sent your ORM to can't be routed right?

    Are you sure the acknowlegde is parsed to a correct format? Could you check that on the context of the suspended instance? 

    Thursday, March 13, 2014 1:58 PM
  • I have two suspended instances. The ORM (resumable) and the ACK (not resumable). I'm guessing the ORM is suspended if the ACK isn't processed ok?

    The message detailes of the suspended ACK seems to have ok context properties. The MSA.1 = AA.

    The message parts of the suspended ACK seems to be empty though.

    Thursday, March 13, 2014 2:48 PM
  • Message parts are indeed empty on a failed routing report. But does the failed routing report have a messagetype defined? That's the most important thing to know. If this messagetype doesn't match the type the orchestration expects, than the message will get suspended.

    Thursday, March 13, 2014 2:53 PM
  • In the tracked message events log, I get a "Transmission failed" on the ORM going to the send port and two seconds later I receive the ACK on the same port. 

    In the context view, the ACK is of messagetype http://microsoft.com/HealthCare/HL7/2X#ACK_24_GLO_DEF.

    The response on my send port is expecting a multipart message where the body part of the message is an ACK. Is that wrong? That is how I receive the ORM into my orchestration and how I send the ORM out of my orchestration. I thought that was what the pipelines were delivering.

    Thursday, March 13, 2014 3:02 PM
  • Multipart should be ok. I will check that tomorrow, when I am at the hospital and can look into our code with regards to receiving an ACK in an orchestration.
    Sunday, March 16, 2014 4:05 PM
  • Ok, I've looked it up. We are actually using an XmlDocument to receive the Ack in the orchestration. Below is a generic orchestration (used for sending all messages out), so we don't know which Ack will be received exactly, hence we use a generic type like XmlDocument.

    We then check the return code by using a regular expression (Acks are always short messages, so performance is good) and act accordingly:

    string rgxStr = @"^MSH.*\rMSA\|(?<value>.*?)($|[\r|\|])";

    I know this probably isn't the best way to solve your problem, but being stuck without a solution isn't so good either :)

    Hope this helps.


    • Edited by Roborop Monday, March 17, 2014 8:17 AM
    Monday, March 17, 2014 8:17 AM
  • Hm, my orchestration is behaving quite strangely. 

    I changed the response type to a BTAHL7Schemas.ACK_24_GLO_DEF, which should be the same as you generic XML response if the pipline is working correctly.

    In the message tracker I can see the original ORM message going into my orchestration correctly and it gets routed to the send port. I never see the send port actually sending the message though. Instead the ACK is received and shortly after that I get a transmission failed on the send port for the ORM message. Then both the ACK and the ORM gets suspended. The ACK is never recived by my logical send port in the orchestration.

    It seems as if the send and receive pipeline has decided that the sending of the ORM has failed and therefore reports a failure back to the send port. My HL7 receiver has received the message though and ACKed it accordingly.

    Regards

    Arvid


    Monday, March 17, 2014 9:12 AM
  • If your HL7 receiver has received the ORM, then the send port must have sent it :)

    You send port fails with a routing failure right? To me it seems that your send port sends the ORM, then receives the ACK, but can't route the ACK further into BizTalk, i.e. no subscribing orchestration or other artifact. 

    Have you considered making a temporary (file) send port to route your ACK out of the system? Just to make sure the HL7 send port works correctly. I mean making another Send Port that subscribes to the SPName or ReceivePort property of the HL7 send port, to make sure the ACK gets routed away from the HL7 send port and it won't suspend anymore. Just for testing/debugging purpose :)


    • Edited by Roborop Monday, March 17, 2014 9:27 AM
    Monday, March 17, 2014 9:26 AM
  • So did you get it to work?

    www.robfox.nl If this answers your question please mark it accordingly

    Wednesday, March 19, 2014 12:37 PM
  • Thanks for your reply. I haven't had time to try it yet though. The strange thing is that the two-way send port worked ok until I started to use a scope to handle timeout. Nothing got suspended and the flows worked fine.

    Therefore I'm not sure the fault is within the send port.

    Wednesday, March 19, 2014 2:39 PM