Testing the unzipcomponent sample

Recently, some people have requested a usage example of the UnzipComponent pipeline component example posted here. I've create a sample solution, containing the UnZipComponent itself and a BizTalk project consisting of a simple receive pipeline witht the UnZipComponent in it.

The UnZipComponent uses a build action to copy itself to "C:\Program Files\Microsoft BizTalk Server 2004\Pipeline Components", so if you have installed BizTalk Server 2004 somewhere else, please alter the location by right-clicking the project, choosing "Build Events", navigating to "Post-build Event Commmand Line" and pressing the three dots button on the right.

A binding file has been included which you can import with the BizTalk Deployment Wizard or from the command-line using "btsdeploy.exe" from the BizTalk Server 2004 installation folder.

The binding file contains folder references, which probably don't match your testbed setup. Alter them after importing them by using BizTalk Explorer (whichever version :p)

The sample project does nothing other than decompressing the inbound zipfile and submitting 1 message for each file within the zipfile. I've included a file called "test.zip", which contains 2 simple XML files consisting of very interesting data, which will be put into the output folder configured. Nothing else.

UPDATED: NEW DOWNLOAD LOCATION

The sample project can be found here. (Don't forget to alter the AssemblyInfo.cs and project properties of the BizTalk project to refer to your own strong name key file.)

Please remember that the btsntsvc.exe process (the BizTalk service) locks the pipeline component when in use. So if you alter anything, stop the service, compile and start the service, otherwise the post-built event will fail)

One more thing... Pipeline components should normally not be within the same solution as the projects that use these components, as the components get loaded by the pipeline designer and locked, so compilation would become rather hard...

Hope you enjoy this!

Exporting bindings

As there have been numerous requests by e-mail for this, I'll explain the ways of exporting binding information from the BizTalk Management database.

Binding files define the connection between components within the BizTalk environment, they define send/receive ports, groups, orchestrations properties, etc.

To export binding information, you have some options:

