Homepage 5 Tag: Oracle

Oracle receives Digital World Class status in EPM

by | September 4, 2024 | PROMATIS recommends

Oracle has received the status as Digital World Class in a recent research study by The Hackett Group.

The EPM Digital World Class Matrix study evaluates the 12 leading EPM software providers and their ability to deliver value. Additionally it offers insights on key benchmarking metrics and return on investment measures for finance leaders.

The research from The Hackett Group® found that two of the software providers – OneStream and Oracle – achieved Digital World Class® status in all three areas that were analyzed – integrated EPM and two subsets – close and external reporting, and planning and forecasting. One additional vendor – Anaplan – achieved Digital World Class status in the planning and forecasting ratings.

Read the full press release here.

Running Oracle SOA Suite on Docker - Part 5: Interactively Creating Repository (RCU) and Domain

Running Oracle SOA Suite on Docker - Part 5: Interactively Creating Repository (RCU) and Domain

by | August 20, 2024 | Techblog

Johannes Michler PROMATIS Horus Oracle


Executive Vice President – Head of Platforms & Development

Operating - installing and maintaining - Oracle Fusion Middleware, especially Oracle SOA Suite 12.2.1.4 is quite some work. Not only does installation itself consist of a number of steps, but each quarterly critical patch update also requires applying a number of patches and - especially in simple, single server environments quite some downtime.

This blog post series will cover how to run Oracle Fusion Middleware - especially Oracle SOA Suite on docker. The first post covered the high-level steps of manual installation, Docker and Kubernetes options and has pointers to the relevant Oracle certification documentation. The second post then described how - using OCI and Oracle Linux - a host to run docker containers can be setup up within minutes. After that in the third post we covered provisioning an Oracle Database instance to hold the meta data of Oracle SOA Suite.

In the 4th episode we've covered how we can quickly create a metadata repository, configure and then start a SOA Suite environment in a headless mode.

In this 5th episode I'll demonstrate an alternative and show how the graphical RCU and config utility can be used within docker.

In upcoming episodes we will cover patching and more advanced deployment options.

Getting X-Forwarding into docker

While it is possible to run both the repository creation utility (rcu) as well as the utility to create the SOA Suite Weblogic domain in a headless mode it is (for a single environment) often easier to use the graphical UI to perform those operations. To start the utilities within a docker container on some remote host we can leverage X-Forwarding to have the UI shown on our local laptop. I prefer to use the X11 server that comes bundled into https://mobaxterm.mobatek.net/. First download that piece of software, start it and configure X11 e.g. as follows:


Basic X11 configuration of MobaXterm

After this double check that the server is running; eventually also open the windows firewall ports to allow connections to those ports (especially 6000):


MobaXterm with running X11 server

With those preparations performed connect to the docker host first and try to set the display as follows:

export DISPLAY=10.13.13.2:0.0
xterm

This should open a xterm window. If you don't have xterm installed, you can try xclock as an alternative for testing. If that is working, we can actually start the rcu.

Creating the SOA Suite docker container

Next we create the SOA Suite docker container especially used for rcu:

docker volume create soa1_userproject
docker run --rm -it --name soa_initiate --network soanet1 -v soa1_userprojects:/u01/oracle/user_projects -h soa1 container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240117 /bin/sh

Since rcu needs some additional packages to start in interactive mode we run (in a separate shell session):

docker exec -it --user root soa_initiate /bin/sh
yum install -y libXext libXrender libXtst
exit

After this preparation we can start the actual rcu script:

export DISPLAY=10.13.13.2:0.0
oracle_common/bin/rcu

This should bring up a dialog as follows:


rcu started from within a docker image displayed on a remote X11 host

Step through the schema creation and selected the database created in the previous blog post as the target:


Connecting to the Oracle Database Free 23ai instance running in a separate docker container

The remaining steps can be executed as if installing SOA Suite locally; you can refer to the official documentation for more details: https://docs.oracle.com/en/middleware/fusion-middleware/12.2.1.4/rcuug/index.html

Creating the SOA Suite FMW Domain

After having prepared the database the second step that requires X11 forwarding (or works easier with it) is the domain creation. Continue in the same shell session with the DISPLAY variable configured:

