I have a C# trace routine, that writes data to a SQL Trace table. It’s kind of like my own Log4Net, and allows a unified trace between BizTalk, WebServices, and other types of progams.

I had the interesting task the last month of writing a WCF Custom Behavior to make JSON work in BizTalk 2010. Moving to 2013 or 2016 was simply not possible at this client in time for implementing the project.

So I had lots of Trace statements in the custom behavior. The bizarre thing was that when I call the trading partner’s webservice, and it succeeded, then I could see the rows inserted. In Debug/Attach mode I could see them as well. But if the trading partners’ webservice returned any error, all the rows inserted were being rolled-backed (rollback). And of course, the Trace results are much more needed in the event of an error; for example, I want to see the JSON that was created.

I earlier had decided to write the JSON to a disk directory. But I still prefer having it in the Trace as well. The Trace has an column of XML data type, where I can store text and blobs. (If the data is not XML, the C# trace program just puts a dummy xml <wrapper> tag around it. Normally in this column I store the request and response to and from any web service. It makes debugging very fast and easy.

I started researching about distributing transactions, and fortunately found a quick and easy fix. All I had to do was add the “Enlist=false” statement to the connection string:

       <add name="Trace" connectionString="server=localhost;database=Trace;Integrated Security=true;Enlist=false" />

I found the answer on this page about .NET distribution transactions. At first I thought I might have to change my C# code to use “EnlistDistributedTransaction” method, but that wasn’t necessary. Just changing the connection string as shown above worked.

First download the C+ distributable from Microsoft: Download 64

Download the CURL MSI from here:
Download CURL MSI

Install will default to this directory, and here is the curl.exe: “c:\Program Files\cURL\bin\curl.exe”.

You need to find the MSI. Many downloads of CURL will include the source code and it requires you to build it with C++ compilers and such. That’s more trouble than you usually need to go through when you just want to install and use the tool. Fortunately, the anonymous author at “ConfusedByCode.com” has been nice enough to create the MSI (Microsoft System Installer) files for CURL so that you can download it, install it, and be using it within minutes.

What is CURL?

A command line tool for getting or sending files using URL syntax.

How is CURL applicable to BizTalk or B2B Teams

B2B and BizTalk developers can use CURL to test websites, often of their trading partners. CURL can be run as part of a batch (.bat) or command (.cmd) file if you need to automate a test or schedule a download using Windows Task Scheduler.

Example Curl commands

Download the HTML of a page to your disk:

curl -o example.html www.example.com

The issue is you are testing, and it’s hard to see the exceptions you are encountering. You don’t want to go read the IIS logs, and they might not have the full .net error anyway.

1) Set customErrors mode attribute to “Off”
2) Set serviceDebug includeExceptionDetailInFaults attribute to “true”

Example of a webconfig below with these two parameters set, so you can see the context and parent nodes of where they fit in.

<?xml version="1.0"?>

    <compilation debug="true" targetFramework="4.0" />
    <customErrors mode="Off" />
      <service behaviorConfiguration="ServiceBehaviour" name="SQRT_WCF.SQRTREST">
        <endpoint address="" behaviorConfiguration="web" binding="webHttpBinding"
          bindingConfiguration="longTimeoutBinding" contract="SQRT_WCF.IDepot" />
        <behavior name="ServiceBehaviour">
          <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
          <serviceMetadata httpGetEnabled="true"/>
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="true"/>
        <behavior name="web">
        <binding name="longTimeoutBinding"
        receiveTimeout="00:10:00" sendTimeout="00:10:00">
          <security mode="None"/>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
    <modules runAllManagedModulesForAllRequests="true"/>

A client C# program was call an orchestration published as a web service. I was turning on Basic Authenticiation in BizTalk and IIS. C# client program kept getting: “The requested service [service name] could not be activated. See the server’s dianostic trace logs for more information.

My Solution:
NOTE: This may not be your solution. We had DNS pointing a subdomain.domain.com to one of two servers. I simply had the servers crossed. I think they were having a load balancing issue, and had DNS just pointing to one of the two. Other users were on Machine A, so I logged on to Machine B, thinking that’s where the DNS was pointing. Later I confirmed that DNS was in fact pointing to Machine A.

One day, I hope to be able to fully understand and explain the “Ambient Transaction” true/false option in BizTalk WCF-SQL and WCF-Custom send and receive ports.  Until then, I’m going to collect the most relevant info and blogs here:

The official Microsoft BizTalk parameter definition (for the WCF Send or Receive Port): http://msdn.microsoft.com/en-us/library/dd787981.aspx

Specifies whether the SQL adapter performs the operations using the transactional context provided by the caller. Default is true, which means that the adapter always performs the operations in a transactional context. If there are other resources participating in the transaction, and SQL Server also joins the transaction, the transaction gets elevated to an MSDTC transaction.

However, there can be scenarios where you do not want the adapter to perform operations in a transactional context. For example:

  • While performing a simple Select operation on a SQL Server database
  • While specifying a polling statement that performs a Select operation, and does not involve any changes to the table either through a Delete statement or by invoking a stored procedure.

Both these operations do not make any updates to the database table and, hence, elevating these operations to use an MSDTC transaction can be a performance overhead. In such scenarios, you can set the binding property to false so that the SQL adapter does not perform the operations in a transactional context.

