API Gateways have gotten increased exposure over the past few years, as SaaS offerings from major vendors continue to accelerate in usage. SaaS in general provides many benefits to customers, but it does present several challenges relative to integrations and extensions, as you are restricted to public API's provided by the vendor, or native file loading capabilities, if you want to perform inbound and outbound data movement of any kind.
In Oracle FA specifically, the necessity of utilizing the API framework for your real time or near real time needs is paramount, and Oracle does a good job of documenting their API capabilities, which can be seen here for Financials, and just with a few clicks you can browse API support for other FA offerings.
Now, an API Gateway provides a layer between the caller and the target, let's say Oracle FA, where in you can perform several actions that will greatly benefit you at scale. With an API Gateway you get some of the following benefits, which are summarized in the graphic below in bullet #1, also, #2 talks to some of the capabilities that you would not want to perform in the gateway, and instead utilize a middleware tool for.
Let's take Oracle ERP as an example, and let's say you want to publish AP related API's to certain consumers but you want to distinguish the traffic generated among them, and you want to protect ERP from abuse. With the gateway you can create quota policies that will limit the usage of the consumer of the API that is proxied in the gateway, and after the user has utilized their quota, their access will be revoked. Similarly, you can create spike arrest policies that will prevent abnormal behavior from taking place, in the way of excessive amount of calls from a consumer that typically does not have that kind of volume. You can also create security policies that inspect incoming request payloads and look for malicious code, in the proxy execution flow, before the message can damage the target. In terms of usage metrics, you can direct results from the API interactions to an Enterprise Logging tool, such as Splunk, where you can build dashboards that will give you in depth analytics about who is making which calls, and what the errors are, etc. so you can discover trends and proactively resolve issues, and you will not be able to do this by just allowing users to call API's in FA directly, and troubleshooting will be labor intensive.
Let's discuss another use case, around simplifying consumer experience of your services. In ERP, oftentimes you need internal ID's from multiple API call's to ultimately perform an action, or just executing API's in sequence. Examples of this can be creating an AR Invoice for a new customer, creating a new customer, or creating a supplier, where multiple API calls have to be made in sequence to accomplish the task. In order to simplify the process and create developer friendly APIs, you can utilize your gateway to create API chains, where you can create a consolidated proxy endpoint with all the payload elements that the consumer will need to pass, and they can make that one call to create a new supplier, and your gateway will then orchestrate the chain of events to create the header, sites, addresses, locations, etc. without burdening the consumer who likely doesn't understand Oracle ERP. You can also hide away the complexity from the Gateway entirely, and proxy an application driven integration from OIC in the gateway instead (or another middleware), as shown in the below example, this is very useful if the actions in the gateway would require significant business logic or complexities beyond what is recommend as far as Gateway scope (see first graphic). Additionally, you can drive reusability and speed up adoption since consumers will just need to meet your payload requirements and understand their own data, and not build significant technical debt or have significant knowledge of Oracle ERP technically.
The above is exemplified in the following graphic, where the Apigee API Gateway is utilized to hide away the complexity of creating a Customer from the consumer. Here the consumer calls the gateway with a consolidated payload, and the gateway invokes OIC where the various API calls to accomplish the task are performed, without the consumer needing to take on this complexity.
Lastly, in terms of options, Oracle has an API Gateway offering that integrates very well with FA and also the Oracle Integration Cloud, and if you don't have an enterprise wide gateway that you are required to use, this will be your best option, you can read more about it here. However, if you have your own gateway and want to use it to enhance FA in ways similar to those described here, then you can certainly proxy your API's in your gateway of choice, and you will just need to integrate your Gateway with Oracle IDCS to securely do auth with FA, unless you are willing to store basic authentication details in your gateway and bypass IDCS (which is not recommended).
No comments:
Post a Comment