Monday Oct 22, 2012

SOA PS5 Bundle Patch 4 and OSB PS5 Bundle Patch 1

Announcing the Availability of SOA Suite 11g PS5 Bundled Patch 4 and OSB PS5 Bundle Patch 1

These Bundled Patches contain a number of high impact fixes for PS5 and are recommended for anyone currently using this release. Please review the list of included fixes in the readmes and if you are running with any SOA or OSB patches not included in the Bundled Patches please request for Support to create a one-off on top of the appropriate Bundled Patch.

The patches can be downloaded from My Oracle Support. 'Patches & Updates' -> Enter '14406487' (SOA) or '14389126' (OSB) and click 'Search'.

Further information on specific included fixes can also be found in the following documents on MOS:
SOA 11g: Bundle Patch Reference, Doc ID 1485949.1
OSB 11g: Bundle Patch Reference, Doc ID 1499170.1

Friday Sep 14, 2012

Upcoming Customer WebCast: Adapters and JCA Transport in Oracle Service Bus 11g

There is an upcoming webcast planned for September 19th that will show how to implement services using a JCA adapter in Oracle Service Bus 11g. The session will help to utilize existing resources like samples and information centers for adapters in the context of Oracle Service Bus.

Topics covered in the webcast are:
  • JCA Transport Overview / Inbound and Outbound scenarios using JCA adapters
  • Implementation of an end-to-end use case using an inbound file adapter and and an outbound database adapter in Oracle Service Bus
  • It will show how to find information on supported adapters in a certain version of OSB 11g
  • Available adapter samples for OSB and SOA
  • How to use SOA adapter samples for Oracle Service Bus
  • A live demo of an adapter sample implementation in Oracle Service Bus
  • Information Centers for adapters and Oracle Service Bus information

The presentation recording can by found here after the webcast. Select "Oracle Fusion Middleware" as product.

The schedule for future webcasts can be found in the above mentioned document as well.

Tuesday Sep 04, 2012

Introduction to Human Workflow 11g

Human Workflow is a component of SOA Suite just like BPEL, Mediator, Business Rules, etc. The Human Workflow component allows you to incorporate human intervention in a business process.

You can use Human Workflow to create a business process that requires a manager to approve purchase orders greater than $10,000; or a business process that handles article reviews in which a group of reviewers need to vote/approve an article before it gets published. Human Workflow can handle the task assignment and routing as well as the generation of notifications to the participants.

There are three common patterns or usages of Human Workflow:

1) Approval Scenarios: manage documents and other transactional data through approval chains . For example: approve expense report, vacation approval, hiring approval, etc.

2) Reviews by multiple users or groups: group collaboration and review of documents or proposals. For example, processing a sales quote which is subject to review by multiple people.

3) Case Management: workflows around work management or case management. For example, processing a service request. This could be routed to various people who all need to modify the task. It may also incorporate ad hoc routing which is unknown at design time.

SOA 11g Human Workflow includes the following features:

  • Assignment and routing of tasks to the correct users or groups.
  • Deadlines, escalations, notifications, and other features required for ensuring the timely performance of a task.
  • Presentation of tasks to end users through a variety of mechanisms, including a Worklist application.
  • Organization, filtering, prioritization and other features required for end users to productively perform their tasks.
  • Reports, reassignments, load balancing and other features required by supervisors and business owners to manage the performance of tasks.

Human Workflow Architecture

The Human Workflow component is divided into 3 modules: the service interface, the task definition and the client interface module. The Service Interface handles the interaction with BPEL and other components. The Client Interface handles the presentation of task data through clients like the Worklist application, portals and notification channels. The task definition module is in charge of managing the lifecycle of a task. Who should get the task assigned? What should happen next with the task? When must the task be completed? Should the task be escalated?, etc

Stages and Participants

When you create a Human Task you need to specify how the task is assigned and routed. The first step is to define the stages and participants. A stage is just a logical group. A participant can be a user, a group of users or an application role. The participants indicate the type of assignment and routing that will be performed.

Stages can be sequential or in parallel. You can combine them to create any usage you require. See diagram below:

Assignment and Routing

There are different ways a task can be assigned and routed:

  • Single Approver: task is assigned to a single user, group or role. For example, a vacation request is assigned to a manager. If the manager approves or rejects the request, the employee is notified with the decision. If the task is assigned to a group then once one of managers acts on it, the task is completed.
  • Parallel : task is assigned to a set of people that must work in parallel. This is commonly used for voting. For example, a task gets approved once 50% of the participants approve it. You can also set it up to be a unanimous vote.
  • Serial : participants must work in sequence. The most common scenario for this is management chain escalation.
  • FYI (For Your Information) : task is assigned to participants who can view it, add comments and attachments, but can not modify or complete the task.

Task Actions

The following is the list of actions that can be performed on a task:

  • Claim : if a task is assigned to a group or multiple users, then the task must be claimed first to be able to act on it.
  • Escalate : if the participant is not able to complete a task, he/she can escalate it. The task is reassigned to his/her manager (up one level in a hierarchy).
  • Pushback : the task is sent back to the previous assignee.
  • Reassign :if the participant is a manager, he/she can delegate a task to his/her reports.
  • Release : if a task is assigned to a group or multiple users, it can be released if the user who claimed the task cannot complete the task. Any of the other assignees can claim and complete the task.
  • Request Information and Submit Information : use when the participant needs to supply more information or to request more information from the task creator or any of the previous assignees.
  • Suspend and Resume :if a task is not relevant, it can be suspended. A suspension is indefinite. It does not expire until Resume is used to resume working on the task.
  • Withdraw : if the creator of a task does not want to continue with it, for example, he wants to cancel a vacation request, he can withdraw the task. The business process determines what happens next.
  • Renew : if a task is about to expire, the participant can renew it. The task expiration date is extended one week.


