Wednesday, January 25, 2012

Scheduling reports on API usage

One really neat feature in the Vordel Application Gateway is the ability to schedule reports on API and Web Service usage. You can schedule reports to run on a regular basis, and have the results emailed to the user in PDF format, just like Google Analytics. These reports include summary values at the top (for example, the number of requests, SLA breaches, alerts triggered, and unique clients in a specified week) followed by a table of APIs and Services, and their aggregated usage data (for example, the number of requests on each API or Web Service).

It is quite simple to configure this with the Vordel Application Gateway. Just right-click the Listeners -> Vordel Reporter node in the Policy Studio tree, and follow the configuration steps which are listed here on the Vordel Extranet: [ If you need a logon for the Vordel Extranet, contact Vordel at ].

Wednesday, January 11, 2012

Who manages Application Gateways?

Because Application Gateways touch on a number of areas of functionality, including networking and security, a very common question is "Who manages an Application Gateway?".

To answer the question, take a step back and think about what an Application Gateway is. An Application Gateway takes tasks such as application integration and application security and it moves them into a piece of network infrastructure (which may be virtual or physical). By moving these tasks out of applications and onto the network, you make the tasks run faster, and easier to manage since they are now decoupled from the applications themselves.

So, breaking it down, there are two things going on here: (1) moving integration and security tasks onto network infrastructure, and (2) managing the Gateway as a piece of network infrastructure. It follows logically that there are two distinct roles involved here: (1) The person configuring services and policies on the Gateway, and (2) the person operationally managing the Gateway. Person (1) knows about APIs, apps, and policies. Person (2) does not need to know anything about APIs (much less know anything about REST or XML) but knows all about SNMP, Splunk, load-balancers, and NAT.

This is why Vordel provides two distinct training courses, aimed at these two different people. For person (1), who will be registering APIs and SOAP services on the Gateway and applying policies to them, we provide the Vordel Certified Systems Engineer (VCSE) training. This involves registering APIs (via their URLs), choosing policies to apply to them, and pushing the policies out to Gateways. It includes SOAP and REST. For person (2), we provide the Vordel Certified Network Administrator (VCNA) training. This explains how to monitor the "speeds and feed" of a Gateway, where alerts can be sent, how to monitor it via network admin tools such as HP Arcsight, how to deploy additional virtual appliances in a VMware ESX environment, etc.

The separation of duties carries over to the Web-based interfaces used to manage the Vordel Application Gateway. In the case of the person managing APIs and policies, they see dashboards such as the one shown above. Here I see the traffic being passed to three APIs: CDYNE's EmailVerify service, SalesForce itself, and SalesForce's login service, for a two minute period on January 9th 2012.

In the screenshot above, we see what the Network Administrator sees. Rather than seeing information about SalesForce APIs, they instead see the network administration view of the Application Gateway. We see, for example, here the RAID Array Status for disks in the Application Gateway. Also, as you can see, system logs, networking, and server status can be monitored in this way. All of the same information can be sent to a product like HP Arcsight so that the network administrator does not even need to look at Vordel tooling.

In summary, there are two distinct types of people who manage Application Gateways on an ongoing basis, and this maps to Vordel's two distinct training courses, and to the different Web interfaces we provide for these people. All of this is geared towards moving application integration application security out of applications and onto the network (virtual or physical).

Tuesday, January 3, 2012

Kin Lane's API Management Service Provider Roundup for 2011 covers Vordel

Vordel is featured in Kin Lane's First Dimension of API Management Service Providers. It's a really good round-up of the current state of play, as we start 2012.

