Wednesday, March 28, 2012

Architecting your Delivery Platform for the API Economy - Recorded Webinar with Randy Heffner from Forrester

I've just added a new link to the Recorded Webinars list on the right-hand side of this blog. It's a recording of last week's webinar with Randy Heffner from Forrester, on Architecting Your Delivery Platform for the API Economy. Randy had a lot of insightful comments to make on API delivery (e.g. if you make it hard for developers to sign up to use your API, they will simply go elsewhere). Be sure to check it out.

Tuesday, March 27, 2012

Job posting: San Diego: IT Engineer skilled in Oracle products and Vordel

Qualcomm in San Diego are looking for an IT Engineer with knowledge of Oracle products and Vordel. This job was posted on 22 March, 5 days ago, so apply now :)

Recommended reading: Oracle Enterprise Gateway integration with Oracle Service Bus and Oracle Web Services Manager.

William Markito and Fabio Mazanatti from Oracle in Brazil have written a very comprehensive guide to Oracle Enterprise Gateway integration with Oracle Service Bus and Oracle Web Services Manager. This is definitely recommended reading if you're planning to use these products together. William and Fabio have put many useful screenshots in there also.

Saturday, March 24, 2012

How to configure URL-Rewriting on the Vordel Gateway

A common scenario with the Vordel Gateway (or any kind of gateway) is to perform URL-rewriting on requests. The "Rewrite URL" filter can be used for simple scenarios like where you want to map "/PathA" always to "/PathB" (you simply drag in a "Rewrite URL" filter into your circuit in Policy Studio and type "/PathB" into it).

But what about more sophisticated URL-rewriting scenarios? Let's take an example: Requests come in to the Gateway on "/PathX/something" and I want to route them on to a back-end server on the path "/PathY/something". I want to do this in such a way that if the request comes in to "/PathX/somethingelse" then they get routed on to "/PathY/somethingelse". Here's how you do that:

In my simple policy, I am using the Search and Replace filter to replace the first instance of "/PathX" in the request with "/PathY". I then put the result into a new variable called "http.request.newpath". [ Side note: I've written about the Search and Replace filter in the Vordel Gateway before, for scenario of searching and replacing with the message itself]

Now I set the URL path to my new path, using a "Rewrite URL" filter, like this:

The next step is to use a "Static Router" filter to tell the Gateway to route to the back-end server ("") over port 80 in this case:

Finally, the "Connection" filter actually makes the connection to the destination server, with the Gateway having done the work of rewriting the URL path. Easy as that :-)

Monday, March 12, 2012

Zip codes could be considered PII (Personally Identifiable Information) under California Law

I found this interesting tidbit in this blog post by Naresh Persaud of Oracle:
...,a recent court ruling in California found that zip codes could be considered PII ( Personally, Identifiable, Information).
If even a zipcode is considered PII, then that's quite significant and, as Naresh says, brings the need for Gateway technology to strip out, encrypt, or redact the PII from the message.

Thursday, March 8, 2012

Pro tip: Find out how long a Web Service call takes

Niall Commiskey has written a really useful guide to measuring the time a Gateway takes to call a Web Service. I recommend you check it out if you're interested in this information. One thing I'd add is that Niall is timing how long a Web Service filter takes to run. The Web Service filter may be doing other things, in addition to calling the Web Service (e.g. it may be doing Schema validation on the message). So the timing is showing how long all of these things take, together. If you call an API or Web Service using a "Connect to URL" filter (as explained in this blog post) then all it is doing is making the call.

To add to Niall's information, here are some other ways you can find this information about how long a Web Service call takes:

1) Use Traffic Monitor. This is available by default by pointing a browser to 8090 on the Gateway. It shows in milliseconds how long each processing step at the Gateway takes, including calls to external Web Services or APIs.

2) Use SR . In the example below, I am using the SR tool (which comes with the free SOAPbox download) to call a Google search API over SSL. You can see it tells me the time the request took. If I want to send many requests, I can do that with the -c (count) and -p (parallel threads) parameters.

C:\soapbox\sr>sr -C -h -s 443 -u "/search?as_q=vordel" -v GET -V
1.1 -qq
will use HTTPS sessions
remote host =
URI = "/search?as_q=vordel"
verb = "GET"
HTTP client version 1.1
2210 ranges from 0 to 3653.903699
add header Connection: close
add header Content-Length: 0
1 threads started
time taken: 0.374000 secs.
bytes sent: 0.000071MB (ju octets)
bytes received: 0.051882MB (ju octets)
transactions: 1
connections: 1
sslConnections: 1
sslSessionsReused: 0
bytes sent/sec: 0.000189MB (197.860963 octets)
bytes received/sec: 0.138721MB (145459.893048 octets)
transactions/sec: 2.673797
protocol/connection errors: 0
transactions by HTTP response code:
code=200, count=1