oracle_common/common/bin/config.sh

The configuration is performed in the usual way and should end with something like:


Successfully completed FMW domain creation

Start SOA Suite interactively for the first time

After those preparation steps we can exit from the shell session to the soa_initiate container used for rcu and config UIs. This will remove the associated docker container, however everything relevant is stored in the persistent soa1_userprojects docker volume. Thus, we can easily start SOA Suite Admin Server in a new (final) container soa1:

docker run --rm -it --name soa1 --network soanet1 -v soa1_userprojects:/u01/oracle/user_projects -h soa1 -p 7001:7001 -p 7003:7003 container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240117 user_projects/domains/base_domain/startWebLogic.sh

This will make the ports 7001 (for the admin server) and the port 7003 (for the soa_server) exposed on the docker host. After the Adminserver is started you can start the soa_server1 as follows:

docker exec -it soa1 user_projects/domains/base_domain/bin/startManagedWebLogic.sh soa_server1

You should now be able to access the SOA Suite environment through a browser. It is also possible to use the pre-built scripts we've seen in the previous episode to start Admin- and managed server as follows (technically you may would even need the ADMIN_PASSWORD once). This will also give you proper Health-Checking:

docker run -d --rm -e DOMAIN_NAME=base_domain -e DOMAIN_ROOT=/u01/oracle/user_projects/domains --name soaadmin --network soanet1 -v soa1_userprojects:/u01/oracle/user_projects -p 7001:7001 container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240117 /bin/sh -c "/u01/oracle/container-scripts/startAS.sh; sleep infinity"

docker run -d --rm -e MANAGED_SERVER_CONTAINER=true -e MANAGEDSERVER_PORT=7003 -e DOMAIN_NAME=base_domain -e DOMAIN_ROOT=/u01/oracle/user_projects/domains -e MANAGED_SERVER=soa_server1 -e ADMIN_PASSWORD=Promatis1 -e ADMIN_HOST=soaadmin -e ADMIN_PORT=7001 --name soamanaged1 --network soanet1 -v soa1_userprojects:/u01/oracle/user_projects -p 7003:7003 container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240117 "/u01/oracle/container-scripts/startMS.sh"

Summary

By using X Forwarding it is possible to create the metadata repository as well as configure the domain for Oracle SOA Suite interactively and with all flexibility. In an upcoming blog post we'll cover how the docker image can get patched as well as which other options are available to create a SOA Suite environment in OCI.

Running Oracle SOA Suite on Docker - Part 5: Interactively Creating Repository (RCU) and Domain

Patching E-Business Suite with more comfort - Part 1 Password Passing

by | August 14, 2024 | Techblog

Johannes Michler PROMATIS Horus Oracle


Executive Vice President – Head of Platforms & Development

Every quarter Oracle releases a bunch of Critical Patch Updates that have to be applied to (often many) E-Business Suite instances. While the patch application is highly automated through the adop utility, there are two (little) things that always annoyed me when patching:

  • You have to provide the apps, ebs_system and weblogic password on every adop command
  • You have to re-check your terminal connection to check if a certain step completed

This first part of this blog post series will cover how we can easily pass the passwords to adop; in the second part I will show how notifications can be brought to your attention quickly once the patching is completed.

Setting passwords to environment variables

First of all (regarding security): I assume that whoever is able to access the E-Business Suite apps tier does usually know the apps, weblogic and ebs_system password. Who made it that fare can do more harm anyway. But keep in mind: if you really permanently store that credsEnv.sh on your server that file will also be in backups or P2T copies. So you might want to set them only temporarily or go for the OCI Vault approach described further down!

I've created a small script credsEnv.sh as follows:

[oracle@prod122app01 ~]$ cat credsEnv.sh
export XX_APPS_PWD=apps
export XX_WEBLOGIC_PWD=Welcome1
export XX_EBS_SYSTEM_PWD=manager

Hopefully in the real world you have more fancy passwords, even though those passwords are not unseen 🙁

I'm using that script for fancy stop/start scripts that I'll describe in another blog post as well.

Of course you could also outsource storing of the passwords from this file to OCI Vault service (and secrets) that are described over there: https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingsecrets_topic-To_create_a_new_secret.htm#createnewsecret

