Tracing SharePoint adapter requests

How to track SharePoint requests

SharePoint adapter does not allow for configuring a proxy. So I will configure SharePoint proxy in BizTalk configuration file. And use Fiddler as the proxy to trace SharePoint web requests and responses.

Purpose of doing the steps below

The purpose is to force SharePoint Adapter to send data through Fiddler proxy. Only one SharePoint host instance will send the data through the proxy.


The default proxy defined in the BizTalk configuration file will work for all web requests. Make sure you restore the original BizTalk config file as soon as you restart SharePoint host instance.

To list the steps needed to trace SharePoint requests:

  1. Create ne 32 bit host, i.e. SharePointTestHost
  2. Create a host instance for the SharePointTestHost on a machine where you have Fiddler application installed
  3. Save original BTSNTSvc.exe.config file as original_BTSNTSvc.exe.config
  4. Modify BTSNTSvc.exe.config file by adding defaultProxy section at proper position
  5. Start SharePointTestHost host instance
  6. Save modified BTSNTSvc.exe.config as withproxy_BTSNTSvc.exe.config
  7. Rename original_BTSNTSvc.exe.config file back to BTSNTSvc.exe.config
  8. Now you are sure that only the host instance that you created will use the Fiddler proxy settings
  9. Configure a receive location, i.e. RecLoc1 to use the SharePointTestHost
  10. Start Fiddler
  11. Configure in Fiddler an option to decrypt https traffic (if BizTalk commuinicates with SharePoint using https protocol)
  12. Enable the receive location “RecLoc1”
  13. Wait for results

Note: if you trace 64 bit host instance, modify BTSNTSvc64.exe.config config file and not BTSNTS.exe.config file.

BizTalk Configuration section

The local proxy on port 8888 is the Fiddler proxy. Make sure the default proxy uses default credentials of the host instance by setting the useDefaultCredentials attribute to true.

    <!-- Setting to let SharePoint Web Requests go through Fiddler proxy -->
    <defaultProxy useDefaultCredentials="true">
      <proxy usesystemdefault="true" proxyaddress="" />

Sample Fiddler results


Full contents of BTSNTSvc.exe.config file

Don’t just copy and paste the config file to your environment. I am also using SharePoint assemblies redirection from version 14 to version 15. Copy only the section.

<?xml version="1.0" ?>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" />
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking;Tracking\interop" />
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="Microsoft.SharePoint.Client" publicKeyToken="71e9bce111e9429c" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion=""/>
        <assemblyIdentity name="Microsoft.SharePoint.Client.Runtime" publicKeyToken="71e9bce111e9429c" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion=""/>
    <!-- Setting to let SharePoint Web Requests go through Fiddler proxy -->
    <defaultProxy useDefaultCredentials="true">
      <proxy usesystemdefault="true" proxyaddress="" />
  <!-- End of SharePoint proxy settings -->
        <provider id="sspi" type="Microsoft.BizTalk.XLANGs.BTXEngine.SecurityServerChannelSinkProvider,Microsoft.XLANGs.BizTalk.Engine" securityPackage="ntlm" authenticationLevel="packetPrivacy" />
        <channel ref="tcp" port="0" name="">
            <provider ref="sspi" />
            <formatter ref="binary" typeFilterLevel="Full"/>

BizTalkAssemblyResourceManager failed to complete end type change request.

Visual Studio stores binding files for BizTalk Server project assemblies. Those files are used when BizTalk application is redeployed using VS. This way you may remove, i.e. orchestration assembly from BizTalk application resources and still have your orchestrations fully bound when you deploy the assembly again.

But sometimes the binding file that VS stores may get out of sync with your current solution and then you won’t be able to deploy the solution on your development machine anymore. Errors may be various, including:

Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Failed to update binding information. Could not enlist orchestration ‘[…]Orchestrations.CreateConstructor,[…]Orchestrations, Version=, Culture=neutral, PublicKeyToken=[…]’. Could not enlist orchestration ‘[…]Orchestrations.CreateConstructor’. All orchestration ports must be bound and the host must be set.

Solving the issue requires removing invalid assembly binding from C:\Users\[user]\AppData\Roaming\Microsoft\BizTalk Server\Deployment\BindingFiles folder.

Windows SharePoint Services adapter error 12310

BizTalk Server 2013 (CU2) could not download a file from a SharePoint 2013 document library. File was left in checked out state on SharePoint and on BizTalk Server you could read:

The Windows SharePoint Services receive adapter has failed to process the SharePoint file test.txt. The following error has been encountered:
[System.InvalidCastException] Unable to cast object of type ‘System.Collections.Generic.Dictionary`2[System.String,System.Object]’ to type ‘Microsoft.SharePoint.Client.Field’.
Error code: 12310
Once you have addressed the issue causing this problem, you can undo the check-out for this file and the adapter will try to process it again. Continue reading

Sending control characters to flat files, AKA “The data send failed unexpectedly”

Not every error in BizTalk is what it pretends to be. Error in the data can break FTP connection while file is being sent.  Recipient thinks he got the file, but half of it is missing. I learned it lately.

The Error

In BizTalk there is a flow routing data from FILE receive location to FTP send port. File is received in XML format and sent as a flat file using flat file assembler in the send pipeline. One cold winter morning BizTalk started suspending messages on the send port with the following error:

The data send failed unexpectedly. Inner Exception details: “(null)”. Continue reading

Receive pipeline events are not tracked

Update: this issue was addressed by Cumulative Update 6 for BizTalk Server 2010

Recently I was investigating an interesting problem in BizTalk Server 2010. All of the sudden events generated for receive locations just stopped being recorded. Noone has changed the configuration. For a simple messaging scenario, in which message flows from receive location A to a send port B, you could see the send port events being tracked. But no sign of when and where the message was received.

Continue reading

Routing failure in dynamic send port after adding new default send handler to HTTP adapter

Version: Microsoft BizTalk Server 2010 Enterprise Edition 3.9.469.0

[Dynamic send ports use default send handlers defined for adapter.]

Issue description
Application with a dynamic send port was imported and started.  We’ve found out later that we need to have the dynamic send port running on a different server. So we’ve added a new (default) send handler with a different host, removed the previous send handler and restarted all host instances. But BizTalk was still running the dynamic send on old server and each time failing with “Routing failure” error. Continue reading