Submitting Xml Documents to BizTalk 2006 via SOAP

 The other day, a question was asked in community ‘has anyone expose BizTalk web service as XmlDocument’. I asked the question to myself and figured that I should write something about this.

Pros and cons when expose untyped web service

The benefit seems apparent, by expose a web service consuming XmlDocument, you basically announcing you will accept any types of message. Imagine your firm requires a ‘messaging portal’ web service instead of building every endpoint for each service, untyped web service is the way to go.

The drawback is apparent as well, your web service consumers have to take care of message construction themselves instead of take advantage of strong type message automatic proxy generation.

Scenario

I pictured a simple example, your exposed web service consumes an XmlDocument, it then relays the request to individual processing orchestrations, each processing orchestration returns an acknowledge message after it gets the request and then continue processing.

This untyped web service acts as message router, each concrete processing orchestration registered in the message router by implement an inverse direct bounding port and filter out messages they not interested. By a design like this, as this ‘messaging portal’ involves, new orchestrations can easily be plugged in the message router. Kevin Lam has a wonderful blog regarding direct binding you may want to take a look.

Implementations

Message Router

The message router monitors messages received by SOAP port, it then detects the message type of this untyped message, forward it to processing step on which all processing orchestration is listening on. It gets ACK message back from processing orchestration and echo it back to SOAP port.

Processing Orchestrations

Each processing orchestration implement the direct bound port defined in message router, by doing that, they are listening on messages distributed.

They then filter on the messages they like by setting filters on receive shape, casts the message to the appropriate type and creates an ACK message sent back to message router. After all these, they are free to do their own business logic.

Web service

You may ask ‘how can I generate an untyped webservice?’ This requires a little trick.

Again, you choose to publish schema as web service, in the next step when it ask for the request response message type, you go ahead randomly select a schema as your request message type, select ACK as response message type.

And

here is the trick, after generating the source code; you should modify the generated C# code to rename the parameter type to XmlDocument. You will discover the WSDL changed; the input parameter type is now

Test

I use XmlSpy to generate a request message

Send to the service, got

Take away

 

·         Be very careful when expose your BizTalk web service as untyped, you should always pay attention to filter settings. In my example, message router filters by BTS.ReceivePortName.

·         Implement dynamic router pattern (recipient list). By doing this, you don’t have to limit the portal ability when it grows.

·         Use promoted property as filter condition in processing orchestration. In my example, I have a property field called ‘message type’, each processing orchestration monitor their interest by filtering on this. I was originally try to promote ‘BTS.MessageType’ as the filter, but in the runtime, it gives me the warning saying it cannot do that because that field is readonly ( why?)

Example is attached here.