Human Workflow provides a mechanism for sending notifications to participants to alert them of changes on a task. Notifications can be sent via email, telephone voice message, instant messaging (IM) or short message service (SMS).

Notifications can be sent when the task status changes to any of the following:

  • Assigned/renewed/delegated/reassigned/escalated
  • Completed
  • Error
  • Expired
  • Request Info
  • Resume
  • Suspended
  • Added/Updated comments and/or attachments
  • Updated Outcome
  • Withdraw
  • Other Actions (e.g. acquiring a task)

Here is an example of an email notification:

Worklist Application

Oracle BPM Worklist application is the default user interface included in SOA Suite. It allows users to access and act on tasks that have been assigned to them. For example, from the Worklist application, a loan agent can review loan applications or a manager can approve employee vacation requests.

Through the Worklist Application users can:

  • Perform authorized actions on tasks, acquire and check out shared tasks, define personal to-do tasks and define subtasks.
  • Filter tasks view based on various criteria.
  • Work with standard work queues, such as high priority tasks, tasks due soon and so on. Work queues allow users to create a custom view to group a subset of tasks in the worklist, for example, high priority tasks, tasks due in 24 hours, expense approval tasks and more.
  • Define custom work queues.
  • Gain proxy access to part of another user's tasks.
  • Define custom vacation rules and delegation rules.
  • Enable group owners to define task dispatching rules for shared tasks.
  • Collect a complete workflow history and audit trail.
  • Use digital signatures for tasks.
  • Run reports like Unattended tasks, Tasks productivity, etc.

Here is a screenshoot of what the Worklist Application looks like. On the right hand side you can see the tasks that have been assigned to the user and the task's detail.


Introduction to SOA Suite 11g Human Workflow Webcast

Note 1452937.2 Human Workflow Information Center

Using the Human Workflow Service Component

Human Workflow Samples

Human Workflow APIs Java Docs

Tuesday Jul 31, 2012

How to run a RDA collection for SOA without providing a password at runtime?

One of my previous blog posts shows in detail how to collect information for a SOA domain using RDA (Remote Diagnostic Agent):
Diagnose SOA Suite 11g Issues Using RDA (Remote Diagnostic Agent).

However, a complete RDA collection for a SOA Suite domain including database artifacts takes some time. Also specific requirements may make it necessary to run the actual RDA collection at times of low system load. Or via a cron job. Usually, during an RDA collection, which connects to the WebLogic Server or to the database, passwords need to be provided.

In newer versions of RDA, functionality has been added so that passwords may be stored in the setup.cfg file in encrypted format. This can be accomplished by using the -A parameter of RDA.

RDA can collect data for one or more domains. RDA can either figure out the name of the administration user to connect to WebLogic Server, or it will ask for it during the setup phase. After the setup is done, a setup.cfg file is created that contains all information necessary to run a collection. Except passwords needed.

To add password information in order to run a RDA collection in silent mode, run the following commands:
  • For every domain (1..n), add the password for the administration user:
    • rda.[cmd|sh] -A WLS_USER_SOA_DOMi
    Use the number of the domain instead of i, like WLS_USER_SOA_DOM1, ..., WLS_USER_SOA_DOMn
  • For every domain (1..n), add the password for the SOAINFRA database schema user:
    • rda.[cmd|sh] -A YourPrefix_SOAINFRA@myhost.mydomain:1521::oracle_sid

After all passwords are stored in setup.cfg, collections can run in silent mode. They can be scheduled via a cron job or run by scripts.

Wednesday Jul 25, 2012

