WCF-WebHttp Adapter issue?

Question

Hello guys
I stumble on this problem while I was trying to develop a custom pipeline component that on runtime generates a GUID and affects it to the context and body of the message. That GUID is placed on Http Headers as a boundary (content type)
and on the message body. What it happens is that, on the first message that I send, everything goes well (header GUID matches body GUID, the service response it’s not important here), after the first message all the following messages on the header will have
the GUID from the first message that I send thought the port, although everything goes fine on the body. Like this:
Request #1:
Header: Content-Type: multipart/mixed; boundary=batch_bead1969-540e-4020-8b47-cf0fbcddef1c
Body:
bead1969-540e-4020-8b47-cf0fbcddef1ce
Request #2:
Header: Content-Type: multipart/mixed; boundary=batch_bead1969-540e-4020-8b47-cf0fbcddef1c
Body:
226dd0f5-501f-4da8-a871-b79e6ac512d0
Request #3:
Header: Content-Type: multipart/mixed; boundary=batch_bead1969-540e-4020-8b47-cf0fbcddef1c
Body:
98b7e6f9-c229-4a0b-a8f1-cd0c1f3e27e8
As you can see in red, between multiple requests the GUID is always the same, and it shouldn’t be since on the body is changing correctly. After some analysis we realized that the problem was with the property “HttpHeaders” (WCF property
schema), where we are writing the “content-type” in our custom pipeline component. It seems that for some reason the value of this property ain’t properly read after a first message went thought successfully.
Why do I say successfully? Well…
If there’s an error on send the message and the message gets dehydrated or suspended, the HttpHeaders seems to be “reseted” and read again, and everything goes as it should.
If the message went to successfully regardless of the response, the issue that I describe will happen.
Restarting the host instance seems to have no effect.
Sometime after the first message went thought successfully, HttpHeaders seem to be “reseted” and read again. Although I don’t know how much time, at least something above 15min.
Stop\Start the send seems to force an “reset” on the property.
Just to make clear some eventual questions, HttpHeaders is correctly written into context before entering the adapter, after the message went thought the adapter, we can see on fiddler that the message isn’t as it should.
I did some code to replicate this issue, and my Execute method on pipeline goes like this:
public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(IPipelineContext pContext, Microsoft.BizTalk.Message.Interop.IBaseMessage pInMsg)
Stream inMsgBodyStream = pInMsg.BodyPart.GetOriginalDataStream();
pInMsg.Context.Write("HttpHeaders", "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties",
"content-type: multipart/mixed; boundary=batch_" + Guid.NewGuid().ToString());
return pInMsg;
I also try this behavior with the classic HTTP adapter, although another issues were raised, the fact is that Http Headers are correctly read between requests, so as far as we can tell this just happens with this adapter.
Does anybody had similar issue? So far I haven’t found a solution.
PS: I’m using Biztalk 2013 RTM
Thanks

Answer 1

Hey, someone else reported a similar issue with the WCF-WebHttp adapter for BizTalk 2013 - see this thread:
http://social.msdn.microsoft.com/Forums/en-US/biztalkgeneral/thread/e477ad7a-505c-4f86-9556-8075d747e447. I will report your finding to Microsoft support.
Thanks,
If this answers your question, please use the "Answer" button to say so | Ben Cline