Hybrid Integration with Sentinet
I previously explored Sentinet 5, and demonstrated how you can easily wrap an on-premises unsecured SOAP/HTTP service into a virtual REST/HTTPs API with JSON message format and basic authentication security scheme. I also added a custom access control feature that governed the throughput of virtual service incoming requests to a maximum of (2) requests per minute.
I was really fascinated with Sentinet powerful features and what it could provide as a robust on-premises API management platform using simple, intuitive configuration-based approach. With the prevalence of hybrid integrations that span on-premises and cloud workloads, I decided to explore it further in that aspect.
In this post I will show how you can easily extend the reach of an on-premises Sentinet virtual service beyond the organization’s network through Azure SB Relay, perhaps to use it as a resource for a cloud-based integration solution, or just externally publish it for a B2B integration.
Using Azure SB Relay will avoid the need for requiring any changes on the organization’s firewall, while leveraging Sentinet will make sure to consistently enforce your organization’s governance rules across all of your internally and externally published assets, and most importantly, without the need to write a single line of code.
Provision Azure SB Relay
You only need to provision the SB relay in Azure portal.
The WCF relays will be created dynamically by Sentinet, when you activate the corresponding virtual service SB endpoint from Sentinet Management console.
Configure Sentinet Node
The Sentinet node is a logical container that is hosting our virtual services, all of the heavy lifting that is abstracted away from us, is handled by this construct. For increasing your solution scalability and availability levels, you can create another dedicated Sentinet node, and each node could be deployed on the same or different machines.
If you have followed the steps in the previous post, you can configure another endpoint on the existing Sentinet node through the Sentinet Management console. Alternatively, you can have a dedicated node, to cater for a different protocol/security binding, and/or to increase scalability and availability levels of your solution, as mentioned above.
Here I am using the same virtual service I used in the previous post, to extend its reach to outside the organization’s network.
In the Sentinet Management console node configuration, you will add the SB relay address, and use shared access signature (SAS) as the credential type, and then you will enter the shared access root key name and shared access root key value; that is the default shared access policy created for you when SB Relay was created. You then apply the binding for WebHTTPRelayBinding for this new endpoint.
What’s really awesome is that if you have any existing Sentinet virtual service, like I had in this scenario, it can quickly be extended to the outside world through Azure SB Relay with just these few configuration-based steps.
Not only are you extending the virtual service reach to consumers outside your organization boundaries, but you are also leveraging any existing API management applied compliance and governance features such as: security, caching, access controls, message format mediation, communication protocol mediation, monitoring, and auditing.
Control over Azure Service Bus WCF Relays
Interestingly, as mentioned in Provision Azure SB Relay section, WCF relays are created and removed dynamically, it can be controlled by simply enabling and disabling respectively the SB endpoint from within the Sentinet Management console.
This could be an excellent way to provide you with governance and cost control over the Azure WCF Relay endpoint from within Sentinet, by making the endpoint temporarily, or permanently not available, if required.
Testing
I was able to successfully consume my back-end physical service through SB relay endpoint using Postman, with all the applied governance features. Moreover, the local endpoint is also still there for internal integrations.
Monitoring
Sentinet provides real-time monitoring for all the transactions that spans across the endpoints of your virtual service, and all the way to the SOAP back-end physical service, with the necessary granularity level that you require to track and inspect the transaction and payload details in different stages.
Recap
In this post, you can see how quickly I was able to provision an external endpoint through Azure SB relay, while leveraging all the existing message format mapping, throttling conditions, access control features provided by Sentinet.
With the proliferation of B2B integrations, and cloud-based services adoption, the need for hybrid integrations arises to be able to integrate the cloud-based workloads with existing on-premises resources as well as securely publish on-premises assets for B2B integrations.
Using Sentinet with Azure SB Relay will make it much easier to securely extend the reach of on-premises assets to cloud-based workloads, and external business entities, while leveraging the organization’s applied governance and compliance requirements in a consistent manner across all of your external and internal published assets.