BizTalk HotRod Magazine.

by | Apr 17, 2007 | BizTalk Community Blogs via Syndication

This morning I came across this interesting magazine via Richard Seroter. I quickly glimpsed through the magazine at work and was very impressed by the contents straight away.

 This is the first magazine I’ve seen dedicated to BizTalk resources. The first issue contains 8 good articles written by people from Microsoft and its partners.

After seeing the content of the magazine I couldn’t resist to wait till the weekend to update  BizTalk247. So, I added a new section to BizTalk247 called MAGAZINE which previews the content of BizTalk HotRod.

I encourage all BizTalk developers to go through the articles in the magazine they are well written based on real time customer situations.

As a feature article, there is an article from Stephen Kaufman which highlights the features of BizTalk 2006 R2.

Nandri!

Saravana

Consume WCF Service Wizard generates port binding configuration files for import into BizTalk Server

by | Apr 17, 2007 | BizTalk Community Blogs via Syndication

Scenario: You have already designed, implemented and hosted a WCF Service. Now, you would like to send (and get) messages to this WCF Service in a BizTalk Orchestration process.  BizTalk communicates with WCF applications via BizTalk WCF Adapter, which can be configured through send and receive ports in BizTalk.  This post talks about how BizTalk’s Consume WCF Wizard can be used to simplify the port creation process in BizTalk, especially the need of mapping the operation(s) with the SOAP Action(s) within the port to invoke the operation in WCF Service.


Microsoft BizTalk Server 2006 R2 now includes a BizTalk WCF Adapter to provide support for WS-* and transport neutrality by letting the user choose most appropriate Windows Communication Foundation (WCF) binding in BizTalk Port configuration.  The BizTalk WCF Adapter can be selected within a Send Port by creating a new port and then selecting a Transport Type.  In Receive Port, the BizTalk WCF Adapter can be selected by creating a new Receive Location and then selecting Transport Type from the drop-down box.   The Receive Location allows for hosting a non-HTTP WCF Service within BTSNtSvc.exe and can be enabled within the BizTalk Administration Console without need for publishing. 


Even though WCF-Custom is the only adapter needed, BizTalk allows other WCF adapters for most common messaging scenarios, as shown in the table below.  For example, WCF-Custom can be used as WCF-WSHttp transport by selecting WCF-Custom, clicking on Configure, select Binding tab and selecting the Binding Type wsHttpBinding or customize this transport by using wsDualHttpBinding or wsFederationHttpBinding. 

















 

Available Send Port


WCF Adapters

Available Receive Port


WCF Adapters


One-way

WCF-BasicHttp


WCF-Custom


WCF-NetMsmq


WCF-NetNamedPipe


WCF-NetTcp


WCF-WSHttp

WCF-BasicHttp


WCF-Custom


WCF-CustomIsolated


WCF-NetMsmq


WCF-NetNamedPipe


WCF-NetTcp


WCF-WSHttp


 


Two-way

WCF-BasicHttp


WCF-Custom


WCF-NetNamedPipe


WCF-NetTcp


WCF-WSHttp

WCF-BasicHttp


WCF-Custom


WCF-CustomIsolated


WCF-NetNamedPipe


WCF-NetTcp


WCF-WSHttp


Note:  Adapters built using WCF LOB Adapter SDK are consumed within BizTalk using WCF-Custom BizTalk WCF Adapter. Once the adapter is configured, it shows up in the Binding Type drop-down box and can be selected like any other predefined WCF binding.


The following section shows, at a very high level, how a BizTalk WCF Adapter is used within a typical BizTalk programming lifecycle.  


%u00b7         Design-Time Experience


o   Create a Visual Studio BizTalk Project


 


o   Use Consume WCF Service Wizard (Right Click > Add > Add Generated Items > Consume WCF Service) to download metadata from a running service using MEX endpoint or import metadata using WSDL.


%u00a7  Following files are generated as an outcome of running this wizard.


 














Metadata

XML Schema Files


Orchestration

BizTalk Orchestration (.odx) file


Port Binding Information Configuration

{ServiceName}_Custom.BindingInfo.xml – Contains port configuration using WCF Custom Adapter


 


{ServiceName}.BindingInfo.xml – Contains port configuration using other WCF bindings as obtained from the MEX endpoint


 


These configuration files can be imported in


 


%u00a7  MEX endpoints only with these transport types are supported


o   http, https, net.pipe, net.tcp


o   Implies users CANNOT use this wizard to import metadata from MEX enabled services that use a custom transport channel.  WCF users can publish and retrieve metadata over a custom binding, which may include transports (and schemes) other than the ones defined above. 


 


%u00a7  Port Binding Information Configuration Contains operation to action mapping strings


%u00b7         <BtsActionMapping> <Operation Name=”Operation1” Action=”Action1”/> </BtsActionMapping>


 


o   Build the BizTalk Project


 


%u00b7         Deployment-Time Experience


 


o   Deploy the BizTalk Project


 


o   Import the Port Binding Information XML file to auto-generate the ports in BizTalk Server 2006 Administration Console


