After the BizTalk Server 2006 R2 Microsoft announces BizTalk Server 2009 which will serve enterprises to build integration solutions with a more powerful Microsoft suite which is the main attraction for me to get my hands dirty with BizTalk Server 2009.
The main features which I found useful on the BizTalk Server Roadmap page on Microsoft’s site are below.

Enhanced development platform:It supports the Windows Server 2008, VS 2008, .NET Framwork 3.5 and SQL Server 2008 which I think is a major change and will have advantages of the new advanced platform. The main feature of Windows Server 2008 is the Hyper-V virtualization which can also be a standalone product to use virtualization on their costly gigantic machines. The BizTalk Server 2009 Hyper-V guide is available for download. The ESB Guidance 2.0 is also available at Microsoft site and the ESB Guide package is available at CodePlex ESB page. With VS 2008 we have new features for debugging artifacts such as Maps, Pipeline components and Orchestrations. With SQL Server 2008 Analysis Services we can get more functionality out of BAM.

Adapters:Unlike the release of BizTalk Server R2, BizTalk 2009 comes with two new adapters Oracle E-Business Suites and SQL Server, while there has been an enhancement in the existing adapters which I still have to explore.

Other Enhancements:On the MS Roadmap for BizTalk Server page on Microsoft’s website you can see enhancements in B2B integration, SOA and web services, Device Connectivity and of course the enhancement in message processing by adding recoverable interchange processing support in the disassembling and validation stages in pipeline. There are also new queries for message tracking in the BizTalk Management Console.

Share this:

Like this:

Last week I came across a scenario where I had to call the card verification service before updating the credit/debit card status. This was the first time I was consuming a web service in an orchestration so I had a little trouble in the beginning. Very innocently I made request and response messages of the schema types which I got from the wsdl, made a request-response port and deployed the project. Configured the port to use the SOAP adapter and gave the URI of the web service. I tested my orchestration and was expecting the results but got the exception in the system Event Log.

“Failed to load “” type.

Please verify the fully-qualified type name is valid.
Details: “”.
The type must derive from System.Web.Services.Protocols.SoapHttpClientProtocol.
The type must have the attribute System.Web.Services.WebServiceBindingAttribute. “.

After a little search on the internet I found out that I have to add the web reference of the web service and configure web ports and web messages and cannot call the web service in this manner. However I succeeded to consume the web service but I had to consume the web service without adding the web references. Because I figured out if the schemas change in the future of the web service (which was most likely too) then I had to update the web references, recompile and redeploy the project.

Adding the web reference in my project I got the following items which will be used by BizTalk to consume the web service.

Universal Resource locator (URI)

WSDL which contains the methods,ports and message type information of the web service.

Reference map (Which will contain xsd’s).

BizTalk will then use web port types and web messages from the web reference generated items. It will capture web ports from the WSDL and web messages from the reference.xsd’s generated.

The trick is if we can generate these items for BizTalk we can surely call the web service without using web reference. The work around for this is generating the proxy class from wsdl.exe. You can generate the proxy class from visual studio command prompt and giving the proper switches will create the proxy class.

After generating the proxy class you can add the proxy class to a .NET Library project, give it a strong name key file, build the project. (Don’t forget to GAC the generated assembly before deploying the BizTalk Project).

Technically the SOAP.MethodName and SOAP.AssemblyName properties are promoted to the context of the message before being published to the message box and these values are supplied automatically when we use web port (which come from the web reference). We can supply the AsemblyName and MethodName from the proxy class we created. After its GAC’d we can configure the send port of the orchestration and supply the AssemblyName and MethodName properties for the message context. After the BizTalk Project is deployed we can configure the send port calling the web service. In the web service tab, select the assembly which was created before by building the .NET library project containing the proxy class. Select the Type name and method name and in the general tab specify the web service URI.

In this way you can have more control over the proxy and handle its versioning and a little change in the web service won’t make you build deploy the project again.