Wednesday Nov 07, 2012

JMS Step 1 - How to Create a Simple JMS Queue in Weblogic Server 11g

JMS Step 1 - How to Create a Simple JMS Queue in Weblogic Server 11g

This example shows the steps to create a simple JMS queue in WebLogic Server 11g for testing purposes. For example, to use with the two sample programs and which will be shown in later examples.

Additional, detailed information on JMS can be found in the following Oracle documentation:

Oracle® Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server
11g Release 1 (10.3.6)
Part Number E13738-06

1. Introduction and Definitions

A JMS queue in Weblogic Server is associated with a number of additional resources:

JMS Server

A JMS server acts as a management container for resources within JMS modules. Some of its responsibilities include the maintenance of persistence and state of messages and subscribers. A JMS server is required in order to create a JMS module.

JMS Module

A JMS module is a definition which contains JMS resources such as queues and topics. A JMS module is required in order to create a JMS queue.


JMS modules are targeted to one or more WLS instances or a cluster. Resources within a JMS module, such as queues and topics are also targeted to a JMS server or WLS server instances. A subdeployment is a grouping of targets. It is also known as advanced targeting.

Connection Factory

A connection factory is a resource that enables JMS clients to create connections to JMS destinations.

JMS Queue

A JMS queue (as opposed to a JMS topic) is a point-to-point destination type. A message is written to a specific queue or received from a specific queue.

The objects used in this example are:

Object Name




JMS Server


JMS Module




Connection Factory



JMS Queue


2. Configuration Steps

The following steps are done in the WebLogic Server Console, beginning with the left-hand navigation menu.

2.1 Create a JMS Server

  1. Services > Messaging > JMS Servers

  2. Select New
  3. Name: TestJMSServer
    Persistent Store: (none)
  4. Target: soa_server1  (or choose an available server)
  5. Finish

The JMS server should now be visible in the list with Health OK.

2.2 Create a JMS Module

  1. Services > Messaging > JMS Modules
  2. Select New
  3. Name: TestJMSModule
    Leave the other options empty
  4. Targets: soa_server1  (or choose the same one as the JMS server)
  5. Leave “Would you like to add resources to this JMS system module” unchecked and  press Finish .

2.3 Create a SubDeployment

A subdeployment is not necessary for the JMS queue to work, but it allows you to easily target subcomponents of the JMS module to a single target or group of targets. We will use the subdeployment in this example to target the following connection factory and JMS queue to the JMS server we created earlier.

  1. Services > Messaging > JMS Modules
  2. Select TestJMSModule
  3. Select the Subdeployments  tab and New
  4. Subdeployment Name: TestSubdeployment
  5. Press Next
  6. Here you can select the target(s) for the subdeployment. You can choose either Servers (i.e. WebLogic managed servers, such as the soa_server1) or JMS Servers such as the JMS Server created earlier. As the purpose of our subdeployment in this example is to target a specific JMS server, we will choose the JMS Server option.
    Select the
    TestJMSServer created earlier
  7. Press Finish

2.4  Create a Connection Factory

  1. Services > Messaging > JMS Modules
  2. Select TestJMSModule  and press New
  3. Select Connection Factory  and Next
  4. Name: TestConnectionFactory
    JNDI Name:
    Leave the other values at default
  5. On the Targets page, select the Advanced Targeting  button and select TestSubdeployment
  6. Press Finish

The connection factory should be listed on the following page with TestSubdeployment and TestJMSServer as the target.

2.5 Create a JMS Queue

  1. Services > Messaging > JMS Modules
  2. Select TestJMSModule  and press New
  3. Select Queue and Next
  4. Name: TestJMSQueue
    JNDI Name: jms/TestJMSQueue
    Template: None
  5. Subdeployments: TestSubdeployment
  6. Finish

The TestJMSQueue should be listed on the following page with TestSubdeployment and TestJMSServer.

Confirm the resources for the TestJMSModule. Using the Domain Structure tree, navigate to soa_domain > Services > Messaging > JMS Modules then select TestJMSModule

You should see the following resources

The JMS queue is now complete and can be accessed using the JNDI names

jms/TestConnectionFactory and

In the following blog post in this series, I will show you how to write a message to this queue, using the WebLogic sample Java program

Wednesday Oct 31, 2012

Announcing Upcoming SOA and JMS Introductory Blog Posts

Announcing Upcoming SOA and JMS Introductory Blog Posts

Beginning next week, SOA Proactive Support will begin posting a series of introductory blogs here on working with JMS in a SOA context. The posts will begin with how to set up JMS in WebLogic server, lead you through reading and writing to a JMS queue from the WLS Java samples, continue with how to access it from a SOA composite and, finally, describe how to set up and access AQ JMS (Advanced Queuing JMS) from a SOA/BPEL process.

The posts will be of a tutorial nature and include step-by-step examples. Your questions and feedback are encouraged.

The following topics are planned:

  • How to Create a Simple JMS Queue in Weblogic Server 11g
  • Using the Sample Program to Send a Message to a JMS Queue
  • Using the Sample Program to Read a Message from a JMS Queue
  • How to Create an 11g BPEL Process Which Writes a Message Based on an XML Schema to a JMS Queue
  • How to Create an 11g BPEL Process Which Reads a Message Based on an XML Schema from a JMS Queue
  • How to Set Up an AQ JMS (Advanced Queueing JMS) for SOA Purposes
  • How to Write to an AQ JMS Queue from a BPEL Process
  • How to Read from an AQ JMS Queue from a BPEL Process

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.

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.


« June 2016