Hi Folks,

This blog will discuss the high level overview for developing a proxy on BizTalk to interface with composite web services. What we want to do is create a multi-part message on the fly when sending the data to the web service. BizTalk deals with data, but the workflow system deals with another message type, specify the stage and status of a message. This is where a SOAP proxy can be of use, by leveraging serializing etc.

The hardest part about making this work is supplying the correct message to the SOAP adapter at run time. If the specified proxy class method takes more than one parameter, BizTalk expects you to supply a multi-part message where each part corresponds to a parameter in the signature. BizTalk will deserialize each message part into the corresponding .NET Framework type before invoking the Web service proxy method, which then serializes everything back into a SOAP message.

Imagine we have a web service that manipulates data. It calls an XSLT engine and then does some formatting to the data. In our case, we use Altova XSLT engine, since users can develop maps and not need to be concerned with the BizTalk Mapper.

On the BizTalk side we would call the web service and parse in as parameters the XML from the BizTalk Message Store that subscribed to this particular send port.

You basically create a standard Send Port and then link the custom dll you have to represent your web proxy in the Web Service tab:

So how do you create a proxy dll. First I always use a dedicated proxy Visual Studio project. So in this case I call it MMIT.Workflow.Common.Proxies.<SubProxyName>

Sp the SubProxyName would be DataManipulation for a web service we need to call via BizTalk.

Proxies are cool, since you can do some formatting and extra logic to the data before sending it to the web service.

I assume in the blog, you all familiar with developing web services, if not, you can always read my other blogs about developing web services.

So here is the template code for calling a DataManipulation proxy service.

Here is how you make a proxy class, then just LINK the method name in BizTalk (see picture above) to the method in the proxy dll.

 

using System; using System.Net; using System.Web.Services.Protocols; using System.Xml; using MMIT.Common.Data.Internal; using MMIT.Workflow.Common.BOL; namespace MMIT.Workflow.Common.Proxies.DataManipulation {     public partial class MMITDataManipulation     {         [SoapDocumentMethodAttribute("http://MMIT.DataManipulation/BizTalkExecute", RequestNamespace = "http://MMIT.DataManipulation/", ResponseNamespace = "http://MMIT.DataManipulation/", Use = System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle = SoapParameterStyle.Wrapped)]         public WorkflowRecord BizTalkExecute(WorkflowRecord msg)         {             msg.WorkflowData.Stage = WorkflowStage.DataManipulation;             try             {                 XmlDocument doc = msg.MMITData.MMIT_Data_Record.Serialize();                 msg.MMITData.MMIT_Data_Record = MMIT_Data_Record.BuildDataRecord(Execute(doc));                 msg.WorkflowData.Status = WorkflowStatus.Succeeded;                 return msg;             }             catch (WebException)             {                 // To use the retry functionality of the send port                 // This exception type includes time outs and service unavailable from the web service.                 throw;             }             catch (Exception e)             {                 msg.WorkflowData.Status = WorkflowStatus.Failed;                 msg.WorkflowData.Error = e.Message;                 return msg;             }         }     } }

In the above code the Execute is a method call to from a web service reference, which accepts an Xml document.

That is all there is to it, whenever BizTalk calls the send port, it will execute the above code and send the data to the web service. In the above, we converting a XML message to a workflow message and then sending it to another system for processing. The main reason we have this feature is to create multi-part messages.

You can read more about this stuff here:

http://msdn.microsoft.com/en-us/magazine/cc163464.aspx

So I hope this blog gets you started.

• Uncategorized