13 May

BizTalk, WIF, WF Tutorial – Part 2.3b Message content based routing – orchestration – configuration

In Part 2.3a we have created a simple orchestration reflecting the following business process.

BizTalk, WIF, WF Tutorial - Part 2.3b - Mail Filtering Business Process

We finished on clicking F6 and building the orchestration corresponding Mail Filtering business process. When any of the readers tried to click the small “play” button may have experience following errors.

BizTalk, WIF, WF Tutorial - Part 2.3b - Unsigned Assemply Errors

The solution to the problem is fairly simple. We just have to create a new key to sign both assemblies. We start from signing Orchestrations. Right-click on Orchestrations project and choose Properties.

BizTalk, WIF, WF Tutorial - Part 2.3b - Visual Studio project properties

Once in Properties window, we switch to Signing section. Where we choose Sign the assembly and create a new key.

BizTalk, WIF, WF Tutorial - Part 2.3b - Signing an assembly - Creating a key

In the pop-up window we choose to name our key MusialTkKey and we type the standard password: P@ssw0rd.

BizTalk, WIF, WF Tutorial - Part 2.3b - Signing an assembly - Password & Key name

We finish by clicking OK. We need to save the changes we have just made to project’s properties, so let’s click Ctrl+S. Now once the Orchestrations project is built, it will be signed using the configured key.

We should do exactly the same with Schemas project. The small difference if of course, that we will use Browse to find the already existing MusialTkKey.

When everything is done, we build both projects once again (Right-click on the Solution and Rebuild Solution). That’s all folks! Let’s do dome configuration. We launch BizTalk Server Administration Console. We then expand Applications and check if our MusialTk application contains already any orchestrations. As expected there are no orchestrations yet.

BizTalk, WIF, WF Tutorial - Part 2.3b - Orchestrations

There are many available ways to install BizTalk Application in BizTalk, but the one I found very useful and which has already been proven by me several times is using Resources group.

BizTalk, WIF, WF Tutorial - Part 2.3b - BizTalk Server Administration Console - Resources

No surprise, there are no resources yet. Let’s add both our projects starting from Schemas and Orchestrations. Right-click in the empty Resources window and then Add -> BizTalk Assemblies…

BizTalk, WIF, WF Tutorial - Part 2.3b - Adding Resources

In the new window we choose Add

BizTalk, WIF, WF Tutorial - Part 2.3b - Add Resources Window

We are then asked to select Assemblies which we want to add to the BizTalk Application.

BizTalk, WIF, WF Tutorial - Part 2.3b - Selecting Resource Files

There are actually two dll’s we should add:

  • Schemas.dll : Schemas/bin/Release/Schemas.dll,
  • Orchestrations.dll : Orchestrations/bin/Release/Orchestrations.dll.

Add Resources window should now look like below.

BizTalk, WIF, WF Tutorial - Part 2.3b - Add Resources Window

Important: both dlls should have exactly the same Options tab settings, that is all checkboxes have to be selected. We confirm newly added resources by clicking OK. In the Resources perspective both our dlls are to be seen. Let’s switch to the Orchestrations view to check, whether any orchestration appeared or not.

BizTalk, WIF, WF Tutorial - Part 2.3b - Unenlisted Orchestration

Exactly as we have expected. There is already one orchestration named Orchestrations.MailFiltering but it’s current state is Unenlisted (unbound) which means that no ports have been assigned yet. Right-click on Orchestrations.MailFiltering and then Properties.

BizTalk, WIF, WF Tutorial - Part 2.3b - Orchestration's Properties

In the newly opened window, let’s switch to Bindngs.

BizTalk, WIF, WF Tutorial - Part 2.3b - Orchestration's Bindings

We first select our host BizTalkServerApplication.

And now a small trick: we choose already existing IN-FolderReceivePort and for both outputs OUT-Folder-SendPort. This way we achieve exactly the same scenario as in the former Part. All messages, despite name will be forwarded to OUT-Folder.

But in order for our trick to work as expected, we have to clear the Filters on OUT-Folder-SendPort.

BizTalk, WIF, WF Tutorial - Part 2.3b - Send Port - Clearing Filters

Now the orchestration is bound but not yet started and enlisted. If we now try to drop a file into IN-Folder we would become an error saying that there are no subscribers. Which is exactly what we expect. Clearing Filters removed this subscription.

We go back to Orchestrations, right-click on Orchestrations.MailFiltering and then Start.

BizTalk, WIF, WF Tutorial - Part 2.3b - Started Orchestration

Let’s try to drop the two following XML files into IN-Folder.

BizTalk, WIF, WF Tutorial - Part 2.3b - Test XML Files

Files disappeared but… No files in OUT-Folder.

