API Management with BizTalk Server
BizTalk server is a robust Integration platform, it is a beast when it comes to message transformations, and translations, business process automation, and most importantly communication protocol mediation using the set of its built-in adapters, and we get all of these capabilities without writing a single line of code.
However, this last statement is not always true in real-world scenarios, in this article, the focus is on BizTalk’s protocol mediation and message transformations capabilities, where it might need some help by coding, if it is manageable, or by leveraging other powerful tools such as an API Management (APIM) to greatly extend these capabilities.
The following are 2 use cases where we might need an APIM along with BizTalk server.
1. Service consumers or providers with unsupported identity protocol requirements
The first use case for using API management with BizTalk Server is when there are communication protocols intricacies that are required by service providers or service consumers, while these are not supported by BizTalk.
For instance, REST protocol has been supported since BizTalk Server 2013 version using the WCF-WebHttp Adapter, and JSON encode/decode pipeline components were introduced a bit later, we might encounter some subtle variants on top of REST, in terms of newly added communication mechanisms and authorization protocols, which are not supported using the out-of-the-box BizTalk Adapters. Let’s look into the following 2 examples:
1.1 Service Consumer requirement: A web-based application asking for Cross-Origin Resource Sharing (CORS) support 
Although one could argue that this protocol could be implemented in BizTalk using an orchestration, but this would not be an elegant solution, remember that orchestrations are meant for business process automation, they are not intended for handling protocol negotiation techniques.
Moreover, every aspect in the CORS negotiation protocol will need to be covered, if we were to properly implement it manually. Check the article by Nick Hauenstein for what is takes to manually implement CORS mechanism using BizTalk artifacts.
1.2 Service Provider requirement: An API requiring OAuth for request authorization
This could be handled using WCF custom behavior, or we could build a custom adapter, if we have the time.
However, these options actually defy the purpose of having BizTalk Server doing the heavy lifting for us in protocol mediation using its set of out-of-the-box adapters, while allowing us focus on the business aspect of the solution.
2. API Governance requirement
The second use case for using APIM with BizTalk Server, is when the customer requires controlling, metering, or auditing for their API assets, which could be aligned with their organization’s internal security policies, for instance.
Again, while this can be implemented using a custom-built application and a persistent data store, we will be reinventing the wheel and we will be responsible for maintaining this custom solution in addition to our integration solution.
In this case, it is obvious that we need a more appropriate tool and here comes: “the right tool for the job” phrase that we all as integrators have been preaching to fellow colleagues and to our customers.
API Management to the rescue
API Management (APIM) platforms are designed to assist in the above-mentioned cases and much more, they extend BizTalk’s protocol mediation and message format transformation capabilities, with minimum overhead, and most importantly, effortlessly using a configuration-based approach.
Thus, truly fulfilling the target of allowing integrators to focus on the business solution, rather than handling unnecessary integration technicalities. Andrew Slivker article go through a no-code approach for supporting CORS using Sentinet; an on-premises APIM platform.
APIM could also enforce policies to protect BizTalk published services, for instance applying throttling or caching policies on the incoming requests at the edge of the solution. It also becomes a facade abstracting the implementation techniques of these assets, which in a way, become shielded by the gatekeeper: the APIM!
In addition to its role in the BizTalk service provider side, APIM could also be positioned to assist BizTalk in consuming backend services with unsupported protocols or flavors.
It may initially seem that there is an overlap between the protocol mediation and message transformation functionalities provided by APIM and BizTalk, and indeed there is, but the difference is subtle.
BizTalk functionalities should be focused in core of the business solution, while APIM functionalities should be on the edges of the solution.
In other words, we should use APIM if what we need to do is straight-forward message format transformation such as JSON to XML, however, if we need to perform business-related transformations and translations, then we should go with BizTalk.
Regarding communication protocol mediation, the decision is much more obvious, if the communication protocol is already supported by BizTalk adapters, then we use BizTalk, otherwise, we could leverage the APIM with its ready-made, extended protocol capabilities.
Cloud-based, On-premises, or Hybrid APIM?
With all the amazing features and capabilities brought to us by Azure APIM, one can be tempted to opt for it, but there are also prominent on-premises APIM platforms for on-premises landscapes.
The decision of choosing between Azure APIM or on-premises APIM should be based on the organization’s current IT landscape, cloud adoption strategy and constraints.
For instance, it makes sense to go with the on-premises APIM platform if the majority of the organization’s workloads reside on-premises or when the organization is restricted from moving to the cloud due to compliance requirements.
On the other hand, organizations with on-premises and Azure hybrid workloads could leverage Azure APIM, this decision could be reinforced by the organization’s cloud adoption strategy, if there is one.
Hybrid API Management
There have been several requests by integration specialists for Azure APIM to be provisioned on-premises, echoing their customers’ needs. During a Q&A section in Integrate 2018 event in London, Microsoft product team acknowledged that request and stated that they have been working on it.
UPDATE 2020: Microsoft introduced a hybrid and multi-cloud APIM solution using self-hosted gateway. The management plane is done through Azure, while containerized APIM gateways could be deployed anywhere, such as on-premises, or even on other cloud providers.
These containerized gateways will handle incoming API requests within the scope of their landscapes, and will apply the APIM policies. This is suited for organizations with a hybrid, or multi-cloud landscapes.
Finally, it is perfectly fine to extend BizTalk Server capabilities using an API Management platform, to gain additional protocol mediation capabilities and provide governance control for its services. We should find the right set of tools and guide our customers according to their ecosystems, strategies, constraints, and needs.