Reuse is a key SOA architectural principle that should always be of consideration when developing a solution. When creating an Oracle API Gateway (OAG) policy that is used to virtualize an OSB REST endpoint (for further details, see Oracle API Data Sheet), it can be done in a generic way allowing for a high level of reuse.
The key to creating a generic policy is defining the API Gateway path with the same value as the OSB endpoint URI. But before the OAG relative path can be created, the policy that virtualizes OSB REST endpoints will need to be implemented first.
As a refresher, an OAG filter is an executable rule that performs a specific type of processing on a message. An OAG policy is a network of message filters in which each filter is a modular unit that processes a message. For more details, see OAG concepts.
Within the OAG Policy Studio, create a policy (Policies->Add Policy), then add ‘Extract REST Request Attributes’ as the start filter. This will extract the Request query string (which is the string parameters from an HTTP POST or GET request) as well as the Request HTTP headers. Doing this provides the ability to reference these values later within the policy.
Next, add a ‘Connect to URL’ filter into the policy. This filter is the step in the policy where the invocation to the endpoint (OSB REST service in our case) is performed. Since we are building this policy to be used in a generic way, the URL of the Service Bus proxy will be generated from the input string of the request into the API Gateway. The http.request.path contains the path on which the HTTP request from the client is received by the API Gateway (which is also the same URI as the OSB proxy, i.e. /someName/ProxyService). The attribute http.raw.querystring contains the parameters (i.e. first=john&last=smith) from the request. Appending this within the URL will enable the request input parameters to be passed along to the OSB proxy.
The completed policy looks like this:
With the generic policy created, it can now be mapped to a relative path that the API Gateway will listen for traffic on. As mentioned above, the endpoints in both the OSB proxy and the OAG path resolver need to be the same to allow the OAG policy to be reused for any OSB REST endpoint.
Below is the OSB proxy endpoint URI proxy:
The same URI as above will be used when creating the listener path in OAG:
As the growth of APIs accelerate, it is important to maximize the reuse potential of your API Gateway. Creating generic policies as demonstrated here will enable agility, requiring minimal configuration when new APIs come online.
Join the Conversation
Which version is this? I'm not sure it this has anything to do with it, but I was having a problem with the steps described above. As I do the Configure "ConnectToRestService" the way it is described, I get a "Not Found" error while trying to invoke the service from the OAG address. I found that I was getting the following error on my trace after calling the REST Service on the Policy flow:
GET //CRMFaseII/GestionMovilRS/FlexibleUpdateWorkOrder?IdWorkOrderFromType=3D1 HTTP/1.1
Via: 1.0 dcpsoapapi3 (Gateway)
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36
X-CorrelationID: Id-20c99d56781b0000070000005986553a 1
I found it weird, as the first call had no double slash.
Then I tried removing the extra slash (/) from the url at the step mentioned as follows:
Then I was able to invoke the service from the OAG address.
I'm working on version 184.108.40.206.0.
Thanks for your post, it was very helpful.
Thanks for the note. The version I was targetting in the blog post was 220.127.116.11.0, so probably the reason for the differences.