Securing a BPEL Composite in Oracle SOA Suite

Recently I was researching BPEL composites in the Oracle SOA Suite and I found this excellent blog post by Shreekanta Roy Chowdhury about securing a BPEL composite using Oracle Enterprise Gateway. The post even provides a very useful Google doc (with screenshots!) of how to install and configure OEG. Highly recommended reading, if you are working with this particular set of products.

Pro Tip: Jython scripting the Vordel Gateway

One of the neatest recent features in the Vordel Gateway is the ability to script certain features using Jython. Many sample Jython scripts are provided. One of the most useful is a short script which registers a Web Service with the Gateway. The possibilities of this scripting are exciting, for example to automatically register a service with the Gateway immediately when it is deployed in another system, or to automatically register a large number of services all at once, together. Jython is also very simple to learn and understand. Definitely worth checking out, I know it's something I use all the time in my day-to-day work with the Gateway.

Wednesday, March 7, 2012

Job posting for Middleware Architect skilled in Vordel and CA, in London

Hot on the heels of the job I just posted in Brussels, here is another position, this time in London, for someone with Vordel Skills:

Posted: 29/02/2012

Job type: Contract

Salary: £500 - £600 per day

Location: England , City of London

Description: An exciting opportunity has arise for a skilled Middleware SSO Architect to work for one of the largest and most prestigious Investment Banking organisations in the world. The successful Architect will have worked in a similar role within a large Banking institution and possess the follwing key skills:

·Experience of working in the Investment Banking sector

·SOA security - SAML / WS-Security

·Kerberos / SSL/TLS / PKI / GSS-API / SPNEGO

·CA Siteminder Web SSO

·Vordel XML security gateway

·IIS/WCF/WIF, WAS security models


·Java development

·Infrastructure standards for network load balancers, servers, networks and storage

Details at:

Job posting for Vordel, IBM, and F5 skills in Brussels

This job was posted 2 weeks ago and they are looking for someone ASAP, so apply fast :-)


6-12 Month Contract: Infrastructure Security,Websphere,Vordel, PKI - Brussels

Ref: CIL / 24571

Location: Brussels

Salary: €500 - €600 Per Day

Duration: 6 - 12 Months

Start Date: ASAP


We are seeking an experienced Infrastructure Security Expert for our client located in Brussels. Candidates must have excellent knowledge within Web Security.

Active knowledge of Tivoli Access Manager, Vordel, Websphere, PKI and F5 (Firewalls).

More details:

Pro Tip: Reading the content.body of a message in the Vordel Gateway into a string

[Update: Vordel was acquired by Axway in 2012 and the Vordel Gateway is now known as the Axway API Gateway]

Recently I configured a policy on the Vordel Gateway which read a message (JSON in this case) into a variable, which I then used later in a policy. Here is the simple script I used to read the content.body attribute of the message into a string which I call "":


function invoke(msg) {
var body = msg.get("content.body");
if (body != null) {
var baos = new ByteArrayOutputStream();
body.write(baos, 0);
var content = new java.lang.String(baos.toByteArray(), "utf-8");
msg.put("", content);
return true;

To show how this is configured in a policy on the Vordel Gateway, I've made a short video of me putting this script into a "Scripting Filter" block in a Vordel Gateway circuit. In the video, I am also specifying that the script requires the content.body attribute as input, and generates an attribute called "". This allows Policy Studio to graphically show whether the script is getting its required input or not .


You'll notice in the video above that the block is colored red, indicating it is not getting the input it needs (the message body). So how do I change the scripting block to not be red anymore? I do this by ensuring that it does get a message as input (since the message will automatically populate the content.body attribute). I can do this by wiring it up to a listener. Here I am doing this, in the following video:


Now, you'll notice the Scripting block is now black, not red anymore. It is getting the input (a JSON message in the content.body attribute) as its required input. I used JSON in this example, but the exact same process would work for XML.

Happy Scripting!

Tuesday, March 6, 2012

How to call a Web Service from the Vordel Gateway

Let's say you've created a SOAP message in the Vordel Gateway, perhaps based on an incoming REST request. And now you want to send this SOAP request to a Web Service. Here is how to do this:

First add a 'Set HTTP Verb' filter to the end of your circuit, and configure this filter to set the verb to 'POST' (this is in case the incoming is a GET, which it will usually be in the case of REST, but the SOAP service expects a POST). Then follow this filter with a 'Connect to URL' filter, and configure it with the full URL of your SOAP service (eg

What if you want to call out to a Web Service "off to the side" then use the response from this to call another service? Here is how to do that: