Four Ways to Accept Any XML Data Into BizTalk Web Services

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:



Categories: BizTalk

9 replies

  1. 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!

  2. 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.

  3. 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

  4. 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

  5. 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.

Trackbacks

  1. Sending XML messages to BizTalk using the WCF Channel Model « Connected Thoughts – Thiago Almeida

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: