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: http://seroter.wordpress.com/2010/05/24/using-the-new-biztalk-mapper-shape-in-a-windows-workflow-service/.
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 http://msmvps.com/blogs/theproblemsolver/archive/2009/12/23/rehosting-the-workflow-designer-in-wf4.aspx. 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.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.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