Unfortunately, if you create a WCF service and drop it under a WSS controlled vroot like _layouts or _vti_bin, your service will fail to activate with the following message in the event log:

WebHost failed to process a request.
Exception: System.ArgumentException: virtualPath
at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.End(IAsyncResult result)

If you attach a debugger to w3wp.exe and enable break on first CLR change exceptions, the stack trace at the time of the failure will look like:

virtualPath 

at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.IsExcludedPath(Stri­ng virtualPath) 
at Microsoft.SharePoint.ApplicationRuntime.SPVirtualPathProvider.FileExists(St­ring virtualPath) 
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceA­vailable(String normalizedVirtualPath) 
at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(St­ring relativeVirtualPath)
at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.HandleRequest()
at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.BeginRequest() 
at System.ServiceModel.Activation.HttpHandler.ProcessRequest(HttpContext context)

After debugging the issue, it turns out¹ that WSS own VirtualPathProvider (SPVirtualPathProvider, briefly described by this MSDN page) refuses to handle requests for which the virtual path starts with "~". 

Now that we understand the issue, a workaround¹ is easy to implement. There are three steps:

1. Write our own VirtualPathProvider. It will detect if the request is made to a WCF service and if so, it will remove the leading "~" and hand off the request to WSS virtual path provider,
2. Arrange for our new virtual path provider to be inserted before WSS provider so we get a crack at all requests before WSS does. This will be done using an ASP.NET HttpModule,
3. Perform a few changes to web.config to insert our new module in the ASP.NET pipeline.

The following paragraphs describe these steps.

A custom VirtualPathProvider

VirtualPathProviders were introduced in ASP.NET 2.0. They are commly used by web applications which want to serve ASP.NET pages saved in other locations that the file system (a SQL table is the most canonical example).

All VirtualPathProviders are daisy chained by ASP.NET. This means that any custom VirtualPathProvider has a "Previous" VirtualPathProvider it can erly on to perform standard operations. For instance, Sharepoint's SPVirtualPathProvider relies on the default VirtualPathProvider to serve ASP.NET pages stored on the file system¹.

For us, we will essentially use the "Previous" VirtualPathProvider (which happens to be of type SPVirtualProvider) to implement our provider. We will pass most requests untouched. We will only look at requests ending with ".svc" and starting with "~". Such a request will be treated as a WCF service call and we will "patch" the virtual path (by removing the leading "~"). The patched virtual path will then be handed off to the previous virtual patch provider for further processing.

Here is the code for our custom VirtualPathProvider:

public class WCFVirtualPathProvider : VirtualPathProvider {

     public override string CombineVirtualPaths(string basePath, string relativePath) {
         return Previous.CombineVirtualPaths(basePath, relativePath);
          }

     public override System.Runtime.Remoting.ObjRef CreateObjRef(Type requestedType) {
         return Previous.CreateObjRef(requestedType);
     }

     public override bool DirectoryExists(string virtualDir) {
         return Previous.DirectoryExists(virtualDir);
         }

     public override bool FileExists(string virtualPath) {                                 
        // Patches requests to WCF services: That is a virtual path ending with ".svc"     
        string patchedVirtualPath = virtualPath;                                            
        if (virtualPath.StartsWith("~", StringComparison.Ordinal) &&                       
          virtualPath.EndsWith(".svc",    StringComparison.InvariantCultureIgnoreCase))     
        {                                                                                  
          patchedVirtualPath = virtualPath.Remove(0, 1);                                   
        }                                                                                   
        return Previous.FileExists(patchedVirtualPath);                                    
     }                                                                                     

     public override System.Web.Caching.CacheDependency GetCacheDependency(string virtualPath,
                System.Collections.IEnumerable virtualPathDependencies, DateTime utcStart) {
        return Previous.GetCacheDependency(virtualPath, virtualPathDependencies, utcStart);
     }

     public override string GetCacheKey(string virtualPath) {
        return Previous.GetCacheKey(virtualPath);
     }

     public override VirtualDirectory GetDirectory(string virtualDir) {
        return Previous.GetDirectory(virtualDir);
     }

     public override VirtualFile GetFile(string virtualPath) {
        return Previous.GetFile(virtualPath);
     }

