Better Together: Oracle Cloud Applications APIs and Oracle API Gateway

Summary

This blog explains how to setup Oracle’s API Gateway – a serverless component from Oracle Cloud Infrastructure (OCI) – to directly call Oracle Cloud Applications REST APIs. I will show how it is done for Oracle ERP Cloud – but this applies to any API exposed by Oracle’s Cloud Applications.

I will not only explain how the setup is done, but I will also explain why you would do this. This blog is not a tutorial on OCI or Oracle's API Gateway.


Why?

So, let’s start with the ‘Why’ question. What value can be derived from using Oracle’s API Gateway in front of Oracle Cloud Applications REST APIs? Quite a lot of value it seems.

First of all, you need to know that Oracle Cloud Applications expose literally hundreds of REST APIs which can be called by other SAAS services, mobile apps, chat-bots and so on. The amount of innovation that can be created using those REST APIs is only limited by your imagination. But you don’t want to forget about security, right?

The innovation you want to bring to your users needs to be delivered in a way that adds value to them (that’s where your imagination plays a role), but it also needs to be delivered in a secure way and that’s where the API Gateway can play a role.

Oracle’s ERP Cloud REST APIs are secured by means of different authentication options. You can go for basic authentication (username-password based). You can also go for token based SAML or JWT authentication. All of this is nicely documented here: https://docs.oracle.com/en/cloud/saas/applications-common/21b/farca/Quick_Start.html

When you access the Oracle Cloud Applications REST APIs as an authenticated user you can only access the data you are entitled to see, and you can only access the REST APIs you are entitled to call. Things are very secure to start with.

But some things cannot be easily done using Oracle Cloud Applications REST APIs. What if you want to throttle the amount of API calls that get routed to Oracle’s ERP Cloud? What if you want to have a custom authentication method that is currently not supported by Oracle’s HCM Cloud? What if you want to enable CORS (Cross-origin resource sharing) based restrictions on the API to bring the security to the next level? What if you want to enable IP whitelisting for a subset of APIs?

All these things – and more – can be done using the API Gateway together with Oracle Cloud Applications. As is the case with most features of Oracle’s Cloud Infrastructure, Oracle Cloud Applications and OCI are really ‘better together’ and they enhance each other’s value and capabilities.

One of the good things about the API Gateway is that it is entirely built as a serverless platform. You don’t need to maintain or pay for servers. You only pay for the actual calls you make. More information can be found here: https://www.oracle.com/cloud/cost-estimator.html


How?

Now that we know why you want to have the API Gateway in front of Oracle Cloud Applications, let’s look at how you can do this. I will use Oracle's ERP cloud as the example.


Access to an OCI tenancy

You need access to an OCI tenancy. If you don’t have access to one, you can start a free trial here: https://www.oracle.com/cloud/free/

Please note that the API Gateway is not part of the ‘Always Free’ tier. It is however available during the first month of your trial.


Create an API Gateway

This blog is not a tutorial on setting up an API Gateway, but if you don’t know how to setup an API Gateway then you can follow the steps in section (I) documented here: 

https://www.ateam-oracle.com/a-simple-guide-to-setup-api-gateway-with-oracle-integration-cloud

Now you should have an API Gateway enabled without any deployments yet.


Create Deployment(s)

The next step is to create a deployment. You can create a deployment per ERP Cloud instance, or you can create one for all of your ERP Cloud instances. I have created a single deployment using the “/fa” path which will cover all ERP Cloud Instances I want to connect to:


Create Route(s)

The next step is to create one or more routes. You need to have at least one route per ERP Cloud instance. You can have more routes per ERP Cloud instance if you want to have specific policies for a subset of APIs. For instance: if you want to throttle the REST APIs which can be used to query for invoices but you don’t want to throttle the REST APIs used to create expense reports.

I have created one route for my ERP Cloud Instance:


The following settings are very important:

PATH 

this specifies how the API will be called by the external applications. In my case I have a single route to cover all calls to my instance so I have /PROD/{generic_path*}. Please note that the generic_path parameter will capture the entire URL which is entered after /PROD/. This means that if a call to /PROD/fscmRestApi/resources/11.13.18.05/invoices/ID
is made,  fscmRestApi/resources/11.13.18.05/invoices/ID will be found in the generic_path variable. This is the way you enable ALL or a subset of APIs to be handled by a specific route.

URL

this specifies where the API Gateway will route the call. In my case I have a single route to cover all calls to my instance so I have
https://<your path to ERP cloud>/${request.path[generic_path]}.
This route will just forward all traffic directly to your ERP Cloud Instance. Please we use the generic_path variable to forward the entire URL.


Test it out!

And that’s it! You just need to look at the endpoint exposed by this API Gateway Deployment as follows:

You can now use the following URL (just an example) in your favorite REST API toolkit:

https://XXX.apigateway.eu-frankfurt-1.oci.customer-oci.com/fa/PROD/fscmRestApi/resources/11.13.18.05/invoices/ID

And you will get the following result if you have included the necessary authentication headers in the call:


And Now?

Right now, this API Gateway is just forwarding all traffic. Now you can start using throttling or custom authentication or whatever is available as functionality in the API Gateway to secure or limit your API calls to ERP Cloud even further. Please look at the API Gateway documentation because that is not really the purpose of this blog:

https://docs.oracle.com/en-us/iaas/Content/APIGateway/Concepts/apigatewayoverview.htm


I hope this is helpful and good luck!


Alex.

I am not a spokesperson of Oracle and the information in this blog reflects my personal findings and opinions.

Comments

Post a Comment

Popular posts from this blog

Create a complex multi-subject area analysis in Oracle Transactional Business Intelligence

Image
Summary Oracle Transactional Business Intelligence (OTBI) is a great reporting tool that is embedded in a lot of Oracle's cloud services - including ERP Cloud, HCM Cloud and many others. A lot of reports and analyses come out-of-the box and you can use the BI tool itself to change existing reports and/or create new ones. Creating a new report is really easy and does not need any IT involvement. It involves dragging and dropping the fields you want analyse and then choosing a nice layout: But what if you want to need to do something much more complex such as combining data from different possibly unrelated subject areas and joining them together?  This blog will explain how you can do that and provide you an example. Subject Areas Data in the OTBI repository is grouped in subject areas. You can easily create your own analyses using the pre-defined subject areas. These subject areas are defined as follows in the online documentation : The BI repository defines the columns that are av
Read more

Use your own approval engine with Oracle SAAS Applications

Image
  Summary There are a lot of approval flows that come out-of-the-box with Oracle's SAAS applications. Just think of the AP Invoices or Purchase Order approval flows in Oracle ERP Cloud. These flows are implemented by Oracle development in Oracle BPM. Most of the times a user-friendly user interface is also delivered allowing users to customize the approval flows without having to write code. Because as soon as you write code you lose upgradeability. But this user-friendliness comes at a cost: you do not have access to all the nice state-of-the-art features of Oracle BPM. Although you can implement 99% of your requirements using the delivered screens in an update-safe way, you might have a mandatory requirement that is not covered by what is available out-of-the-box. This blog explains a way to externalize some approval processes allowing you to use an external business process engine such as Oracle Process Cloud ( https://www.oracle.com/cloud/integration/process-cloud-service/ ) or
Read more