%u00a7  Right click on Applications within BizTalk Group, select Import > Bindings and then navigate to the Visual Studio BizTalk project folder


%u00a7  Select the Port Binding Information XML file


 


o    Enlist and start the orchestration (and all its dependencies)  


 


%u00b7         Execution-Time Experience


 


o   Trigger the orchestration depending on your scenario – e.g. dropping a file in the file drop for receive location to pick it up



See the attached document for screen shots of Consume WCF Service Wizard.

Error installing Google Photos Screensaver on Vista

by | Apr 16, 2007 | BizTalk Community Blogs via Syndication

If you try to install the new Google Photos Screensaver on Vista, through the Google Updater, you’ll probably run into the following error:
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2739.
This is an MSI error that means Javascript is not registered on the machine. You can fix this by registering jscript.dll from a command prompt (with administrator rights)as follows:
c:\windows\system32>regsvr32 jscript.dll
Once you’ve done this, run Google Updater again to reinstall the Google Photos Screensaver, and it will work.
The new version of the screensaver is pretty sweet — it now supports local Picasa albums, Picasa Web albums, and photo RSS feeds.

BizTalk Framework Pipeline Component

by | Apr 16, 2007 | BizTalk Community Blogs via Syndication

Because there is so much written about this pipeline component, I would list some things it does (refering to here and here):

  1. Provides a way to ensure guaranteed delivery of a message
  2. Creates a unique id for that message
  3. Provides a standardized context ‘wrapper’ XML docuement that contains the context properties of the message
  4. Keeps the message in the MessageBox until a corresponding acknowedgment is recieved.

Now the question is why/where would you use it?

  1. If you are doing BizTalk to BizTalk communication, you want two seperate BizTalk Hosts talking to each other.
  2. You want exactly-once delivery of data.
  3. You need to save the context data w/o modifying the original data.

I am involved in a project that the use #3 is the reason why I needed to use it. We are creating a standard message, and the process to import the data into the application is complete, the only problem is there is no routing information in the data, where it came from. It only has data about the patient, not who sent the data. What I really needed to do is attach wrapper data to the original message.

The Framework Pipeline component is the perfect solution. Some things that are required, but not documented are the following properties (in bold):

IsReliable
PassAckThrough
eps_to_address
eps_to_address_type
eps_from_address
eps_from_address_type
prop_identity
prop_sentAt
prop_topic
svc_deliveryRctRqt_sendTo_address
svc_deliveryRctRqt_sendTo_address_type
svc_deliveryRctRqt_sendBy
svc_commitmentRctRqt_sendTo_address
svc_commitmentRctRqt_sendTo_address_type
svc_commitmentRctRqt_sendBy
prc_type
prc_instance
deliveryRct_receivedAt
deliveryRct_identity
commitmentRct_identity
commitmentRct_decidedAt
commitmentRct_decision
commitmentRct_commitmentCode

If you don’t specify those properties you will get the following errors:

There was a failure executing the send pipeline: Reason: Invalid BTF message. The message is missing context properties eps_from_address that are required to generate a proper BTF envelope.

There was a failure executing the send pipeline: Reason: Invalid BTF message. The message is missing context properties eps_from_address_type that are required to generate a proper BTF envelope.

There was a failure executing the send pipeline: Reason: Invalid BTF message. The message is missing context properties eps_to_address that are required to generate a proper BTF envelope.

There was a failure executing the send pipeline: Reason: Invalid BTF message. The message is missing context properties eps_to_address_type that are required to generate a proper BTF envelope.

There was a failure executing the send pipeline: Reason: Invalid BTF message. The message is missing context properties prop_topic that are required to generate a proper BTF envelope

Here is an example of how you set those variables is the following properties:

InputMsg(BTF2.eps_from_address)=InputMsg(BTS.ReceivePortName);
InputMsg(BTF2.eps_from_address_type)=”Lab”
InputMsg(BTF2.eps_to_address)=”Order Directory”
InputMsg(BTF2.eps_to_address_type)=”XML”
InputMsg(BTF2.prop_topic)=”Order”

Which will make the following envelope around the message:

Validating Schemas in WebMethods using Attributes

by | Apr 15, 2007 | BizTalk Community Blogs via Syndication

One of the most annoying things in BizTalk is when an error is generated in a Receive Pipeline indicating that a message has been suspended because of the content of the message doesn’t validate against the given schema (for the moment, we’ll gloss over the fact that in an ideal situation this should only ever happen during testing).

Using BizTalk 2006’s new Failed
Message Routing feature, it’s fairly simple to write something which can deal
with this situation (using either an Orchestration or SendPort subscribing to the
Error Report).

Returning a message back to a Web Service caller indicating that there is something
wrong with their message, is non-trivial – it’s possible, but requires some in-depth
knowledge of how instance subscriptions work.

However, there is an easier way: validating the message at the endpoint (i.e. inside
the Web Service itself).
Aaron Skonnard and
Dan Sullivan wrote an article for MSDN magazine in July 2003 on how
to implement attribute based schema validation for Web Method parameters.