     public override string GetFileHash(string virtualPath, System.Collections.IEnumerable virtualPathDependencies) {
               return Previous.GetFileHash(virtualPath, virtualPathDependencies);
     }

     protected override void Initialize() {
        base.Initialize();
     }
}

Most method delegate work to the "Previous" virtual path. Virtual Paths appearing to be WCF service calls are patched.

Registering our VirtualPathProvider 

According to MSDN, VirtualPathProviders must be registered using HostingEnvironment.RegisterVirtualPathProvider. Moreover, VirtualPathProviders must be registered with ASP.NET before the first line of code is compiled. An HttpModule is the perfect place for us to register our provider. The module is trivial:

public class WCFPatchupModule : IHttpModule {
   
   static bool virtualPathProviderInitialized = false;
   static object virtualPathProviderInitializedSyncLock = new object();

   public void Dispose() {
   }

   public void Init(HttpApplication context) {
      if (!virtualPathProviderInitialized) {
         lock (virtualPathProviderInitializedSyncLock) {
             if (!virtualPathProviderInitialized) {
                    WCFVirtualPathProvider vpathProvider = new WCFVirtualPathProvider(); 
                    HostingEnvironment.RegisterVirtualPathProvider(vpathProvider);       

                    virtualPathProviderInitialized = true;
             }
         }
      }
   }
}

Now, we need to compile the two classes above into a strongly named assembly and isntall it into the GAC.

Configuration changes

Assuming you have compiled the two classes above and signed the assembly, you are now ready to insert our HttpModule in the ASP.NET pipeline. This is easily done by changing the <httpModules> section of the sharepoint site as follows:

<httpModules>
<clear />
<add name="SPRequest" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add name="OutputCache" type="System.Web.Caching.OutputCacheModule" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />

<add name="WcfVirtualPathProvider" type="WcfVirtualPathProvider.WCFPatchupModule,         
           WcfVirtualPathProvider, Version=1.0.0.0, Culture=neutral,                       
           PublicKeyToken=[... put your assembly public key token here ...]"/>             

<!-- <add name="Session" type="System.Web.SessionState.SessionStateModule"/> -->
</httpModules>

Our HttpModule will run after Sharepoint's "SPRequest" module. Since SPVirtualProvider is registered by the "SPRequest" module at startup¹, we know our VirtualPathProvider will always come into  play *after* Sharepoint's SPVirtualPathProvider and therefore, we will get a chance to patch the request's virtual path before it reaches Sharepoint. Of course, you will need to substitute your assembly name, version and public key token. 

You are now ready to test: deposit an WCF service under _layouts and call it. You should now see your service getting activated and calls should now be sucessful.

es.UpdateActivity("PurchaseOrder", poid, "POShipped", DateTime.UtcNow);

This rule is unfortunately easy to forget. For instance, let's assume you have a message with a date/time field you want to track with BAM. You start the tracking profile editor and map the message field to the adequate activity element. It was so easy that you forgot the above rule: the date/time data in the message must always be expressed in UTC or you'll start to see the tracked date/time behave funny in the BAM Portal as well as durations based on this date/time.

If the field is not expressed in UTC, the right approach is to convert it to UTC before you hand it off to BAM. You can do this in a map (with a scripting functoid), an orchestration or in a custom pre-processor component.

Happy date/time tracking!

This error message means that there are instances with duplicate ID in the activity you were searching. If you look at the "Application" event log on the computer which runs the BAM Web Services, you will find one entry from "BAM Web Service" comparable to the following:

EXCEPTION:
System.Web.Services.Protocols.SoapException: There are instances with duplicate ID 'PO_COMPLETED_100' in activity 'PurchaseOrder'. The duplicates must be removed from the database to fix this problem.

BAM will not operate properly if there are duplicate activity instance IDs. Internally, BAM uses these IDs to perform correlations and expects them to be unique. The database is considered corrupted when this situation occurs and this condition should be fixed as soon as possible.

Why does that happen?

You installed one of the BAM sample or tutorial and caused BizTalk to process the same message more than once. Sample messages have hardcoded IDs, so if you process the same message twice, you'll end up with two activity instances with the same ID. 

This can also happen if BAM was asked to insert data with duplicate activity instance IDs through the BAM APIs such as DirectEventStream or BufferedEventStream.