SOA Suite 11g PS5 Bundled Patch 3 (

Announcing the Availability of SOA Suite 11g PS5 Bundled Patch 3

This Bundled Patch contains a number of high impact fixes for PS5 and is recommended for anyone currently using this release. Please review the list of included fixes in the readme and if you are running with any SOA patches not included in the Bundled Patch please request for Support to create a one-off on top of the Bundled Patch.

Patch can be downloaded from My Oracle Support. 'Patches & Updates' -> Enter '14082705' and click 'Search'. The patch is 606MB.

Tuesday Jul 24, 2012

Follow Up to Proactive Support Presentation at the Fusion Middleware Summer Camp in Munich

On July 18th, I had the oportunity to present the SOA Proactive Support projects at the Oracle Fusion Middleware Summer Camp in Munich. This post is a follow up in order to provide the material that was covered for your reference.

Thanks to everyone who listened to the sessions and for the interesting discussions around RDA and Selective Tracing and other diagnostic tools.

The link to the event can be found here.


SOA Proactive Support Overview
SOA Diagnostic Tools Overview
Using Selective Tracing with Oracle SOA Suite 11g

Tuesday Jun 12, 2012

Overview of SOA Diagnostics in

What tools are available for diagnosing SOA Suite issues?
There are a variety of tools available to help you and Support diagnose SOA Suite issues in 11g but it can be confusing as to which tool is appropriate for a particular situation and what their relationships are. This blog post will introduce the various tools and attempt to clarify what each is for and how they are related. Let's first list the tools we'll be addressing:

This overview is not mean to be a comprehensive guide on using all of these tools, however, extensive reference materials are included that will provide many more details on their execution. Another point to note is that all of these tools are applicable for Fusion Middleware as a whole but specific products may or may not have implemented features to leverage them.

A couple of the tools have a WebLogic Scripting Tool or 'WLST' interface. WLST is a command interface for executing pre-built functions and custom scripts against a domain. A detailed WLST tutorial is beyond the scope of this post but you can find general information here. There are more specific resources in the below sections.

In this post when we refer to 'Enterprise Manager' or 'EM' we are referring to Enterprise Manager Fusion Middleware Control.

RDA (Remote Diagnostic Agent)

RDA is a standalone tool that is used to collect both static configuration and dynamic runtime information from the SOA environment. RDA is generally run manually from the command line against a domain or single server. When opening a new Service Request, including an RDA collection can dramatically decrease the back and forth required to collect logs and configuration information for Support.

After installing RDA you configure it to use the SOA Suite module as decribed in the referenced resources. The SOA module includes the Oracle WebLogic Server (WLS) module by default in order to include all of the relevant information for the environment. In addition to this basic configuration there is also an advanced mode where you can set the number of thread dumps for the collections, log files, Incidents, etc.

When would you use it?
When creating a Service Request or otherwise working with Oracle resources on an issue, capturing environment snapshots to baseline your configuration or to diagnose an issue on your own.

How is it related to the other tools?
RDA is related to DFW in that it collects the last 10 Incidents from the server by default. In a similar manner, RDA is related to ODL through its collection of the diagnostic logs and these may contain information from Selective Tracing sessions.

Examples of what it currently collects: (for details please see the links in the Resources section)
  • Diagnostic Logs (ODL)
  • Diagnostic Framework Incidents (DFW)
  • SOA MDS Deployment Descriptors
  • SOA Repository Summary Statistics
  • Thread Dumps
  • Complete Domain Configuration

RDA Resources: top

DFW (Diagnostic Framework)

DFW provides the ability to collect specific information for a particular problem when that problem occurs. DFW is included with your SOA Suite installation and deployed to the domain. Let's define the components of DFW.
  • Diagnostic Dumps: Specific diagnostic collections that are defined at either the 'system' or product level. Examples would be diagnostic logs or thread dumps.
  • Incident: A collection of Diagnostic Dumps associated with a particular problem
  • Log Conditions: An Oracle Diagnostic Logging event that DFW is configured to listen for. If the event is identified then an Incident will be created.
  • WLDF Watch: The WebLogic Diagnostic Framework or 'WLDF' is not a component of DFW, however, it can be a source of DFW Incident creation through the use of a 'Watch'.
  • WLDF Notification: A Notification is a component of WLDF and is the link between the Watch and DFW. You can configure multiple Notification types in WLDF and associate them with your Watches. 'FMWDFW-notification' is available to you out of the box to allow for DFW notification of Watch execution.
  • Rule: Defines a WLDF Watch or Log Condition for which we want to associate a set of Diagnostic Dumps. When triggered the specified dumps will be collected and added to the Incident
  • Rule Action: Defines the specific Diagnostic Dumps to collect for a particular rule
  • ADR: Automatic Diagnostics Repository; Defined for every server in a domain. This is where Incidents are stored

Now let's walk through a simple flow:
  1. Oracle Web Services error message OWS-04086 (SOAP Fault) is generated on managed server 1
  2. DFW Log Condition for OWS-04086 evaluates to TRUE
  3. DFW creates a new Incident in the ADR for managed server 1
  4. DFW executes the specified Diagnostic Dumps and adds the output to the Incident
  5. In this case we'll grab the diagnostic log and thread dump. We might also want to collect the WSDL binding information and SOA audit trail

When would you use it?
When you want to automatically collect Diagnostic Dumps at a particular time using a trigger or when you want to manually collect the information. In either case it can be readily uploaded to Oracle Support through the Service Request.

How is it related to the other tools?
DFW generates Incidents which are collections of Diagnostic Dumps. One of the system level Diagonstic Dumps collects the current server diagnostic log which is generated by ODL and can contain information from Selective Tracing sessions. Incidents are included in RDA collections by default and ADRCI is a tool that is used to package an Incident for upload to Oracle Support. In addition, both ODL and DMS can be used to trigger Incident creation through DFW.

The conditions and rules for generating Incidents can become quite complicated and the below resources go into more detail. A simpler approach to leveraging at least the Diagnostic Dumps is through WLST (WebLogic Scripting Tool) where there are commands to do the following:
  • Create an Incident
  • Execute a single Diagnostic Dump
  • Describe a Diagnostic Dump
  • List the available Diagnostic Dumps
The WLST option offers greater control in what is generated and when. It can be a great help when collecting information for Support. There are overlaps with RDA, however, DFW is geared towards collecting specific runtime information when an issue occurs while existing Incidents are collected by RDA.

There are 3 WLDF Watches configured by default in a SOA Suite 11g domain: Stuck Threads, Unchecked Exception and Deadlock. These Watches are enabled by default and will generate Incidents in ADR. They are configured to reset automatically after 30 seconds so they have the potential to create multiple Incidents if these conditions are consistent. The Incidents generated by these Watches will only contain System level Diagnostic Dumps. These same System level Diagnostic Dumps will be included in any application scoped Incident as well.

Starting in, SOA Suite is including its own set of application scoped Diagnostic Dumps that can be executed from WLST or through a WLDF Watch or Log Condition. These Diagnostic Dumps can be added to an Incident such as in the earlier example using the error code OWS-04086.
  • soa.config: MDS configuration files and deployed-composites.xml
  • soa.composite: All artifacts related to the deployed composite
  • soa.wsdl: Summary of endpoints configured for the composite
  • soa.edn: EDN configuration summary if applicable
  • soa.db: Summary DB information for the SOA repository
  • soa.env: Coherence cluster configuration summary
  • soa.composite.trail: Partial audit trail information for the running composite
The current release of RDA has the option to collect the soa.wsdl and soa.composite Diagnostic Dumps. More Diagnostic Dumps for SOA Suite products are planned for future releases along with enhancements to DFW itself.

DFW Resources: top

Selective Tracing

Selective Tracing is a facility available starting in version that allows you to increase the logging level for specific loggers and for a specific context. What this means is that you have greater capability to collect needed diagnostic log information in a production environment with reduced overhead. For example, a Selective Tracing session can be executed that only increases the log level for one composite, only one logger, limited to one server in the cluster and for a preset period of time. In an environment where dozens of composites are deployed this can dramatically reduce the volume and overhead of the logging without sacrificing relevance.

Selective Tracing can be administered either from Enterprise Manager or through WLST. WLST provides a bit more flexibility in terms of exactly where the tracing is run.

When would you use it?
When there is an issue in production or another environment that lends itself to filtering by an available context criteria and increasing the log level globally results in too much overhead or irrelevant information. The information is written to the server diagnostic log and is exportable from Enterprise Manager

How is it related to the other tools?
Selective Tracing output is written to the server diagnostic log. This log can be collected by a system level Diagnostic Dump using DFW or through a default RDA collection. Selective Tracing also heavily leverages ODL fields to determine what to trace and to tag information that is part of a particular tracing session.

Available Context Criteria:
  • Application Name
  • Client Address
  • Client Host
  • Composite Name
  • User Name
  • Web Service Name
  • Web Service Port

Selective Tracing Resources: top

DMS (Dynamic Monitoring Service)

DMS exposes runtime information for monitoring. This information can be monitored in two ways:
  1. Through the DMS servlet
  2. As exposed MBeans
The servlet is deployed by default and can be accessed through http://<host>:<port>/dms/Spy (use administrative credentials to access). The landing page of the servlet shows identical columns of what are known as Noun Types. If you select a Noun Type you will see a table in the right frame that shows the attributes (Sensors) for the Noun Type and the available instances. SOA Suite has several exposed Noun Types that are available for viewing through the Spy servlet. Screenshots of the Spy servlet are available in the Knowledge Base article How to Monitor Runtime SOA Performance With the Dynamic Monitoring Service (DMS).

Every Noun instance in the runtime is exposed as an MBean instance. As such they are generally available through an MBean browser and available for monitoring through WLDF. You can configure a WLDF Watch to monitor a particular attribute and fire a notification when the threshold is exceeded. A WLDF Watch can use the out of the box DFW notification type to notify DFW to create an Incident.

When would you use it?
When you want to monitor a metric or set of metrics either manually or through an automated system. When you want to trigger a WLDF Watch based on a metric exposed through DMS.

How is it related to the other tools?
DMS metrics can be monitored with WLDF Watches which can in turn notify DFW to create an Incident.

DMS Resources: top

ODL (Oracle Diagnostic Logging)

ODL is the primary facility for most Fusion Middleware applications to log what they are doing. Whenever you change a logging level through Enterprise Manager it is ultimately exposed through ODL and written to the server diagnostic log. A notable exception to this is WebLogic Server which uses its own log format / file.

ODL logs entries in a consistent, structured way using predefined fields and name/value pairs. Here's an example of a SOA Suite entry:

[2012-04-25T12:49:28.083-06:00] [AdminServer] [ERROR] [] [oracle.soa.bpel.engine] [tid: [ACTIVE].ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: ] [ecid: 0963fdde7e77631c:-31a6431d:136eaa46cda:-8000-00000000000000b4,0] [errid: 41] [ BPELProcess2_pt] [APP: soa-infra] [composite_name: TestProject2] [ fabric] [ bpelprocess1_client_ep] [ soa-infra] Error occured while handling a post operation[[

When would you use it?
You'll use ODL almost every time you want to identify and diagnose a problem in the environment. The entries are written to the server diagnostic log.

How is it related to the other tools?
The server diagnostic logs are collected by DFW and RDA. Selective Tracing writes its information to the diagnostic log as well. Additionally, DFW log conditions are triggered by ODL log events.

ODL Resources: top

ADR (Automatic Diagnostics Repository)

ADR is not a tool in and of itself but is where DFW stores the Incidents it creates. Every server in the domain has an ADR location which can be found under <SERVER_HOME>/adr. This is referred to the as the ADR 'Base' location. ADR also has what are known as 'Home' locations. Example:
  • You have a domain called 'myDomain' and an associated managed server called 'myServer'. Your admin server is called 'AdminServer'.
  • Your domain home directory is called 'myDomain' and it contains a 'servers' directory.
  • The 'servers' directory contains a directory for the managed server called 'myServer' and here is where you'll find the 'adr' directory which is the ADR 'Base' location for myServer.
  • To get to the ADR 'Home' locations we drill through a few levels: diag/ofm/myDomain/
  • In an SOA Suite domain you will see 2 directories here, 'myServer' and 'soa-infra'. These are the ADR 'Home' locations.
  • 'myServer' is the 'system' ADR home and contains system level Incidents.
  • 'soa-infra' is the name that SOA Suite used to register with DFW and this ADR home contains SOA Suite related Incidents
  • Each ADR home location contains a series of directories, one of which is called 'incident'. This is where your Incidents are stored.

When would you use it?
It's a good idea to check on these locations from time to time to see whether a lot of Incidents are being generated. They can be cleaned out by deleting the Incident directories or through the ADRCI tool. If you know that an Incident is of particular interest for an issue you're working with Oracle you can simply zip it up and provide it.

How does it relate to the other tools?
ADR is obviously very important for DFW since it's where the Incidents are stored. Incidents contain Diagnostic Dumps that may relate to diagnostic logs (ODL) and DMS metrics. The most recent 10 Incident directories are collected by RDA by default and ADRCI relies on the ADR locations to help manage the contents.

ADRCI (Automatic Diagnostics Repository Command Interpreter)

ADRCI is a command line tool for packaging and managing Incidents.

When would you use it?
When purging Incidents from an ADR Home location or when you want to package an Incident along with an offline RDA collection for upload to Oracle Support.

How does it relate to the other tools?
ADRCI contains a tool called the Incident Packaging System or IPS. This is used to package an Incident for upload to Oracle Support through a Service Request. Starting in IPS will attempt to collect an offline RDA collection and include it with the Incident package. This will only work if Perl is available on the path, otherwise it will give a warning and package only the Incident files.

ADRCI Resources: top

WLDF (WebLogic Diagnostic Framework)

WLDF is functionality available in WebLogic Server since version 9. Starting with FMw 11g a link has been added between WLDF and the pre-existing DFW, the WLDF Watch Notification. Let's take a closer look at the flow:
  1. There is a need to monitor the performance of your SOA Suite message processing
  2. A WLDF Watch is created in the WLS console that will trigger if the average message processing time exceeds 2 seconds. This metric is monitored through a DMS MBean instance.
  3. The out of the box DFW Notification (the Notification is called FMWDFW-notification) is added to the Watch. Under the covers this notification is of type JMX.
  4. The Watch is triggered when the threshold is exceeded and fires the Notification.
  5. DFW has a listener that picks up the Notification and evaluates it according to its rules, etc
When it comes to automatic Incident creation, WLDF is a key component with capabilities that will grow over time.

When would you use it?
When you want to monitor the WLS server log or an MBean metric for some condition and fire a notification when the Watch is triggered.

How does it relate to the other tools?
WLDF is used to automatically trigger Incident creation through DFW using the DFW Notification.

WLDF Resources: top

Friday May 11, 2012

Sample Script for Extending an Existing Oracle Service Bus (OSB) Cluster by Adding Additional Managed Servers

Extending an existing Oracle Service Bus (OSB) cluster (scaling up or scaling out) is currently a manual task as described in our product documentation:

If some of the steps or tasks involved in adding the server are not completed successfully or omitted, the new managed servers will fail or have issues. In order to help with this task, we have created a very basic sample scipt that should help to successfully create the additional managed servers. The script is available as a SAMPLE CODE document provided by Oracle Customer Support:

To run the script, download the attachments of the note above and store them in a directory of your choice:

Open the file in a text editor and adapt it to your environment:

The admin server of the domain should be up and running before adding additional managed servers. To run the script, start a command prompt window and set the domain environment for your existing domain:

Change to the directory containing the downloaded script and property file. To run the script, you can use the wlst.cmd|sh script which is provided with the WebLogic Server installation. The wlst.cmd|sh script is available in %MW_HOME%\wlserver_10.3\common\bin on Windows and $MW_HOME/wlserver_10.3/common/bin on Linux/Unix. Run the script:

  • wlst.cmd|sh

The script will analyze the cluster as defined in the file and check which managed servers are already available. The prerequisite for this sample script is, that all managed server names have the same prefix like osb_server and that they are numbered sequentially, in my example osb_server1 to osb_server4. The script will create a new managed server osb_server5:

The script will also create the related JMS objects for the new managed server:

Wednesday Apr 25, 2012

Extending a SOA Domain to Include BAM

This post includes instructions and screen shots on how to extend a SOA domain to include BAM. We follow the SOA 11g EDG guide:

     Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1)
     Section 7.3 Extending the Domain to Include BAM

The environment used had 2 physical hosts: BAMHOST1 and BAMHOST2. The steps were performed on BAMHOST1. Please refer to the following section in the EDG for instructions on how to propagate the domain to the other BAM server.

     Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1)
     Section 7.7 Propagating the Domain Configuration to BAMHOST1 and BAMHOST2 Using the
     pack/unpack Utility

    1. Change directory to the location of the Configuration Wizard. It should be under the $ORACLE_COMMON_HOME/common/bin directory:

          Example: cd /u01/app/oracle/product/soa/common/bin

    2. Start the Configuration Wizard:


    3. In the Welcome screen, select Extend an existing WebLogic domain, and click Next.

    4. In the WebLogic Domain Directory screen, select the following WebLogic domain directory, $ORACLE_BASE/admin/domain_name/aserver/domain_name Example: /u01/app/oracle/product/admin/aserver/edg_domain.

    Click Next.

    (click image for full view)

    5. In the Select Extension Source screen, do the following:

      5.1 Select Extend my domain automatically to support the following added products
      • Oracle Business Activity Monitoring [soa]

      Click Next.

      (click image for full view)

    6. The warning message CFGFWMK-64061 may appear. Select Replace existing component and click OK

    (click image for full view)

    7. In the Configure JDBC Component Schema screen do the following:

      7.1. Select BAM Schema.

      7.2. Select Configure selected component schemas as RAC multi data source schemas in the next panel.

      Enter values for the following fields:

      • Driver: Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11.
      • Service Name: Enter the service name of the database; for example, ORCL
      • User Name: Enter the BAM complete user name for the schema; example DEV_ORABAM
      • Password: Enter the password to use to access the schema

      7.3. Click Add and enter the details for the first and second RAC instance. For example:

      • HostName: (used SCAN address)
      • Instance Name: ORCL1
      • HostName: (used SCAN address)
      • Instance Name: ORCL2

    Click Next.

    (click image for full view)

    8. In the Test JDBC Data Sources screen, the connections should be tested automatically. The Status column displays the results. Ensure that all connections were successful. Click Next.

    (click image for full view)

    9. In the Select Optional Configuration screen, select the following:

    • Managed Servers, Clusters, and Machines
    • Deployments and Services
    • JMS File Store

    Click Next.

    (click image for full view)

    10. In the Select JMS Distributed Destination Type screen, select UDD from the drop-down list for all Fusion Middleware Components' JMS Modules.

    11. In the Configure Managed Servers screen, rename the bam_server1 server to WLS_BAM1.

    (click image for full view)

    12. Click on Add and add a new server called WLS_BAM2. Give these servers the attributes shown in the picture.

    (click image for full view)

    13. In the Configure Clusters screen, add the following cluster:

    • Name: BAM_Cluster
    • Cluster Address: leave it empty

    (click image for full view)

    14. In the Assign Servers to Clusters screen, add WLS_BAM1 and WLS_BAM2 to the BAM_Cluster. Do not modify the other assignments that display in this screen; leave them as they are.

    (click image for full view)

    15. In the Configure Machines screen, do the following:

      15.1 Delete the LocalMachine that appears by default.

      15.2 Click the Unix Machine tab. You should add the BAMHOST1 and BAMHOST2 machines and have the following entries:

    (click image for full view)

    16. In the Assign Servers to Machines screen, do the following:

    • Assign WLS_BAM1 to BAMHOST1
    • Assign WLS_BAM2 to BAMHOST2

    Click Next.

    17. In the Target Deployments to Clusters or Servers screen, ensure the following targets:

    • usermessagingserver and usermessagingdriver-email should be targeted only to SOA_Cluster and BAM_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)
    • WSM-PM should be targeted only to WSM-PM_Cluster.
    • The DMS Application should be targeted to BAM_Cluster, SOA_Cluster, WSM-PM_Cluster and Admin Server.
    • Target the oracle.sdp.* library only to SOA_Cluster and BAM_Cluster. Target the oracle.soa.* library only to SOA_Cluster.
    • Target the oracle.rules.* library to SOA_Cluster, BAM_Cluster and Admin Server.
    • The oracle.wsm.seedpolicies library should be targeted only to the WSM-PM_Cluster.
    • oracle.bam* is targeted only to BAM_Cluster.

    Click Next.

    (click image for full view)

    18. In the Target Services to Clusters or Servers screen, ensure the following targets:

    • mds-owsm, mds-owsm-rac0, and mds-owsm-rac1 should be targeted to both WSM-PM_Cluster and AdminServer.
    • mds-soa, mds-soa-rac0, and mds-soa-rac1 should be targeted to both SOA_Cluster and AdminServer.
    • OraSDPMDatasource, OraSDPMDatasource-rac0, and OraSDPMDatasource-rac1 should be targeted to both SOA_Cluster and BAM_Cluster.

    Click Next.

    (click image for full view)

    19. In the Configuration Summary screen, click Extend.

    (click image for full view)

    20. In the Configure JMS File Stores screen, enter the shared directory location example: u01/app/oracle/admin/shared /jms

    21. In the Creating Domain screen, click Done.

    (click image for full view)