Then you could replace the above mentioned with something like:

export XX_APPS_PWD=$(oci secrets secret-bundle get --secret-id ocid1.vaultsecret.oc1.eu-frankfurt-1.12345 --query "data.\"secret-bundle-content\".content" --raw-output | base64 -d)

(where ocid1.vaultsecret.oc1.eu-frankfurt-1.12345 is the OCID of the secret storing the apps password)

Creating a custom myadop.sh script

Based on this I created a custom myadop.sh script as follows:

[oracle@prod122app01 ~]$ cat /home/oracle/myadop.sh
source /home/oracle/credsEnv.sh
{ echo ${XX_APPS_PWD};echo ${XX_EBS_SYSTEM_PWD};echo ${XX_WEBLOGIC_PWD} ; } | adop "$@"

Using this simple command I'm then able to run something like:

 ./myadop.sh phase=apply patches=36117775,36117775_D:u36117775.drv

This will result in something like:


Call to custom adop wrapper

Summary

While the procedure shown above is not "officially certified/documented" I made got experience with those commands; I'll also leverate them for "better" start/stop scripts for E-Business Suite that I'll show in a related blog post soon to be published.

Running Oracle SOA Suite on Docker - Part 5: Interactively Creating Repository (RCU) and Domain

Connect from OIC to OCI Database with private endpoint

by | August 8, 2024 | Techblog

Johannes Michler PROMATIS Horus Oracle


Executive Vice President – Head of Platforms & Development

It is a quite common requirement to integrate Oracle E-Business Suite instances running on Oracle Cloud Infrastructure (OCI) through Oracle Integration Cloud (OIC). In the past this required - since E-Business Suite is nevertheless an "on Premise Solution" to install a Connectivity Agent to connect to the database of Oracle E-Business Suite through the database adapter. Recently it is possible to skip that step by using a private endpoint.

Let us have a closer look at this!

Architecture when using the Connectivity Agent

Traditionally when connecting from Oracle Integration Cloud (that runs in the OCI data center) to on premise environments the natural solution is to leverage a Connectivity Agent. This is described over there (for OIC3): https://docs.oracle.com/en/cloud/paas/application-integration/integrations-user/downloading-and-running-premises-agent-installer.html#GUID-C12FA0F2-6264-4C60-BC90-C76850317304

My colleague Yves Chassein has covered that in great detail over here.


Integration Pattern when using the Connectivity Agent

Note: It doesn't matter here if the "Customer on prem application" is technically running on OCI as well. You still had to install the Connectivity Agent on a virtual machine in OCI to allow (private) connectivity between OIC (on OCI) and your own Virtual Cloud Networks (on OCI as well).

Private Endpoints

Luckily recently Oracle OIC is providing more and more "private endpoints". This results in an architecture as follows:


Architecture with private endpoints

So using this concept you're able to directly connect from the OIC instance that runs in a "special network" in OCI to a Virtual Cloud Network (VCN) of your own OCI Tenancy.

Setup Step-by-Step

The actual setup is very easy:

First, we create an appropriate subnet in your OCI VCN and allow it to access your target instance; here that is an OCI Base Database Service:


Subnets used for the OIC private endpoint (named soa-subnet here)


Ingress rule attached to the database network allowing connectivity from the OIC private endpoint network

After that we can create a private endpoint in the Oracle Integration Cloud (OCI console part):


Private endpoint connecting OIC to a OCI VCN Subnet

Finally, you can change your database connection to be a DBaaS (instead of a regular Database) Adapter Connection and then enter the details to connect to the database as follows:


Connecting through a Base Database through a private endpoint

The DBaaS adapter has the same capabilities as the "regular", "onPrem" Database adapter of OIC. Note: as the documentation states, it is mandatory to provide the hostname and NOT the IP address of the database to be connected; otherwise, you'll get a very difficult to understand or correlate error:

{"detail":"","status":"HTTP 500 Internal Server Error","title":"Operation [testConnection] failed: This connection is configured with an address which is not in an allowable range","type":"https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1"}

The documentation for this can be found here: https://docs.oracle.com/en/cloud/paas/application-integration/dbaas-adapter/using-oracle-database-cloud-service-adapter-oracle-integration-3.pdf

