(For more resources related to this topic, see here.)
In WABS, a bridge is used for transporting a message from one place to another. Unlike BizTalk Server, a message entering a bridge will always be routed to one destination only.
All bridges have an HTTPS entry point. Additional entry points, such as FTP and SFTP, can be added.
The following is a list of what can happen in a bridge:
A bridge can also send messages to another bridge for further processing. A bridge will always act as one whole step, meaning that if a bridge cannot submit to its destination, the message will not be removed from the source.
Let us create a very simple bridge that picks up a text message from an FTP folder and drops the file in another FTP location.
For this example you will need an FTP site and three folders:
Also, a username that has full access to these folders and a corresponding password will be required.
Parameter | Value |
File Mask | *.* |
Folder Path | In |
Initial Status | Stop |
Password | [The FTP User’s password] |
Server Address | [The FTP Server address] |
Use SSL | False |
Username | [The FTP Username] |
Note that the Initial Status is by default Start, which will have the source polling from the FTP folder as soon as the project is deployed. To gain better control of when the polling starts, we will set it to Stop instead and then manually start it using a PowerShell command.
As of now, the only place we can configure the FTP properties are in Visual Studio. In the future, other configuration options in the Azure Portal might be possible. This also means that, for now, if a password changes, you will need to change this in the Visual Studio project, and then redeploy the project.
A bridge can have from one to many destinations. Unlike a publish-subscribe engine, the message will only be routed to one of these destinations. This is done by setting a filter condition on each connection to the destinations and then prioritizing the destinations in the bridge’s Route Ordering Table property.
All destination connections need a filter condition (which is also the reason we received the two errors before), and a bridge will always have each of its destinations in a prioritized Route Ordering Table.
When a message leaves the bridge, the filter condition for the destination connections will be evaluated in the order they appear in the Route Ordering Table. The first positive match will get the message, and the algorithm will stop, so that no more than one destination will get the message.
In our rather simple example from before, all we have is one destination, and we naturally want all messages to evaluate to that destination’s Filter Condition.
We are now left with a single warning message when building the project:
FTP Filename property needs to be specified at the Route Action stage
Although this is only a warning and the project will build and deploy, the solution would not work since the FTP destination will not have any name to assign to the file it is writing to the Out folder.
For now, we will just hardcode the output.txt filename. Later, we will change the solution so that the original filename is used, by using the Enrich feature in the bridge.
To set the FTP filename used by the FTP destination, we need to create a Route Action on the connection to the destination, by using the following steps:
To deploy a project to the BizTalk Service in Azure, we need the following:
To deploy, perform the following steps:
Now we need to verify that the bridge and the source have been deployed in the WABS, and then start the source so that it will commence picking up files from the In FTP folder.
This article has dealt with some of the basics of BizTalk Server and BizTalk Services in Azure. We have seen how to create accounts and Servers in Azure, how to use them, how to set up an EDI agreement for exchanging messages with partners in the cloud, and even how to route messages from Azure to your local on-premise applications.
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…