EAI

Handling SOAP Exceptions in BizTalk Orchestrations with WCF Send Adapter

Paul Petrov — Mon, 23 Jun 2008 17:29:28 GMT

Below is an idea how to improve SOAP exception handling in BizTalk to WCF communication. Let’s consider approach recommended in BizTalk SDK documentation (Catch Typed Fault Exception sample):

Add custom WCF fault to the service contract and add corresponding exception handler in the BizTalk orchestration.
In BizTalk orchestration add hander that expects System.Web.Services.Protocols.SoapException to catch any general SOAP exceptions

This allows catching any custom WCF faults and handling them gracefully. It also handles general SOAP exceptions but the downside is that SOAP exception caught will not be original SOAP fault that came over the wire from the service. It’s going to be secondary SOAP exception thrown by the adapter. Receive pipeline will try to match incoming message type using XPath expressions defined in the send port configuration. Since custom WCF faults are embedded as content of Detail node of the soap:Fault message there will be XPath expression like this: /*[local-name()='Fault']/*[local-name()='Detail']/* | /*[local-name()='DivideResponse'], where the first part is matching any child of Detail element. In case if WCF service returns general SOAP fault it will put original exception in Detail element as ExceptionDetail node (QName: http://schemas.datacontract.org/2004/07/System.ServiceModel#ExceptionDetail). Since the schema for ExceptionDetail is unknown to pipeline it will throw SOAP exception with generic description and all original details will be lost. This secondary SOAP exception is the one that actually caught by our generic handler:

There was a failure executing the response(receive) pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Send Port: "WcfSendPort_Operator_WSHttpBinding_IOperation" URI: "http://localhost:8005/calculate" Reason: Finding the document specification by message type "http://schemas.datacontract.org/2004/07/System.ServiceModel#ExceptionDetail" failed. Verify the schema deployed properly.

One solution to this problem is to define http://schemas.datacontract.org/2004/07/System.ServiceModel#ExceptionDetail schema and include it as a fault contract for the WCF operation on the client side. That way all original SOAP fault details can be captured and propagated as ExceptionDetail fault. So that’s how I modified BizTalk orchestration in SDK sample:

Declared new schema ExceptionDetail.
Created new multi-part message type IOperation_Divide_SoapFault that has part of type ExceptionDetail
Added to Divide operation new GenericSoapFault fault of type IOperation_Divide_SoapFault
Added exception handler CatchSoapExceptionDetails for this new fault

Notice no changes required on the service side, all I had to do is on the client. But I did one thing in the service code to throw SOAP exception if numerator equal to 0 (just to be able to test such scenario):

if (numerator == 0)

throw new System.Web.Services.Protocols.SoapException("Test exception", new XmlQualifiedName("A100"));

Dropping input file with 0 as numerator (DivideGenerateSOAPExceptionInput.xml) will create following message in the Fault folder:

<?xml version="1.0" encoding="utf-8"?><MyOperationException xmlns="http://schemas.datacontract.org/2004/07/Service" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Error>&lt;ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"&gt;&lt;HelpLink i:nil="true" /&gt;&lt;InnerException i:nil="true" /&gt;&lt;Message&gt;Test exception&lt;/Message&gt;&lt;StackTrace&gt;   at Service.Operator.Divide(Int32 numerator, Int32 denominator) in C:\Projects\TestBed\Typed Fault Exception Handling\WcfService\Program.cs:line 37
   at SyncInvokeDivide(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]&amp;amp; outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)&lt;/StackTrace&gt;&lt;Type&gt;System.Web.Services.Protocols.SoapException&lt;/Type&gt;&lt;/ExceptionDetail&gt;</Error>
  <Operation>Divide</Operation>
</MyOperationException>

Note it contains exception detail section with original "Test exception" message.

Another approach would be to use exclusively SOAP faults for all kind of custom and system faults, reducing number of exception handlers in orchestrations to one. It can be achieved by implementing custom XML Disassembler pipeline component where incoming message would be inspected and if SOAP Fault is detected all properties can be copied to secondary SOAP fault thus preserving all original exception details.

Source code of modified SDK sample is available here.

MSBuild Tasks for BizTalk Continuous Integration

Paul Petrov — Tue, 10 Jun 2008 01:04:19 GMT

If you store BizTalk application settings in Enterprise SSO database and adapt continuous integration you'll find this MS Build task useful. DeploySSOConfigStore task reads settings from XML configuration file and saves them to the SSO database. The XML can be created (exported) using Richard Seroter's SSO tool which I modified to support this operation. So, if you change your configuration settings, just update XML file in the source control and build process will pick it up and propagate changes to your target environment. Using this task is very simple, it accepts just one parameter - location of the XML settings file:

    <UsingTask AssemblyFile="CustomMSBuildTasks.BizTalk.dll" TaskName="CustomMSBuildTasks.BizTalk.DeploySSOConfigStore"/>

    <Target Name="DeploySSOConfigStore" DependsOnTargets="BizTalkDeploy">
        <CustomMSBuildTasks.BizTalk.DeploySSOConfigStore XmlConfigurationUrl="$(SolutionRoot)\$(BuildBranch)\Source\BizTalkSettings\BizTalk.Configuration.xml"/>
    </Target>

I also added another useful task for publishing WCF services: PublishBizTalkWcfServices. It's very simple but does all that stuff: setting up virtual directories (if needed), publishing contracts, creating receive locations. It has comprehensive logging that helps tracking down deployment issues quickly.

    public class PublishBizTalkWcfServices : Task
    {
        private string serviceDescriptionUrl;

        /// <summary>
        /// The URL to the description file.
        /// </summary>
        [Required]
        public string ServiceDescriptionUrl
        {
            get { return serviceDescriptionUrl; }
            set { serviceDescriptionUrl = value; }
        }

        /// <summary>
        /// Publishes BizTalk schemas as WCF services.
        /// </summary>
        /// <returns></returns>
        public override bool Execute()
        {
            WcfServiceDescription description = WcfServiceDescription.LoadXml(ServiceDescriptionUrl);

            Publisher publisher = new Publisher();
            publisher.BackgroundWorker = new System.ComponentModel.BackgroundWorker();
            publisher.BackgroundWorker.WorkerReportsProgress = true;
            publisher.BackgroundWorker.ProgressChanged += new System.ComponentModel.ProgressChangedEventHandler(BackgroundWorker_ProgressChanged);

            try
            {
                PublishingResults results = publisher.Publish(description);

                Log.LogMessage(results.Message);
            }
            catch (Exception ex)
            {
                Log.LogError(ex.ToString(), null);
                return false;
            }
            return true;
        }

        public void BackgroundWorker_ProgressChanged(object sender, System.ComponentModel.ProgressChangedEventArgs e)
        {
            Log.LogMessage(e.UserState.ToString(), null);
        }
    }

Complete Visual Studio project is available here.

Improved SSO Configuration Data Store Tool

Paul Petrov — Fri, 16 May 2008 20:54:34 GMT

Richard Seroter published useful utility to store/retrieve BizTalk configuration settings in Enterprise SSO database. I added some more functionality to it.

First, I added Export/Import functions allowing to actually save values in the external XML file (Richard's implementation allowed storing only field names, calling for extra work should you delete and restore SSO aplication). I kept file format the same but added values stored as text nodes:

<sso>
  <application name="eCommerce.BizTalk.Configuration">
    <description>Configuration storage for eCommerce BizTalk applications</description>
    <appUserAccount>BizTalk Application Users</appUserAccount>
    <appAdminAccount>BizTalk Server Administrators</appAdminAccount>
    <contactInfo>http://geekswithblogs.net/paulp</contactInfo>
    <field ordinal="0" label="App1.SiteId" masked="no">2</field>
    <field ordinal="1" label="App1.UserId" masked="no">8</field>
    <field ordinal="2" label="App2.Timeout" masked="no">5000</field>
    <flags configStoreApp="yes" allowLocalAccounts="yes" enableApp="yes" />
  </application>
</sso>

New usage scenarios:

1. Saving configuration:

1.1 Create application;
1.2 Save to XML;
1.3 Manage application - Retrieve settings;
1.4 Export to XML file created in (1.2).

2. Restoring previously saved configuration:

2.1 Create application;
2.2 Manage application - Import configuration from file created in (1.4) ;
2.3 Save Changes.

Accordingly, menu items Import/Export available when the Manage Application tab is selected only.

The second part of improvement is where I failed. I added "Select Application" button on the Manage Application tab to browse for available applications in SSO database. Currently, it won't find any ConfigStore application it will come back with "No Applications Found" message. I left this button on intentionally hoping that some would help me to solve this problem. It appears that neither ISSOMapper nor ISSOMapper2 return list of ConfigStore type SSO application. This API call will return application of types Individual, Group or Host Group but not ConfigStore which is the one we create using this tool. At least with the SSOFlag combination being set (0x140006). I tried different flag combinations but could not make it work. So please let me know.

The code can be downloaded here.

Generic BizTalk message broker source code

Paul Petrov — Mon, 04 Feb 2008 18:18:30 GMT

I uploaded source code for the generic BizTalk message broker described in this post.

Generic BizTalk Patterns: Message Broker with Dynamic Transformation

Paul Petrov — Thu, 24 Jan 2008 19:25:31 GMT

This time we'll combine loosely-typed BizTalk messaging concept with dynamic mapping to create generic transformation orchestration. Then we'll add it to the message broker created in the first article to make it even more powerful.

Quite often message dispatching task must be combined with some content adaptation: data mapping, filtering, calculation, etc. Generally, maps are used in BizTalk to achieve that. Since maps are based on source and destination schemas we need to find a way to abstract transformation process from specific schema type to common XmlDocument. What makes it possible is XLANGs transform command. This command accepts output message as argument and uses System.Type of BizTalk map. It allows us dynamically load and apply any map type to any message type.

First, we have to author schemas and maps. I created two input schemas for this project: NewEmployee.xsd, NewOrder.xml; two output schemas: Employee.xsd, Order.xsd; and two corresponding maps: NewEmployee_to_Employee, NewOrder_to_Order.I did some changes in DispatchMessage orchestration to integrate with TransformMessage.odx. I added new message variable msgTransformed which is an output from transformation orchestration. Then I simply added Decide shape to check if transformation required for incoming fie. If yes, we pass map key and input message to the TransformMessage.odx using CallOrchestration shape. If no mapping provided then we simply copy incoming message content to msgTransformed:

Again, to retrieve required map name at runtime, we're going to use the same key-value pairs in the configuration file. In our example we used file name as the key so let's follow this trend. If we're gonna store these keys in the same configuration file we need to modify them to keep unique, for example by adding ".MAP" prefix, i.e. <add key="NewEmployee.xml.MAP" value="GenericBiztalkPatterns.Maps.NewEmployee_to_Employee" />.

To keep things clean and reusable I factored out mapping functionality in separate TransformMessage.odx. orchestration. This orchestration contains three parameters: msgInput, mapKey, out msgOutput which are self explanatory. Notice, all message parameters are of XmlDocument type again. The orchestration id very simple itself. Read fully qualified map name by passed in key and get Type of this map:

mapTypeQName = System.Configuration.ConfigurationManager.AppSettings[mapKey];
mapType = System.Type.GetType(mapTypeQName);

Then in ConstructMessage shape just apply transformation:

transform(msgOutput) = mapType(msgInput);

That's how it looks in designer:

I did some changes in DispatchMessage.odx to integrate with TransformMessage.odx. There is new message variable msgTransformed which is going to be an output from transformation. Also, I added Decide shape to check if mapping required. If yes, then input message and map key is passed into TransformMessage.odx through CallOrchestration shape. Ohterwise, input message simply copied to msgTransformed:

Now, all we need is to make sure there're proper entries in the configuration file:

At some point, configuration file can get quite large, that's why I prefer to keep group of settings in individual configuration files, like destinations.config, maps.config, etc., but that's a topic for another article. So far, we've seen how generic messaging concept can help creating flexible agile BizTalk applications. [Source code is available]

Generic BizTalk Patterns: Message Broker

Paul Petrov — Tue, 15 Jan 2008 06:13:34 GMT

Although current BizTalk release does not support .NET generics it does support concept of genericity at the message level. It is possible, of course, through "untyped" messages or messages that don't have specific type attached to their context. Such messages are represented as System.Xml.XmlDocument type in orchestrations. To read more on message typing aspect of BizTalk please refer to this excellent post by Charles Young. I'd like show practical examples of applying generic programming to typical BizTalk tasks. These examples will help to make your BizTalk solutions leaner, more flexible, and easier to maintain.

Let's start with very common pattern where BizTalk is used as merely message dispatcher - Message Broker. The goal of our generic message broker will be to dispatch any type of message to its destination decided at runtime. So, by avoiding type dependency and early routing binding (basically, hardcoding) we would get single very flexible orchestration which can easily handle requirement changes - one of the top goals of good application design.

Some things to consider before creating BizTalk orchestration. First, we need to figure out how and where to store input to output destination map. Since, it's just key-value pairs, application configuration file will work fine. In my work, I prefer to keep collections of homogenous setting like this in separate xml config files and read them in custom XmlSerializable map (objects like NameValueCollection or Dictionary being non XmlSerializable won't work in orchestration unless placed inside atomic transaction scope). I'll place them in application configuration file now to keep it simple. Next thing, is to decide what to use as a key. Since messages all of the same type to orchestration, we should select something that uniquely maps message to destination. Let's assume that per our requirements it's a input file name, although it can be anything inside message content. The destination will be expressed as complete URL, i.e. [protocol]://[path]/[fileName], for example ftp://myserver/files/dest.dat. So, the map entry can look like this: <add key="emp.dat" value=file://myserver/incoming/employees.dat />. I use .dat extension here just to emphasize it's applicable to any files and not only XML.

Once questions have been answered, the orchestration comes together fairly quickly. On the global level it has one input port, expression to read routing configuration, Decide shape to branch on routing availability condition, and dynamic send port. Receive shape receives input message of XmlDocument type. Output message of the same type is sent through dynamic send port after routing address and all properties have been set:

Inside Decide_IfRoutingAvailable shape there are two branches of execution. If routing address is found then it will read destination URL from the configuration and select transport protocol. Otherwise, destination will be set to the backup location from configuration file in order for the message to be preserved:

Once protocol is identified, we can create output message and set its properties and destination address. In case if protocol is not supported, we route message to the backup location using the same dynamic send port. That's how it looks inside Choose Protocole decide shape:

Let's dive into ConstructFtpMessage shape, to see how properties set:

msgOutput = msgInput;
msgOutput(FTP.UserName) = System.Configuration.ConfigurationManager.AppSettings["FTPUserName"];
msgOutput(FTP.Password) = System.Configuration.ConfigurationManager.AppSettings["FTPPassword"];
msgOutput(FTP.PassiveMode) = System.Convert.ToBoolean(System.Configuration.ConfigurationManager.AppSettings["FTPMode"]);
msgOutput(FTP.RepresentationType) = System.Configuration.ConfigurationManager.AppSettings["FTPRepresentationType"];
msgOutput(FTP.BeforePut) = System.Configuration.ConfigurationManager.AppSettings["FTPBeforePut_" + receivedFileName.ToUpper()];
msgOutput(FTP.CommandLogFileName) = System.Configuration.ConfigurationManager.AppSettings["FTPCommandLog"];

First line simply copies our generic input message content to the output message. Susequent lines set FTP properties from configuration file. Then, all that left is to set destination URL on dynamic port and send output message through it:

DestinationSendPort(Microsoft.XLANGs.BaseTypes.Address) = destUrl.ToString();

As the result, we have a single orchestration that can handle hundreds of different message schemas and multiple protocols. Another positive outcome is that deployment greatly simplified. The application has one orchestration, two ports, but only one of them is bound at deployment time. Also, note no schemas, no maps at this time, we will add them later when we augment application with content transformation functionality.

Sending flat files to IBM z/OS mainframe by BizTalk FTP adapter

Paul Petrov — Fri, 19 Oct 2007 05:17:04 GMT

Recently, I had to create an orchestration that transfers files to the IBM mainframe running z/OS (also called sometimes MVS - Multiple Virtual Storage because of the legacy). The orchestration used dynamic FTP port to correlate incoming messages to the destination. During this exercise I learned something about FTPing to the mainframe with BizTalk adapter.

First, flat files obviously must be passed in ASCII mode so the FTP server is able to convert them to EBCDIC format. Passed in binary mode files will not be readable as text files since these two formats have incompatible code pages. To ensure proper conversion set FTP.RepresentationType to "ASCII" on the message context.

Second, records in files must be separated with CR LF not just LF as I was getting from UNIX system. Otherwise, only one record was transferred. You'd likely get a message like "250 Transfer completed (data was truncated)".

Third, record size must be passed to the mainframe system. This is done by setting FTP.BeforePut property to command options like: SITE DCB LRECL=50 RECFM=FB where LRECL sets the record size of 50 characters.

Finally, on some MVS datasets we experienced data truncation even if the LRECL was set properly when record size in flat file exceeded 80 characters. Those unlucky files kept getting truncated to 80 characters per records (which is default value for z/OS) until I sent command WRAPRECORD. So, for such cases setting FTP.BeforePut to something like "SITE DCB LRECL=600 RECFM=FB WRAPRECORD" did the trick.

Why BizTalk Schema Publishing Is Not True Contract-First

Paul Petrov — Tue, 18 Apr 2006 23:07:00 GMT

In previous post describing features of BizTalk Web Services Publishing wizard I surfaced some thoughts suggesting that schema publishing option does not completely follow contract-first development principle. This post explains why I think so.

In a nutshell, according to contract-first approach one is supposed to produce service contract before trying to implement the service’s guts. After contract is done it can be published so the service consumers can start developing against it. On the other side, service provider is free to develop and bind any compatible service implementation to published contract. Service contract, when properly designed upfront, provides a great deal of decoupling between systems.

What goes into a service contract? Full blown service contract may include lots of things like functional description, message schemas, bindings, message exchange patterns, communication protocols, policies, quality of service, constraints, etc. If we are building web services, then at the very least we should create some WSDL as a standard way of describing services nowadays. We are about to check how BizTalk schema publishing handles this task. For guide how to publish schemas in BizTalk please refer to documentation and see articles by Aaron Skonnard and Richard Seroter.

Let’s design a simple service that does something banal, like weather reporting. I defined following simplistic schema:

<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns="http://WeatherService.Schema" targetNamespace="http://WeatherService.Schema" xmlns:xs=http://www.w3.org/2001/XMLSchema attributeFormDefault="unqualified" elementFormDefault="qualified">

<xs:simpleType name="ZipStruct">

<xs:restriction base="xs:string">

<xs:length value="5" />

xs:restriction>

<xs:simpleType>

<xs:complexType name="WeatherInfoType">

<xs:sequence>

<xs:element minOccurs="1" maxOccurs="1" name="Temperature" type="xs:integer" />

<xs:element minOccurs="0" maxOccurs="1" name="Humidity" type="xs:integer" />

<xs:element minOccurs="1" maxOccurs="1" name="WindSpeed" type="xs:string" />

<xs:element minOccurs="0" maxOccurs="1" name="Conditions" type="xs:string" />

xs:sequence>

<xs:attribute name="Zip" type="ZipStruct" />

xs:complexType>

<xs:element name="WeatherInfo" type="WeatherInfoType"/>

<xs:element name="GetWeather">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="1" maxOccurs="unbounded" name="Zip" type="ZipStruct" />

xs:sequence>

xs:complexType>

<xs:element>

<xs:element name="GetWeatherResponse">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="1" maxOccurs="unbounded" ref="WeatherInfo" />

xs:sequence>

xs:complexType>

xs:element>

Although pretty basic, this example contains some common constructs and constraints found in real life schemas. It has global type definition of a simple type ZipStruct derived by restriction. There’s global complex type WeatherInfoType, and request/response messages declared as global elements. Take a close look at cardinality constraints on the elements. We’d like all those constraints to make into the service contract as part of our business requirements.

The first surprising thing after publishing schema using BizTalk Publishing wizard is that there’s no WSDL file created. Web directory contains WeatherReport.asmx that refers to WeatherReport.asmx.cs code file in the App_Code subfolder. Neither of three other subdirectories (bin, temp, and xsd) harbors our service description.

What we’ve got here essentially is a C# service stub generated from our schema. Let’s browse to the service URL and let .Net dynamically generate web service description for us. This will return a standard WSDL with common sections: types, messages, portTypes, bindings, services. So, what’s the problem? Let’s take a close look at the types section:

<wsdl:types>

<s:schema elementFormDefault="qualified" targetNamespace="http://WeatherService.Schema">

<s:element name="GetWeather">

<s:complexType>

<s:sequence>

<s:element minOccurs="0" maxOccurs="unbounded" name="Zip" type="s:string" />

s:sequence>

s:complexType>

<s:element>

<s:element name="GetWeatherResponse">

<s:complexType>

<s:sequence>

<s:element minOccurs="0" maxOccurs="unbounded" name="WeatherInfo" type="s1:WeatherInfoType" />

<s:sequence>

s:complexType>

s:element>

<s:complexType name="WeatherInfoType">

<s:sequence>

<s:element minOccurs="0" maxOccurs="1" name="Temperature" type="s:integer" />

<s:element minOccurs="0" maxOccurs="1" name="Humidity" type="s:integer" />

<s:element minOccurs="0" maxOccurs="1" name="WindSpeed" type="s:string" />

<s:element minOccurs="0" maxOccurs="1" name="Conditions" type="s:string" />

s:sequence>

<s:attribute name="Zip" type="s:string" />

s:complexType>

s:schema>

wsdl:types>

Surprisingly, to get a weather report we are not required to pass parameters as Zip element became an optional one. Also, its value is no longer restricted to 5 characters length. The same striking change is seen in the response definition: all fields of the WeatherInfo element are optional now. What a big change in our service interface! Would you want to share such contract that lacks original fidelity? I wouldn’t.

Of course, what we’re observing here is a typical example of so called “impedance mismatch” between XML Schema and object-oriented worlds. Whenever mapping entities from one domain to another we have to deal with differences between document-centric and object-centric models plus variations imposed by specific type system implementation. In our case, we got this effect because BizTalk first generated .Net types (DataTypes.cs) and service endpoint code (WeatherService.asmx.cs). Then .Net framework generated WSDL from this code when we hit the service URL. Thus, original schema got distorted by .Net common type system view of the world.

Therefore, BizTalk schema publishing supports development flow as depicted below. The picture below shows parts of a service contract in blue while implementations in yellow. Notice how WSDL is no longer an abstract service description but rather description of concrete service endpoint:

However, when doing contract-first development, we want to create artifacts that belong to service contract before any implementation begins. This way, the WSDL preserves original type definitions, without exposing consumers to service implementation domain:

This is why just publishing schemas in BizTalk is not true contract-first development.

So, does BizTalk still allow designing a contract-first way? Yes, it does. Remember, we started from XML messages schema which is a part of the service contract.

Does it strictly follow contract-first development flow? No, because it creates part of the service contract (WSDL) based on premature platform specific implementation (service endpoint) which hinders original types’ definitions.

Is it possible to work around this limitation? Yes, we can disable dynamic WSDL generation and provide static WSDL that imports original unaltered schema:

<wsdl:types>

<xsd:schema>

<xsd:import schemaLocation="MyTypes.xsd" namespace="http://weather.services"/>

xsd:schema>

wsdl:types>

Another way is to author WSDL and import it using BizTalk BPEL import project.

Are there any other practical considerations when doing contract-first development with BizTalk? Yes, stay tuned for the next article.

BizTalk 2006 RTM is available.

Paul Petrov — Tue, 28 Mar 2006 13:12:00 GMT

BizTalk 2006 is officially released to market. Downloads are available through MSDN subscriber web site. The real thing which will open up its full potential in service oriented world is still ahead - WCF (former Indigo) adapter for BizTalk is planned for the end of this year.