Automating the Provisioning of Oracle SOA Suite on AWS

1. Overview

Rubicon Red MyST delivers automated platform provisioning and continuous delivery for Oracle Middleware, enabling users to deliver a consistent and reliable platform in minutes.

MyST also provides infrastructure independence; enabling customers to deploy consistent middleware platforms across all infrastructure types: on-premise and various cloud providers including Oracle and Amazon Web Services (AWS).

In this post we will show how to provision an Oracle SOA Suite environment within minutes on AWS.

If you want to use an AWS Oracle RDS instance, you can follow the instructions in this post: .

Alternatively, you can provision against an Oracle database running on an AWS EC2 instance.

We will provision the following, using the standards defined in the Oracle Enterprise Deployment Guide (EDG):

  • A two node cluster environment
  • OFMW Components: SOA, OSB, WSM, BPM, OHS

We will use MyST Studio to:

  • Discover the AWS resources, and define our Infrastructure Provider
  • Define the Platform Blueprint
  • Define the Platform Model
  • Provision two EC2 instances On-Demand
  • Provision Oracle Fusion Middleware:
    • Install the required binaries
    • Run RCU to create the database objects against RDS
    • Create the WebLogic Domain
    • Apply the Oracle EDG recommended configurations, which is a MyST knowledge module

2. AWS Configuration Prerequisites

Security Groups:

A security group allows us to control access to specific inbound/outbound ports, as well as restrict access based on source address.

The following table details the Security groups we are using for the purpose of this blog post:

Security Group Associated with Inbound Notes
Type Protocol Port Range Source
DEVTEST-SG-VPN-INTERNAL VPN Instance EC2 instance Associates the Security Group with the VPN Gateway
MYST-STUDIO-SG MyST Studio EC2 Instance HTTPS TCP 443 DEVTEST-SG-VPN-INTERNAL Allows access from the VPN Gateway to MyST STudio UI
TEST-RDS-SG RDS Instance: RDSTEST Oracle-RDS TCP 1521 DEVTEST-SG-VPN-INTERNAL Allows access from the VPN Gateway to the Oracle DEVTEST RDS Instance (Optional)
Oracle-RDS TCP 1521 OFMW-DEV-SG Allows access from DEV Oracle Fusion Middleware Instances to the DEVTEST Oracle Database
OFMW-DEV-SG On-Demand EC2 Instances created by MyST Studio for DEV SSH TCP 22 MYST-STUDIO-SG Allows access from MyST Studio to OFMW DEV instances via SSH
All Traffic OFMW-DEV Allows access to all traffic among the OFMW DEV instances
Custom TCP Rule TCP 7777 DEVTEST-SG-VPN-INTERNAL Allows access from VPN Gateway to OHS port

Create a user for MyST Studio in AWS Identity and Access Management (IAM)

MyST Studio interacts with AWS via its APIs, in order to discover AWS resources, and create the EC2 instances on which Oracle Fusion Middleware will be deployed.

For this purpose we will create an AWS user called fusioncloud and grant the appropriate privileges. The steps to do this are as follows:

  • Access the AWS Console.
  • Go to: Services -> IAM -> Users -> Create New Users .
  • Create a new user called fusioncloud, and generate the Access Key. Make sure you keep the access and secret keys in a safe location.

You will need these two keys later on, to configure the AWS On-Demand Infrastructure Provider in MyST Studio.

