First Steps with BizUnit

• Posted by Jeremy Bokobza on October 12, 2009
• 16 comments

I’ve always been afraid to use BizUnit.

It seemed like a lot of work had to be done before I could actually test anything so I never really bothered to look into it.

I was recently on a project where testing any functionality was a very very long process.

Put some files somewhere, check some emails, go to a website, check SQL tables … you know the drill.

At some point I had enough and decided to see what all the fuss about BizUnit was about.

Let me tell you that from now on, this is how I’ll do testing.

The documentation is clearly not the best in the world, so I’ve cooked a very simple example for anyone interested to start using BizUnit.

The little solution

The solution in this example is very simple:

BizTalk picks up a file from a folder location, applies a little transformation, and send the result to another location.

I could have done it without an orchestration, but I still used one for you guys to add some functionality to it if you wanted to extend the example a bit.

0. Installation of BizUnit

You can download it here and install it following the installation steps – nothing fancy here.

1. Identify the steps required for testing

After you’ve implemented and deployed your BizTalk solution and that you’re ready to test it, you need first of all to identify the steps required for testing:

• Do you need to put some files in a folder for BizTalk to pick up?
• Do you need to validate some data in those files first?
• Do you need to see if some rows got successfully inserted in some SQL tables?

Basically, write down all you need to check for your test to be declared successful.

For my little solution, I have 5 steps:

               1. Delete all the files present in the receive location

               2. Put a file in the receiving location   

               3. Wait 10 seconds – give time to Biztalk to do its business

               4. Check there is a file in the send port location     

               5. Delete the file in the send port location 

2. Create the Test Cases

A TestCase is an XML file that declares all the steps described in the section above.

It consists of 3 distinct parts:

• TestSetup – this stage is used to setup your environment (here we’ll do step 1)
• TestExecution – this stage will do the actual test (here we’ll do step 2, 3 and 4)
• TestCleanup – this stage will cleanup the environment to leave it as it was. (here we’ll do step 5). Note that this stage will execute even if the previous stages fail.

Each of these stages has 0, 1 or multiple TestSteps which represents the actual steps we described above.

The basic structure of a TestCase is like this:

<TestCase testName="Test_01">
    <TestSetup>
        <TestStep assemblyPath="" typeName="">            
        </TestStep>
        .
        .
        .
    </TestSetup>

    <TestExecution>
        <TestStep assemblyPath="" typeName="">
        </TestStep>
        .
        .
        .
    </TestExecution>

    <TestCleanup>
        <TestStep assemblyPath="" typeName="">
        </TestStep>
        .
        .
        .
    </TestCleanup>
</TestCase>

Each of the TestSteps has a typeName attribute and some parameters as element.

The typeName tells us what function to execute and the parameters are parameters of this function.

You create all the steps you need in the stages where they must be executed.

For example, to copy a file from a folder to another, the testStep will look like this:

<TestStep assemblyPath="" typeName="BizUnit.FileCreateStep">
     <SourcePath>source.xml</SourcePath>
     <CreationPath>destination.xml</CreationPath>
</TestStep>

For deleting files from a folder the function is BizUnit.FileDeleteMultipleStep, to add a delay it is BizUnit.DelayStep etc…

There are functions for almost everything.

It’s a bit of a hassle because there isn’t any structured XML so you don’t have intellisense here.

The place to go and look at if you’re looking for a method is the BizUnit.chm (located in C:\Program Files\BizUnit\BizUnit 3.1\bins).

If you’re interested in how any method operates, you should look into the BizUnit solution (located in C:\Program Files\BizUnit\BizUnit 3.1) where most of them are.

3. Create a test project (if you do tests with Visual Studio) or a class library (if you use NUnit)

Add a test project and then add a reference to the BizUnit assembly (C:\Program Files\BizUnit\BizUnit 3.1\bins\BizUnit.dll)

Then add 1 TestMethod per XML TestCase file.

We have one TestCase XML for our tests so we have only one test method.

In the TestMethod, the code to invoke BizUnit looks like this:

[TestMethod]
public void TestMethod1()
{
     BizUnit.BizUnit bizunit = new BizUnit.BizUnit(@"path\TestCase_01.xml");
     bizunit.RunTest();
}

4. Run your tests

Once you’ve done all the above, you’re ready to test.

Run your test and check that it passed.

If you click on the Test Result row, you can see the output of the tests in the Standard Console Output.

I hope this helps in starting with BizUnit.

The source code for my example is provided below.

It includes everything you need for our example : the BizTalk project, the test project, the TestCase, the binding file (for the ports) and the test file and folders.

GACing made easy.

• Posted by Jeremy Bokobza on August 28, 2008
• 16 comments

As a BizTalk developer, you need to GAC, GAC and GAC again, over and over.

Oh, GAC stands for Global Assembly Cache (but everyone that reads this article knows that, right?), and "to GAC" means to put an assembly in the GAC.

So as I said, this action of GACing is repeated many times during development and, let's be honest, it's a pain.

The reasons why GAC is good for you are multiple:

- it gives you the ability to use the same assembly for multiple applications (hence its name)

- you can have multiple versions of the same assembly deployed thus allowing side-by-side execution.