Wednesday Apr 18, 2012

Follow Up to SOA 11g Database Guide Webcast

On April 11th I presented a webcast talking about the SOA Suite 11g database guide. This post is a follow up to answer the questions asked and also provide the link for the presentation recording.

The presentation recording can by found here

The schedule for future webcasts can be found here


Q. I've just finished setting up partitioning for our SOA installation. My question is if we drop a partition for BRDECISIONINSTANCE table for example, how do we avoid violating constraints and FKs?

A. This is answered in the following documentation:

- Referential Integrity and Equipartioning (version

Q. I am working on an 11g upgrade ( ->, and reviewing the documentation, I do not explicitly see information on running the RCU for the BAM schema, so does this mean that there is no requirement to upgrade BAM in this version?

A. With RCU you would create new and empty schemas. As you want to upgrade your schemas from to, the tool to do this is called Patch Set Assistant (PSA). After upgrading your software installation to, you would then use PSA to upgrade the schemas. I would recommend to check the related section in the guide 1384379.1:

Upgrade --> Updating SOA Schemas from 11g to a Later Patch Set
Check this section to understand the update process.
Then check the km document linked from there - Note 1325406.1 - Updating Repository Schemas for Oracle Fusion Middleware 11g with Patch Set Assistant (PSA) [Video]
This document has a video that explains step by step how to run PSA and what to do to update the schemas.

Finally, before actually running PSA, check section Which Schemas and Objects Need to be Upgraded? in the guide 1384379.1 to understand which schemas need to be updated if updating from to This information is available in the documentation linked from the guide.

Q. Is there also a way to programatically terminate long running composites? We have to many to manually terminate them?

A. These instances need to be terminated either manually in EM or via the API. Information is available in KM note 1400612.1 - How to Purge Active Instances ("Running" / "Recovery Needed" State) in the SOA Application.

Q. Q: I want to know basic to SOA. Can you send some links or doc id for basics of SOA?

A. This link to the Oracle SOA Suite, Business Process Management Suite, and Web Services Documentation Library is a good starting point:

Q. How can we delete long running instances that will never complete?

A. These instances need to be terminated either manually in EM or via the API. Information is available in KM note 1400612.1 - How to Purge Active Instances ("Running" / "Recovery Needed" State) in the SOA Application

Thank you to everyone who attended and to anyone who views the recording. If there are further questions or discrepancies please add a comment to this post for update.

Thursday Apr 05, 2012

Upcoming Customer WebCast: SOA 11g Database: Guide for Administrators

The SOA infrastructure database is used by SOA Suite products like BPEL PM, BAM, BPM, Human Worklow, B2B and Mediator. A SOA administrator is involved in many different tasks like installation, upgrade, performance tuning and other administrative topics. Another important one is purging - see the posting for this: SOA Suite 11g Purging Guide.

We have implemented a guide to help with thess tasks: SOA 11g Infrastructure Database: Installation, Maintenance and Administration Guide.

An upcoming advisor webcast planned for Wednesday, April 11 2012 at 15:00 UK / 16:00 CET / 07:00 am Pacific / 8:00 am Mountain / 10:00 am Eastern will walk you through the guide and show some of the highligts. Registration for this webcast is available in SOA 11g Database: Guide for Administrators [ID 1422913.1].

The presentation recording can by found here after the webcast.

The schedule for future webcasts can be found here

Friday Mar 30, 2012

SOA Suite 11g Purging Guide

We now have a single source of truth concerning Purging in My Oracle Support. The material is contained within the SOA 11g Infrastructure Database: Installation, Maintenance and Administration Guide under the 'Purging' tab.

All of the previous purge related content for 11g is now deprecated and many of the documents will redirect to this Guide while others simply contain a disclaimer.

What does the Guide contain?

  • Summary Overview of Purging. What it does and why it's important
  • Specific information on each release of 11g
  • Available patches for each release of 11g and recommendations
  • How to run the different purge scripts
  • Tips on improving performance
  • How to begin troubleshooting problems with the process
  • How to identify orphaned records
  • Useful reference information

Here are a couple of screen shots to help with navigation:

Guide Landing Page:

(click image for full view)

Select the 'Purging' tab:

(click image for full view)

The left menu contains the following options:
  • Alternative: Database Partitioning
  • What to do on 11gR1 GA (
  • What to do on PS1 (
  • What to do on PS2 (
  • What to do on PS3 (
  • What to do on PS4 (
  • Overview of PS5 (
  • Purging Step by Step
  • Performance Tips
  • Troubleshooting Purge
  • Orphaned Records
  • Reference

This resource goes hand in hand with the excellent documents SOA 11g Database Growth Management Strategy and Start Small, Grow Fast available on OTN.

The latest product documentation can be found here.

Friday Mar 09, 2012

Follow Up to SOA Selective Tracing Webcast

On March 7th I presented a webcast on how to use Selective Tracing with SOA Suite 11g. This post is a follow up to answer the questions asked and also provide the link for the presentation recording.

The presentation recording can by found here

The schedule for future webcasts can be found here

There is a mistake in the slides on where to start WLST from. It should be started from 'oracle_common/common/bin', NOT wlserver_10.3/common/bin.


Q. Can the loggers for selective tracing participation be chosen through the WLST interface?

A. Yes. The loggers can be enabled or disabled using the WLST 'configureTracingLoggers' command. Full documentation on the WLST interface for Selective Tracing can be found here

Q. What is the best way to trace a login process?

A. Selective Tracing is only effective for ODL (Oracle Diagnostic Logging) loggers. Give that the actual login process is mostly handled by WebLogic Server, Selective Tracing will not capture this information because WLS does not implement ODL. To capture data about a login it is recommended to enable the WLS Authentication and Authorization debug loggers through the WLS console.

Q. Can tracing be enabled for WebLogic Server 10.3.5 for a particular managed server?

A. From Enterprise Manager Selective Tracing is a set at the domain level, however, the WLST interface offers an option on many of the commands called 'target'. Here you may specify a particular managed server for the tracing session. More information can be found in the product documentation referenced above. Note that a WLS only installation will not have the 'oracle_common' folder and without this Selective Tracing is unavailable.

Thank you to everyone who attended and to anyone who views the recording. If there are further questions or discrepancies please add a comment to this post for update.

Friday Mar 02, 2012

How to Reset a SOA 11g DMS Metric

What is DMS?

DMS stands for 'Dynamic Monitoring Service' and is a facility through which WebLogic Server and many of our deployed applications expose runtime information. At the top level there is a list of 'Nouns' and these Nouns have attributes where the specific values are populated.

To view the runtime DMS you can access the following URL on any running WebLogic instance:


Login using the administrative credentials and you will see the following screen.

(click image to enlarge)

If SOA is deployed and running on the instance you will see a list of SOA related Nouns like the following:

(click image to enlarge)

Some of these simply state what is deployed such as the composite names, components, etc. Others provide runtime metrics for the SOA components such as the number of requests processed, the average time of those requests, etc. Most of these metrics are aggregated across composites and components.

Why Reset a Metric?

There could be several reasons for resetting a particular metric at runtime but the use case of concern here is when you have configured a WLDF Watch to monitor for some state. Here we are monitoring the average processing time of a BPEL Process in the 'soainfra_component' Noun. When the average time exceeds 5 seconds we want to trigger a Diagnostic Framework Incident and then we want to reset the Noun so we can continue monitoring it without triggering the Watch over and over and don't have to restart the server.

Here is what the metric looks like in Spy:

(click image to enlarge)

Our avg time is 1545 milliseconds. We run some load and push the avg processing time over our threshold of 5 seconds.

(click image to enlarge)

We'll assume that the Incident is generated and now we want to reset this particular metric. To do this we pass in some arguments to the Spy servlet through the URL.

  • operation: What operation do we want to perform?
  • format: What format is the data in
  • cache: What action to take on the cached data
  • name: The name of the object we want to reset
  • recurse: Do we want the reset to be recursive

Here are our values:
  • operation = reset
  • format = raw
  • cache = refreshall
  • name = <discussed below>
  • recurce = all

The 'name' is quite long and one way to get it is directly from the WLDF Watch configuration. Here is the expression that was used to create the Watch taken from the WLS console:

(click image to enlarge)

We're going to copy the 'name' from here and paste it into our reset URL. Here is the complete URL:


Every environment will be different and the name will change upon redeployment of the project.

An alternative approach is to build the 'name' value manually. It takes the form:


The following fields can be pulled directly from the soainfra_component table in DMS Spy:
  • COMPOSITE NAME is the 'soainfra_composite' column
  • COMPOSITE REVISION is the 'soainfra_composite_revision' column
  • COMPOSITE LABEL is the 'soainfra_composite_label' column
  • COMPONENT TYPE is the 'soainfra_component_type' column
  • COMPONENT NAME is the 'Name' column

These fields can change depending in the DMS metric used so WLDF can help for establishing the template to be used going forward.

We paste the URL into our browser and make the request. Refreshing the metric in Spy we see that it has been reset:

(click image to enlarge)

We'll take a quick look at the 'soainfra_Binding' metric to confirm that only soainfra_component was reset:

(click image to enlarge)

You can reset all metrics with the following URL:


I hope this post is helpful to anyone interested in working with the DMS metrics and sheds some light on how they work.

Monday Feb 27, 2012

Policy Authorization Example in SOA Suite 11g

Use Case:

We have a composite that we want to limit access to.  We will use HTTP basic authentication and an authorization policy to ensure that access is only granted to users who are members of a particular group.

We will use the WebLogic Server Console to create our users and group.  Authentication and Authorization for the composite will be entirely configured in Enterprise Manager with notes on how some steps can also be done in JDeveloper. Note that all screenshots were taken using (PS5).

Configure the Users and Group

(No screenshots for this section but they will be used extensively in the following sections)
  1. Login to the WLS console ('http://<host>:<port>/console')
  2. In the left menu select 'Security Realms'
  3. Select the realm where you want to create the users and groups.  The default is 'myrealm'
  4. At the top select the 'Users and Groups' tab
  5. You'll start with 'Users' so click 'New' and enter your user name and pwd.  Create as many users as you want.but here we are using 'Bob1', 'Bill1' and 'jane'
  6. Go to the 'Groups' tab and create a new group.  Here we're using 'Group1'
  7. Go back to the users and select 'Bob1'
  8. Select the 'Groups' tab and add 'Group1'.  Do the same for Bill1. We're gong to intentionally leave 'jane' out of the group.

You've got your users and groups configured

If you haven't already done so, deploy your composite now.

Configuration in Enterprise Manager (EM)

The EM configuration is comprised of the following steps:
  1. Add a Domain Credential
  2. Add an Application Role
  3. Add an Application Policy that assigns the Application Role a specific permission
  4. Add 3 WS Policies to the project

Let's first add a domain Credential.  From the left menu expand the domains and right click on the domain name

1.  Add Domain Credential

1.1) Login to EM

1.2) Select 'Security' -> 'Credentials'

(click image for full view)

1.3) Select 'Create Map'

(click image for full view)

1.4) Enter the map name as ''

(click image for full view)

1.5) Click 'OK'

1.6) Highlight the new Map and select 'Create Key'

(click image for full view)

1.7) Enter the key name as 'basic.credentials'

1.8) Enter the user name and pwd, we're using the admin user 'weblogic' here

