The Management API
The Sentinet management API is available as REST or SOAP service. The main concept here is that every operation you can do using the Sentinet UI is available as an API.
You can then leverage those interfaces to write custom tools that fit your needs the best. A common example is a script to automate your version strategy or change the authorizations.
Scenario
With the “mobile first, cloud first” mantra ticking in our minds, we want to make the hosted services usage information and statistics available to the customers outside the enterprise boundaries.
To achieve that we’re going to virtualize a few Management API operations (e.g. usage report, node status) and to present them on an azure website using Azure Hybrid Connections.
Sentinet is natively integrated with Microsoft Azure. Other possible ways to bridge from cloud based application to your on-premise resource are to use the Azure Service Bus Relay or, for example, to configure the Sentinet Nodes in the hybrid deployment scenarios where some Nodes are deployed on-premise while others are in the cloud.
Virtualize the management API
The native management API – like any other API – can be virtualized to extend or modify its own operations/behavior. Let’s pick the GetTopServiceVersionsUsageReport operation as an example and virtualize it.
The GetTopServiceVersionsUsageReport service returns different statistic data based on the {REPORTTYPE} parameter. I want to simplify this operation to get rid of all the parameters except the number of services parameter {TOPCOUNT} for which the statistics needs to be fetched.
Let’s see which Sentinet’s features I leveraged to compose the new virtualized service to fit our scenario:
– Virtualization (to expose only the operations we want and reduce the interface complexity).
– Protocol mediation (from https to http). Though https should be everywhere in case of APIs, we will use http for simplifying the scenario configuration.
– Authorization (from username/password to API keys). This is a two steps process where the first one is to set up the access control with an HTTP header validation.
Any management API calls has to be authenticated with a token that is obtained by calling the login method with username and password. The second step is to plug the SignInManager behavior that maps the API key to a valid authorization token.
Mobile first, cloud first
In order to target a variety of devices I prepared a simple ASP.NET MVC 5 Web Application. It uses Bootstrap 3 as its default CSS Framework and it’s a matter of few clicks to publish to Azure websites.
You can then setup the Azure website to use Hybrid Connections that enables to build hybrid applications using the same application connection string /URI that you would normally use if these were hosted locally on your private network.
Hybrid connections will be activated only on the node machine where I hosted the virtualized API so only a specific subset of services will cross the enterprise’s boundaries.
You can find the procedure to setup the Azure WebSite and HC at this link.
1. Create an Azure Website
2. Create a Hybrid Connection and a BizTalk Service
3. Install the on-premises Hybrid Connection Manager to complete the connection
Once completed the HC is displayed in the web site as connected.
Test
To test our scenario access to the Azure WebSite at this address http://sentinetdashboard.azurewebsites.net. If the virtual machines I used for this demo are up and running you will see the number of transactions increasing every times you load the main page otherwise a mocked data will be displayed.
For testing the responsive design of the application and the compatibility with different browsers/devices a service like browserstack can be used.
Conclusion
In this post we saw how the Sentinet’s management API, like any other API, can be virtualized to the change the accessibility and security requirements. In the next post I will continue the extensibility series to discuss about the WIF extensibility point.
Cheers,
Massimo
Subscribe to our RSS feed