1. Problem
You have deployed a solution and need to validate that your send ports are enlisted and started.
2. Solution
An important step in the
deployment of a BizTalk solution is to enlist and start send port
messaging artifacts. You can do this from the BizTalk Administration
Console, either in isolation or as part of a larger application
deployment.
NOTE
An important
prerequisite to enlisting and starting a send port involves configuring
the send port to subscribe to BizTalk messages, either via setting a
filter on a send port or by binding a send port to a BizTalk
orchestration artifact. In both of these instances, a send port has
subscription criteria identifying which messages it will consume from
BizTalk.
The following steps outline the procedure for starting and enlisting send ports using the BizTalk Administration Console.
Open the BizTalk Administration Console.
In the left pane, navigate through BizTalk Server Administration to your BizTalk group, expand the Applications folder where your send port resides, and select the Send Ports node.
Right-click your send port(s), and select Enlist, as shown in Figure 1. The send port(s) will move from the unenlisted to the stopped state.
Right-click your send port(s) again, and select Start. Your send port(s) should now be started and enlisted.
3. How It Works
In this recipe's
solution, we demonstrated how to enlist and start send ports via the
BizTalk Administration Console. Enlisting and starting are two mutually
exclusive states on a send port. Enlistment sets up the port and ensures
that it is recognized and properly bound. Starting the port has it
begin listening for the trigger that will cause it to execute. These are
two logical mandatory steps to enable a BizTalk solution to be
deployed.
NOTE
In this example, we
demonstrated the explicit steps of enlisting and starting for
demonstration purposes only. A send port can also be explicitly started
from an unenlisted state.
Enlisting a port enables a
subscription in the BizTalk MessageBox. If a send port is not enlisted, a
message published to the MessageBox will not be subscribed to by the
send port. If a subscriber is not found (the message had only the send
port as the intended subscriber), a BizTalk error would be thrown,
indicating that a matching subscription could not be found, and the
message instance would be suspended but resumable in the MessageBox. (In
previous versions of the product, this would have caused the message
instance to be suspended but not resumable.)
If a message is published to the
BizTalk MessageBox and a send port is not started, the message instance
will sit in the MessageBox, waiting for the subscribing send port to be
started. This situation is often hard to troubleshoot, as no error is
thrown during the message submission process (an administrator would
need to proactively look at what processes have been suspended using the
Group Hub page).
In addition to
administering send ports via the product tool set, BizTalk also has an
object model available to allow programmatic administration via Windows
Management Instrumentation (WMI). Send port administration is accessible
via the base class Microsoft.BizTalk.ExplorerOM.SendPort. Within this class, a send port has a variety of methods available (for example, ChangeSendPortStatus()). Refer to the BizTalk product documentation for an inclusive list.