You may also extract activity IDs from incoming messages using a tracking profile and two messages came with the same ID.

For BAM, it is critical you ensure all activity instasnce IDs are unique.

So why does BAM allow me to insert duplicate IDs?

If BAM cannot operate with duplicate activity instance IDs, why doesn't BAM refuse to insert them in the first place? Well, this is for performance reasons. Internally, BAM splits the data into partitions to make insertions faster. Checking for the uniqueness of a key would require to lock multiple tables in a transaction and scan for this ID into multiple partitions / tables. This would dramatically slow BAM down.

Installation

Donwload the attached file and extract Reflector.BizTalkDecompiler.dll into the same directory as Reflector (otherwise it won't work). Go to View|Add-Ins in Reflector, and Add Reflector.BizTalkDecompiler.dll.

Usage

Using File|Open..., add the BizTalk assembly you'll like to decompile to Reflector's assemblies list. Right click on the BizTalk assembly and select "BizTalk Server 2006 Artifacts".

You should see a list of all artifacts, with their type, name and namespace they were compiled into. Click the "Decompile..." button to decompile all selected artifacts into source files. You can select / de-select artifacts by using the selection check box on the right.

In the decompile dialog, specify the path to the directory where files should be created and press "Decompile". The decompile dialog is multi-threaded for a more responsive user interface.

Screenshot

Limitations

[Update June 19, 2006 - 10:00] This addin was compiled for the .NET Fraework 2.0 and Reflector 4.2 (and above). It will not work with the .NET Framework 1.1: you will get an error comparable to:

System.BadImageFormatException: The format of the file 'Reflector.BizTalkDecompiler.dll' is invalid.
File name: "Reflector.BizTalkDecompiler.dll"
   at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Boolean stringized, Evidence assemblySecurity, StackCrawlMark& stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
   at ᜧ.ᜀ(String A_0)

 I am currently investigating a port to .NET 1.1 but I do not promise I'll do it. The addin was designed for BizTalk Server 2006 which requires the .NET Framework 2.0 so you should have any problem.

Most BizTalk artifacts can be decompiled back to their original source form (Pipelines, Schemas). Some artifacts cannot be decompiled to their original source (Maps). When decompiling a map, the addin will export the XSLT which was generated by the compiler, not the actual .btm file.

[Update June 9, 2006 - 13:00] Recovering the full source of orchestrations is possible but invovles a manual step. After exporting, open the .odx file in the BizTalk Orchestration Designer (in Visual Studio) and save it without making any change. The editor will rebuild missing information which cannot be infered from the compiled assembly. Once this is done, the resulting .odx file should behave as if it was the source of the orchestration.

Feedback welcome!

[Update June 9, 2006 - 12:20] This tool is handy but I'd like to make sure everyone understands that is is offered "AS IS" with no warranty. I did not anticpate so much interest in the tool so I had to append this legal disclaimer.

This being said, if you found a bug, want a new feature or just want to say that you are using BizTalk decompiler and you love it, feel free to use the "Email" link above to drop me a note!

Reflector.BizTalkDecompiler.zip

You can donwload it at https://www.microsoft.com/downloads/details.aspx?FamilyId=DDA047E3-408E-48BA-83F9-F397226CD6D4&displaylang=en.

As its name hints, this web service allows the BAM Portal to retrieve BAM instance data without connecting directly to a SQL server.

This web service is intended to be called by the BAM Portal only. Therefore, it is not documented and Microsoft will not support code which makes direct calls to this web service.

A long time ago, when we designed BAM for BizTalk Server 2004, we knew we wanted to get data without connecting to SQL server directly. Unfortunately, we did not have the time to provide a robust, well designed, general purpose set of APIs to query BAM instance data so we settled for a private API which served our immediate needs. It was believed that we would have time in a next release to think about this again and perhaps expose well designed APIs for BAM instance data retrieval. Alas, it was on the list but did not make the cut for BizTalk 2006.

The supported way of retrieving BAM instance data is documented on MSDN (link updated 09/18/2007). Essentially, you need to connect to the SQL server hosting BAM and query the following view (available within the BAM Primary Import Database):

bam_<ViewName>_<ActivityName>_View