none
Send Port vs. Orchestation Subscription Issue RRS feed

  • Question

  • I have a Biztalk 2010 application that receives 837P files and uses party agreements to generate a 997.  If I drop an instance file into my receive folder that complies with the 837P schema, I get a 997 that shows everything validated.

    If I drop into the folder an instance file with a schema violation (missing DTP element), I get a 997 showing the errors, and I have a send port that subscribes to failed messages based on the following:

     ErrorReport.ReceivePortName == 837receive (my receive folder)
     
     this works fine, and I write out copy of the instance file into a error folder.
     
     I really want to handle the message subscription inside an orchestation, so that I can do some other custom processing.  So I removed the filter shown above from the 'Send Copy of Failed Message' port and created a simple orchestration.  It has a receive shape that has a filter expression just like I used in the send port: 
     
      ErrorReport.ReceivePortName == 837receive
     
      I then have a send shape that is unbound, that in the admin console I have bound to the Send Copy of Failed Message' port.  Message type is xml.  Admin console also shows that the orchestration's logical Inbound port is tied to my 837 receive directory.
     

    I thought this would be a simple change, and that orchestration would grab the new message and send along to the failed copy port.  What happens is as follows:

    File is processed/removed from 837receive directory
    correct 997, showing error, is generated
    Copy of file is not written to failed copy folder

    The message ends up suspended, and in the event log viewer, I get the following:

    A message received by adapter "FILE" on receive location "837receivelocation" with URI "c:\837\*.txt" is suspended.
     Error details: An output message of the component "Unknown " in receive pipeline "Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive, Microsoft.BizTalk.Edi.EdiPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is suspended due to the following error:
         Error encountered during parsing. The X12 transaction set with id '2535' contained in functional group with id '12535', in interchange with id '000012535', with sender id '383323617      ', receiver id '38-6004862     ' is being suspended with following errors:
    Error: 1 (Field level error)
     SegmentID: DTP
     Position in TS: 37
     Data Element ID: DTP02__DateTimePeriodFormatQualifier
     Position in Segment: 2
     Data Value: 20101119
     7: Invalid code value

    Error: 2 (Field level error)
     SegmentID: DTP
     Position in TS: 37
     Data Element ID: DTP03__AdjudicationOrPaymentDate
     Position in Segment: 3
     Data Value:
     1: Mandatory data element missing

    .
     The sequence number of the suspended message is 1. 
     MessageId:  {3CDFC344-AEBE-4A5C-B02D-EE35E0BC01D4}
     InstanceID: {9BF4F454-4291-4FF9-B240-9A778AF57FEE}
     
     
     
     Any thoughts on what is causing this?
     
     

     


    Thanks for any and all help... Mike
    Friday, March 4, 2011 4:28 PM

Answers

  • This ended up being resolved by using a Direct Port in my orchestration instead of Binding Later....

     


    Thanks for any and all help... Mike
    • Marked as answer by Mike J Dugan Tuesday, March 8, 2011 2:46 PM
    Tuesday, March 8, 2011 2:46 PM

All replies

  • Unlike Send Ports, when you use filter expressions inside an orchestration you need quotes "" around the string so the expression should look like this:

    ErrorReport.ReceivePortName == "837receive"

     

    Try that and see if the orchestration is picking up the error messages now

     

    Morten la Cour

    Friday, March 4, 2011 7:06 PM
  • thanks for reply: I do have the double quotes in the orchestration, I just copied line from sendport to paste into this message - any other thoughts?

     


    Thanks for any and all help... Mike
    Friday, March 4, 2011 7:16 PM
  • Maybe you need to use the EDI receive pipeline with validate = false for this "failed" orchestration. It looks like you have a problem with serializing the message.
    Monday, March 7, 2011 2:37 PM
  • thanks for the reply: My Receive Location pipeline has the following settings right now:

    EDIDataValidation = True

    XMLSchemaValidation=False

     

    are these the settings you are referring to?  As I mentioned, when I leave orchestration out of the picture and put a filter on the send port directly, it works fine.  Either way the message is getting into the database with a message_id.  It just seems like the Route failed messages isn't working with the orchestation in the picture.  Here is event viewer log, which shows error description and messageid at bottom:

    A message received by adapter "FILE" on receive location "837_Receive_Location" with URI "c:\837\*.txt" is suspended.

    Error details: An output message of the component "Unknown " in receive pipeline "Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive, Microsoft.BizTalk.Edi.EdiPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is suspended due to the following error:

    Error encountered during parsing. The X12 transaction set with id '2535' contained in functional group with id '12535', in interchange with id '000012535', with sender id '383323617 ', receiver id '38-6004862 ' is being suspended with following errors:

    Error: 1 (Field level error)

    SegmentID: DTP

    Position in TS: 37

    Data Element ID: DTP02__DateTimePeriodFormatQualifier

    Position in Segment: 2

    Data Value: 20101119

    7: Invalid code value

    Error: 2 (Field level error)

    SegmentID: DTP

    Position in TS: 37

    Data Element ID: DTP03__AdjudicationOrPaymentDate

    Position in Segment: 3

    Data Value:

    1: Mandatory data element missing

    .

    The sequence number of the suspended message is 1.

    MessageId: {B1FE0CC5-AA9D-40A9-B5AB-213244FFEC92}

    InstanceID: {276E4678-08D3-49AD-AEFD-64CC564AD4C6}

     

     

     


    Thanks for any and all help... Mike
    Monday, March 7, 2011 4:06 PM
  • This ended up being resolved by using a Direct Port in my orchestration instead of Binding Later....

     


    Thanks for any and all help... Mike
    • Marked as answer by Mike J Dugan Tuesday, March 8, 2011 2:46 PM
    Tuesday, March 8, 2011 2:46 PM