top of page

Integrating with Oracle Hospitality OPERA Cloud

This article explains how to work with integration on OPERA Cloud, with a focus on real-time solutions. No matter what kind of integration you want, it must be implemented through OHIP, Oracle Hospitality Integration Platform.

Before continuing, I would like to remind you that I made a high-level article to highlight what needs to be done before starting, so please read the article article first.

Mission

The approach is to develop a streamlined client focused solely on forwarding events to Oracle Streaming Services (OSS).Read more about Streaming API

Requirements

The requirements for this WebSocket (WS) client include:

1)      Stay connected 24/7.

2)      Auto ping to keep connection alive.

3)      Refresh authentication token every hour, -  only valid for 1 hour.

4)      Keep tracking of Offset state. What has been sent to OSS.

5)      Forward events to Oracle Streaming Services.

6)      Support multiple stages, - development, test, production.

7)    Monitoring for client metrics.

8) All passwords and other secrets must be saved and fetched from OCI Vault.

Choice of programming language

Choosing the most appropriate programming language is a crucial decision when setting up the OHIP client. The choice will depend on your preferences and in my situation the default choice is python.Prior to making a language selection, I established the client requirements:

1)      Easy support for WS Client against GraphiQL.

2)      Must be able to support asynchronous functions.

3)      Proven tools and projects using WS.

4)      Must be able to run it on OCI.

After evaluating WebSocket support and considering factors for stable and easy deployment, the decision was made to use NodeJS/TypeScript. TypeScript is a strongly typed, object-oriented, compiled language that offers advanced asynchronous patterns, making it an ideal choice for this client.

Choice of service to run client

image (4).png

We have several options for running our client in Oracle Cloud Infrastructure (OCI).

Run as OCI Instance

​Initially, I set up the application on an OCI Compute instance, but I ended up using a Docker setup anyway. Given the challenges of maintaining OCI Compute instances and their higher costs, it became clear that they weren't the best option for this use case.

Run as Container instance

Using OCI Container Services has proven to be the easiest solution with significantly less maintenance compared to managing an OCI Compute Instance.
Since we're already using Docker for development, choosing OCI Container Services was an easy decision. Deployment is nearly as straightforward as deploying an OCI Function, making it a seamless extension of our workflow.

OCI Container Instances are ideal for our needs as they allow us to start containers that run continuously until we stop them. Additionally, we can configure auto-scaling to dynamically adjust resources, ensuring the system can handle increased workloads seamlessly.

Run as OCI Function

The development setup aligns almost perfectly with OCI Container Services, making it a natural fit. In contrast, OCI Functions are limited to a 3-minute execution time, which makes them unsuitable for our use case.

Structure of WS Client

1737725928241.png

The overall architecture for this solution

As outlined in the Requirements section, a robust client is needed to control event reception based on the QueueSize.

What we need is a client that is connected to the OHIP Stream API 24/7 and is forwarding events to an internal Queue. A Queue handler, which runs asynchronously, will monitor the queue and forward events to OSS. The queue handler will save the offset state to an object in OCI Object storage and when starting the client it will fetch the current offset state.

As seen above I have created a drawing of the architecture of the WS Client. To get started, download and try Luise Weirs demo client. This is a good baseline for creating a robust architecture.

1737639126373.png

Once the solution is operational, we need to monitor its performance. To achieve this, we send log and metric data from the WebSocket client to OCI Log Analytics and Metrics. This allows us to set up alarms and triggers for any missing data.

image (6).png

This is the QueueSize reported real-time to a OCI Custom Metrics.

Next steps

Events are now being published to Oracle Streaming Services, and the OHIP interface allows you to select the specific business events you wish to receive.

You can now tab in to the stream and process the data:

 

  1. Store data in OCI Data lake.

  2. Process and transform data with OCI Date flow (Spark)

  3. Update tables in OCI Data Warehouse

  4. Push data events to Oracle CX Unity (Customer Data Platform)

  5. Push events, via Unity, to marketing automation platforms like Eloqua or Responsys

Keys to success

1)      Start with Postman. Get all requests to work before starting development.

2)      Focus on logging and debugging. Make it easy to see whats going on!

Links:

  • LinkedIn

Written by: Henrik Jochumsen

bottom of page