Not performing operations in a transactional context is advisable only for operations that do not make changes to the database. For operations that update data in the database, we recommend setting the binding property to true; otherwise you might either experience message loss or duplicate messages, depending on whether you are performing inbound or outbound operations.


http://seroter.wordpress.com/biztalk-and-wcf-part-iii-transaction-patterns/  (Richard Seroter – usually has great blogs on BizTalk topics)

http://msdn.microsoft.com/en-us/library/ms973865.aspx (Richard Seroter above refers to the “Ambient Transaction” feature as being part of the Systems.Transaction in .NET Framework 2.0 and afterwards.  It seems like understanding Ambient Transactions from native C# first would be key to understanding how it works in BizTalk.

The above link provides the following information, but as for me now, it does not pass the “so what” and the “WIIFM” (What’s In It for Me) test.

System.Transactions defines a concept called an ambient transaction. The ambient transaction is the transaction that is present in the thread that the current application code is executing within. To obtain a reference to the ambient transaction call the static Current property of Transaction:

<em>Transaction ambientTransaction = Transaction.Current;</em>

If there is no ambient transaction, Current will return null.

The ambient transaction object is stored in the thread local storage (TLS). As a result, when the thread winds its way across multiple objects and methods, all objects and methods can access their ambient transaction.

Later it says:

The value of TransactionScopeOption lets you control whether the scope takes part in a transaction, and if so, whether it will join the ambient transaction or become the root scope of a new transaction.


A TransactionScope object has three options:

  • Join the ambient transaction.
  • Be a new scope root, that is, start a new transaction and have that transaction be the new ambient transaction inside its own scope.
  • Do not take part in a transaction at all.


This forum post tries to answer the question: “What exactly is an ambient transaction?”



StackOverflow: http://stackoverflow.com/questions/224689/transactions-in-net

There are 2 main kinds of transactions; connection transactions and ambient transactions. A connection transaction (such as SqlTransaction) is tied directly to the db connection (such as SqlConnection), which means that you have to keep passing the connection around – OK in some cases, but doesn’t allow “create/use/release” usage, and doesn’t allow cross-db work.

The alternative is an ambient transaction; new in .NET 2.0, the TransactionScope object (System.Transactions.dll) allows use over a range of operations (suitable providers will automatically enlist in the ambient transaction). This makes it easy to retro-fit into existing (non-transactional) code, and to talk to multiple providers (although DTC will get involved if you talk to more than one).

Note here that the two methods can handle their own connections (open/use/close/dispose), yet they will silently become part of the ambient transaction without us having to pass anything in.

If your code errors, Dispose() will be called without Complete(), so it will be rolled back. The expected nesting etc is supported, although you can’t roll-back an inner transaction yet complete the outer transaction: if anybody is unhappy, the transaction is aborted.

The other advantage of TransactionScope is that it isn’t tied just to databases; any transaction-aware provider can use it. WCF, for example. Or there are even some TransactionScope-compatible object models around (i.e. .NET classes with rollback capability – perhaps easier than a memento, although I’ve never used this approach myself).


Blog on on the topic:  Transaction.Current and Ambient Transactions by Florin Lazar:


Key phrase from above blog: “Transaction.Current can detect that the transaction was created inside a COM+ context and provide it to anyone asking for the ambient transaction.

StackOverflow: Difference Between Transaction and TransactionScope


Key phrase: The ambient transaction is the transaction within which your code executes.

Transaction Scope Class (C# examples): http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope%28v=vs.90%29.aspx

And final link – to a comparison of Transaction Handling in 1.0 and 2.0 .NET (rather old, but may help give the background of when the “Ambient Transaction” was birthed: http://msdn.microsoft.com/en-us/library/ms973865.aspx

CodeProject Sample Demo/Code: http://www.codeproject.com/Articles/690136/All-About-TransactionScope

A transaction which automatically identifies a code block that needs to support a transaction without explicitly mentioning any transaction related things. An ambient transaction is not tied just to a database, any transaction aware provider can be used. TransactionScope implements an ambient transaction. If you see the use of TransactionScope, you will not find transaction related anything sent to any method or setting any property. A code block is automatically attached with the transaction if that code is in any TransactionScope. A WCF transaction is another example of a transaction aware provider. Any one can write a transaction aware provider like the WCF implementation.



WCF-SQL and DTC Ambient Transactions in a cross domain scenario


The ambient transaction option ensures that the BizTalk adapter flows a transaction through to SQL Server and thus the SQL transaction will only commit when the message received by BizTalk is successfully written to the BizTalk message box database.  This is of course crucial in a guaranteed delivery based solution where you can’t afford to lose any messages.

I found that all worked well when ambient transactions were turned off, however when turned on it looked like the receive location just hangs, holding a lock on SQL resources (I tried to do a select on the table in question using SQL Server Management Studio and it couldn’t return any values due to locks being in place) which won’t be removed until the host instance is reset.

The above blog talks about using DTCPing and DTCTester to identify DTC issues, and fixing them by laxing the security options in the DTC configuration.

Conclusions (or lack thereof):

So for now, I suggest studying that second web page to get an idea of what the topic is really about.  If I had time, I would write some C# programs to test outside of BizTalk.