1. Problem
You want BizTalk Server to send the same message to multiple downstream systems for further processing.
2. Solution
To demonstrate how to send a
message to multiple systems, we will use the example of sending data to
an enterprise resource planning (ERP) system. Suppose that you have an
orchestration that sends sales order information to your company's ERP
system. The business requires sales order information to be available to
other departments in your company that do not have access to the ERP
system. The business would like to see the data available via the
internal data warehouse. Additionally, the business requires minimal
downtime for the existing deployed solution due to the need to process
orders 24 hours a day, 7 days a week.
The solution is to create a
send port to the data warehouse and create a send port group that will
manage sending messages from the orchestration to the existing ERP send
port as well as the new data warehouse send port. This recipe assumes
that the orchestration already exists.
To create the new send port group, in the BizTalk Administration Console, right-click Send Port Groups, and select New => Send Port Group.
In the Send Port Group Properties dialog box, add one or more existing send ports, as shown in Figure 1.
Update the send port binding of the deployed orchestration, and choose the send port group, as shown in Figure 2.
Verify the send port group and referenced send ports are enlisted and started before testing the updated orchestration binding.
3. How It Works
Send port groups are
collections of send ports through which BizTalk Server can publish the
same message to multiple destinations using a single configuration. Send
port groups are similar to send ports in their ability to be bound to
orchestrations, as well as be implemented in pure messaging scenarios
(via filter subscriptions).
Send ports that are included in a send port group process messages in two ways:
Send port groups are
incredibly useful in the situations where multiple parties are
subscribing to the same message using different messaging protocols or
different message formats. For example, one subscriber could receive an
XML version of a message, and a separate subscriber could receive a flat
file version of that same message, without extra coding or changes to
the orchestration that produced the message. Another good use for a send
port group is to keep backup files of the transactions sent from
BizTalk to external subscribers. Without changing the existing
orchestration and with little effort, you can implement a new send port
and send port group that creates a backup of the existing message.
Send ports that are
included in a send port group operate differently from send ports
operating independently. Keep the following considerations in mind when
using send port groups:
Filters:
Filters on send port groups do not override filters on individual send
ports. Filters used on both send ports and a send port group operate in a
cumulative nature. If the same filter is used on a send port group as
well as the individual send ports within the group, it is likely that
duplicate messages will be sent. Special care must be given if filters
are implemented on both send ports and send port groups.
One-way static ports:
Send port groups can use only static one-way send ports. The strength
of send port groups is the ability to send the same message to multiple
subscribers. However, one limitation of send port groups is that they
can include only static one-way send ports.
Operating states:
The operating state between send ports and send port groups is in
dependent. The states between send ports and send port groups are
identical:
Bound: The send port or send port group has been physically linked to an orchestration.
Enlisted: The send port or send port group has been associated with the message to which it will be subscribing from the MessageBox.
Started: The send port or send port group is ready to process messages matching the appropriate message subscription.
Enlisted ports:
You must verify that both send ports and their parent send port groups
have been enlisted and started before messages will be sent.
Additionally, send ports must be enlisted or started before a send port
group can be started. However, a send port group can be enlisted,
regardless of the state of the individual send ports it references. The
send port group must be stopped before all of the individual send ports
can be unenlisted.
Table 1 shows how state affects the behavior of message processing.
Table 1. Send Port and Send Port Group States
| Message Published | Send Port Group State | Send Port State | Description |
|---|
| Send port | Any state | Started | Message processed |
| Send port | Any state | Stopped | Message suspended |
| Send port group | Started | Started | Message processed |
| Send port group | Any state | Stopped | Message suspended |
| Send port group | Stopped | Any state | Message suspended |
Send port groups are
powerful tools for allowing multiple subscribers to subscribe to the
same message. Individual mappings for each subscriber can be maintained
and implemented without affecting other subscribers. Additionally, send
port groups allow the ability to resubmit suspended messages, if there
is a communication problem, to a single system without having to
resubmit to other systems in the send port group.
