Trying to Rehost the BizTalk Mapper Activity (AppFabric Connect)


Recently I was working on a technical question and proof of concept about being able to reuse the BizTalk mapping designer functionality. The goal was to be able to reuse the functionality within a business user application to enable an information worker to create a map. One of my personal goals was to try to do this in an environment that did not incorporate Visual Studio. This is challenging because until recently with BizTalk 2010 there was not really any way (that I know of) to export or hijack the BizTalk extensions from Visual Studio and reuse them in a separate non development environment.

With the BizTalk 2010 beta it has been possible to develop message transforms within the VS 2010 workflow projects once you install the WCF LOB SDK beta. A Windows workflow (WF) activity known as the BizTalk mapper activity shows up in the VS toolbox. A few other articles exist on using this activity, see the following for a good summary:

I decided that it would be interesting to know whether or not you could work with this activity within a WF rehosted environment because this would provide the ability to reuse the mapper functionality in a partial trust, non VS environment. A WF rehosted environment provides a lighter-weight visual editing environment for a workflow that is either stopped or running.

This post shows what I encountered when trying to rehost and manipulate a workflow that use the BizTalk mapper. Unfortunately I found that in the current beta it is not possible to easily manipulate the BizTalk mapper activity in a rehosted workflow. Upon further investigation, the API for the mapper depends on the presence of Visual Studio and simply compiling a project that references the mapper toolbox activity requires extensive Visual studio references. Hopefully this post will save you some time from trying to do this yourself.



To start out with a good basis for the test, I found a blog post which provided a good WF 4 rehost sample. I chose the one at Thanks to Maurice for this great WF 4 post. Basically this enables you to open an Activity.xaml file for a coded workflow and then view it in the rehost environment with the toolbars at the left like in VS. To add the BizTalk mapper activity I did the following steps:

1. Directly referenced the assemblies relating to the BizTalk Mapper activity. Below I give a little more detail on these:

There are a couple of assemblies related to the beta version of the BizTalk mapper activity, but all of them install into “C:Program Files (x86)Microsoft BizTalk Server 2010Developer Tools” (on a 64-bit system) rather than the typical WCF LOB SDK path of “C:Program FilesWCF LOB Adapter SDKBin”.
  • Microsoft.ServiceModel.Channels.MapGenerator – Creates the cs or vb code for the code behind of the map.
  • Microsoft.ServiceModel.Channels.MapperActivity – WF 4 activity classes, and also includes the type selector form pop up form that generates the BizTalk schemas and default maps.
  • Microsoft.ServiceModel.Channels.MapperToolboxItem – additional packaging that basically wraps the MapperActivity but relies extensively on the VS packaging assemblies.

2. Then I started trying to build the project for the new references because I want to try to manipulate a workflow with the mapper activity already added in and/or add it to a new workflow. To help with this I opened the three assemblies above in Reflector to look at the references. Quickly we see that the MapperActivity assembly does itself rely on Microsoft.VisualStudio.Shell.Interop (v. 7.1 so this is VS 2003) as well as the BizTalk mapper compiler.

If you keep all three of the assemblies from #1 referenced then you have to also reference a couple of other VS assemblies commonly used with VS extensions (obviously the MapperActivity was not meant for use outside of VS):

  • Microsoft.VisualStudio.OLE.Interop
  • Microsoft.VisualStudio.Shell.10.0
  • Microsoft.VisualStudio.Shell.Interop.10.0
  • Microsoft.VisualStudio.Shell.Interop.9.0
  • Microsoft.VisualStudio.Shell.Interop.8.0
  • Microsoft.VisualStudio.Shell.Interop (v. 7.1)
  • System.Drawing (for basic ComponentModel extensibility)

Basically to illustrate some of these dependencies, here are the first and third assemblies in reflector with references shown:

Then here is the second one for the MapperActivity:

You can also see that the MapperActivity relies on EnvDTE (related to VS) and also ole32.dll (unmanaged code).

3. Also add reference to Microsoft.XLANGs.BaseTypes.dll for handling the BizTalk type system and some other essentials.

4. Add code for adding the Mapper activity to the constructed toolbox:

// Add the BizTalk mapper
var bizTalkcat = new ToolboxCategory(“BizTalk Activity”);
var assembliesBTS = new List();


var queryMapper = from asm in assembliesBTS
from type in asm.GetTypes()
where type.IsPublic &&
!type.IsNested &&
&& type.ContainsGenericParameters    // Only matches the Mapper activity
select new ToolboxItemWrapper(type.FullName, type.Assembly.FullName, null, “MapperActivity”);