Kin mentions that:
One thing to know about these API management service providers is, well...they are API management service providers. To my knowledge they don’t actually deploy your API for you, they help you build a strategy, and manage the API. But you still need to rely on other tools and in-house resources to deliver your API.
This is where I'd disagree slightly. In the case of an API Gateway, it can also be used as a service delivery platform to deliver an API in front of existing enterprise system systems. This is because API Gateways include many adapters to, for example, various message queues, TIBCO EMS/Rendezvous, databases, and FTP/SFTP. These are used to deliver a REST API interface in front of an enterprise system which does not natively support REST, not to mention JSON, OAuth, or OpenID. This can be as simple as delivering a REST API interface in front of an existing SOAP service within the enterprise, to mapping from REST into messages placed on the message queue, through to mapping from "lightweight" identity mechanisms suitable for APIs (such as OpenID or OAuth) through to enterprise identity management (e.g. mapping from Google OpenID to Oracle OAM). So, an API Gateway usually does not only manage the API, it actually delivers the API too.

Mapping from Google login, with OpenID, to Oracle Access Manager login, with obsso cookie

[ Update: Axway acquired Vordel in 2012 and the new name for the Vordel Gateway is the Axway API Gateway ]

For a demo recently, I configured the Vordel Gateway to map from a Google account logon to an Oracle Access Manager obsoo cookie. This was to enable users to use their Google account to log into a local enterprise service, using the Vordel Gateway to do the mapping to the Oracle Access Manager login (since Oracle Access Manager is what is protecting the enterprise service).

Here is the policy in action. You can see that the Vordel Gateway creates a hyperlink to Google, to ask the user to select their account. If you look at the status bar in the screenshot below, you can see the OpenID string generated by the Vordel Gateway:

When I click the link, I am asked which Google account I want to use to log into the service. Google shows me the two accounts which I am currently logged into:

Once I choose the Google Account, I see that the Vordel Gateway has generated an Oracle Access Manager obsso cookie, which is visible in Firefox:

If you're interested in getting a copy of the policies I used for this, contact Vordel at . For more information, including videos, about Vordel Gateway interop with various Oracle products, check out:

Monday, January 2, 2012

Returning JSON fault information to JQuery-based API clients

Since many APIs are called by JavaScript libraries like JQuery, it's convenient to return fault information as JSON so that it can be easily read by the client. The object is then parsed to retrieve the reason for the fault. Some APIs make this easy, such as the Rackspace Cloud Identity API which allow faults to be returned as JSON or XML. But in many cases, you have to laboriously configure this JSON conversiona yourself [For example, in the case of WCF, Iain Mitchell has a good blog post about how it can be made to return JSON formatted faults for consumption by JQuery.]

A Gateway serves an important purpose here, by providing fine-grained information on why clients are blocked. A Gateway can return XML to clients which expect XML responses, and JSON to REST API clients which expect JSON. Let's see how you can use the Vordel Gateway to take a policy which returns an XML fault (in this case a SOAP Fault) and converts it automatically to JSON...

To start this, I fired up Vordel Policy Studio and connected to my Dev API Gateway. I then dragged in a Policy Shortcut to a policy called "JSON Fault". Next I right-clicked on it and choose "Set as Fault Handler", as shown below:

This means that if any of the filters in the chain return false, my policy gets called. Next let's look at this policy. You can see below that it takes a regular SOAP Fault and converts it automatically to JSON:

When we look at it in action, in the API Gateway's Real-Time Monitoring, we see the familiar "Path through the policies" on the left, and on the right you can see the JSON which is returned to the JQuery client:

The API Gateway's Real-Time Monitoring shows what is happening now for your APIs and services. But in order to look at what has happened in the past, we open the API Gateway's audit trail. Here you can see the opening page, and I click on the "Audit Trail" button:

On the Audit Trail, I run a report for the API requests blocked in the last hour by my API Gateway. Here I see a bunch, and I click on one to see more detail.

When I click on the API request which was blocked, I see the exact reason why it was blocked in the "Path through the Policy". I can see below that it was the authentication which failed, the same reason which was passed back to the JQuery client.

So in summary, it's quite straightforward to return JSON fault information to clients, and view fault information in the Audit Trail, using the Vordel Gateway. To get more info, or your own copy of the Vordel Gateway, contact us on

How to change the default alert email subject line

First How-To of 2012 and it's via Niall Commiskey, who posted a useful tip which applies also to the Vordel Gateway: How to change the default alert email subject line.