In Part 2.3a we have created a simple orchestration reflecting the following 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.

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.

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

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

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.

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.

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…

In the new window we choose Add…

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

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.

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.

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.

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

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.

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.

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

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.

Let’s click on the link Group by Application.

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

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 propertiesare 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.

All we need to do is to select XMLReceive.

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.

Now when we click F5 on BizTalk Group we should see no suspended 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!

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.

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.

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_*.

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.

We confirm the changes clicking OK.

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 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.