Richard Seroter's Architecture Musings

New BizTalk Whitepapers on SQL Adapter, Web Services

Written by

Richard Seroter

in

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:

Comments

5 responses to “New BizTalk Whitepapers on SQL Adapter, Web Services”

  1. Patrick Wellink Avatar
    Patrick Wellink

    Hi Richard….
    You probably don’t know me, but I always read your posts with great interest (See http://bloggingabout.net/blogs/wellink/archive/2005/12/02/10422.aspx ). 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 ?

    Reply
  2. Richard Seroter Avatar
    Richard Seroter

    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.

    Reply
  3. Patrick Wellink Avatar
    Patrick Wellink

    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 !

    Reply
  4. Richard Seroter Avatar
    Richard Seroter

    Just posted the promised follow up post here … https://seroter.wordpress.com/2007/07/13/avoiding-service-timeouts-in-high-volume-orchestration-scenarios/

    Reply
  5. Jorryt Avatar
    Jorryt

    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.

    Grtz,
    Jorryt

    Reply

Leave a comment

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

More posts