(click image for full view)

1.9) Click OK and your Credentials should now look like this:

(click image for full view)

(back to top)

The next steps in our configuration are to configure the Application Role and Application Policy.  These will be used by the Authorization policy.

2.  Create the Application Role

2.1) In the left menu right click the domain name

2.2) Select 'Security' -> 'Application Roles'

(click image for full view)

2.3) Select 'soa-infra' in the 'Application Stripe' drop down

2.4) Select 'Create' as we are going to create a new Application Role

(click image for full view)

We're going to name our new role 'GroupOneRole'

2.5) Under Members click 'Add'

(click image for full view)

The Type should be 'Group'

2.6) Search and select Group1 which we created earlier

2.7) Click 'OK'

(click image for full view)

You should now have Group1 in your Members list.

(click image for full view)

(back to top)

3.  Create the Application Policy

3.1) Right click on the domain name again

3.2) Select 'Security' -> 'Application Policies'

(click image for full view)

The 'Application Stripe' is 'soa-infra'
The 'Principal Type' is 'Application Role'

3.3) Search

3.4) Click 'Create'

(click image for full view)

3.5) Under 'Permissions' click 'Add'

(click image for full view)

3.6) Immediately click the 'Continue' button to get to the custom entry form

Intuitively it seems that the selections here are needed but they're actually not for what we want to do.