Summary

Using a private endpoint provides a much easier way to access databases in an OCI network from OIC. Unfortunately, when scanning through the list of all OIC adapters (https://docs.oracle.com/en/cloud/paas/application-integration/find-adapters.html), not all adapters so far support private endpoints. The feature is available e.g. for:

  • Oracle Database Cloud Service Adapter
  • REST Adapter
  • AQ Adapter

It is not available however for:

  • Oracle Database Adapter
  • Oracle E-Business Suite Adapter
  • MySQL Adapter

So unfortunately, so far you can not use a private endpoint to

  • access a database that is just running on an OCI compute instance or
  • use an IPSEC VPN Tunnel to get from the private endpoint network to some onPrem database instance.

This seems "highly random", and I hope this will be changed soon. Eventually/Probably you can work around this by just using the Database Cloud Service Adapter instead and still connect to an OnPrem / OnCompute Database instance.

Running Oracle SOA Suite on Docker - Part 5: Interactively Creating Repository (RCU) and Domain

Running Oracle SOA Suite on Docker - Part 3: Starting a database

by | August 6, 2024 | Techblog

Johannes Michler PROMATIS Horus Oracle


Executive Vice President – Head of Platforms & Development

Operating - installing and maintaining - Oracle Fusion Middleware, especially Oracle SOA Suite 12.2.1.4 is quite some work. Not only does installation itself consist of a number of steps, but each quarterly critical patch update also requires applying a number of patches and - especially in simple, single server environments quite some downtime.

This blog post series will cover how to run Oracle Fusion Middleware - especially Oracle SOA Suite on docker. The first post covered the high-level steps of manual installation, Docker and Kubernetes options and has pointers to the relevant Oracle certification documentation. The second post then described how - using OCI and Oracle Linux - a host to run docker containers can be setup up within minutes.

In this third post we will cover provisioning an Oracle Database instance to hold the meta data of Oracle SOA Suite.
In the 4th episode I'll investigate provisioning and configuring SOA Suite itself. While I'll first show those steps in a minimalistic way, to wrap up, the final episodes will cover patching and more advanced deployment options.

Signing into Oracle Container Registry

To use the pre-built containers provided by Oracle (and patched each quarter) navigate to https://container-registry.oracle.com/ and sign-in with your Oracle SSO credentials. Navigate to Auth Token there:


Creation of an Auth Token (Step 1)

Then click "Generate Secret Key" and safely store the generated key: It is not possible to reveal it again (but you can delete and create a new one).

Then go to your docker host and issue:

docker login container-registry.oracle.com

Provide your Oracle SSO Username as well as the token created:


Successful login to Oracle Container Registry

Downloading a database image

For testing purposes, it might be enough to use the latest "Free" Edition of the database; this is not supported though. Let's give it a try for this mini-instance nevertheless; you can switch to a "proper" Database Edition by just replacing "free" with "enterprise":

docker pull container-registry.oracle.com/database/free:latest

On OCI that command runs roughly 5 minutes. This is mainly for downloading 2 GB and extracting it to a 9 GB all-prepared image.

Starting the database

After having downloaded the latest image you can start with the following simple commands:

docker volume create mydbvol
docker network create soanet1
docker run --name myxe1 --network soanet1 -e ORACLE_PWD=Promatis1 -p 1521:1521 -v mydbvol:/opt/oracle/oradata --rm container-registry.oracle.com/database/free:latest

This first of all creates a persistent volume that will store the datafiles and will survive reboots of the environment. Furthermore, it creates a network that we will use late on to allow connecting to the database both from the host and from the SOA container. To make this as easy as possible we also expose port 1521 to the host. The entire process just takes 2 minutes:


Initial startup of the new database

Now you can connect to the DB e.g. using sql developer with the password provided as user SYSTEM; the service name is freepdb1.


Connection to newly started Oracle Database 23ai free

Summary

As shown starting an Oracle Database (e.g. 23 ai free) is a thing of 3 commands and completes in 5 to 10 minutes (network bandwidth permitting). In the next section of the blog, we'll see how we can run an Oracle SOA Suite using that Database.