none
BT2010 HL7 Ack generation RRS feed

  • Question

  • I'm executing the DASM receive pipeline successfully from inside my orchestration, and I have the party configured for automatic Ack/Nack generation, however I'm having difficulty determining exactly where the Ack/Nack is going if it is even being created.

     

    Does the DASM output the Ack/Nack for a validly configured party as a message out of the pipeline just like the desired payload? Or does it somehow circumvent this and directly place the Ack/Nack into the Messagebox database? This doesn't seem to be clear from reading the documentation. 

     

    When testing I checked the ReceivePipelineOutputMessages object (the return type of a receive pipeline call) and it only has in it a single message. This is only the multipart message containing the MSH, Body, and ZSegment. But, the thing is, I had a couple send ports set up with filters for Acks to output them in case the messages were getting placed directly in the Messagebox database. Nothing comes out of them. No errors about no subscribers being found. Nada.

     

    I am without doubt that I have the party resolution properly set since for the same file when I pass it through a file receive it generates the Acks properly.

     

    So, since my send ports aren't picking them up it seems I could rule out them being placed into the Messagebox database directly, but I'm also not finding them in the return value from the pipeline call. Anyone have any insight? This isn't a killer thing since I can just manually generate the Acks I suppose, but it would be nice to be able to get at least the Level 1 ack automatically since it has no real need for custom content in my situation.

    Monday, April 18, 2011 4:40 PM

Answers

  • Hi,

    Yes the DASM outputs the Ack/Nack out of the pipeline.  You can prove this by creating a custom pipeline with the DASM (Disassemble) and a custom pipeline component in a stage after it.  Debugging the custom pipeline component would allow you to see the disassemble message stream and the Ack/Nack message stream.

    Thanks,

    William

    Monday, April 18, 2011 5:36 PM
  • Microsoft has confirmed through a support ticket that it is not possible to generate acknowledgements anywhere but from a pipeline.
    • Marked as answer by Bon Franklin Monday, April 21, 2014 9:39 PM
    Monday, April 21, 2014 9:39 PM

All replies

  • Hi,

    Yes the DASM outputs the Ack/Nack out of the pipeline.  You can prove this by creating a custom pipeline with the DASM (Disassemble) and a custom pipeline component in a stage after it.  Debugging the custom pipeline component would allow you to see the disassemble message stream and the Ack/Nack message stream.

    Thanks,

    William

    Monday, April 18, 2011 5:36 PM
  • I'll double check but it said the enumeration was complete after pushing out the first message which contained the disassembled HL7 Xml. Thank you very much for your input, I'm confident you're right and I didn't investigate thoroughly enough so I'll check again as you suggest.

     

    Monday, April 18, 2011 5:38 PM
  • This appears to be true for only executing the pipeline from a receive location. 

     

    http://msdn.microsoft.com/en-us/library/microsoft.xlangs.pipeline.receivepipelineoutputmessages_members(v=bts.70).aspx

     

    If you have Acknowledgements for a party configured in pretty much any manner I can test (MSH15 and MSH16 AL, SU, or ER) OTHER than NE, NE you get this exception:

     

     

    General Exception in GenRegSingPart

    0 : Object reference not set to an instance of an object.

    0 :  at Microsoft.XLANGs.Pipeline.PipelineBMessage.GetPartDataStream(IBaseMessagePart bpart)
      at Microsoft.XLANGs.Pipeline.PipelineBMessage.AddBaseMessagePart(XLANGMessage xmsg, IBaseMessagePart bpart, String partName, Int32 partIndex, Boolean addNewPart)
      at Microsoft.XLANGs.Pipeline.PipelineBMessage.ToXLANGMessage(XLANGMessage inxmsg)
      at Microsoft.XLANGs.Pipeline.ReceivePipelineXMessages.GetCurrent(XLANGMessage xmsg)
      at AZDHS.ASIIS.Orchs.Generic_RegistryInterface_Single_Part.segment3(StopConditions stopOn)
      at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
    
    Even if one gets just the FIRST message from the ReceivePipelineOutputMessages enumeration. 
    But if I have it set as NE/NE I can get the first message from the enumeration as expected. Any idea why you can't also get the ACKs? It is recognizing the party since it is performing Validation as I have it set to use.
    It isn't killer for me since I can easily generate the ACK/Nack from scratch, but the auto generated one would be pretty awesome to get from the orchestration.

     

    Thursday, April 28, 2011 7:08 PM
  • Can anyone follow up on this perhaps?

    The Ack message output from the pipeline is absolutely correct (context, part names) EXCEPT the message stream containing the Ack XML is null for all 3 parts.

    It being null is what causing the error in my last post. Is it depending on something that is only present when executing in the context of a receive location that isn't available in an orchestration? 

    Sunday, June 16, 2013 6:00 PM
  • Microsoft has confirmed through a support ticket that it is not possible to generate acknowledgements anywhere but from a pipeline.
    • Marked as answer by Bon Franklin Monday, April 21, 2014 9:39 PM
    Monday, April 21, 2014 9:39 PM
  • Monday, April 21, 2014 10:35 PM
    Moderator