Book Image

SOA Patterns with BizTalk Server 2013 and Microsoft Azure

By : Richard Seroter, Mark T Brimble, Coen J Dijkgraaf, Mahindra Morar, Mark Brimble, Colin Dijkgraaf, Johann Cooper
Book Image

SOA Patterns with BizTalk Server 2013 and Microsoft Azure

By: Richard Seroter, Mark T Brimble, Coen J Dijkgraaf, Mahindra Morar, Mark Brimble, Colin Dijkgraaf, Johann Cooper

Overview of this book

Table of Contents (21 chapters)
SOA Patterns with BizTalk Server 2013 and Microsoft Azure Second Edition
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Configuring BizTalk messaging


Understanding how to design and arrange BizTalk messaging settings is an absolutely critical part of designing any BizTalk solution, let alone a service-oriented one.

Earlier in this chapter on BizTalk Server, we discussed the BizTalk messaging architecture and its foundation in a publish and subscribe routing model. One of the most important parts of a messaging configuration is enabling the receipt of new messages. Without the ability to absorb messages, there's not much to talk about. In BizTalk Server, messages are brought onboard through the combination of receive ports and receive locations.

Receive ports can be configured from within the BizTalk Server Administration Console. Receive ports support both "one-way" and "two-way" message exchange patterns. On the left-hand side of a receive port configuration, there is a series of vertically arranged tabs that display different sets of properties. Choosing the Receive Locations tab enables us to create the actual receive location, which defines the URI that BizTalk will monitor for inbound messages. In the Transport section of a receive location's primary configuration pane, we can choose from the list of available BizTalk adapters. Once an adapter is chosen from the list, the Configure button next to the selected transport type becomes active. For a receive location exploiting the FILE adapter, "configuration" requires entering a valid file path into the Receive folder property as illustrated in the following screenshot:

The next step in configuring BizTalk messaging is to create a subscriber for the data that is published by this receiving interface. BizTalk send ports are an example of a subscriber in a messaging solution. Much like receive locations, send ports allow you to choose a BizTalk adapter and configure the transmission URI for the message. However, simply configuring a URI does not complete a send port configuration as we must pinpoint what type of message this subscriber is interested in. On the left-hand side of a send port configuration window, there is a vertical set of tabs. The Filters tab, as shown in the following screenshot, is where we can set up specific interest criteria for this send port. For example, we can define a subscription that listens for all messages of a particular type that reach the MessageBox database:

Note

A send port can be in three distinct states. By default, a send port is unenlisted. This means that the port has not registered its particular subscription with BizTalk, and would not pull any messages from the MessageBox. A send port may also be enlisted, which is associated with ports that have registered subscriptions but are not processing messages. In this case, the messages targeted for this port stay in a queue until the port is placed in the final state, Started. A started port has its subscriptions active in MessageBox is heartily processing all the messages it cares about.

The BizTalk Server messaging engine is the heart and soul of a BizTalk solution. Here, we saw how to create new input interfaces and define subscribers for the published data.