XtremeCloud 3M Pak for Oracle E-Business Suite (EBS)

Xtremecloud Migration, Modernization, and Maintenance (3M) Pak.

Introduction

Migration

The XtremeCloud 3M Pak for Oracle E-Business Suite (EBS) is a set of Ansible Playbooks hosted in Ansible AWX, the upstream open source fork of Red Hat Ansible Tower, that facilitates a smooth migration of an on-premise Oracle EBS implementation to a Cloud Service Provider such as Amazon Web Services (AWS) and Oracle Cloud.

In addition to the generally-available Ansible collections for AWS and Oracle Cloud, this 3M Pak includes Ansible Playbooks specific to an Oracle EBS migration to the cloud. With our secret sauce added to the Ansible Playbooks, our customers experience migration automation that has captured decades of Oracle EBS experience, and underlying Oracle technologies experience, that will simplify and accelerate the cloud migration effort.

Modernization

You cannot bring up modernization in today’s IT landscape, particularly the cloud, without talking about Kubernetes. Eupraxia Labs does not bring up Kubernetes or dive head first into the technology without a broader automation strategy. Kubernetes can’t manage your entire application lifecycle, nor can it bootstrap itself. You cannot settle for automating the inside of a Kubernetes cluster while using manual processes to build and manage your cluster. This becomes increasingly difficult as you manage more than one cluster. Multiple clusters are certainly a best practice for many environments. For instance DevOps, Staging, and Production clusters, or possibly a private internal cluster and a public facing cluster.

We consider Kubernetes clusters to be essential for any effort to modernize as a cloud migration occurs. Of course, Kubernetes clusters do not just appear out of thin air. They must be provisioned, configured, and maintained. With the XtremeCloud 3M Pak for Oracle E-Business Suite, we take care of that heavy lifting. You can provision Kubernetes clusters through a Cloud Service Provider’s (CSP) managed offering (e.g. Marketplace) or you can use our Kubespray Ansible Playbook for your own self-managed Kubernetes cluster.

One important facet of modernizing an IT landscape is to move the on-premise Identity and Access Management (IAM) solution to a cloud-native solution that is easier to deploy and maintain.

NOTE

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

Oracle E-Business Suite (EBS) is in use by thousands of customers worldwide today. Many of those customers have implemented single sign-on (SSO) to ensure a smooth user experience. The most common use case is to deliver a transparent sign-on experience from the user’s desktop through to EBS. The traditional, certified approach for achieving this is through the deployment and integration with Oracle Access Manager (OAM) and either Oracle Internet Directory (OID) or Oracle Unified Directory (OUD) as depicted below.

While this approach is well understood and documented, it introduces a number of additional components and additional complexity to an EBS deployment. For SSO you need to deploy Access Manager, a Directory, a WebGate, an AccessGate, and configure each to integrate with EBS. All of these additional components need to be cared for, nurtured, patched, and updated. It’s a lot of work and prone to misconfigurations. For some customers, this additional complexity has led to delayed SSO implementations, resulting in a poor delivery experience.

However, we provide a simpler option available which will still enable that streamlined user experience you require, without the need to deploy and manage all of the above components, and without the need to make significant configuration changes within EBS, such as configuring the integration with OID or OUD.

Our cloud-native XtremeCloud Single Sign-On (SSO) is Eupraxia Labs’ multi-cloud Credentialing, Identity, and Access Management (CIAM) platform, which now enables SSO to a standard installation of EBS through its EBS Connector. The figure below shows this simplified integration.

Source Code Management (SCM) Best Practices

Playbook Repository Structure

It is recommended that the playbook repository structure follow a certain layout. You must create a structure that works with both Ansible Core and Ansible AWX/Tower. Here is an example of a repository structure:

Davids-MacBook-Pro:eds-ansible davidjbrewer$ ansible-galaxy init role_name --offline
- Role role_name was created successfully
Davids-MacBook-Pro:eds-ansible davidjbrewer$ tree role_name/
role_name/
├── README.md
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

8 directories, 8 files

Some notes regarding this layout:

ansible.cfg is at the root of the repository. It allows you to keep version control on the basic Ansible settings. groupvars defines the group variables for the playbooks The inventory is best managed within Ansible AWX/Tower.

A best practice is to have a playbook repository structure by team. For example, Infrastructure, App_1, App_2, Patching. In this example, there are no roles in the repository /roles directory. A best practice is to separate “roles” into its own repository so they can version controlled, shared and life cycle independently of other playbooks.

Use and Create Roles

Roles are a way of automatically loading specific vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows for easy sharing with other users. Here are a couple best practices around roles:

A repository should be created by each role. This allows you to share an individual role with Ansible Galaxy or with other Playbook repositories inside your organization. You should be able to perform unit testing in each role in a Continuous Integration (CI) model. A convenient way to test roles is by using containers. This will allow you to test the role across multiple distributions. Virtual machines (VM) are recommended to test roles when the role is performing low level actions like bootloader setting, kernel parameters, firewall settings, etc..

Use the ansible-galaxy command to create the role structure:

ansible-galaxy init role_name --offline

A .gitignore file should be used to ignore every role inside a playbook repository and allow them to be managed individually with a SCM.

XtremeCloud SSO EBS Connector

The EBS Connector offers the following features when implementing SSO with EBS applications:

• Non-intrusive solution, requiring minimum configuration changes in the EBS application. After SSO is enabled, administrators can continue accessing EBS directly if needed for recovery purposes or fail over.
• Support EBS mobile applications build on Oracle Mobile Application Framework like Approvals and Expenses.
• Support Single Logout (SLO) with XtremeCloud SSO and EBS application.
• Support multiple access modes for SSO with EBS application:
• Access using EBS Connector’s URL
• Access via redirect using EBS default login page
• Access via EBS deep links (e.g., links on email notifications)
• Support integration of EBS with Oracle Web ADI documents.
• Enhanced security on EBS applications by leveraging XtremeCloud SSO strong authentication and adaptive security capabilities, including multi-factor authentication, risk based adaptive authentication and access policies.

1. The user requests access to an Oracle E-Business Suite protected resource.
2. Oracle E-Business Suite redirects the user browser to the E-Business Suite Connector application.
3. The E-Business Suite Connector redirects the browser to XtremeCloud SSO.
4. XtremeCloud SSO presents its single sign-in page to the user.
5. User submits credentials to XtremeCloud SSO.
6. XtremeCloud SSO issues an authorization code and redirects the user browser to the E-Business Suite Connector.
7. The E-Business Suite Connector exchanges the authorization code for an access token.
8. XtremeCloud SSO issues an access token and an ID token to the E-Business Suite Connector.
9. The E-Business Suite Connector creates an Oracle E-Business Suite cookie and redirects the user browser to Oracle E-Business Suite.
10. Oracle E-Business Suite presents the user with the requested protected resource.