Much has been written on RedThunder.blog about the Oracle API Platform Cloud Service. In this blog, I am going to get into the advanced topic of Custom Policies. You would start exploring this area when the built-in policies do not cover your use case. The power and ease of implementing Custom Policies, I believe, is a killer value proposition of this platform.
Before we proceed, it would helpful to understand the backend technology of what the API Platform is built on. API Platform built-on the heritage of the sturdy and scalable WebLogic server.
There are 3 components:
- Management Portal – Used to create and manage APIs. This is an application hosted in WebLogic server, utilising WebLogic for clustering and scaling. Oracle hosts and manages this in our Public Cloud and automates the whole installation process, so you just have a make a few clicks to provision it. The Management Portal is the brains of the API Platform, registering Gateways and deploying and publishing APIs to the Gateways and Developer Portal. You can access all its functions through REST API.
- Gateway Node – Holds the run-time of the API. This is based on the Oracle Communications Service Gatekeeper (OCSG) from our telco-grade suite of products. Built-on WebLogic, the Gateway Nodes can be installed on any platform on-premise or in the Cloud (e.g. Amazon, Azure, Oracle). It is packaged as a zip file downloaded from the Management Portal itself. Once installed, the Gateway calls home to the Management Server to register itself. It pulls APIs and the policies associated with it from the Cloud once they are deployed. Gateways forms a logical cluster for HA purposes, so you deploy once and the APIs propagate to all the nodes in the cluster.
The Gateway Install zip also hosts the necessary code nuggets for customisation.
- Developer Portal – Used for developers to review documentation and subscribe to APIs. Also an application, this is by default hosted in the same WebLogic Server as the Management Portal. If you wish to run another Developer Portal, let’s say on-premise or customise it, you can extract the Developer Portal war from the Gateway Server install zip and host it in another WebLogic server.
Now coming to Custom Policies, they are essentially Java-code packaged as war files. The Gateway Install zip holds the code nuggets necessary to generate a Policy Stub. It also holds the necessary libraries aka Policy SDK (matching the version of the Gateway server) to compile against.
Continue reading “Creating Custom Policies for Oracle API Platform Cloud Service”
Much has been written on the design of ideal REST APIs, from Roy Fielding’s original description of HATEOAS interfaces, to much more practical approaches mirroring APIs rolled out by large technology companies. When working alone, I have a lot of freedom in how I design and build my APIs, and I always strive to design APIs which I would love to consume, based upon a number of undocumented, but strongly-held design intuitions. Collections are plurals; sub-objects are used sparingly, and mostly for practical considerations like payload size; HTTP status codes are used appropriately for particular types of errors and responses; etc.
When I work as part of a larger team, I often find that we end up building interfaces with slight inconsistencies, even if the design of them was based upon some documented high-level design principles. These inconsistencies impact the productivity of both internal and external developers which have to use these APIs, as they have to carefully parse the documentation to develop around the ‘quirks’ of the individual APIs.
Ironing out these inconsistencies can be achieved in a couple of ways, adopting a waterfall-style development model, in which each team is required to submit their detailed design specifications to an architecture council for review and sign-off; or putting a system in place which checks new API designs for consistency, and provides real-time feedback to API designers as they sketch out the interface. Oddly enough, the approach that I am going to discuss in this blog post is not the former; instead we are going to explore the Style Guide capabilities offered by Apiary.io, which allows us to develop rules governing API styles, which are assessed in real-time during API design.
Continue reading “API Design Governance – Style Guides in Apiary”
Previously, I showed how to use Terraform and PSM CLI to spin up a “Build Server” and use it to provision Oracle Integration Cloud (OIC) environments. You can find this blog here.
In this blog I am going to show you how to do the same, but to provision Oracle API Platform environments.
The approach that I will be following is the same:
Continue reading “Teaching How to use Terraform to automate Provisioning of Oracle API Platform”
Hi, just thought to post the solution for this error, when I hit this error, searched all over internet couldn’t find any specific blog describing possible cause of getting this error while invoking an API.
Let me give some background. I have created an API using Oracle API Platform Management Portal and when I tried invoking that API using google postman tool I was getting below error –
This was a silly mistake but worth highlighting. When we create API definition in API Management portal there is tab page “API Implementation” which has configuration field “API Request” where we need to define the API endpoint URL where consumer of this API will send input request. While I was declaring that portion I have given this URL “api/medrec”.
Continue reading “‘API life Cycle is invalid!’ Error for Oracle API CS API’s”
In this blog I am going to document the Oracle API Platform Gateway Node (Version : 18.1.3) Installation steps which is one of the critical components of API Platform Cloud Service.
Oracle provides API Platform Cloud Service as a foundation product for API Management that comprises the Full API Lifecycle, encompassing the complete API Design & Documentation, API Security, Discovery & Consumption, Monetization, and Analysis etc.
Oracle API Platform comprises 3 major components as stated below to serve specific purpose-
Management Portal – This is used to create and manage APIs, deploy APIs to gateways, and manage gateways, and create and manage applications. You can also manage and Deploy APIs and manage gateways with the REST API.
Developer Portal – Application developers subscribe to APIs and get the necessary information to invoke them from this portal.
Gateway Node – This is the security and access control run-time layer for APIs. Each API is deployed to a gateway node from the Management Portal or via the REST API.
In addition to above, Oracle also offer Oracle Apiary to quickly design, prototype, document and test APIs.
Below is the high level architecture diagram of API Platform.
Continue reading “Oracle API Platform Cloud Service – Installation Steps of Gateway Node”
Infrastructure as Code is becoming very popular. It allows you to describe a complete blueprint of a datacentre using a high-level configuration syntax, that can be versioned and script-automated. This brings huge improvements in the efficiency and reliability of provisioning and retiring environments.
Terraform is a tool that helps automate such environment provisioning. It lets you define in a descriptor file, all the characteristics of a target environment. Then, it lets you fully manage its life-cycle, including provisioning, configuration, state compliance, scalability, auditability, retirement, etc.
Terraform can seamlessly work with major cloud vendors, including Oracle, AWS, MS Azure, Google, etc. In this blog, I am going to show you how simple it is to use it to automate the provisioning of Oracle Cloud Infrastructure from your own laptop/PC. For this, we are going to use Vagrant on top of VirtualBox to virtualise a Linux environment to then run Terraform on top, so that it doesn’t matter what OS you use, you can quickly get started.
This is the high-level idea:
Continue reading “Teaching How to use Terraform to Manage Oracle Cloud Infrastructure as Code”
In this blog I am going to show you three new capabilities introduced in Oracle Integration Cloud (OIC) that massively simplify the enablement of Application integration with extensions to Business Process Automation workflows and finally how to expose all of that as secured APIs via the Oracle API Gateway.
These three new capabilities are:
- Call your Process Cloud Service (PCS) workflows from an Integration Cloud Service (ICS) orchestration.
- Call your ICS integrations from a PCS business process.
Expose your ICS integrations as APIs into the Oracle API Gateway
Our scenario is simple, it is an incident management extension, that requires some human intervention to manage service requests.
To be specific, let’s assume the following components:
- We need to extend Oracle Service Cloud out-of-the box incident Management functionality with a custom business process automation. For this, Oracle Integration Cloud Service (ICS) will seamlessly listen/subscribe to events in Oracle Service Cloud and when a new Service Requests gets created, it will pass it on into Oracle Process Cloud Service (PCS) to manage the Human interventions.
- PCS starts a new workflow and it redirects the various tasks to the appropriate task owners for approvals/rejections.
- As the PCS workflow runs across the various human interventions, PCS keeps updating the Service Request status into Service Cloud (via ICS) to determine whether it is invalid and needs to be rectified or it is in progress until completion.
- Finally, if we determine that this Incident Management extension workflow could become a reusable asset among other use cases, we can simply go to the ICS integration that triggers the PCS workflow and expose it as an API to be deployed and run into the Oracle API Gateway.
This is a high-level view:
Continue reading “Teaching how Oracle Integration Cloud (OIC) simplifies Application Integration, Process Automation and API Management”