The client connection might have been disconnected while receiving AS2 transmission in BizTalk 2010
-
21 aprilie 2012 03:41
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: FalseI 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
Toate mesajele
-
24 aprilie 2012 06:54
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
-
25 aprilie 2012 01:17
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
-
25 aprilie 2012 06:30Also, 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
-
26 aprilie 2012 03:07
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
-
26 aprilie 2012 19:27
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
-
27 aprilie 2012 01:23
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
-
28 aprilie 2012 06:30
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
- Marcat ca răspuns de MarkXMou 28 aprilie 2012 06:30
.png)