Define the following policy, and attach it to the fusioncloud user:

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "Stmt1440993615000",
            "Effect": "Allow",
            "Action": [
            "Resource": [

3. MyST Studio

The following section describes how to configure AWS as an infrastructure provider in MyST Studio. It then leads you through the process of creating a "model" in MyST of the required SOA environment and finally shows you how provision it.

Within MyST, we divide the "model" into two layers. First, the Platform Blueprint, which defines an environment agnostic topology/configuration and provides an abstraction layer over the underlying infrastructure. The second is the Platform Model which defines the environment specific configurations.

Typically the initial setup and defining the Platform Blueprint and Platform Model takes between 10-15 minutes.

The provisioning, depending on the components, number of nodes and Compute Instance Types can take between 20-60 minutes.

3.1 Creating the Infrastructure Provider

The Infrastructure Provider holds the details about your infrastructure, which is referenced at a later stage by your Platform Model.

MyST currently supports the following two Infrastructure Providers:

  • AWS On-Demand: MyST will introspect your AWS infrastructure, in order to give you options on how the EC2 instances will be configured.

  • Pre-existing: The Pre-existing Infrastructure Provider is used when you either already have your compute instances created, or you want to create your compute instances independently from MyST.

The Pre-existing infrastructure provider will also hold the hosts and credentials details. They will be referenced by your Platform Model.

With Pre-existing Infrastructure Provider, you can use MyST Studio to Provision against:

  • Any Cloud Provider
  • Exalogic
  • Any Hypervisor running On-premises
  • Baremetal running On-premises

Create an AWS On-Demand Infrastructure Provider

Within MyST Studio, select Infrastructure Providers -> Create New -> On-Demand (AWS), as follows:

Complete the following details:

  • MyST Studio metadata

    • Name: The Infrastructure Provider Name
    • Description: A brief description for your Infrastructure Provider
    • Workspace: This is used to define the role base access control. For the purpose of this post we will use the default workspace. We will cover Role Based Access Control (RBAC) in a future Blog
  • AWS Region and Credentials

    • Region: The AWS Region in which you will provision your Oracle Fusion Middleware Instances
    • Access Key: The AWS Access Key for the fusioncloud user we created earlier. MyST will use this to connect to AWS via the APIS's and introspect your AWS resources, from which you can select which resources will be available to provision your Oracle SOA Environment.
    • Secret Key: The AWS secret Key associated to the Access Key.
  • The Infrastructure Provider details which will be used by your Platform Models/Instances. Regarding the resources introspected from your AWS account in the selected region, you must select only the resources which will be used by your Oracle Fusion Middleware instances. We recommend selecting only the required ones, in order to reduce the chances of someone making a mistake (e.g: targeting a compute instance to the wrong VPC or Security Group). You can update these resources at any time.

    • VPCs: The potential VPCs that you would like MyST to provision the EC2 instances to. When you create your platform model, you will be able to select which VPC you want to use, from the subset selected at this stage.
    • Subnets: The potential subnets you would like to provision the EC2 instances to. The subnets are associated to a single VPC. When you create your platform model, you will be able to select which Subnet you want to use, from the subset selected at this stage.
    • Security Groups: The security groups you would like to associate to your instances.
    • AMIs: The AMIs you will use to provision your EC2 instances. You will map an AMI to a Compute Logical Definition. That's the way MyST abstracts the Compute definition defined in the Platform Blueprint, and this allows MyST to be able to provision the same Platform Blueprint across multiple Providers, being either on-premises or on the cloud.
    • Instance Types: The EC2 Instance Types which you would like to be shown for selection when creating a Platform Model.
    • AWS Key Pairs: The AWS Key Pair, which will be associated with the OS Admin Credential.
    • OS Admin Credentials: The credentials used to connect to the EC2 instance. Usually the username is ec2-user, depending on the AMI. At this stage MyST does not use this credential. That's for future releases.
    • Agent Key Pairs: The Operating system SSH Key to be used by the MyST agent.
    • OS Agent Credentials: The credentials to be used by the MyST agent. It can use either username/password, or a username/SSH Key.

Once you save the Infrastructure Provider, you will see a summary under the Infrastructure Providers list, as follows:

3.2 Creating a Platform Blueprint

The Platform Blueprint describes the Platform Topology, as well as the Oracle Fusion Middleware configuration.

A platform Blueprint is Infrastructure agnostic, and abstracts horizontal and vertical scaling. That means that you can for example, have a single Platform Blueprint with your definitions, and provision different topologies as follows:

  • DEV environment running on AWS with 2 compute nodes. Instance Type=m4.large.
  • Test environment running on AWS with 4 compute nodes. Instance Type=m4.xlarge.
  • Production environment running in Exalogic with 8 compute nodes.

This allows you to define a standardized topology, which can be leveraged by all Platform Models to provision a consistent middleware platform across all environments and prevent configuration drift.

Create a Platform Blueprint

Within MyST Studio, select Platform Blueprints -> Create New, as follows:

Provide the following details:

  • Name: The Platform Blueprint name.
  • Description: A brief description of your Platform Blueprint.
  • Workspace: Which workspace your platform blueprint will be associated to. For now stick with the Default workspace.
  • Initial Version: The Initial version of the Platform Blueprint. Usually it starts with 1.0.0.
  • Method to create the Platform Blueprint: You can create a Platform Blueprint either using a Wizard, or a Template. MyST comes with a few out of the box templates. You can also define your own templates. For the purpose of this document, we will use the Wizard.

We will now select the product family, the Oracle Fusion Middleware version and which components we want to provision. As mentioned in the beginning of this document, we will select the following components: OSB, SOA, BPM and Webtier (OHS) 12.2.1.

We will now configure the Platform topology, as follows:

  • Do you want a standalone admin node?: You can either have the Admin Server to running on a separate compute node, or in one of the nodes which will handle the workload (e.g: with the managed servers). You can override this information on the Platform Model, if required.
  • The number of compute groups: Defines how many compute groups you want, so you can group the components together. In our case, we want all the components to be provisioned homogeneously among all nodes.
  • Components: You can target the components to the compute groups. In our scenario, we have defined a single compute group.
  • Maximum Nodes: The maximum number of nodes for a given Compute Group. This constraint will be validated in the Platform Model against the Actual number of nodes property.
  • Minimum Nodes: The minimum number of nodes for a given Compute Group. This constraint will be validated in the Platform Model against the Actual number of nodes property.
  • Default Nodes: The default value to be assigned to the Actual number of nodes in the Platform Model. The value can be overridden in the Platform Model.
  • Compute Definition: Defines a Logical Compute Node. This information will be used by the Platform Model/Instance, to determine the Operating System type, and also to map to an AMI when using On-Demand AWS Infrastructure Provider.

You can now define the characteristics of your WebLogic domain:

  • WebLogic Domain Name
  • Listen Port types: You can select if you want either standard ports (plain HTTP), SSL enabled and/or Administration Port enabled.
  • JDBC Datasource: You can select between Generic datasource and Gridlink.
  • Persistence Strategy: You can choose how the TLOGS and JMS persistence will be stored. The choices are either: Filesystem or Database.

You will be able to see the summary of the Platform Blueprint, and once you confirm, the Platform Blueprint will be created.

The Platform Blueprint will be automatically displayed once it is created. At this stage, you can customise your platform configuration. You can for example, add new datasources, JCA adapters, JMS Queues, etc. Note that MyST already did the heavy lifting of computing the configuration based on the options you selected from the wizard, and applying the Oracle EDG recommendations.

For the purpose of this blog post, we will not make any additional configuration changes.

3.3 Creating the DEV Platform Model

We will now create the DEV environment Platform Model. The Platform Model describes the specific environment settings on top of the Platform Blueprint.

Typically these are the configurations defined at the model level:

  • Infrastructure Provider relationship
  • Mapping to hosts/credentials
  • Endpoint definitions
  • Tuning parameters. e.g: JVM memory arguments, datasource connection pool settings
  • SSL certificates
  • Environment Type association

Create a Platform Model

Within MyST Studio, select Platform Models -> Create New

  • Platform Blueprint: Select which Platform Blueprint this Platform Model is related to.
  • Platform Blueprint Version: Select which version of the Platform Blueprint this Platform Model is related to.
  • Environment: Based on the Environment selected:
    • For Pre-existing Infrastructure Provider, only the hosts belonging to that environment will be shown.
    • Role Based Access Control will allow/deny access based on this environment Type.
  • Name: The Platform Model name.
  • Description: A brief description of the Platform Model.
  • Workspace: Which workspace this Platform Model is related to.
  • Auto-update: When this option is selected, prior to an application deployment, MyST will also perform a Platform update.

We can now define the Compute Node settings, as follows:

  • Standalone Admin node: If we want to have the Admin Server in a separate node. The value is defaulted from the Platform Blueprint.
  • Actual Nodes: The number of compute nodes for this model. We are overriding this value to two compute nodes.
  • AMI: The AMI mapped to the Compute Definition.
  • Instance Type: The AWS EC2 Instance Type. We are selecting a m4.large for DEV, as 8GB of RAM is enough for the components we selected for DEV purposes.
  • Security Group: The security group which will be associated to the EC2 instance.
  • Agent User: The user on the target host, which MyST will run as.
  • Configure Agent User: Sets the Key pair to the OS Admin User, defined under the Infrastructure Provider.

We will now define:

  • AWS Instance Prefix: The EC2 instance TAG Name will be prefixed with this value.
  • Node Name: The node name. This value will be appended with the AWS Instance prefix, which will constitute the EC2 TAG Name value.
  • IP Address: The IP Address to be assigned to the EC2 instance. Usually this is left empty, which means that AWS will automatically assign an IP address.

Note that there are two tabs: General and Advanced.
We will define the following settings in General and Advanced:

  • General

    • Domain Name: The default value is taken from the Platform Blueprint.
    • WebLogic Admin User: The default value is weblogic.
    • WebLogic Admin password
    • JDBC Datasource Type: One of the following three: Generic Datasource; Generic Datasource (RDS); Gridlink. We will select the Generic Datasource (RDS).
    • RCU Database URL: The Database URL. In our case, is the RDS Oracle Database. Note that we are using the DNS alias rather than the hostname provided out of the box by RDS.
    • RCU Prefix: The Database schema prefix for the schemas created by RCU. The Prefix must be unique among all platforms for a given Oracle Database.
    • RCU Database Password: The password for the schemas which will be created by RCU.
    • RCU SYS User: The administrator DB User. Note that SYS user is not allowed on AWS RDS. We created an "admin" user, as the RDS master user.
    • RCU SYS Password: The password for the RDS Master user
  • Advanced

    • JVM Memory arguments
    • SOA Parameters

Then you'll see a summary of the Model Settings.

Be sure to click on the "Finish" button, to create the Platform Model.

The Platform Model editor will then open. Note that differently from the Platform Blueprint (where you had one compute group), now you have the concrete Compute Nodes. We will not make any changes to the Platform Model.

3.4 Provisioning

Now that we have the Platform Model created successfully, we will provision it.

Select Platform Models -> Select the model we just created -> Click on Actions -> Provision

Optionally, we can provide a "Provisioning Note". Click on the Finish button. This will kick-off the provisioning process.

35 minutes later, we have the confirmation that the Platform was provisioned successfully and is active, as follows:

We can see in the AWS Console two running compute instances with your OFMW platform.

We can also see in the Enterprise Manager Console, the Admin Server and 4 managed servers running in a healthy state.

4. Conclusion

In this Blog Post, we explored how to configure your MyST Studio for the first time, and successfully provision a 2 nodes EDG compliant SOA Domain. The entire infrastructure is running on AWS: EC2 for OFMW compute nodes, and Oracle RDS for the OFMW database repository.

This blog focussed on provisioning against a single Availability Zone. In an upcoming blog post, we will cover provisioning a test environment in Multi-Availability Zones.