Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Showing the Response Times for Individual Requests in the Axway/Vordel API Server

DZone's Guide to

Showing the Response Times for Individual Requests in the Axway/Vordel API Server

· Performance Zone ·
Free Resource

xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.

When managing APIs, one of the most important requirements is to perform a root cause analysis of any API bottlenecks. Remember that the APIs that you expose to your clients may themselves rely on other APIs.


Let's say that you are exposing an API on an API Gateway that in turn calls out to SalesForce APIs. If your own API is running slowly, you need to be able to isolate the reason. Here, in the web interface to the API Server, I am looking at the transaction and I see two call-outs to SalesForce APIs. The second one, to the SalesForce log-in service, is taking a long time (see the timings circled in red below).


We see at a glance each input and output message being sent to the API, and we can also look at the request and the response to the client calling the API at the API Server. This allows you to pinpoint the cause of any delay and see message timings at a fine-grained level.

You can then go one step further. If you click on the Filter Execution section and expand it, you can see exactly the timing of each step in the API Server. I've highlighted the step where we call out to SalesForce to log in to SalesForce. We can see that that step is taking a long time, whereas other steps within the API Server are very fast.


We've tried to make it very simple to see not only how long a transaction takes but also how long each step in the transaction takes. So if a client says "my API calls are too slow!" you can look at the API Server's web interface and see the reason at a glance. Then, you can take action (e.g. enable distributed caching, or add proactive load-balancing across multiple APIs).

3 Steps to Monitoring in a Connected Enterprise. Check out xMatters.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}