queryMapper.ToList().ForEach(ti => bizTalkcat.Add(ti));



So after configuring the WF 4 rehost to handle managing the BizTalk mapper activity, the activity shows up in the toolbox and can be added to the workflow editing screen but cannot be effectively managed and configured. Here is a screenshot of the running host with the BizTalk activity and a workflow rehost showing the mapper activity:This is great until you try to configure the BizTalkMapClass via the Edit button on the designer surface or via the property grid and you get an error that the project cannot be found as shown below:

This is because the Mapper activity relies on the EnvDTE project that does not exist outside of VS. I will attempt to do some other workarounds for managing the mapper activity outside of VS but for now it looks like the mapper is restricted to use within VS. I welcome all comments on other approaches to making this work. Also, the code for my attempts so far may be found here: Ben’s SkyDrive public folder


SharePoint Workflow Services

I was working recently on a SharePoint Workflow project and was exploring some of the Office SDK samples. The latest Office SDK ( includes samples that were built for VS 2005 but you can convert nearly all of these over to work with VS 2008 using the .NET conversion wizard. I was exploring one of these samples and found some code that worked with IWorkflowModificationService and then realized that there are at least 4 workflow services exposed by the SharePoint workflow host. The IWorkflowModificationService (as documented at has just a single exposed method for EnableWorkflowModification(). This method performs some of the same functionality that that the activity shape Microsoft.SharePoint.Workflow.EnableWorkflowModification performs. Then I noticed that in the workflow designer in VS 2008 this activity actually has an InterfaceType which referes to IWorkflowModificationService. Interestingly, when I clicked the … on this part of the property box the object explorer filtered my referenced assemblies by ExternalDataExchangeAttribute and gave me the filtered window as seen below:
The items listed above are the four available workflow services provided with the SharePoint Workflow host. For this reason a considerable number of the built-in SharePoint activities are just wrappers that work with the workflow services. This was a very interesting find for me because it helps me to understand the way that workflow services are working under the surface the SharePoint workflow host.
While I was looking at the MSDN documentation for IWorkflowModificationService I also found there is good documentation for these other workflow services including ISharePointService, ITaskService, and IListItemService. Because these are exposed you can quickly come up with the implementation behind most of the built-in SharePoint activities.

Future of Send/Receive Ports

Today I attended a session on the Windows Workflow enhancements included with .NET 3.5. Two new WF shapes were introduced for sending messages to other workflows or WCF services. These two new shapes are the send and receive activities. Here is a link to a good article on these enhancements: In the BizTalk world, processes are defined using the orchestration designer and the send and receive parts of the process are defined on sides of the designer windows and are connected visually with lines that correspond to the send and receive activity shapes. Here is an example image which shows these lines: From a visual perspective, if you have a lot of send and receive ports, especially in scenarios where you are sending lots of messages or multiple messages from a single send shape, there can be a lot of lines all over the design surface which can get messy very quickly. In fact, the lines can become a huge distraction in designing an orchestration. In .NET 3.5 the send and receive activities use arrows to denote the messaging direction rather than using connective lines. While the connective line does provide a visual cue in the orchestration designer whether the port is setup properly, I think not having the lines is much cleaner and more manageable.
The ContextExchange class was talked about and I got a glimpse of how context properties are receivable through the Inner Channel (Context Channel) of this class. This is an important BizTalk feature I was looking for a replacement feature for. Here is a good powerpoint that describes this:
I also learned that the WF workflow instance Id is important for calling back into a long-running WCF service marked with the DurableService attribute. The thing to know is that this Guid value must be stored somewhere in a custom application because the WF infrastructure will not provide a built-in location for this. Use of this value when passed back into a method of a long-running process will activate the dehydrated (persisted) workflow instance.
Thanks for tuning in about my TechEd sessions!

Striving for MOSS ROI

Lately I have been working on a SharePoint workflow project and have been finding some good opportunities for optimizing the time-to-market and return-on-investment of SharePoint workflows. For anyone who has worked with this technology extensively, it can be difficult to transition between workflow form types such as task forms and modification forms. One goal I will be taking up in the next few days will be to build a small framework for reducing the cost involved to switch between these types of workflow form types. The primary challenge I have found is that the way that saving data to a list versus saving data in serialized form to a database is remarkably different. So to accomplish the challenge, the question would be whether to build a more loosely-coupled or tightly-coupled implementation. I will provide more details on my approach to solve this development challenge this week.

Blog at

Up ↑