I ran into a BizTalk problem today that was inevitable.  We interface with PeopleSoft  a bunch.  PeopleSoft has some very specific Schemas it uses to communicate.  We have two seperate applications that make use of the same schema in reading responses posted to the PeopleSoft web service.  Well the second of two projects what put into production a few days ago.  When I came in this morning, one of them had a suspended message on the receive side of a HTTP Send/Receive adapter:

Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Source: "XML disassembler"
Receive Port: "rcvFile"
URI: "C:\Test\In\*.xml"
Reason: Cannot locate document specification because multiple schemas matched the message type

So, as expected, BizTalk could not figure out which schema to resolve the message to as it exists in this Applicaion and another.  The default XML Receive Pipieline is not very helpful in this situation as it is just that - default.  The solution turns out to be quite simple.  Create a new Receive Pipeline and add an XML Disassembler to the Disassemble stage.  In the XML Disassembler's properties, add the desired schema from the application to the disassembler's Document Schemas collection.  This tells the disassembler to select from this list only.  If the list is empty, it will behave the same way as the default XML Receive Pipeline.

Andrew Connel & Bob Fox kick-off TechEd right with SharePoint by Day and SharePint at Night.

• SharePoint by Day, SharePint by Night @ TechEd North America 2008 Developer
  Monday, June 2, 7p ->? @ BB Kings Orlando (9101 International Drive #2230; Orlando, FL)
• SharePoint by Day, SharePint by Night @ TechEd North America 2008 IT Pro
  Monday, June 9, 7p ->? @ BB Kings Orlando (9101 International Drive #2230; Orlando, FL)

The onslaught of things to in the evening continues (You don't have to be going to TechEd to come to this one!):

Microsoft Architecht Evangelist Jeff barnes will be presenting Siverlight 2.0 on Wednesday May 21st for the SCDNUG.  We last saw Jeff with Joe Healy on the Tiki Hut Tour.  Jeff is a great presenter and I am looking forward to getting up to speed on Silverlight 2!  More Info Here.

I am looking forward to TechEd but am also a little overwhelmed.  I am working up my shcedule with the Schedule Builder and am frankly in awe of the number and variety of sessions.  I want to attend sessions, meet with folks, do labs and even take a cert or two.  How to do all of this and stay sane?

GeekFest 2008 TechEd Edition

Doug Seven & Company (MSFT) are throwing this event at Howl at the Moon.  I haven't been to a Howl at The Moon since the one at Church Street closed.  I am looking forward to getting reaquainted in Geek style.  Hope to see some familiar faces there.

Spent a few days battling an error on an HTTP Send Port.  We've been having messages suspend when posting data to Siebel.  The funny part is that the messages got accross ok.  We were only getting the error on the ACK from the send port.  The error message on the suspended message was:

The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

We brough this up to the Siebel guys but they were a little slow moving on the informatio that they were sending us bad responses.  After a few days I got nervous that the problem may have not been on their end.  So I dragged out NetMon.  And here's what I saw:

  Frame:
+ Ethernet: Etype = Internet IP (IPv4)
+ Ipv4: Next Protocol = TCP, Packet ID = 50895, Total IP Length = 467
+ Tcp: Flags=...PA..., SrcPort=HTTP(80), DstPort=1427, Len=427, Seq=2928398986 - 2928399413, Ack=4246831364, Win=64240 (scale factor not found)
- Http: Response, HTTP/1.1, Status Code = 204
  - Response:
     ProtocolVersion: HTTP/1.1
     StatusCode: 204, No content
     Reason: No Content
     Date:  Thu, 15 May 2008 20:28:51 GMT
     Server:  Microsoft-IIS/6.0
     XPoweredBy:  ASP.NET
     process instance id:  1-1DEHL5
     user-agent:  Microsoft (R) BizTalk (R) Server 2006 3.0.1.0
     datahandlingsubsystem:  HRFQADProductInbound
     transporttype:  HTTP
     expect:  100-continue
     object id:  1-Z02HX
     connection:  Keep-Alive
     cache-control:  no-cache, must-revalidate, max-age=0
     Pragma:  no-cache
     Host:  mlbsbltst1vm
     HeaderEnd: CRLF

So I dragged out RFC 2616 to go over what the HTTP Header should look like.  I found that the header field name should be a token and that the definition of a token is:

So, in the aforementioned header the following fields are of interest:

     process instance id:  1-1DEHL5

     object id:  1-Z02HX

They are bad.  BizTalk is right.  Working on the Siebel guys to take out these custom header fileds (or make them compliant at the least). 

The problem troubleshooting something like this is that BizTalk chokes on the message in the pipeline and it doesn't get captured anywhere.  I had to reproduce it in an environment where I could use NetMon to grab the actual data from the wire.