Understanding BTS architecture is very important for any one who would like to pursue their career on BTS either as a Developer or administrator.
Often the problems that we encounter in BizTalk can be solved by thinking architecturally. Nothing to worry if you don't understand the above line. We will come to this in near future.
BizTalk at high level it work on a principle called Publish-Subscribe(Pub-Sub) Architecture.
Before understanding Pub-Sub architecture we need to understand at least Receive and Send Ports.
Receive Ports(RP):- In BizTalk we connect to any external system using Receive ports. RP is a logical container that contains one of more Receive Locations. Receive port and Receive location both have names. Just remember that we will be using Receive Port Name on Send Port Filters to subscribe messages.
Receive location is the Physical thing, Receive Location is where we configure how we get the data(in BizTalk world it is called message) from external system.
On the Receive Location we have to configure following things to connect to external system.
1). Adapter:- Based on the Adapter that we select the configuration properties change.
Ex:- If we select FILE adapter, then we need to configure the file location.
If we select WCF-SQL Adapter then we need to configure SQL Connection string and the query that we need to execute
If we select MSMQ adapter then we need to select the server name and Queue Name and so on.
2).Pipeline:- There are 4 default pipelines that come out of the Box. 2 on receive side XMLReceive, PassThruReceive and 2 on send side, XMLTransmit, PassThruTransmit. We will talk more about the above mentioned default pipelines and building custom pipelines in detail in upcoming articles.
Pub-Sub Architecture:-
Publish(Pub):- At high-level when BizTalk Connects to any system and receive message it saves(Persists) the message into its own Database called MessageBox(MessageBox is the SQL database gets created as part of the BizTalk installation and configuration). This process of saving message to the MessageBox is called Publishing technically speaking.
So in other words Receive Ports Publishes the messages to the MessageBox. So Receive port acts as a Publisher.
Subscription(Sub):- When the Message gets persisted in the MessageBox. Now we need to send the message to destination system(s). In order to send the messages to destination, BizTalk Send Ports retrieve the messages from MessageBox Based on the filters specified on Send Ports. This process of Send port retrieving the messages from the MessageBox is called Subscription.
By saying above we can conclude that send ports subscribe the message from MessageBox. So Send Port works as a subscriber.
Note:- When we configure receive and send ports accordingly the Publish and Subscription happens internally automatically. We don't write any code to persist the message to MessageBox. If at all we need to insert the message to our own custom database for tracking purposes then, we need to configure another send port that inserts into SQL.
Below diagram explains the complete architecture of the BizTalk and we can make following observations from it.
So we can safely say that orchestrations works as both Publisher and Subscriber.
Often the problems that we encounter in BizTalk can be solved by thinking architecturally. Nothing to worry if you don't understand the above line. We will come to this in near future.
BizTalk at high level it work on a principle called Publish-Subscribe(Pub-Sub) Architecture.
Before understanding Pub-Sub architecture we need to understand at least Receive and Send Ports.
Receive Ports(RP):- In BizTalk we connect to any external system using Receive ports. RP is a logical container that contains one of more Receive Locations. Receive port and Receive location both have names. Just remember that we will be using Receive Port Name on Send Port Filters to subscribe messages.
Receive location is the Physical thing, Receive Location is where we configure how we get the data(in BizTalk world it is called message) from external system.
On the Receive Location we have to configure following things to connect to external system.
1). Adapter:- Based on the Adapter that we select the configuration properties change.
Ex:- If we select FILE adapter, then we need to configure the file location.
If we select WCF-SQL Adapter then we need to configure SQL Connection string and the query that we need to execute
If we select MSMQ adapter then we need to select the server name and Queue Name and so on.
2).Pipeline:- There are 4 default pipelines that come out of the Box. 2 on receive side XMLReceive, PassThruReceive and 2 on send side, XMLTransmit, PassThruTransmit. We will talk more about the above mentioned default pipelines and building custom pipelines in detail in upcoming articles.
Pub-Sub Architecture:-
Publish(Pub):- At high-level when BizTalk Connects to any system and receive message it saves(Persists) the message into its own Database called MessageBox(MessageBox is the SQL database gets created as part of the BizTalk installation and configuration). This process of saving message to the MessageBox is called Publishing technically speaking.
So in other words Receive Ports Publishes the messages to the MessageBox. So Receive port acts as a Publisher.
Subscription(Sub):- When the Message gets persisted in the MessageBox. Now we need to send the message to destination system(s). In order to send the messages to destination, BizTalk Send Ports retrieve the messages from MessageBox Based on the filters specified on Send Ports. This process of Send port retrieving the messages from the MessageBox is called Subscription.
By saying above we can conclude that send ports subscribe the message from MessageBox. So Send Port works as a subscriber.
Note:- When we configure receive and send ports accordingly the Publish and Subscription happens internally automatically. We don't write any code to persist the message to MessageBox. If at all we need to insert the message to our own custom database for tracking purposes then, we need to configure another send port that inserts into SQL.
Below diagram explains the complete architecture of the BizTalk and we can make following observations from it.
- Receive Port has multiple Receive locations( We can have one or more receive locations on any given receive port).
- Receive Location has Adapter and Pipeline.
- We configure Maps on the Receive port level but not on receive location. Both receive and send ports can have 1 or more maps. and Maps are optional.
- After Receive Port components(adapter, pipeline and maps) are executed the XML message gets generated and gets published(saved) to the message box DB.
- Once the message is persisted(published) to the MessageBox DB, All the time send ports are listening to the MB for relevant messages. Once send port sees that MB has the message it is looking for then it reads(subscribes) to that message send it to the destination system by running Maps(if exists), pipeline and adapter.
- On the Other hand Orchestration can subscribe the messages from MB and execute some logic on the Message and publish the modified message back to the MB. Again the send port that is listening to the newly published message subscribes the message and send the message to destination.
So we can safely say that orchestrations works as both Publisher and Subscriber.
BizTalk Architecture |
If you don't understand what the adapters, pipelines, maps and orchestrations are please don't worry you will get proper understanding of what they are in near future with examples. For now if you understood how the architecture is then we are good to go.
Hi
ReplyDeleteAs I know IBM WebSphere is also integration software.
So this means biztalk does the same job as IBM WebSphere?
I shall be providing detailed article soon that explains features that both the products offer in near future.
DeleteUnderstood very well about basics and architecture of Biztalk.Please would request you to post more
ReplyDeleteSure thank you Amith. I shall be writing articles on weekly basis.
Delete