Losing Database Insert in a BizTalk WCF-CustomBehavior when it fails

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:

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

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.

Uncategorized  

Leave a Reply