1. Use the BizTalk Deployment Wizard from the Microsoft Biztalk Server 2004 start menu and follow the steps (choose "Export BizTalk assembly binding file, choose the server, choose the appropriate assembly, the location of the exported binding and press Finish)


2. Utilize the command-line application "btsdeploy", located within the BizTalk Server 2004 installation folder, e.g.:
   

   C:\Program Files\Microsoft BizTalk Server 2004>btsdeploy export name="UnzipSampleProject" version="1.0.0.0" culture="neutral" publickeytoken="8321b1fe6c55c81a" binding="unzipsampleproject.xml"



3. Use BizTalk Explorer (my version), found here. Right-click the assembly you'd like bindings to be exported for, choose a folder to export to. The binding files will be named after the assembly and postfixed with "_export" and ".log".

BizTalk Explorer v1.1

I've updated my BizTalk Explorer. You can download it here. New in this release:

• Deployment, easily add your BizTalk assemblies to multiple servers at once
• Altered the "browse for BizTalk database" dialog
• Numerous bugfixes (thanks for the feedback!)

Hope you like it, let me know!
If you encounter a diagnostics screen on startup, remove the config file from %userprofile%\local Settings\Application Data (BizTalkExplorer.config)

Pipeline Component Wizard v1.32

Small update. Thanks to feedback from Aman, I discovered that SchemaWithNone and SchemaList were not functioning correctly. I fixed the issue for SchemaWithNone, it works fine now. However, for SchemaList, you need some functionality to store the selected schemas within the PropertyBag as a string, and the CodeDOM I was working on didn't quite cut it, so I decided to let it up to you to implement a simple StringBuilder to store the selected Schemas from the SchemaList.

version 1.32 can be downloaded here

BizTalk Explorer v1.0

OK, so having a lot of clients asking me for a BizTalk Explorer UI without the need to install Visual Studio .NET 2003, I've (re)written BizTalk Explorer outside. It has support for:

• Undeployment of assemblies, including removing any binding information for pipelines, mappings, etc.


• Exporting bindings posed by Assemblies


• Binding, (un)enlisting, starting, stopping and killing Orchestration(s) (instances)


• Adding, removing and configuring Parties


• Adding, removing, (un)enlisting, starting, stopping and configuring Send Port Groups, including send ports which belongs to those groups


• Adding, removing, (un)enlisting, starting, stopping and configuring Send Ports, including filter expressions (including promoted properties for your own documents), and inbound/outbound mappings


• Adding, removing, and configuring Receive Ports, again including filters and maps


• Adding, removing, enabling, disabling and configuring Receive Locations

For now, expect and please report bugs, as it's an initial release. More features to come, feel free to request any! I hope to make this utility BizTalk Explorer on steroids...

The sourcecode will be made available soon, but I've got some more work to do before I think it's stable and elegant (and documented?) enough to release to the general public.

Please let me know what you think. I've spend a great deal of time on this application and would love feedback, including bugs, flames, comments, suggestions, the works!

You can download the application here

O, by the way, while I was working on this application, I got in contact with a great guy, which has also released a utility that matches mine. His name is Paul Somers, and he has won (congrats!) the BizTalk Server competition (Next time, gadget, next time!) (Scott, please adjust the Dutch gaming laws, so we can join the competition next time around...:-p). Check out his version of the tool here

Hope you enjoy!

Using the Pipeline Component Wizard

Lately, I've been getting lots of e-mail from people asking me how, after installing the Pipeline Component Wizard, they can actually use it. To do so:

• Open up Visual Studio .NET 2003


• Press CTRL+SHIFT+N to create a new Project


• The New Project dialog appears, containing a tree to the left of the screen, called "Project Types".


• In the project types tree, choose "BizTalk Projects"


• In the templates screen, on the right of the dialog, the available BizTalk templates appear.


• Within the templates screen, choose "BizTalk Server Pipeline Component Project"


• Type a name and location for your new project, and press OK


• The wizard will appear, follow the screens and choose your options for the new Pipeline Component you're about to build.


• After finishing the wizard, it will generate the solution, project files, resources, assemblyinfo and code for the options you selected within the configuration pages of the wizard.

You're done, now a fully functional pipeline component according to your specifications has come to life, implement the code you'd like the component to perform, compile it, etc.

Property editors & pipeline components

There have been a lot of questions in the newsgroups recently regarding custom type editors within pipeline components.

I've created a sample component in which you choose which database you'd like to connect to and subsequently choose a customer the pipeline component is specific to. These kind of properties could be used to perform customer specific actions within a pipeline component.

Currently, the component implements a UITypeEditor derivement to implement it's editing functionality for choosing a customer. It uses the NorthWind database within the choosen server, and has very little error checking to see whether or not the DBMS exists, etc.

However, it demonstrates the purpose of custom editors for your properties, besides the obvious SchemaWithNone and SchemaList which are already supplied within Microsoft.BizTalk.Component.Utilities.dll and within my Pipeline Component Wizard.

Now for a screenshot, as it usually clarifies a lot (I've removed a portion of the connection string configured):



The component can be downloaded here

Please note this:

1) As BizTalk uses a component called ComponentObjectWrapper to wrap the actual object being handled within the pipeline component editor, and you simply cannot reference Microsoft.BizTalk.PipelineEditor.dll in a decent way without breaking Visual Studio integration with BizTalk, I've applied a "dirty" reflection hack in which I at runtime retrieve the actually instantiated component from this object using reflection, like this:

BindingFlags bindingFlags = BindingFlags.NonPublic | BindingFlags.Instance;
Type t = context.Instance.GetType();
FieldInfo fi = t.GetField("cachedPipelineComponent", bindingFlags);
CustomerSpecificComponent instance = fi.GetValue(context.Instance) as CustomerSpecificComponent;

 

It's a dirty way to get to the object, but it means I don't have to reference any other components and currently seems to be the only way to achieve reading another property from our design-time component.

2) The project has a build event specified which should deploy the component to the GAC. If it doesn't work, please alter it to represent the location of your gacutil installation.

As always, all sourcecode is included, and comments are very welcome!

Scripting functoids

Ever wondered how the scripting functoid generates the code to perform what you have put into the buffer, how the checking for validity is done and the methods you define are published?

In reality, Microsoft.BizTalk.BaseFunctoids.InlineScriptCompiler compiles all scripting functoids to the target language. It generates an assembly by using CodeDOM and ICodeCompiler services, in about the same way as outlined in e.g. KB Q304655.

Let's say we have implemented an inline script functoid which defines a C# method like this one:

public string MyConcat(string param1, string param2)
{
   return param1 + param2;
}

The InlineScriptCompiler would generate an assembly like this:

using System;
namespace BizTalkMapper
{
   public class FunctoidInlineScripts {
      public string MyConcat(string param1, string param2)
      {
         return param1 + param2;
      }
}

Considering the above, I would argue that combining your logic into one external assembly would be better for a lot of reasons, including code re-use, documentation purposes (try using NDoc on inline script functoids :-p), functional grouping, the ability to use resources, external assemblies, etc.

Just my 2 cents...