Startseite 5 Schlagwort: Oracle SOA Suite
Running Oracle SOA Suite in Docker Blog Post Series

Running Oracle SOA Suite in Docker Blog Post Series

Check out the blog post series of PROMATIS expert Johannes Michler (Executive Vice President – Head of Platforms & Development) and Oracle ACE Director. Here’s a summary of these six blog posts on “Running Oracle SOA Suite in Docker”, which focus on highlighting the core benefits, such as an easier installation, a consistent setup in several environments, and faster and fully automated patching:

Running Oracle SOA Suite in Docker – Overview

This post introduces the concept of running Oracle SOA Suite in a Docker container. It discusses the benefits of containerization, including simplified deployment and scaling, and outlines the steps involved in setting up the Oracle SOA Suite in a Docker environment. Read more >

Part 2: Installing a Docker Host

This article covers the installation of a Docker host, which is a necessary foundation for running Docker containers. It explains how to set up Docker on a virtual machine, detailing prerequisites, installation steps, and basic configuration to get Docker ready for Oracle SOA Suite. Read more >

Part 3: Starting a Database

The third post focuses on starting the database required for Oracle SOA Suite. It provides instructions for setting up an Oracle Database in a Docker container, which is essential for storing metadata and configuration data for SOA Suite. Read more >

Part 4: (Quick-)Starting an Environment

This post describes how to quickly start an Oracle SOA Suite environment in Docker. It walks the reader through setting up the necessary containers and configurations to launch the environment in an efficient manner, emphasizing automation and ease of use. Read more >

Part 5: Interactively Creating Repository (RCU) and Domain

In this article, the blog explains how to create the Oracle SOA Suite repository (RCU) and domain interactively. It covers running specific commands in the Docker container to set up the repository and define the domain structure necessary for SOA Suite to function properly. Read more >

Part 6: Patching

The final blog in the series discusses how to apply patches to Oracle SOA Suite running in Docker. It highlights the process of updating the Docker images and containers with the latest patches to ensure the environment remains secure and up-to-date. Read more >

These posts collectively guide users through the complete process of setting up, configuring, and maintaining Oracle SOA Suite in a Docker environment.

Running Oracle SOA Suite on Docker - Part 6: Patching

Running Oracle SOA Suite on Docker - Part 6: Patching

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. Next up were in the 4th and 5th episode all the details on provisioning and configuring SOA Suite itself - especially the metadata repository in the database created previously as well as the SOA Suite domain.

In this final episode we will cover patching options for the environment.

Patching to latest SOA Suite image

Patching to the latest SOA Suite CPU is straightforward and fast. Let’s walk through this step by step. In this example we start with a SOA Suite instance on the January CPU level:

[root@docker-test ~]# docker image ls container-registry.oracle.com/middleware/soasuite_cpu
REPOSITORY TAG IMAGE ID CREATED SIZE
container-registry.oracle.com/middleware/soasuite_cpu 12.2.1.4-jdk8-ol7-240117 7d72a1d5c81f 6 months ago 4.6GB


List of available versions; we see a later one that 240117 here

To upgrade this to the latest version (at the point of this screenshot the April CPU), simply pull the latest image:

docker pull container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240430


Newly pulled soasuite image

Then stop the existing instance and just start it again:

docker stop soams1
docker stop soaadmin1

docker run -d --rm --name soaadmin1 --network soanet1 -v soa1_userprojects:/u01/oracle/user_projects -p 7001:7001 --env-file ./adminserver.env container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240430

docker run -d --rm --name soams1 --network soanet1 -v soa1_userprojects:/u01/oracle/user_projects -p 8001:8001 --env-file ./soa_server1.env container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240430 "/u01/oracle/container-scripts/startMS.sh"

And there you go; the latest CPU is applied (on all parts of FMW/SOA):


April 2024 CPU being applied with 10 minutes of work and 3 minutes of downtime

Doing this manually is a multi-hour effort; just pulling the latest container image brings this down to 10 minutes with just 5 minutes of downtime.