(click image for full view)

3.7) For 'Permission Class' enter ''

3.8) We're going to cheat a bit and enter '*' for both Resource Name and Permission Actions.  In an actual implementation you would probably specify the web service and relevant actions.

(click image for full view)

3.9) Click 'Select' and here's what we have for Permissions:

(click image for full view)

3,10) Under 'Grantee' click 'Add'

(click image for full view)

3.11) Search with the defaults and select 'GroupOneRole'

3.12) Click 'OK'

(click image for full view)

Your 'Create Application Grant' screen should now look like this:

(click image for full view)

3.13) Click 'OK' at the top right and confirm that the 'GroupOneRole' Principal appears in the list

(click image for full view)

(back to top)

We're now ready to add the policies to the project

4.  Add WS Policies to Project

4.1) Right click on the project name

4.2) Select 'Policies'

(click image for full view)

Here we see that the project has no policies associated with it.  We're going to add 3.

4.3) Select 'Attach To/Detach From'

(click image for full view)

Depending on the complexity of your project you will likely have more components than this.  Here we're going to select the web service that is the entry point for our composite, 'bpelprocess2_client_ep'.  The following window opens.

(click image for full view)

We're going to add 3 policies:

  • 'oracle/wss_http_token_service_policy' for authentication
  • 'oracle/log_policy' for logging the policy activities
  • 'oracle/binding_permission_authorization_policy' for authorization
