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”
This blog is the second part of an end-to-end exercise that starts explaining the steps to clone a GitHub repository that contains an agnostic Medical Records application, built by us in NodeJS and which exposes REST API endpoints via a Swagger API-descriptor running locally on Swagger UI (all included as part of the repository). The previous part of this 2-blogs series also explains the steps required to run the MedRec NodeJS application on Docker containers either locally or in the Oracle Public Cloud. For more information about this first part, go here.
Moving to this second part, we are going to cover the following steps:
- Create an Apiary account used to Design APIs (API First approach) and create a new API Project using the existing MedRec Swagger API-definition.
We are going to spend a little bit of time playing with Apiary to feel comfortable in areas such as:
- Validating API definitions
- Testing API endpoints
- Switching across out-of-the-box Mock Servers and real Production MedRec service end-points.
Login to Oracle API Platform and configure an API, this includes:
- Enforcing Security and other policies.
- Deploy API and securing access level to on-premise and Cloud-based API Gateways.
- Publishing APIs into the API Developers Portal.
- Linking API to Apiary Swagger API-definition living document.
Login to API Developers Portal (API Catalog)
- Register a New Application
- Understanding the role of API Keys
- Reviewing MedRec API Documentation
- Registering to consume MedRec APIs
- Testing APIs.
- Understand API Analytics, consumption, metrics and monitoring dashboards.
Continue reading “Teaching How to Design and Secure an API with Oracle API Platform”
The first AppDev Made Easy (previously known as DX Workshop) for this tour started in Perth. We are continually trialing a few different things as such as we incorporated Fn project https://fnproject.io.
The whole demonstration of Functions was to articulate that there are different ways to execute and understanding the problem to solve as well as the values that the organisation holds (including both business and IT departments including developers) which will determine the technology.
For the demo we start from the very beginning.
Continue reading “Experimenting with Fn project”
In this blog, I want to share my experience after having created many APIs using different approaches and technologies. I am going to encapsulate a simple process that will help you construct APIs, starting from scratch with an idea or requirement and move it all along to a happy consumption.
The best part of APIs is that they are microservices enablers, which implies that they are not technology prescriptive, so in this blog you will see that your APIs can be implemented using any technology or programming language.
I decided to use “Jokes” as the vehicle to explain the APIs construction best practices, mainly because jokes are a simple concept that anyone can relate to, but also because I want you to feel compelled to consume these APIs and by doing so, get a laugh or two.
My original idea with jokes is to:
- Get a random joke.
- Translate the joke to any language.
- Share the original or the translated joke with a friend via SMS.
This is the high-level view of how our end solution will look like:
Continue reading “Teaching best practices to Design, Build, Secure and Monitor APIs”
APIs are becoming the window to the digital assets of the modern business. Well documented, well governed and easy to use APIs are key to their successful uptake, longevity and associated business success. Yes, I did say well documented. In this instance I am talking about the documentation required to describe the APIs capabilities in a manner that is meaningful for your ultimate audience, the “API Consumers”, however it will also provide the template for the API Developer to develop their code from. In the modern business climate, we probably don’t want to produce War and Peace, we simply want to take a minimum viable approach to our API documentation. But where would I find a capability that will simplify our task as API Designers, capture the design documentation for our APIs, allow us to do some initialise testing to validate the usefulness of our design before any code is cut, and also have the documentation ready for consumption by team members and interested parties using a standards based approach. Where indeed ! Look no further than Apiary.io. Continue reading “Apiary designed APIs tested using Dredd”
In this blog, I am going to show you how to get started with the Loopback framework to easily auto-build REST APIs in NodeJS and persistence layer in a variety of options, including relational and non-relational databases e.g. In-memory DB, MongoDB, MySQL, Cassandra, Oracle, etc.
In terms of API design and development, Loopback allows you to work “top-down” or “bottom-up”. I am going to cover both approaches in this blog.
First, we are going to create an API model definition in place, as we are building the REST APIs, this exercise will give us a Swagger-based API definition. Alternatively, we are going to start from an existing Swagger definition and use it to implement NodeJS REST APIs pointing to a persistence layer of choice (in-memory DB, MongoDB, MySQL, DB2, Oracle, etc.). I personally prefer the “API First/Top Down” approach, as it gives me the option to properly design and test my APIs first and then, simply move to implementation phase, but this ultimately depends on situations, preferences and requirements.
Continue reading “Teaching How to simplify building NodeJS APIs with Loopback Framework”
Modern Integrations require touching lots of different APIs coming from multiple “systems”. These “systems” can be big enterprise backend applications, such as: E-Business Suite, SAP, JDE, Siebel, etc. As well as modern SaaS Applications, such as: Service Cloud, ERP Cloud, Salesforce, Netsuite, Workday, etc. These “systems” can also be other smaller or custom applications running either on premise or in the cloud exposing either SOAP or REST services.
Rarely any of these “systems” can provide solid abilities to remotely expose APIs in a way that are tailored for a specific business case. Commonly, to achieve this, we need a separate integration layer that orchestrates APIs from multiple “systems” and easily obtain the desired business outcome, in a way that they are also reusable APIs to be utilise in other business scenarios. Furthermore, in order to properly apply security measures and effectively protect these APIs and safely expose them to external consumers (potentially in the public Internet), normally we need to use an API Gateway (see this blog to learn how).
Also, in previous blogs, John Graves showed us how to automate the creation and deployment of existing “internal Integration APIs” and expose them as secured external APIs using Oracle API Platform. (See ICS to API Platform and Oracle Service Bus to API Platform).
If we take the same automation concept, we can then apply it in a DevOps scenario, where we want to achieve the following:
Continue reading “Teaching how to DevOps automate the provisioning of external APIs using Oracle API Platform and Developer Cloud Service”