To GAC, someone that just starts using BizTalk usually clicks on the project, copies the path of the project folder, open Run, copy the path, go to the bin folder, open the GAC folder (Run --> assembly) and drag the compiled assembly to the GAC.

Copy-Paste does not work, an assembly is added/updated to the GAC only by dragging.

And you have to do that every time you want to run your application using the latest version of either a BizTalk assembly or an assembly BizTalk uses. 

And that's really annoying, don't you think/know?

There are ways to do it just painless, one click or two at most.

By the way, on a development machine it's not so important, but believe me when you need to apply a single patch to a production environment, it is essential you backup, just in case you made a mistake and need to rollback.

So first, let's see how you can backup the assembly stored in your GAC.

Type C:\WINDOWS\assembly\GAC_MSIL or C:\WINDOWS\assembly\gac (gac in lowercase) in Run and you have all the folders with your assemblies in them.

Backup and now you can GAC.

Now, as I said, there are a few ways to GAC an assembly much faster than described above.

There are 3 solutions I know of, it's up to you to use the one that suits you most.

• First you can add a registry entry that will allows you to right-click on the assembly and GAC it.

  To do this, you create a file called for example addToGAC.reg, edit it and copy the following:

  [HKEY_CLASSES_ROOT\dllfile\shell\Add to GAC\command]
  @="\" C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\Bin\\gacutil.exe\" /i \"%1\""

  Now if you right click the assembly, you'll see the "Add to GAC" option and this will add the assembly to the GAC.

You won't have to drag anymore, which is already two steps less, but you can do better.

Here's how:

• In VS, go to Tools -> External Tools, click on Add, and enter a

     - title, for example "GAC assembly"

     - command  : c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe

     - argument: /i $(TargetPath)

     - initial directory: $(TargetDir)

       and apply.

   

    

  When you build a project and you want to add the assembly to the GAC, just have the project highlighted, and click Tools --> GAC assembly and that's it, it's GACed. Of course you have to do this step once in your environment and that's it.

No more bin and development opened folders by the dozen.

Even better than the previous solution, right?

• Alternatively, you can also have a post-build event that will  automatically GAC the assembly after a build, but be cautious because sometimes you want to build but don't want to install to the GAC automatically so this option can get pretty annoying.

  If you're interested though here's how you do:

  • For a BizTalk assembly, just set to true the option "install to global assembly cache" in the BizTalk project properties.

    This will install the assembly to the GAC only after deployment, not build.

    Here you're better off with the previous option.

  • For a .NET assembly, go to properties of the project, go to Build Events and in the Post-build event command line, copy this:

    "$(DevEnvDir)..\..\SDK\v2.0\Bin\GacUtil.exe" /i "$(TargetPath)" /f

    When you build, the assembly will be GACed automatically.

That's all.

Well, happy easy GACing!

Enabling Message Properties Filter in HAT

• Posted by Jeremy Bokobza on July 30, 2008
• 5 comments

First you enable tracking on Messages Bodies and Properties in the port .

Then, in the BTS admin you double-click on the schema that has the promoted property and you enable tracking there.

Finally you can go to the HAT and will find your property filter there.

Shortcuts for the BizTalk orchestration Editor

• Posted by Jeremy Bokobza on July 26, 2008
• 39 comments

Something I've noticed while working on an orchestration:

To add a shape, you can either right-click on a Shape connector line or use the BizTalk Orchestration Toolbox.

It can be quite frustrating sometimes when you use the first way because the shapes are not in alphabetical order so you have to read them all in order to get what you want.

If you right click on the shape connector line, show the choice of shapes and press one of the key below, the corresponding shape will appear.

Not such a big deal, but still useful.

W: Throw Exception

E: Send

T: Start Orchestration

Y: Delay

U: Construct Message

I: Decide

O: Loop

P: Parallel

A: Terminate

S: Scope

D: Suspend

F: Transform

G: Group

L: Listen

X: Expression

C: Call Orchestration

V: Receive

M: Message Assignment

 R: Call Rules (works only in atomic scopes…)

 N: Compensate (provided you're in a compensation block)

Weird Error in orchestration

• Posted by Jeremy Bokobza on July 26, 2008
• 13 comments

Sometimes, even though the orchestration does not show any error , when you build your project, you get a lot of them and when double-clicking the error it shows you something perfectly normal.

You can close VS ten times but it doesn't help…

This thing drove me crazy for a while until I knew what to do.

What do you do then?

Well, you know the orchestration is formed of 2 parts, right?

One is XML of type <om:MetaModel  xmlns:om="http://schemas.microsoft.com/BizTalk/2003/DesignerData"/> and the other is in X# (or Xlang if you want).

If you look at the Xlang part, you'll see that your error is showing there instead of the relevant piece of code.  However, in the XML, the code appears and not the error.

The conclusion is that it's the XML part that builds the Xlang part and not the opposite.

Great! Now what?

Edit the orchestration, get rid of the second one (basically everything below the #endif // __DESIGNER_DATA line), when rebuilding the project, it will behave as normal - showing no errors (provided that you really don't have any error there).

Now if after building you open your orchestration with the XMLEditor (right click -> open with -> XMLEditor), you'll see that the Xlang part has not been generated...

The thing is that the X# won't be generated unless you change something in the orchestration.

Just open any shape like an expression shape and add a random space anywhere and that will do the trick.

Edit again and you'll see the X#.