BizTalk has following components
- Receive Port: BizTalk Receives messages from source systems via Receive Ports.
- Adapters: Information interchange with external systems. There are several types of in-build adapters which are using to send/receive message to applications from BizTalk. E.g. File, web service, FTP, SQL etc.
- Pipelines: Pipelines is basically used for converting message into xml format and promote message content/context properties on the message. So that subscriber (Send port or orchestration) can receive the message for further activity. BizTalk plays message in XML format only. If message is in another format, then it should be converted into xml format in pipeline and then proceed further. BizTalk provides inbuild pipeline component to convert into xml from text & JSON files. If file format is different from xml, text or json, then there is require writing custom pipeline component to convert into xml. For more details you can visit following links:
- Schemas: Schemas is used to set the format of the message in xsd format.
- Maps: map is used to transform the message format from source to destination. Transformation allow the application to map one message specification to another and transform data as it is processed. BizTalk messages are XML documents within the system. and as such, transformations are created from Extensible Stylesheet Language (XSL). Microsoft has provided mapping tool inside BizTalk development. This tool has rich set of funtoid which help in message transformation. BizTalk also support custom XSLT for mapping.
- Message Box: The BizTalk server uses a publish-subscribe messaging engine architecture and the heart of this architecture is the BizTalk MessageBox database. This message box is responsible for storing the messages, message properties, subscriptions, orchestration states, tracking data and other such information. The Message Box is made up of two components:
- one or more Microsoft SQL Server databases
- Messaging Agent
The SQL Server database provides the persistence store for many things including messages, message parts, message properties, subscriptions, orchestration state, tracking data, host queues for routing, and others. The BizTalk Server group may have one or more MessageBox databases into which it publishes messages and from which subscribers to those messages extract messages.
7. Send Port: A send port is the location to which Microsoft BizTalk Server sends messages or from which BizTalk Server receives messages. It also provides the technology that BizTalk Server uses to implement the communication action. The name of the port uniquely identifies the location.
8. Send Port Group: A send port group is a named collection of send ports that BizTalk Server can use to send the same message to multiple destinations in one configuration
9. BizTalk Orchestration: Orchestrations are executable business processes that can subscribe to (receive) and publish (send) messages through the MessageBox database. In addition, orchestrations can construct new messages. When messages are sent from an orchestration, they are published to the MessageBox in the same manner as a message arriving on a receive location with the appropriate properties getting inserted into the database for use in routing.
It is a flexible, powerful tool for representing an executable business process based on XLANG/s language. XLANG/s can be viewed as a messaging language with some of the expression capabilities of C#. You can design flow, interpret and generate data, call custom code, and organize the entire process in an intuitive visual drawing, and at run time, the BizTalk Orchestration Engine executes XLANG/s files which are the executable business processes that are produced by BizTalk Orchestration Designer.
10. Role Links: role links is an abstraction layer between orchestrations and trading partners. Role links allow you to dynamically determine the trading partner for interaction based on message content, database values, basically on anything you can think of. A role is a collection of port types that either uses a service or implements a service. A role defines how parties interact with orchestrations.
11. Party: Party connect with send port with help of role link. This will define at run time where message should process based on Party configuration