All of these policies can be added to the web service in JDeveloper by right clicking on the service in the composite design view and selecting 'Configure WS Policies...'. The form is similar to what is shown here in EM.

4.4) Highlight the selections from the list and click 'Attach'.  When completed your 'Directly Attached Policies' should look like this:

(click image for full view)

4.5) Select 'Validate' and then 'OK'

Your policies list should now look like this:

(click image for full view)

The configuration is complete.

(back to top)

For testing we're using JMeter, submitting the request along with the HTTP authentication header.

I won't get into the JMeter configuration but will  provide the responses for two requests.  Let's first try our user 'Bob1'.

HTTP Authorization header value is 'Basic Qm9iMTp3ZWJsb2dpYzE='  (this is the Base64 encoding of 'Bob1:weblogic1')

Response from our server:

(click image for full view)

Now let's try user jane who exists in the domain but is not a member of Group1

HTTP Authorization header value is 'Basic amFuZTp3ZWJsb2dpYzE='  (Base64 encoding of 'jane:weblogic1')

Response from server:

(click image for full view)

Here we see the response code 403 which means the resource is forbidden to the authenticated requester.

In our server standard out we see the following error message:

<Error> <> <WSM-00045> <HTTP authentication/authorization failure.>

I hope this post is helpful for anyone trying to enable authorization for their SOA 11g  composite applications.  It's a very simply example but perhaps will serve as a good starting point.  In the future we may add the complexity in follow up posts.

(back to top)


This is the official blog of the SOA Proactive Support Team. Here we will provide information on our activities, publications, product related information and more. Additionally we look forward to your feedback to improve what we do.


« May 2016