PaaS Community Blog

Teaching How to Recover Errored Instances with Oracle Integration Cloud by Carlos Rodriguez Iturria

Building Enterprise integrations in the Cloud with iPaaS brings many benefits, including among others: simplicity, agility and scalability. However, these benefits should not be taxed by having a weak core, not able to properly manage common enterprise requirements, such as error management. I’ve been a bit disappointed with how most iPaaS vendors handle runtime exceptions of integration flows. A typical example of this, is not being able to support dehydration for asynchronous flows (i.e. dehydration is crucial to supporting long-running instances by saving their memory state into a database, until a correlation invocation, a.k.a call-back, wakes it up to continue with the flow). This causes that when an error occurs, recovery has to start from the beginning of the integration flow that failed.

In these situations, we would have to either design an integration to be fully idempotent and stateless across all its partner links (service invocations), which is not always possible. Another way to do it is by manually handling the recovery of errored scenarios, this is to avoid state inconsistency across the previous service invocations in the orchestration, prior to the error… But then if we have to manually handle compensation, what about iPaaS being easier?

Luckily, Oracle Integration Cloud maintains simplicity at the front end and a mature and strong integration core at the backend. It acknowledges when an orchestration is asynchronous, so that dehydration points (a.k.a. break points) are enforced along the way across service invocations or long-term actions (e.g. waits), enabling with this long-term running instances avoiding to timeout, but to stay in memory (and DB back store) until all activities and external call-backs in the orchestration flow complete. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Oracle API Platform Cloud Service: Design-First approach and using Oracle Apiary by Marc Lameriks

At the Oracle Partner PaaS Summer Camps VII 2017 in Lisbon last year, at the end of august, I attended the API Cloud Platform Service & Integration Cloud Service bootcamp.

In a series of article’s I will give a high level overview of what you can do with Oracle API Platform Cloud Service. The version used of Oracle API Platform CS was Release 17.3.3 — August 2017.

See https://docs.oracle.com/en/cloud/paas/api-platform-cloud/whats-new/index.html to learn about the new and changed features of Oracle API Platform CS in the latest release.

In preparation of creating an API Blueprint document, I took a closer look at Oracle REST Data Services and used the RESTful Services feature in Oracle SQL Developer, to generate example JSON payload’s based on some tables in the “HR’ schema. For more information about this, see my article “Oracle REST Data Services (ORDS)”.
_{[https://technology.amis.nl/2018/01/22/oracle-rest-data-services-ords/]}

In this first article in the series about Oracle API Platform CS, the focus will be on the Design-First approach and using Oracle Apiary.

Short overview of Oracle API Platform Cloud Service

Oracle API Platform Cloud Service enables companies to thrive in the digital economy by comprehensively managing the full API lifecycle from design and standardization to documenting, publishing, testing and managing APIs. These tools provide API developers, managers, and users an end-to-end platform for designing, prototyping. Through the platform, users gain the agility needed to support changing business demands and opportunities, while having clear visibility into who is using APIs for better control, security and monetization of digital assets.
_{[https://cloud.oracle.com/en_US/api-platform/datasheets]}

Architecture

Management Portal:
APIs are managed, secured, and published using the Management Portal. The Management Portal is hosted on the Oracle Cloud, managed by Oracle, and users granted API Manager privileges have access.

Gateways:
API Gateways are the runtime components that enforce all policies, but also help in collecting data for analytics. The gateways can be deployed anywhere – on premise, on Oracle Cloud or to any third party cloud providers.

Developer Portal:
After an API is published, Application Developers use the Developer Portal to discover, register, and consume APIs. The Developer Portal can be customized to run either on the Oracle Cloud or directly in the customer environment on premises. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Web APIs: A Pillar of Digital Transformation Oracle API Cloud Services – Part 2 by Rolando Carrasco

How to Publish APIs to the API Portal

Either for internal or external purposes, it’s necessary to have an API Portal where 3rd parties or internal developers can register applications to subscribe to APIs. Our API management strategy will be successful only if developers actually use our APIs. And if that happens, we need to:

• Identity those developers
• Manage them
• Communicate to them any changes in our APIs
• Understand how they’re using the APIs
• Receive feedback from them

An API Portal is key to enabling this communication. Oracle API Platform Cloud Service offers an out-of-the-box portal that you can use to fulfill the requirements listed above. In the next section of this article we will publish our Tickets API to the API Portal.

The following steps are performed within the API Manager Portal:

(https://<hostname&gt;:<port>/apiplatform)

Login as an API manager user: Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Validating API Platform Policies & Gateway Deployments by Phil Wilkins

When configuring API Policies in the the Oracle API Platform it helps if there is a simple back end that can take the received payload and record the sent values (header & body) as well as reflect the call details back as the response, or possibly respond with a test payload (so that response policies, particularly policies that require payload navigation  can be exercised correctly).  By having this facility it becomes a lot easier to determine whether the policies are executing correctly in terms of routing, transforming, filtering etc. without needing to worry about whether the API implementation is correct. You could say that this is a kind of mock for testing the API Platform.

The added benefit of having a mock back end is that it is easy to ‘smoke test’ a gateway deployment very easily.  Particularly if the mock is happy to receive any form of call.

Whilst implementing such a capability can be done in pretty much any language and platform you like.  We have in the past for example built a Springboot Java application that can have the dependencies configured to then deploy into WebLogic for example.  We have come to refer these test apps/mocks as PlatformTests as that’s exactly what they help do. A Node.js implementation of a PlatformTest such as as the following implementation is particularly appealing as the Node.js footprint is small and simple to deploy and undeploy. A basic Node.js implementation can also consume any URL and operation you choose to use. The nature of JavaScript makes it very quick to adapt the mock if need be. Although in the ideal world, we write the solution once and then use simple configuration to tune behavior. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Teaching How to Design and Secure an API with Oracle API Platform by Carlos Rodriguez Iturria

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:

1. Create an Apiary account used to Design APIs (API First approach) and create a new API Project using the existing MedRec Swagger API-definition.

2. We are going to spend a little bit of time playing with Apiary to feel comfortable in areas such as:

1. Validating API definitions

2. Testing API endpoints

3. Switching across out-of-the-box Mock Servers and real Production MedRec service end-points. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Understanding API Deployment State on API Platform by Phil Wilkins

The new Oracle API Platform makes it possible to deploy different versions of your APIs to different gateway instances. When you you’re managing the Development API Policies through all the different stages of the lifecycle (Design to Production) from a single management tier such a capability is essential. This is further challenged by the fact that each save of you API Definition creates a new iteration (the term used to identify each saved ‘version’ of the API)

However it does lead the challenge from a management perspective of knowing which iterations are running on each Gateway. You can get the information from the current UI but it requires multiple steps to get the information. The UI also lends itself more to the design processes today than perhaps the more dense information views that an operational report might warrant.

I’m sure that over time these views will come, but today we can solve the problem by taking advantage of the fact that the product lives by its own ‘mission’ by offering a very rich set of APIs. As a result it becomes possible to actually build your own views. To that end I have written a Groovy script which will go through each API that can be seen and retrieves the iteration deployed to each logical gateway. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress