Road to Oracle Cloud

In this blogpost, I want to share my experience of migrating an Oracle SOA solution from on-premise to the cloud. But why was it necessary to think about this possibility? More than two years ago, our customer launched a comprehensive program to to make sales fit for the future. A huge area also covered IT support and automation of sales business processes. The solution introduced the use of different cloud system that have to be integrated. The integration part was achieved with the Oracle SOA platform. The SOA platform connects internal IT systems with external business partners and customers. The SOA platform is operated on-premise in the customer’s DMZ zone.

Now that several systems have already been operated in the cloud and due to limited resources available to operate the SOA platform, the customer considered to move the platform into the cloud. The primary goal of a cloud deployment was to relieve the operations team. This allows the operations team to focus on functional monitoring. Furthermore, the following objectives were important:

  • The manufacturer ensures the best support for the operation of the platform, e.g. load balancing and clustering.
  • Installation of patches or new versions performed by the software provider.
  • HA capabilities are already firmly integrated in the cloud service and the system is continuously protected by backups against failure.
  • Additional resources can be easily requested or returned on demand.

Starting Point


SOA Projects

The following projects have been implemented with the SOA platform:


This project implements a solution to exchange EDI documents between trading partners and the customer (B2B). It uses the components SOA Suite and B2B. SOA Suite takes over the intermediary role between the internal ERP system and Business partners. Main parts of the order processing are automated with this solution.

Digital Sales Support

The platform consists of a number of cloud-based systems (CRM, Field Support, Webshop, etc.) exchanging data with the ERP system on-premise. The SOA platform with the components SOA Suite, Service Bus and Resource Adapters provides a central data hub between the different systems. The platform is used worldwide and needs to meet country-specific requirements. AIA patterns (Oracle Application integration Architecture) were applied to design and build the solution.


Development Process

The development process is supported by the use of Gitlab and partially automated. Gitlab includes a git, a build server and issue management. Apache Maven is used as build tool. The Gitlab CI/CD component is used to automatically deploy all artitfacts to the different environments. A manual deployment with JDeveloper or Enterprise Manager is not allowed by policy.

SOA Platform Architecture

SOA Infrastructure

The SOA platform consists of two middleware nodes. Every node is located in separated data center.  Reverse Proxies and Loadbalancer are used to secure routing from the Internet to the middleware servers in the DMZ. SOA Suite and Service Bus are configured as a separate cluster. Configuration Plans stored and managed in a shared file system to allow exchange between the middleware servers. JMS resources are written to the file store in the database. Due to this the middleware components are protected against failure. However the database used for the dehydration store runs as a single node without a RAC configuration and also doesn’t use a standby database with Oracle Data Guard.

Which SOA Cloud Service to use?

Basically Oracle distinguishes between a classic and a new variant of the SOA Cloud Service. Both variants are different in functionality . For this reason, the required components must be compared. The following components are actively used by the projects:

  • BPEL
  • B2B
  • Service Bus
  • Human Workflow
  • FTP Adapter
  • File Adapter
  • DB Adapter
  • JMS Adapter
  • SAP Adapter

Currently the listed components are only offered in the classic version of the cloud service. For this reason, the test was made with the classic variant.

Migration steps

SOA Cloud Service Dependencies

The SOA Cloud Service needs the Database and Storage Cloud Service. These services must be configured first before the SOA Cloud Service can be provisioned. In this context, the required authorizations must also be observed. Each service defines its own roles and permissions. These permissions must be assigned to the user who performs the provisioning. The following roles must be taken into account:

  • DBAASApp-*
  • DBBCSApp-*
  • JASSApp-*
  • SOAApp-*
  • StorageApp-*

Without these roles, the SOA Cloud Service cannot be provisioned successfully!

Database Provisioning

The infrastructure database is used to manage the schemas for SOAINFRA, MDS, etc. It is important to use the option „Database as as Service“ instead of „Database Schema“ of the Oracle Database Cloud Service. In addition, both „Cloud Storage and Block Storage“ have to be set as the backup option. According to documentation, Oracle recommends the use one Database Cloud Service for one SOA Cloud Service. Technically, it should be possible to use different SOA Cloud Service instances with exact one Database Cloud Service, because a SOA Cloud Service generates a unique schema prefix. After successful provisioning, the service have to be started manually to continue the provisioning process.

SOA Provisioning

It is important to ensure that the first 8 characters of the service name are unique. These are used to name the WebLogic domain and clusters:


In the test, the configuration of a SOA Cluster failed several times. For this reason, I started first without a cluster configuration and created a WebLogic Domain with an Admin Server and one Managed Server. Afterwards it is possible to extend the configuration by adding Managed Servers manually.  A detailed error analysis was not carried out in this case. For a production environment I recommend to involve Oracle Support for configuration issues. The following folders are provided on each node of a SOA Cloud Service.

File System

Important: Basically the SOA Cloud Service doesn’t provide a shared file system mounted to exchange files between middleware servers! So for a HA setup the database have to be considered as a central storage location, e.g. for JMS Queues etc.

Changes made in the folder /u01/data/domains will remain intact even after a restart. The folder /u01/soacs/dbfs_directio/share/soa is a configured DBFS (Database File System)  mount in the database. The DBFS seems to be the only way to share data between middleware servers, like deployment plans etc.. Files located in this folder automatically stored in the database.

WebLogic Domain Configuration

Typically, a WebLogic Domain can be configured automatically by the use of WLST scripts. The SOA Cloud Service allows two possibilities to execute WLST scripts. On one side configure and use  a SSH tunnel. This possibility enables the execution of WLST script from a remote host, like a CI/CD environment. However, the use of references to the file system must be checked within the WLST scripts, such as reading property files. On the other hand copy and execute the WLST scripts directly to one of the middleware servers in the cloud. In the projects we used WLST scripts heavily to create and modify Data Source, JMS Queues, Resource Adapters, OWSM Policies and other security related configurations.


In our project, the following artifacts had to be considered during deployment:

  • Web applications with Oracle ADF
  • SOA Composites
  • Service Bus Projects
  • Shared WSDLs, XSDs in MDS
  • B2B Configuration

Basically, all artifacts can be manually deployed through the Enterprise Manager. Deployment with the build tool Apache Maven works also when a SSH tunnel has been established. In this case, only the configuration plan had to be modified.

However, deployment via Oracle JDeveloper is not supported!

Experiences and Findings

SOA Cloud Service Architecture

In comparison to on-premise installation, the SOA Cloud Service does not offer the same flexibility. All SOA components (SOA Suite, Service Bus, B2B,…) run on one JVM and configured in one cluster. Typically, an on-premise installation is split into multiple clusters, such as clusters for SOA, Service Bus etc.. The SOA Cloud Service uses the Oracle Traffic Director to distribute the load to the available middleware servers. On-premise is often a combination with the usage of a hardware Load Balancer and Reverse Proxy based on Oracle HTTP Server. The service only provides the database as a shared storage between middleware nodes. This is an important information when designing a high availability system based on the SOA Cloud Service. Take this into account when defining the location for JMS Queues or distributed transactions (T-Logs). Also other components must therefore be carefully be analyzed, such as the File Adapter. In the Cloud Service, the File Adapter can only be operated in an active/passive mode. An active/active configuration needs a shared file system. When using Resource Adapters in general, consider the location of the config plans. Typically, these are also stored in a distributed file system to ensure access by each middleware server. But this is not the case with the SOA Cloud Service. You may be able to do this by using the Database File System (DBFS), however a test of this variant wasn’t executed.  The interaction of the middleware with the database (SOAINFRA-dehydration) is identical to the on-premise version. Moreover, it is very easy to re-configure the CPU and memory settings for the middleware when the workload increases or decreases. Similarly, the cluster can also be enlarged or reduces using the the management console.


With no more than two hours a complete SOA infrastructure with all components could be built up. Typically, an on-premise installation takes a lot of more time for planing and installation. Positively no source code modification was necessary (SOA Suite, Service Bus, etc.) for deployment to the new environment. Only the configuration plan had to be adapted to the new environment. All known management tools (e.g. Enterprise Manager) are also available in the SOA Cloud Service. This guarantees quick use and inlanding. Furthermore, adapting the infrastructure to a changed worked load is very easy. When the restrictions in terms of flexibility and high availability aren’t a show stopper and the SOA will be heavily used to integrated systems in the cloud the use of the SOA Cloud Service is a must. It is also important to know that the user of the Cloud Service is responsible to maintain the SOA infrastructure, as with an on-premise usage.