Obviously, it makes sense to doublecheck the release notes of the latest CPU patches if any pre- or post-patching steps are required. But in most cases this such steps are not necessary.

Applying custom patches

In many real-world scenarios additional (one-off) patches have to be applied. If you want to for example connect to Office 365 for UMS E-Mails (see here) you may want to apply patch 35773019. Let’s see how this can be achieved using the weblogic image tool.

Get the latest version of the WebLogic Image tool from here: https://github.com/oracle/weblogic-image-tool/releases and thus install as follows:

wget https://github.com/oracle/weblogic-image-tool/releases/download/release-1.13.2/imagetool.zip
unzip imagetool.zip
yum install jdk-17 # minimum of Java8
export JAVA_HOME=/usr/java/jdk-17.0.5/
imagetool/bin/imagetool.sh update --fromImage container-registry.oracle.com/middleware/soasuite_cpu:12.2.1.4-jdk8-ol7-240430 --tag soasuite_jm --patches 35773019 --user johannes.michler@promatis.de --password


Creating custom image with One-Off patch

As you can see it took just 30 seconds to download all the relevant patches, apply them and build a custom image including the patch. That image can then be started in the regular way:


One-Off patch is applied, Office365 here we go

You might consider to push this image to your own container registry (e.g. on OCI) after creating the image on a testing environment to make sure that you run the exactly same image everywhere.

Summary

This concludes this blog series on running Oracle SOA Suite on docker. As has been shown, using docker greatly simplifies management of the environment and especially makes patching both faster and more reliable.

In another soon to be published blog series I’ll cover an option to run Oracle SOA Suite without a “pre-paid” license by subscribing to a SOA Suite license through the Oracle Cloud Marketplace. So, stay tuned.

Running Oracle SOA Suite on Docker - Part 6: Patching

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

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 6: Patching

Running Oracle SOA Suite on Docker - Part 2: Installing a docker host

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.

This second post will then describe how using OCI and Oracle Linux a host to run docker containers can be setup up within minutes.

In upcoming posts I will then cover provisioning an Oracle Database instance to hold the meta data of Oracle SOA Suite. In the 4th episode I will look into provisioning and configuring SOA Suite itself. While I will first show those steps in a minimalistic way, to wrap up, the final episodes will cover patching and more advanced deployment options.

Runtime environment - here Oracle Cloud Infrastructure (OCI)

While there are options to running containers in OCI in a managed fashion, e.g. using the Oracle Container Engine for Kubernetes or Oracle Container Instances, the most flexible and often cheapest option to run docker on OCI is by leveraging Virtual Machines. For the purpose of this blog, I've created a new virtual machine in a public network subnet (so it is directly accessible through the internet) as follows:

Creation of a docker-test virtual machine with Oracle Linux 8

In general, "bursting" (so over-subscribing) is a helpful feature to reduce costs; however keep in mind that this is not a good idea when using software that is licensed "by processor core":

Flexible selection of an appropriate compute shape

Installation of docker

After creating the virtual machine ssh into the newly created instance and install docker as follows. If you increased the boot volume size grow the file system appropriately:

ssh opc@193.1.2.3sudo dnf upgradesudo dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.reposudo dnf install docker-ce --nobestsudo systemctl enable docker.servicesudo systemctl start docker.servicegrowpart /dev/sda 3sudo lvextend -l +100%FREE /dev/ocivolume/rootxfs_growfs /df -h / -- should show 88gbsudo reboot
# For UI start of config tools later:dnf install xauth xterm

After having installed docker itself you can perform a quick test e.g. as follows:

docker run hello-world

This should download and start the hello-world docker container similar to the following screenshot:


First start of the hello-world container

    Summary

    As shown creating a docker host e.g. on OCI is straightforward. In the next section of the blog, we'll see how we can run an Oracle Database on this Docker host.

    Running Oracle SOA Suite on Docker - Part 6: Patching

    Exposing NULL values and Booleans in JSON/REST with Oracle SOA Suite

    Johannes Michler PROMATIS Horus Oracle


    Executive Vice President – Head of Platforms & Development

    Recently we had a couple of projects where we needed to expose data extracted from an Oracle Database through a simple SQL query as a REST service producing JSON. Let’s have a look at how it is possible to control the JSON produced in such a scenario.

    Implementation

    The composite is very, very trivial:


    Composite in SOA Suite

    It just maps two URL query parameters to the WHERE condition of the SQL query:


    REST Service Configuration

    When the service is invoked, unfortunately, the JSON returned is not really “optimal”:

    {
    "XxisBlanketMatkoV" : [ {
    "lineId" : 278000,
    "shipSiteAddress1" : "PROMATIS software GmbH",
    "shipSiteAddress2" : "Pforzheimer Str. 160",
    "shipSiteAddress3" : {
    "@nil" : "true"
    },
    "shipSiteAddress4" : {
    "@nil" : "true"
    },
    "shipSiteCountry" : "DE",
    "shipSitePlz" : "76275",
    "bulkFlag" : "N"
    } ]
    }

    Issues with initial version

    This is ugly for two reasons:

    • One usually does not describe NULL values in JSON like that. It would be better to either “omit” the element “shipSiteAddress3” or have them set to “shipSiteAddress3”: null.
    • bulkFlag is a boolean, it would be better to have this as “bulkFlag” : false.

    Of course, there is an obvious solution to this: Just add a mediator or even a BPEL process and do an XSLT transformation from the data from the Database Adapter to an explicit schema, and one can map Y/N to true/false over an xsl:if and is additionally able to e.g. omit the NULL elements based on xsl:if.

    However, this is “one more thing” to maintain, and if the base SELECT changes, this transformation has to be adapted as well.

    Producing better “null” values

    Obviously, SOA Suite first extracts the data from the database column SHIP_SITE_ADDRESS4 (which in NULL) to an xml representation of

    <shipSiteAddress3 xsi:nil=”true”/> and then translates that attribute into a json child “@nil”=true.

    Luckily in the meantime, SOA Suite got a patch 31926382 (which is part of SOA Bundle Patch 12.2.1.4.221122). With that patch, according to 2764402.1, one is able to modify the XSD that defines the XML elements that in the end are converted to JSON as follows:


    Modified XML Schema

    just add:

    xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:version="JSON" nxsd:encoding="UTF-8" nxsd:isNillableSupported="true"

    and the @nil will be converted to “proper” null values.

    true and false

    Unfortunately, pure (Oracle) SQL does not support boolean data types in the database so far. This also makes it a bit difficult to produce true/false when fetching data through the JCA Database adapter of SOA Suite. I managed to fix this by doing the following:

    1. Returning 0 for false and 1 for true in the SQL field of “bulk_flag,
    2. modifying the or-mappings.xml to:
    <attribute-mapping xsi:type="direct-mapping"
    <attribute-name>bulkFlag</attribute-name>
    <field table="XXIS_BLANKET_MATKO_V" name="BULK_FLAG" xsi:type="column"/>
    <attribute-classification>java.lang.Boolean</attribute-classification>
    </attribute-mapping>>

    (Thus changing it from java.lang.Decimal to java.lang.Boolean.)

    Summary: Prettier JSON

    By implementing these two tiny changes:

    • Add nxsd:isNillableSupported=”true” to schema,
    • modify the or-mappings.xml to have <attribute-classification>java.lang.Boolean</attribute-classification> to

    The REST service gives us:

    {
    "XxisBlanketMatkoV" : [ {
    "lineId" : 278000,
    "shipSiteAddress1" : "PROMATIS software GmbH",
    "shipSiteAddress2" : "Pforzheimer Str. 160",
    "shipSiteAddress3" :null,
    "shipSiteAddress4" : null,
    "shipSiteCountry" : "DE",
    "shipSitePlz" : "76275",
    "bulkFlag" : false
    } ]
    }

    Which is way better JSON ?