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:

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:

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:

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