Re: HELP: BizTalk 2004 Direct Port to Message Box - Delivered not consumed
- From: "Dave" <dmartret@xxxxxxxxxxxxxx>
- Date: 5 Jun 2021 00:00:00 -0700
OK - here is the answer - after much research:
Have to tighten up the filter expression - because once i subscribe to
it, then dump it to the folder (file drop) this also goes VIA the
message box .. therefore setting up an infinite loop.
Message Box Direct Bound Ports
Message box direct bound ports, as its name implies, allows you to drop
messages directly into the message box without an explicit recipient
and it allows you to subscribe to messages, not from any particular
sender, which meet certain criteria. To configure a message box direct
bound port set the 'Partner Orchestration Port' property to
Sending a message on a message box direct bound port is equivalent to
publishing the message to a message bus, in this case the message box.
For any published message there can be any number of subscribers for
that message. If there are no subscribers interested in the message at
the time you publish it a persistence exception is thrown.
Sometimes when sending a message through a message box direct bound
port you may have an implicit recipient in mind and will set properties
to particular values that you know a subscriber(s) is looking for and
is therefore used as a method for loose-coupling.
Recipients of the message can be any type of service that can subscribe
to messages which include orchestrations and send ports.
Receiving a message through a message box direct bound port is
equivalent to subscribing to a message bus with filter criteria. For
an activating receive shape the subscription will be the message type
and the filter and for non-activating receive shapes the subscription
will be the message type and the correlation set.
Every receive shape always includes the message type as part of its
If you don't add any filter criteria to the activating receive shape
connected to a message box direct bound port then the subscription will
Which can be read as, "Give me every message whose message-type is
MyMessageType". This is what differentiates a send port subscription
from an orchestration subscription. A send port subscription, if you
don't provide it with a filter, will only handle messages sent
directly to it via a bound (specify-now or specify-later) logical
orchestration port (i.e. the subscription for a send port includes its
send port id as a clause OR'ed with it's filter). A message box
direct bound receive port that does not have a filter explicitly added
will receive every message that matches the message type that the
port's operation is configured for. Note: If the message-type is
XmlDocument then this is a type-agnostic port and in this case the
subscription will be empty and not match any incoming message.
When using message box direct bound receive ports be careful to make
the filter as specific as possible. I typically caution developers to
only use receive message box direct bound ports only when it is
absolutely necessary or the benefits (e.g. loose-coupling) out-weigh
the risks, as many developers make the mistake of not making their
filter distinguishing enough. The side effect of not having a
distinguishing enough filter is that the orchestration can receive
messages it didn't intend to.
An example of a mistake that is commonly made is the following; an
activating receive shape with a filter using some custom property
followed sometime later by a send shape sending the same message to a
send port physically bound to an endpoint. In this case the developer
assumes that since the logical send port is bound to a physical send
port then only that physical send port will get the message. This is
not the case. What will happen is that after the first message is
published to the message box an infinite number of orchestrations will
be activated. This will happen because the message being sent to the
send port endpoint is published to the message box and, because every
time a message is sent to the message box all subscriptions are checked
for a match, the activation filter of the orchestration will match the
message and a new orchestration instance will be started. If the
orchestration is more complex and/or if the receive is using a
correlation set as its subscription then the difficulty of trying to
debug a similar scenario increases dramatically.
- Prev by Date: create Receive port dynamically
- Next by Date: problem to process an XML
- Previous by thread: Re: BizTalk 2004 Direct Port to Message Box - Delivered not consumed
- Next by thread: Invoking an orchestration from Web Application