Hi all

Disclaimer: I do NOT encourage the usage of he information in this blog post.
The post is merely about some silly experiment, he results thereof and a conclusion
on it.

So, this friend
of mine
(and former colleague) mentions every now and then that he isn’t all that
sure that the “No subscribers found” should be an error but maybe more a warning.
His man argument is, that if I have two subscribers for something, say all incoming
orders are put into an archive file drop and also sent to the ERP system, and the
send port that sends to the ERP system is unenlisted, then no errors will occur in
BizTalk, but from a business point of view, the system is definitely not working.
So the fact that you don’t get the error that indicates something is wrong with routing
is not actually very useful, because parts of the system may be down after all.

Anyway, we were discussing what to do about this in case you just don’t want that
error to occur if no subscribers were found. We came up with two options:

  1. Add a send port that uses Tomas Restrepos /dev/null adapter. you can find it at http://winterdom.com/dev/bts/index.html
    look for “BizTalk 2006 R2 Null Send
    Adapter
    ”. Using this adapter in the send port will cause everything going through
    the port to magically disappear.
  2. Mostly for fun we came up with the idea to have an orchestration that only as one
    receive shape. This receive shape should receive a message of type System.Xml.XmlDocument
    – since this will let the orchestration receive any message types. Also, it would
    have to be a direct bound port, so the orhestration would get ALL messages that are
    published to the MessageBox, so we would never get the “No subscribers found” error.
    Now, naturally, this solution is extremely silly, since we would fire up an orchestration
    for all published messages. But we started thinking what the subscription would look
    like.

The rest of this post is to explore item 2 above to find out how the subscription
would look like.

To do this, I created four scenarios – just to explain it to you.

The four scenarios are:

  1. An orchestration that receives a message of type ReceiveSchema.xsd and is linked to
    a “Specify Later” port. This is the normal and widely used scenario.
  2. An orchestration that receives a message of type System.Xml.XmlDocument from a “Specify
    Later” port. The common way of receiving binary files or any file without caring about
    what files they are.
  3. An orchestration that receives a message of type ReceiveSchema.xsd and is linked to
    a direct bound port. This is the common way to receive ALL published orders, no matter
    what receive port or orchestration they were published from.
  4. An orchestration that received a message of type System.Xml.XmlDocument and is linked
    to a direct bound port. This is not something I have ever seen used, but this is what
    I want to find out about 🙂

So, to summon up the subscriptions:

Scenario Subsription Description
1

http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID ==
{C464C9C6-F4BB-4ADF-9322-B2E89E6C8885}  And

http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType ==
http://ReceiveEverything.ReceiveSchema#ReceiveSchemaRoot

This is the most common subscription. It consists of both a ReceivePortID (Because
the logical port is bound to a physical port) and the message type (Because I am using
a strongly typed message).
2 http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID ==
{C464C9C6-F4BB-4ADF-9322-B2E89E6C8885}
This subscription is partly like the first one. The ReceivePortID part is the same,
but no message type is specified. This is because I am using System.Xml.XmlDocument
as message type, and this is just a “catch all” message type.
3 http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType ==
http://ReceiveEverything.ReceiveSchema#ReceiveSchemaRoot
This subscription has the part of the first subscription that was missing from the
second one and it doesn’t have the part that was actually in the second subscription.
This is because I am now using a direct bound port, and therefore the port ID becomes
irrelevant in the subscription. I am using a strongly typed message, though, so the
message type is relevant.
4   Surprised? A completely empty subscription. Kind of makes sense, when you think about
it, since we are using a direct port, so the port ID is irrelevant and we are using
a untyped message, making the message type irrelevant.

Now then As I wrote, it makes sense, but it wasn’t what I was expecting, actually.
With this empty subscription, I STILL get the “No subscribers found” error when I
pick up a message and publish it into the Message Box.

So instead of doing this, I started thinking about what else to do. So I created a
receive port with a receive location and let a message go through it and get suspended.
Looking at the details of the context of the message that was suspended I gor this:

ReceiveLocationSuspended

So I need a subscription that is not empty, but that will make sure my orchestration
gets EVERYTING that is published into the MessageBox. This is done by setting the
filter on he receive shape of my orchestration in scenario 4. The filter will have
to include one of he above properties that is promoted. But looking at them I really
don’t expect a message created inside an orchestration and then sent to the messagebox
to have any of those properties set. So I decided to create a small orchestration
that will simply just send a message to the messagebox. The context of the message
published to the MesageBox looks like this:

OrchesrationSuspended

As you can see, no overlap at all.

So, as I see it, a filter like “BTS.ReceivePortID exists OR BTS.Operation exists”
should do the trick. Now, this subscription works in my small example, but I cannot
guarantee it will work for all scenarios. I can’t think of an example right now where
either the ReceivePortID or the Operation doesn’t exist, but there might be examples.

So Basically, the whole idea about having an orchestration taking in ALL published
messages to avoid errors about no subscribers is REALLY silly and should not be implemented.
And if you choose to do it anyway, please remember that the above filter isn’t guaranteed
to work in all scenarios I was just playing around 🙂

Not sure this will ever help anyone but there goes 🙂



eliasen