We go back to BizTalk Server Administration Console, select BizTalk Group node and click F5. There are actually two Suspended Service Instances which means that something wrong happened and now IN-ReceivePort and MailFiltering orchestration are suspended.

BizTalk, WIF, WF Tutorial - Part 2.3b - BizTalk Server Administration Console - Suspended Instances

Let’s click on the link Group by Application.

BizTalk, WIF, WF Tutorial - Part 2.3b - Errors grouped by Application

When we double click the one with Service Class = Messaging, we can see the following error information.

BizTalk, WIF, WF Tutorial - Part 2.3b - Routing Error Details

Pretty straightforward. No subscribers, which means that no one waits for our message. Question is: where lays the problem.

Receive Pipeline

This term is the answer. Our IN-FolderReceiveLocation used to work with all the files which means we selected PassThruReceivePipeline. When we do so, messages are not interpreted and no properties are promoted which completely disables routing based on the message type as a type comes from the content.

We go to IN-FolderReceiveLocation, right-click and select Properties.

BizTalk, WIF, WF Tutorial - Part 2.3b - In-Folder-ReceiveLocation - PassThruReceive Pipeline

All we need to do is to select XMLReceive.

BizTalk, WIF, WF Tutorial - Part 2.3b - IN-Folder-ReveiceLocation - XMLReceive Pipeline

Confirm clicking OK and we now can test if everything works. But before we do so, let’s go back to the group view and right click on MusialTk results and then Terminate instances. Finally confirm that you’re determined to do so.

BizTalk, WIF, WF Tutorial - Part 2.3b - Terminating Suspended Instances

Now when we click F5 on BizTalk Group we should see no suspended instances.

BizTalk, WIF, WF Tutorial - Part 2.3b - BizTalk Group View with NO Terminated Instances

Let’s drop both Amy.xml and Tom.xml into IN-Folder. Disappeared! Ha!

Now let’s check OUT-Folder. HA! Two new files!

BizTalk, WIF, WF Tutorial - Part 2.3b - OUT-Folder with Results

It works! Amazing, huh?

But we should now choose to save Tom’s messages other than the ones addressed to the others. Let’s clear OUT-Folder before proceeding. Now we go back to the MusialTk application in BizTalk Server Administration Console. Let’s review Send Ports. For now we have exactly one. Let’s rename it to OUT-Folder-Tom-SendPort.

BizTalk, WIF, WF Tutorial - Part 2.3b - Configuring TOM's Port

There’s actually a small thing to do. Let’s mark Tom’s messages with a prefix. In order to do so, click Configure… and type Tom_%MessageID%.xml in File name field.

BizTalk, WIF, WF Tutorial - Part 2.3b - Tom's prefixed FILE adapter

Now OK & OK and we’re done. If we now try once again to drop both XMLs we would get the same result, but both files would be marked Tom_*. This is not what we expect, and above all, how our business process looks like. As there are two outputs from the orchestration we should create another Send Port to handle Other’s messages.

We create a new port by right-clicking on the empty surface and selecting New -> Static one-way Send Port. We have already done that in the past, so you could check in previous parts of my tutorial. This time we name the port OUT-Folder-Other-SendPort and configure FILE adapter to prefix it’s messages with Other_*.

BizTalk, WIF, WF Tutorial - Part 2.3b - OTHER's Send Port

Once created, we right-click and choose Start.

Now we are almost ready to test. The last thing to do is to right-click on Orchestrations.MailFiltering, choose Properties and then map OtherMessagesOneWayPort to the newly created OUT-Folder-Other-SendPort.

BizTalk, WIF, WF Tutorial - Part 2.3b - Mail Filtering Orchestration with two diferent Send Ports

We confirm the changes clicking OK.

BizTalk, WIF, WF Tutorial - Part 2.3b - Orchestration changes blocked - Error

Surprise. We cannot change an already enlisted orchestration. We simply click Cancel and in the Orchestrations right-click on Orchestrations.MailFiltering we chose Unenlist. Now we go back to Properties and without any problems save a new configuration with Other Send Port. After configuration is altered we right-click and choose to Start the orchestration.

Testing

Let’s drop both XMLs into IN-Folder. Disappeared. Let’s switch to OUT-Folder and YEAH! There are two files with different prefixes.

BizTalk, WIF, WF Tutorial - Part 2.3b - Final Results

BizTalk did exactly what we wanted him to.

We succeeded once again in our BizTalk experience. This time we modeled a business process from the very beginning till the very end. Careful reader notices that as we already have a working orchestration, creating new Receive and Send Ports using completely different adapters is easy and only a matter of configuration and not implementation.

There’s even more to come.

Leave a Reply