This topic covers using .NET WCF flowed transactions with SOAtest.

Sections include:

SOAtest and .NET WCF Flowed Transactions

SOAtest can initiate flowed transactions using WS-Atomic Transaction or the Microsoft OleTransactions protocol.  Flowed transactions can be used when the service endpoint's binding configuration has transactionFlow="true" and either transactionProtocol="OleTransactions" or transactionProtocol="WSAtomicTransactionOctober2004".

If the operation contract for the Web service uses the TransactionFlow attribute with the TransactionFlowOption.Allowed property, then enabling transactions in SOAtest is optional and does not require any extra test configuration.

However, if the operation contract is using the TransactionFlowOption.Mandatory property, then transactions are required and the test suite must be configured to initiate a flowed transaction. For general information about WCF flowed transactions, see the following:

The above WS Transaction Flow MSDN article explains what is required to configure a WCF web service client to initiate a flowed transaction. The steps necessary to configure transactions in SOAtest are similar or analogous to what is described in this article. It is highly recommended for users to read the WS Transaction Flow article in order to first understand the basic concepts behind transactions in WCF.

Configuring MSDTC

The Microsoft Distributed Transaction Coordinator (MSDTC) must be configured correctly on the machine running SOAtest, as well as the machine hosting the Web service. The MSDN WS Transaction Flow article has instructions for configuring MSDTC and how to configure the Windows firewall to allow DTC. Here are a few other articles that may be useful when configuring MSDTC.

Configuring the Test Suite

Invoking several Web service operations within the scope of a transaction requires configuring a TransactionScope object. Take the following C# code snippet:

CalculatorClient client = new CalculatorClient("transactionEnabledEndpoint");using (TransactionScope tx = new TransactionScope(TransactionScopeOption.Required)) {
	client.add(1, 2); 
	client.add(2, 3); 

In SOAtest, an equivalent test suite would be structured as follows:

  • Extension Tool 1: Create Transaction Scope
    • XML Data Bank: propagation token
  • Tool 1: add(1,2)
  • Tool  2: add(2,3)
  • Extension Tool 2: Complete Transaction

In the test suite above, Extension Tool 1 is needed to create the TransactionScope object and to get the propagation token for the current transaction. The propagation token is then put into an XML Data Bank because it will be needed later by the tools (described later). Here is sample Jython code that can be used for Extension Tool 1:

from webtool.soap.wcf import *; 
from soaptest.api import *;
def createTransaction(input, context):
   context.put("MY_TRANSACTION_ID", id)
   token = WcfUtil.getCurrentPropagationToken()    
   return SOAPUtil.getXMLFromString([token])

The Extension Tool 2 in the test suite is used to complete the transaction. This Extension tool is doing the equivalent of tx.Complete() in the above C# code snippet. Here is the Jython code for Extension Tool 2:

from webtool.soap.wcf import *;
def endTransaction(input, context):
   id = context.get("MY_TRANSACTION_ID")   

The WcfUtil methods and corresponding .NET API are described below:

int webtool.soap.wcf.WcfUtil.createTransactionScope(int scopeOption, int isolationLevel, int scopeTimeout)



  • See TransactionScopeOption Enumeration:

  • Can be one of the following:



  • See IsolationLevel Enumeration:

  • Can be one of the following:



  • The timeout of the TransactionScope in ms.


An ID that can be used to reference the TransactionScope.

String WcfUtil.getCurrentPropagationToken()


The Base64 encoding of the propagation token for the current transaction.

WcfUtil.completeTransactionScope(int transactionScopeRef)



  • The id returned by WcfUtil.createTransactionScope()

Configuring Transaction Headers

The tools each need to have a SOAP header that contains the propagation token. This propagation token comes from the XML Data Bank chained to the first Extension Tool test that was described earlier. The type of SOAP header that is needed depends on the transaction protocol. 

OleTransaction Headers

For OleTransactions, a OleTxTransaction SOAP header is needed.  For convenience, here is a sample OleTxTransaction SOAP header:

<OleTxTransaction b:Expires="59904" s:mustUnderstand="1"

To add the above header to tool 1, complete the following:

  1. Select the SOAP Header tab from within a tool’s Request tab.

  2. Click the Add button within the SOAP Header tab. The Add New SOAP Header dialog displays.

  3. Select Custom from the Add New SOAP Header dialog and click the OK button. A new row is added to the SOAP Header tab.
  4. Double-click the new row in the SOAP Header tab. An Edit dialog displays.

  5. Paste the following sample OleTxTransaction SOAP header into the Literal/XML text field of the Edit dialog:

    <OleTxTransaction b:Expires="59904" s:mustUnderstand="1"
  6. Select Form XML from the Views drop down box of the Edit dialog, and click Yes to override Form XML values with Literal XML values.
  7. In the Form XML view, select the PropagationToken element, then select the Parameterized option for the element's value. This will allow you to choose the XML Data Bank column containing the propagation token.
  8. Click the OK button.

WS-Atomic Transaction Headers

For WS-Atomic Transaction, a CoordinationContext SOAP header is needed instead. Similar to the OleTxTransaction header, the PropagationToken element must be parameterized to include the propagation token from the XML Data Bank. For convenience, here is a sample CoordinationContext SOAP header:

<CoordinationContext s:mustUnderstand="1"
	<ReferenceParameters xmlns="">
   <PropagationToken xmlns=""></PropagationToken>

To add the above header to tool 2, follow the same procedure as outlined for tool 1, but instead paste the above CoordinationContext SOAP header into the Edit dialog.

  • No labels