BizTalk Server: Basics principles of Maps – Introduction (Part 1)

Introduction

Maps or transformations are one of the most common components in the integration processes. They act as essential translators in the decoupling between the different systems to connect. In this article, as we explore the BizTalk Mapper Designer, we will explain its main concepts, covering slightly themes such as product architecture, BizTalk Schemas and some of the most widely used standards in the translation of messages.

This article intends to be an introductory note for who is taking the first steps in this technology.

We can define BizTalk, in a very generic and simple manner, as a server for message routing, capable of handling, validate, transform and control numerous processes, simplifying the needs of adjustments to connect each system, i.e., is a tool and infrastructure unique, ideal to be used primarily for Enterprise Application Integration (EAI), Business to Business (B2B) Integration. Besides the patterns “Fire & Forget”, BizTalk Server is also used for more complex scenarios where the business logic (workflow) depends on various messages that need to be correlated with orchestrations – Business Process Management (BPM) solutions. In this article, we will focus only on the process of mapping and transformation of messages.

Architecture

All messages are received by BizTalk through physical ports, called Receive Ports. A Receive Port is a logical container for one or several receive locations, whereas, the Receive Locations are where you specify the details about the transport to be used, the exact address where the message is to be received and any other specific properties to that transport type, as you can see in the following example:

A FILE adapter could be, for example, a network folder (\\fileshare.local\orders\) with a filter (*.edifact) and parallel we could also be receiving orders from a Web Service (SOAP/REST/XML).

When a message is received from the adapter, it will execute a pipeline. A Pipeline is a simple sequential composition of components whose main objective is:

• Translate and transform messages: which may be in different formats: text files (Flat File), compressed files (ZIP) to the format that BizTalk uses internally to process messages: XML (Extensible Markup Language).
• Validate incoming messages: In its normal functioning, BizTalk Server only processes messages that are internally recognized. For that, it uses XML Schema that allows describing the structure (records, elements, attributes, namespace, names, data types) and that also defines the validation rules (whether it is required or not, the number of times the element may appear (occurrence), hierarchy) of the XML messages.

Then the messages are dumped inside the MessageBox (database) where the different subscribers (1 or more interested in this message) will subscribe the message and receive them. These subscribers can be other physical ports, typically, send Ports (for message routing scenarios) or orchestrations, launching new processes or waking up those who were waiting (through correlated fields)

Note: The key to understanding port terminology in BizTalk is to understand the notions of logical ports (also called orchestration ports) and physical ports. To oversimplify, it’s the difference between creating ports in Orchestration Designer (logical), and using BizTalk Explorer or BizTalk Administration Console (physical). When a developer creates a Specify Later port in Orchestration Designer, he’s configuring a logical port, leaving the corresponding physical port properties to be configured later by the BizTalk administrator. Giving the administrator the flexibility to configure the physical port in the production environment is a key reason why Specify Later is the most frequently used option.

Related links

• BizTalk Server: Basics principles of Maps – What are maps and where BizTalk can use them? (Part 2)
• BizTalk Server: Basics principles of Maps – Introduction to map editor (Part 3)
• BizTalk Server: Basics principles of Maps – Basic maps functionalities (Document mapping) (Part 4)
• BizTalk Server: Basics principles of Maps – Organizing Maps (Part 5)
• BizTalk Server: Basics principles of Maps – Testing and Validation of maps (at design time) (Part 6)

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira