Four Ways to Accept Any XML Data Into BizTalk Web Services

Written by

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

Comments

10 responses to “Four Ways to Accept Any XML Data Into BizTalk Web Services”

June 16, 2009

Ryan CrawCour

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!

Reply
June 16, 2009

Richard Seroter

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.

Reply
July 20, 2009

Thiago Almeida

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

Reply
1. July 16, 2015
  
  Gabriel
  
  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
  
  Reply
  1. July 16, 2015
    
    Gabriel
    
    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
    
    Reply
    1. July 17, 2015
      
      Gabriel
      
      <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>
      
      Reply
      1. November 10, 2016
        
        Ralf
        
        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
August 8, 2009

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

[…] to have a generic receive location in BizTalk to accept any XML file. Richard Seroter has listed a few options already on how to do […]

Reply
October 28, 2009

amarax

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

Reply
March 29, 2011

Ritesh

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.

Reply