The document discusses provisioning Oracle Service Bus domains and customizing deployments. It provides steps to create an OSB production domain from scratch using a WLST script, export an OSB configuration from a development domain, create a customization file, import the configuration into a staging domain, edit the customization file to update environment parameters, and test the solution in the new staging environment. The key steps are automating domain provisioning using scripts for repeatability, exporting configurations between environments, and customizing configurations using customization files for different deployment targets.
1. Oracle Service Bus – Lesson 3
Name – Rakesh Gujjarlapudi
Email Address – rakesh_gujj@yahoo.com
Provisioning OSB Domains and Customizing Deployments
2. Introduction
OSB production domains are often provisioned automatically. Creating an OSB domain from scratch is not
difficult. If creating a domain for the first time, one normally will leverage the out of the box Configuration
Wizard. If creating many domains, one normally wants to automate OSB domain provisioning is by using WLST
scripts. In fact the Configuration Wizard uses WLST scripts to build domains. This creates a repeatable process
and minimizes errors and risk.
In this lab you will create a single node OSB production domain ‘from scratch’ using a simple WLST script. Scripts
are also available as samples to create OSB cluster vis WLST scripts.
In addition to creating the domains themselves, OSB applications are also often deployed automatically into
other domains using scripts. For example, when moving an OSB application from Integration Test to Staging, one
will want to script these steps to minimize any manual steps. Again, this creates a repeatable process and
minimizes errors and risk. We call this capability “lights-out to Production”
In this lesson we will manually provision an OSB solution from a Development environment into a Staging
environment and learn how to update environment parameters with Customization files.
Create a Single Node OSB Production Domain
High-level Steps
During this lab you will accomplish the following tasks:
Create OSB Reporting Provider Tables In The Database.
Build an OSB Domain Using WLST Domain Creation Script
Export an OSB Configuration File from Development Domain
Create an OSB Customization File
Import an OSB Configuration Into Staging
Edit and Apply An OSB Customization File
Test the Solution
3. Create Reporting Provider Database Tables
An OSB domain requires 2 database tables. OSB will not successfully boot without a defined database
connection to the database that has the tables present, plus the database must be up and running. When a
‘development mode’ domain is created through the configuration wizard these tables are created automatically.
This convenience does not occur in a production domain even when the domain is created through the
configuration wizard. You will create a production mode domain in this lab, and as a first step you will create the
db tables. For convenience, the Derby database that ships with WebLogic Server samples will host the tables
At the command prompt enter sh ./createDerbySchema.sh. SQL related messages will scroll across the
terminal window. The script will run successfully whether Derby is running or not, or whether the tables already
exist or not. This script is located in /home/oracle/bin
Close the terminal session. The tables have been successfully created.
Build an OSB Domain Using WLST
Introduction
The vast majority of the challenges in creating simple or complex OSB domains with WLST scripts are already
handled for you by a set of pre-defined OSB domain templates. These templates are created by OSB engineering
and contain sophisticated logic that helps to ensure that OSB domains have the proper components and
configuration, regardless of the domain topology (single node, cluster, etc). The templates are used
automatically, behind the scenes, by the WebLogic Configuration Wizard. Outside the Configuration Wizard,
WLST scripts can leverage the templates in the same way that the configuration wizard does. In fact, in this
training module you will run a script that essentially duplicates what the Configuration Wizard does when it
creates a single node OSB domain.
4. A simple WLST script to create a single node OSB domain is OSBSingleSvrDomain.py . Please email me
rakesh_gujj@yahoo.com for the script. Run the script and start up the osb domain.
Now login to the OSB console and use this url http://localhost:8111/sbconsole to access the OSB console.
Credentials are the usual: weblogic/welcome1.
We have built an OSB domain from scratch using a WLST script!
Export an OSB Configuration File from Development Domain
The typical lifecycle of an OSB solution is that it is promoted/migrated from Dev to Test to Staging to Pr- Prod to
Production, etc.. One way to provision an OSB solution into a new environment is to export it from one domain
and import it into another. We will do that manually to learn about the process and the value it and opportunity
it provides.
Login to the OSB development environment console at http://localhost:7001/sbconsole.
Scroll down and in the System Administration task group click the Export Resources link as shown.
There’s no need to start a session because nothing we will do will change the existing configurations. We are
simply going to export existing configurations.
The list of all projects is displayed. Note that you can export entire projects, or selected project resources.
Also you can export global system operational settings.
By default all resources are selected to be exported. But we want to export only the Credit Services
project. Configure the Export Resources screen so that only the Credit Service project will be exported. Then
click Export. The default file name for exported OSB configurations is sbconfig.jar. You should name it something
with more meaning, like CreditServiceDevConfig.jar. By default the export file will be saved to
/home/oracle/Downloads.
5. Create an OSB Customization File
Next, create a Customization file. This is an XML file that represents all the configurable properties of an OSB
solution. The customization file is used to specify configuration changes to be made to an OSB resource, for
example a Project. The configuration file can be applied to a project, or certain project artifacts, or multiple
projects.
To create the customization file click the Create Customization File link in the Customization task group.
Select only the Credit Services project and click Create File.
Name the configuration file CreditServicesStagingConfigFile.xml. The naming is a reference to the
environment where the OSB configuration you just exported will be migrated. This configuration file needs to be
edited to reflect the requirements of the new environment.
Import an OSB Configuration Into Production Domain
Go to the OSB console of the Staging domain (http://localhost:8111/sbconsole).
Scroll down and click the System Administration task group link.
6. Start a session. You should be at the Import/Export page. If not, click on Import Resources.
Click the Browse button and navigate to /home/oracle/Downloads. Select the CreditServiceDevConfig.jar then
click Open.
Click Next.
Now click Import.
Activate the session.
We have successfully provisioned an OSB solution into a new environment. The solution is imported with no
change to its configuration. This may very well work out in reality, but if and only if the endpoints, urls, paths etc
are exactly what the target environment requires. This is not usually the case. We’ll solve that problem in the
next using step.
7. Edit and Apply an OSB Customization File
You are going to update a business service url in the customization file. The new IP address will be the IP address
of the staging location of the business service. The IP address of your running instance will be the target IP
address. To find the IP address of your instance launch a Terminal window. At the command prompt run
/sbin/ifconfig. Note the IP address of your instance as shown here.
Navigate to the customization file and open it for editing. Find the first occurrence of “orabpm-server”
(or it might be localhost if you used localhost instead). Note that the XML parent node is
”<cus:envValueAssignments>”. Just remember that this means “environmental value assignment”. You’ll see
why in a minute.
Replace orabpm-server (or localhost depending on what you used) with the IP address captured in the previous
step. Make sure there are no trailing or leading spaces in the IP address. Find all remaining occurrences of
localhost and replace them with the IP address. Close the file when done.
Go back to the OSB staging domain console, create a Session, and select the Execute Customization File link.
Browse to the customization file and select it. Click Next to display a review of the possible targets for
customization. Notice the Set Environment Value(s) section? This is where your modifications were
made.
8. Now click the Execute button to execute the customizations you specified.
Activate the changes.
Now confirm that the changes were made to the OSB project. Through the Resource Brower navigate to
the BusinessServices and click on validationForCC.
Notice that the Endpoint URI’s are both IP addresses. No localhost
Test the Solution
Test the proxy services to verify that they function correctly in the new environment.