New BizTalk Whitepapers on SQL Adapter, Web Services

A couple of useful BizTalk whitepapers released today. It’s good to see two once-dormant BizTalk blogs (first MartyWaz, now Doug from the CSD Customer Experience) wake up in the past couple weeks.

The first paper, Best Practices for the SQL Adapter, covers how to properly write SQL receive location queries, deal with unsupported data types, handle annoying MSDTC errors, and resolve SQL Adapter Schema Wizard problems. It’s only 14 pages long, so you clearly have time to go read it right now. I’ll wait.

Welcome back. The second paper, Sample Design Patterns for Consuming and Exposing Web Services from an Orchestration, explains in words and pictures how to best set up templates to consume and expose services from BizTalk orchestrations. It’s fairly short, but, should help people who are getting started with web services and orchestration.

Technorati Tags:

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

5 thoughts

  1. Hi Richard….
    You probably don’t know me, but I always read your posts with great interest (See ). I have a question About the WebServices wich probably you can answer (I Hope).

    Basically it boils down to the following question.

    Why is the Timout for consuming a WebService not tied to the actual time spend in the adapter. (Instead it’s bound to the time the message leaves the orchestration). And how can we work around this.

    To elaborate a little more here is our Scenario.

    We have to consume a webservice that takes about 5 Seconds to complete.
    The webservice has only 5 connections. (We cannot influence that) So only 5 concurrent calls are possible to the remote webservice.

    We (can) get hundreds of messages at once that all have to be delivered to that specific webservice. So they all get queued inside bistalk. This results in messages timing-out that never even made it to the SOAP Adapter……

    Do you have a solution for this problem ?

  2. Sheesh, that was the next topic in my blog queue! I hope to post more on this scenarioin the next couple days. I haven’t fully formulated a solution, but I have a couple ideas in mind.

  3. Well i tried a couple of things myself… See the intance controller on codeplex……

    But unfortunately in our environment this just wasn’t reliable enough (could be performance related) On some machines the instance controller would run flawlessly but on others I ended up with zombies.

    Looking very very very forward to what you have to say about this problem !

  4. Well, i’ve had a simular problem once…
    I’ve made an orchestration that puts alle the messages in a SQL database. And then we’ve created a polling mechanish (orchestration) with the SQL adapter to send the messages to another webservice. Using a top 5 mechanism and a polling interval, you can receive all the messages you want and regulate the moment when you answer them.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.