It’s a great idea: decorate a Web Method with an attribute, and when the web method
is called then any messages received will be validated against their schemas – if
they don’t validate, then a SOAP Fault is returned back to the caller.

Looking through the code, I realised that with a few modifications it could work for
my situation.

The main issue with the code as it was is that, by default, it would validate incoming
XML messages against the XSD contained in the WSDL.

If you’re using the BizTalk Web Services Publishing Wizard, you’re probably
letting the tool do all the code generation for you. This also means that you’re probably
letting the .NET Framework look after generating your WSDL for you.

There’s a problem with auto-generation (as an aside, auto-generation might make your
life easier, but it can cause all sorts of problems if you’re not aware of how it
works, and what “default scenarios” it assumes).

Here’s what most people would do:

  • Create a schema in BizTalk in represent a message.
  • Use the Web Services Publishing Wizard to create a Web Service which can accept message
    using this schema.
    During this process, the wizard will use the xsd.exe tool
    to auto-generate a class (usually a C# class) which represents the XSD.
  • A caller then requests the WSDL for the web service – and the auto-generated class
    is converted into an XSD for inclusion in the WSDL.

However, a C# class can’t fully represent an XML schema (and vice versa). Anyone who’s
worked with complex (real-world) schemas will have realized this.

One area where the whole thing falls over is when we put restrictions on attributes
or elements.

For example, suppose we an attribute called “name” which we wanted to restrict to
being between 1 and 20 chars long:
    <xs:attribute
name=”name” use=”required“>
        <xs:simpleType>
            <xs:restriction
base=”xs:string“>
                <xs:maxLength
value=”20” />

                <xs:minLength
value=”1” />

            </xs:restriction>
        </xs:simpleType>
    </xs:attribute>

When this schema gets “converted” into a class representation, we get the following
for the attribute
    /// <remarks/>

    [System.Xml.Serialization.XmlAttributeAttribute()]
    public string name {
        get {
            return
this.nameField;
        }
        set {
            this.nameField
= value;
        }
    }

And then when this class gets converted back to XSD again, we get this:
    <xs:attribute
name=”name” type=”xs:string”
/>

All the restrictions have disappeared!
That’s because they’re not supported by the xsd.exe tool (or, more specifically,
by the internal classes used by xsd.exe to do the heavy lifting).

So that’s the problem with using the default SchemaValidator code: because
it validates incoming messages against the schemas in the WSDL, then unless you have
manually created your WSDL, the schemas in your WSDL will not be same as the original
schemas you created.

The solution is simple: validate the incoming messages against the original schemas.
And it just so happens that when you use the Web Services Publishing Wizard all
the original schemas are copied into the web service folder, in a sub folder called xsd.
What’s more, the original SchemaValidator code supports looking for schemas
in a folder called xsd – however, it simply has these take a backseat to the
ones in the WSDL.
Note: another solution is to handcraft your WSDL and put the original schemas
in there yourself – in fact, this is what everyone should do IMHO.

So the modifications I made to the original code are simple:

  1. Change the order for searching for schemas to being the xsd folder first, then
    the WSDL
  2. Added a schema-namespace check – if the schema has already been loaded, then we don’t
    attempt to load it again

All the changes I made are in a single class: ValidationExtension.cs

How to use

Compile the solution, and then either copy the SchemaValidation.dll assembly into
your web service’s bin folder, or give the assembly a strong name and put it in the
GAC.

Then, update the web.config file for your web service as per the example given in
the solution:

    <soapExtensionReflectorTypes>
        <!– add type=”$SoapExtensionReflectorType.FullName$,
$AssemblyName.Name$” /–>

        <add type=”SchemaValidation.ValidationExtensionReflector,
SchemaValidation, Version=1.0.0.0“/>
    </soapExtensionReflectorTypes>
    <serviceDescriptionFormatExtensionTypes>
        <add type=”SchemaValidation.ValidationFormatExtension,
SchemaValidation, Version=1.0.0.0“/>
    </serviceDescriptionFormatExtensionTypes>

Finally, open the code-behind file for your web service and do the following:

    add a using SchemaValidation; statement
at the top
    Add a [Validation] attribute
to all web methods where incoming messages should be validated

e.g.
    [WebMethod]
    [Validation]
    public string Test(MyType bp)
{

Now if you call the web method with a message which doesn’t validate against the schema,
you’ll get a SOAP Fault similar to this:


<?xml version=”1.0″ encoding=”utf-16″?>
<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Client</faultcode>
      <faultstring>System.Web.Services.Protocols.SoapException:
Incoming message failed validation: Error: The ‘name’ attribute is invalid – The value
” is invalid according to its datatype ‘String’ – The actual length is not equal
to the specified length.
   at SchemaValidation.ValidationExtension.xrs_ValidationEventHandler(Object
sender, ValidationEventArgs e)

The code for this solution can be downloaded from here:

SchemaValidation.zip
(21.99 KB)

If you have any issues with it, let me know.