Monitoring a Virtual Service

 

I my previous post; Exposing a service through Sentinets Virtual Service concept i’ve explained how to redesign a service by leveraging the Virtual Service concept.

We will now execute this service and monitor it. When we open up Sentinet, we have a catalog of Virtual Services; If we go into the details of the Virtual Service, we can generate the WSDL;

This WSDL will be made available for a limited duration (i believe 15 min), so that we can use it to generate the consumer, so we see here, that we have our webservice GeoAdmin i had created earlier;

We can now use a tool such as SOAPUI to fire requests to the service;

As we can see, only the method we had choosen earlier is available, the method ‘GetGeoIPContext’ was not selected in our Virtual Service;

Resulting methods in our wsdl;

We can send a request to the service;

And here, we can use the features Sentinet provides, which is something we can use On-Premise, and in Azure by placing Sentinet Nodes in-front of Azure Services! We see a request;

And if we look at our specific service, we can look at the message flow;

We can look at the message details which shows which rules were applied;

And we can tune the monitoring profile, from None, Extend, Full, Custom (we can choose which event to monitor);

If we enable full monitoring, we have tracking for each operation, on a meta and message level;

If we send a another request, we can now look, and see even the message details;

Because Sentinet works as a repository, we have a dashboard which shows a lot of information on a high-level indicating the state of the repository;

 

So, controlling/monitoring/securing/redesigning services is all possible and managed in a single repository.

In future posts, i would like to look at hybrid scenarios, where this allows us to ‘secure’ a relay, monitor the Cloud endpoints, decouple the Cloud from the On-premise, a lot of potential added value.

 

 

Cheers,

Sander