I knew of three techniques for creating generic service on-ramps into BizTalk, but last night learned of a fourth.
So what if you want to create an untyped web service endpoint that can accept any valid XML message? I previously knew of three choices:
- Orchestration with XmlDocument message type. Here you create a throw-away orchestration which takes in an XmlDocument. Then you walk through the service publishing wizard and create a service out of this orchestration. Once you have the service, you can discard the originating orchestration. I seem to recall that this only works with the ASMX publishing wizard.
- Create wrapper schema around “any” node. In this case, you build a single schema that has a child node of type “any.” Then, you can use the “publish schemas as web service” option of the publishing wizards to create a general purpose service on ramp. If you’re using WCF receive locations, you can always strip out the wrapper node before publishing to the MessageBox.
- Custom WSDL on generated service. For BizTalk WCF-based services, you can now attach custom WSDLs to a given endpoint. I cover this in my book, but in a nutshell, you can create any WCF endpoint using the publishing wizard, and then set the “externalMetadataLocation” property on the Metadata behavior.
So that’s all well and good. BizTalk service endpoints in WCF are naturally type-less, so it’s a bit easier to muck around with those exposed interface definitions than when dealing with ASMX services.
That said, last night I was watching the third in Peter Kelcey’s video series on the ESB Toolkit, and he slipped in a new way (to me) for building generic service endpoints. Simply start up the BizTalk WCF Service Publishing Wizard, choose to publish schemas as a service, and when choosing the message type of the contract, you browse to C:\Program Files\Microsoft BizTalk Server 2009 and pick the Microsoft.XLANGs.BaseTypes.dll.
Once you do that, you can actually pick the “any” schema type that BizTalk defines.
Once you finish the wizard (assuming you chose to create a metadata endpoint), you’ll have a WSDL that has your custom-defined operation which accepts an “any” message.
So there you go. Maybe this was common knowledge, but it was news to me. That’s a pretty slick way to go. Thanks Peter.
Technorati Tags: BizTalk
Richard Seroter's Architecture Musings 
Awesome! new to me too. i’ve been using the 2nd approach up until now. Must still be getting to that point in the book where you discuss option 3.
But option 4 seems much less painful.
Thanks, i’ll be sure to check it out!
Chapter 8. Although I just peeked at what I had wrote in that chapter, and while I did it all in a custom WSDL, I still used a wrapper node that I shredded in the receive location.
Hi Richard,
Just a note on the (great) method used by Peter: the WCF receive location in BizTalk needs to have the ‘Inbound BizTalk message body’ configured to Path, with a Body path expression set to /part and Node encoding set to String for it to work.
Regards,
Thiago Almeida
Hello Tiago ,
I’m able to push the message into Biztalk , it strips the “part” element and takes the payload if finds there (the xml). However , when the response is comming back , it is not wrapped in “part” element , so the client doesn’t know where to look for the payload of the response (the client is looking into the ProxyResponse.part section).
Looks like the web service is wrapping the request payload into “part” element and I was expecting also that the web service to do it again when it’s sending the response to the client.
Thanks
Sorry , I already got it , I need to feel this in Outbound WCF message body (Template section) :
This will recreate the format the client is expected and the client will be able to take the payload from the part section.
Regards
<part i:type="a:string" xmlns:a="http://www.w3.org/2001/XMLSchema" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="string" />
</part>
Hi Rickard and Gabriel,
Would need your help of an C# sample which sends an XML document to the published BizTalk WCF Service using the Microsoft.XLANGs.BaseTypes.dll method as described above.
Have get exception that It cant serialize the XML document to the Type part.
Please, would appreciate your help!
Cheers
There is a problem when you use this last way to accept any xml document with webservice publishing wizard.
The problem that in generated webservice’s code DocumentSpecName property assigned to this XLANGs.BaseTypes.Any#Root value. Because of this XmlDisassebler pipeline component doesn’t promote MessageType property based on actual xml passed to webservice and pipeline fails. You can read about it here
http://www.biztalkgurus.com/blogs/biztalksyn/archive/2007/08/16/SOAP-Adapter-and-BizTalk-Web-Publishing-Wizard-_2D00_-things-you-need-to-know_2E00_.aspx
refer to section about bodyTypeAssemblyQualifiedName
Excellent post, which consolidates all the 4 options!!
The issue -amarax mantioned here, I too faced this. To get things working for me, what I did was create a custom little pipeline component which inspecs the inbound XML, extracts the target namespace and root node, concat them togather with a #, thus creating the message type and promoting to the context of the message before publishing to msgbox. This gives me the flexibility to accept any XML message using a single endpoint.