none
The client connection might have been disconnected while receiving AS2 transmission in BizTalk 2010 RRS feed

  • Question

  • Hello guys,

    We currently have a BizTalk application, which will receive EDI transactions via AS2 from partners, The HTTP receive location was configured to pass the received EDI payload to an AS2X12Receive pipeline. The message disassembled by the pipeline was subscribed by a send port directly, these is no orchestration, while testing it, we have found that sometimes the message got suspended with this error: Error Code 0xc0c16b7, Error Description: The BizTalk HTTP receive location "%1" could not send the HTTP headers to the client. The client connection might have been disconnected.  I have googled this around, seems no luck.

    The context fragment of the suspended message was listed at below:

    IsRequestResponse:    True
    RouteDirectToTP:    True
    SuspendAsNonResumable:    True
    TreatEPMSuspendAsSuccess:    True
    AuthenticationRequiredOnReceivePort:    False
    InboundTransportType:    HTTP
    IsAS2AsynchronousMdn:    False
    IsAS2Http200OKResponse:    False
    IsAS2MdnResponseMessage:    False
    IsAS2MessageEncrypted:    True
    IsAS2MessageSigned:    True
    IsAS2PayloadMessage:    False
    SendMDN:    True
    DispositionMode:    automatic-action/MDN-sent-automatically
    DispositionType:    processed
    IsAS2FailedMessage:    False
    IsAS2MessageCompressed:    False

    I have looked into the related IIS logs, which contains a "POST" log entry with status code "500", there wasn't any event log (Application, System) relevant to this, except the BizTalk Suspended error.  When we look at the app log, the BizTalk actually received the EDI transaction even this error occur.

    One thing that I want to mention here is, after we run the application about 20 hours, the related IIS worker process (w3wp.exe) was consuming more than 1.5GB memory, we think it should be caused by the application loaded dozens of EDI schema into memory. Is this normal? or we doing the wrong thing?  is this related to the error?

    Is there anyone hit the same problem? or any hint might helpful.

    Thanks in advance,

    Mark



    Saturday, April 21, 2012 3:41 AM

Answers

  • After we separated the AS2 receive process and EDIX12 disassemble process, the 500 error disappeared, because we have a customized EDI X12 disassembler component which may throw exception for some validation failure. It seems that if we customizing pipeline used for AS2 receive, we should not throw any exception inside the pipeline, which will case the MDN failed to send back, we can just send the message to the SuspendedMessageQueue, and also avoid to touch the data stream which produced by the AS2Disassembler component.

    Thanks Atin again for your kindly help.

    Best regards,

    Mark

    • Marked as answer by MarkXMou Saturday, April 28, 2012 6:30 AM
    Saturday, April 28, 2012 6:30 AM

All replies

  • This seems to be a Request Response HTTP Receive port. What are we trying to send back as response on this port? Basically I would like to know how we are sending MDN and 997 back to partner.



    Atin Agarwal

    Tuesday, April 24, 2012 6:54 AM
  • Hi Atin,

    Thanks for the reply, it is a Request Response HTTP Receive port, it should be sending back the MDN as response, since its sync AS2 transportation.

    Yesterday, after I looked at the captured  network traffics via MS Network Monitor during the BizTalk error occurs, no error was found in the related HTTP conversation, even the IIS log is showing 500 http status code. Currently, we are trying to separate the HTTP receive adapter and AS2X12Receive pipeline, which has EDI disassembler pipeline component with multiple X12 schema loaded at the run time, to pin point the root of issue cause. To achieve this, we are trying to route the received AS2 message to file system, and read it back to msgbox via a file receive port with EDI X12 pipeline.

    I'll update this post if we found anything.

    Best regards,

    Mark

    Wednesday, April 25, 2012 1:17 AM
  • Also, make sure that we are not sending 997 back on the same Request Response HTTP Receive port by un-checking the options of Generating TA1 and 997 on the EDI party settings. This would make sure we are not trying to send back both MDN and 997 on the same two way receive port.

    Atin Agarwal

    Wednesday, April 25, 2012 6:30 AM
  • Hi Atin,

    Are you saying that if we check the 997 Expected in the receive tab of X12 agreement, the BizTalk will trying to send back generated 997 as the response through the same HTTP connection of the inbound AS2 message?

    TA1 is unchecked as we don't need it.

    On the receive location (the Request Response receive location), we are using AS2EdiReceive as the receive pipeline, which will disassemble the inbound X12 file and generate 997(we have the 997 Expected checked in the agreement settings because we need it to be sent to the partner), and AS2Send as the send pipeline of this receive location.

    In our application, we have a Static Solicit-Response send port to subscribe the generated 997 and assemble it to X12, then send it to the partner's As2 receive URL. In the send port, the AS2EdiSend is used as the Send Pipeline, which will assemble the 997 message to X12.

    Thanks a lot and best regards,

    Mark

    Thursday, April 26, 2012 3:07 AM
  • Hi Mark,

    Actually, the Biztalk will send the 997 as the response on the same receive port if the check box "Route Ack to Send Pipeline on request-response receive port" is checked on the party setting. If this is unchecked, I think we are good.

    Also, do you know if the partner actually receive the MDN as response or not in the instances when we receive the error in Biztalk.

    Regards,

    Atin Agarwal


    Atin Agarwal

    Thursday, April 26, 2012 7:27 PM
  • Yes, we have checked the party configuration,we found that the check box "Route Ack to Send Pipeline on request-response receive port" is checked by default yesterday, after unchecking it, problem still exists.

    The partner didn't receive MDN, a 500 error occurred on the partner side. Currently, we are working on separating AS2 receive and EDIX12 disassemble process.

    Thanks a lot,

    Mark

    Friday, April 27, 2012 1:23 AM
  • After we separated the AS2 receive process and EDIX12 disassemble process, the 500 error disappeared, because we have a customized EDI X12 disassembler component which may throw exception for some validation failure. It seems that if we customizing pipeline used for AS2 receive, we should not throw any exception inside the pipeline, which will case the MDN failed to send back, we can just send the message to the SuspendedMessageQueue, and also avoid to touch the data stream which produced by the AS2Disassembler component.

    Thanks Atin again for your kindly help.

    Best regards,

    Mark

    • Marked as answer by MarkXMou Saturday, April 28, 2012 6:30 AM
    Saturday, April 28, 2012 6:30 AM