Blogpost Retrieving Composite and Component Audit levels Dynamically

1. Description

At one of our clients I’m working with Oracle SOA Suite 11g on which we have deployed quite a lot of SOA composites. For troubleshooting purposes the SOA Suite supports fine grained configuration of audit levels for individual SOA composites and components. Although the audit level can be toggled manually using the Fusion Middleware Enterprise Manager Console, managing this using WLST has several benefits.

This article describes how Weblogic Scripting Tool (WLST) can be used for retrieving the current SOA Composite and SOA Component Audit Levels. The target audience is Oracle SOA Suite Administrators.

The aim is to retrieve these Audit Levels dynamically, making no need to change the script or a property file after a deployment of new SOA composites.

2. SOA Composite and SOA Component Audit Levels

The SOA Composite Audit Level determines how the audit trail is logged in the SOA-Infra database. The Audit trail is viewable in the FMW EM console. The possible values for SOA Composite Audit Levels are:

  • – Off
  • – Production
  • – Development
  • – Inherit

Viewing the detailed component flow, for example a BPEL flow in a composite, is possible by setting the Component Audit Level. This data is also stored in the SOA-Infra database and can be viewed in the FMW EM console, accessible through the SOA Composite audit trail. The possible values for SOA Component Audit Levels are:

  • – Off
  • – Minimal
  • – Production
  • – Development
  • – Inherit

3. Audit Level values explained

Oracle has documented the following descriptions of the possible Audit Level values. Note that Inherit will inherit the value used on SOA Infrastructure level.

  • – Off: No composite instance tracking and payload tracking information is collected. No more composite instances can be created. No logging is performed. Note that disabling logging and the display of instances in Oracle Enterprise Manager Fusion Middleware Control Console can result in a slight performance increase for processing instances. Instances are created, but are not displayed.
  • – Development: Enables both composite instance tracking and payload detail tracking. However, this setting may impact performance. This level is useful largely for testing and debugging purposes.
  • – Production: Composite instance tracking is collected, but the Oracle Mediator service engine does not collect payload details and the BPEL process service engine does not collect payload details for assign activities (payload details for other BPEL activities are collected). This level is optimal for most normal production operations.

The Audit Level values have great impact on performance. Especially ‘Development’ will result in a huge decrease in performance. It is therefore advised that the Audit Levels on Production environments are set to Production or Off for synchronous traffic.

It can be a time-consuming administrative task to check (and correct if necessary) the Composite and Component Audit Levels using the FMW EM Console. We can also perform these tasks with WLST, as shown below.

4. Retrieving SOA Composite Audit Levels using WLST

In order to access the MBeans, being part of the SOA Suite, WLST can be used to manage the appropriate audit levels. We need to switch to the custom tree, after connecting to the appropriate SOA managed server:

           ## Connect to managed server
           connect(username, password, URL)
           ## Navigate to custom tree
           custom()

Once connected to a managed server and navigated to the custom tree, we can find a directory structure containing the SOA Composites as well as the SOA Components inside the ‘oracle.soa. config’ directory.

For retrieval we only need to use one managed server for each WebLogic cluster. If the deployments are targeted to a cluster, the properties.xml is used for every managed server in the cluster, resulting in the same properties on all managed servers in the cluster.

Using the following code we can retrieve the Audit Levels for each SOA Composite deployed on the managed server:

           cd(‘oracle.soa.config’)
               ## Redirect screen output of ls() to /dev/null
               redirect(‘/dev/null’,’false’)
               ## Retrieving directories in oracle.soa.config
               list = ls(returnMap=’true’)
               ## Show output again
               redirect(‘/dev/null’,’true’)
 
               for composite in list:
                       compositeObject = ObjectName(composite)
                     ## Retrieving Audit Level only for objects with j2eeType SCAComposite
                       if compositeObject.getKeyProperty(‘j2eeType’) == ‘SCAComposite’:
                               ## Properties of compositeObject
                              compositeProperties = mbs.getAttribute(compositeObject, ‘Properties’)
                               try:
                                       auditLevelValue = compositeProperties[0].get(‘value’)
                              except:
                                       auditLevelValue = ‘Inherit’

The try/except in de code above is used because there is no compositeProperties[0] when the auditLevelValue is set to Inherit for this composite.

5. Retrieving SOA Component Audit Levels

To link the composite with its underlying components (i.e. BPEL component), we can use the MDS label. This label is the same for the composite and its components. The following snippet shows how to retrieve the Audit Level for the BPEL components belonging to the current composite.

                       ## Retrieving composite MDS label
                       compositeLabel = compositeObject.getKeyProperty(‘label’)


for component in list:
                        componentObject = ObjectName(component)
 
                       ## Retrieving component MDS label
                       componentLabel = componentObject.getKeyProperty(‘label’)
 
                       ## Retrieving Audit Level for SCA Components with same MDS label as the SCA Composite
                       if componentObject.getKeyProperty(‘j2eeType’) == ‘SCAComposite.SCAComponent’ and
                           componentLabel == compositeLabel:
                               componentProperties = mbs.getAttribute(componentObject, ‘Properties’)
  
                               ## Looping through elements in Properties
                               for element in componentProperties:
                                       if element.containsValue(‘bpel.config.auditLevel’):
                                               componentAuditLevelValue = element.get(‘value’)

6. Changing the Audit Levels

Changing the Audit Level through an MBean operation though, requires to execute this operation on each managed server in the cluster. This is because we are executing this MBean operation only on the managed server we are connected to. This can cause inconsistency when, for example, a managed server is down, therefore I haven’t added the code for changing it with WLST in this blogpost. For those who wish to change with WLST, I would advise to add a check if all the servers are present in de serverRuntime.

To avoid this issue we can simply change the Audit Levels in the FMW EM Console. These changes are being processed on all the managed servers targeted for the SOA-Infra deployment. The downside of changing it in the FMW EM Console, as previously stated, is that this can be a time-consuming job for large domains.

blog_maarten1 SOAFigure 1: SOA Composite Audit Level in FMW EM Console
 
  blog_maarten2 SOA
Figure 2: SOA Component Audit Level in System Mbean Browser

7. Summary

It is possible with WLST to create a list of SOA Composites and their underlying SOA Components, along with their Audit Levels.

blog_maarten3 SOA

 

 

 

 

 

Figure 3: Example result of WLST script

Changing the Audit Levels through WLST is also possible. However, it requires the invoke to be executed on each Managed Server targeted for the SOA Infra deployment. This can cause situations of inconsistency when, for example, a server is down.