Auditing SOA Composite Applications at the BPEL Activity Level

Audit trail data often accounts for a large percentage of the state data persisted to the database. To reduce the amount of persisted state data, you can specify finer-grained levels of auditing at the BPEL process activity level. These settings take precedence over the audit trail settings configured at the service component, SOA composite application, BPEL process service engine, and SOA Infrastructure levels.

You perform the following procedures:

Create and configure an audit policy XML file that defines the level of auditing to perform on BPEL activities in the SOA composite application.
Create and configure an audit policy binding XML file that binds the audit policy to the BPEL process.
Place the files in the same directory location as the composite.xml file or in a separate directory that you identify with properties in the composite.xml file.
Deploy the SOA composite application to the SOA Infrastructure.
View the audit trail of the BPEL process activities in the flow trace of the SOA composite application in Oracle Enterprise Manager Fusion Middleware Control.

Note the following guidelines:

The audit policy supports the auditing of both standard BPEL 1.1 and 2.0 activities and scopes and BPEL extension activities, such as emails, notifications, and all others. Within a parent scope, you can configure specific child scopes to be audited, and other child scopes to not be audited.

The supported auditing levels are shown in Table 50-7.

Table 50-7 Auditing Levels

Level	Description
`Inherit`	Logging matches the SOA Infrastructure audit level that you set on the SOA Infrastructure Common Properties page in Oracle Enterprise Manager Fusion Middleware Control. This is the default setting.
`Production`	Minimal information for business flow instances is collected. For example, the BPEL process service engine does not capture the payload. Therefore, the payload details are not available in the flow audit trails. This level is optimal for most standard operations and testing.
`Development`	Complete information for BPEL process activities is collected. This option allows both composite instance tracking and payload tracking. This setting may have an impact on performance because the payload is stored at each step in the message flow. This setting is useful for debugging purposes.
`Off`	No logging is performed. Composite instance tracking information and payload tracking information are not collected.

Support is provided for wild-card matching of process names and revision numbers in the fault policy binding file. For example:
- Entering Order* applies to BPEL process service components included in the composite named OrderProcess, OrderRejected, and OrderConfirmed:
```
<process auditPolicy="noLoops" name="Order*"/>
```
- Entering 1* applies to composite revisions 1.0, 1.1, and 1.2:
```
<process auditPolicy="noAssign" name="*" revision="1.*"/>
```

The following example shows the audit policy schema to use:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/auditpolicy"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="http://schemas.oracle.com/bpel/auditpolicy"
   elementFormDefault="qualified">
   <!-- activity can have a type or a name as optional attribute.-->
   <!-- Audit rules apply to all activities if no specific type or name is -->
   <!-- provided -->
   <xs:complexType name="Activity">
        <xs:attribute name="type" type="xs:QName" use="optional"/>
        <xs:attribute name="name" type="tns:idType" use="optional"/>
        <xs:attribute name="auditLevel" type="tns:auditLevelType" use="required"/>
   </xs:complexType>
   <xs:simpleType name="idType">
        <xs:restriction base="xs:string">
             <xs:minLength value="1"/>
         </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="auditLevelType">
         <xs:restriction base="xs:string">
              <xs:enumeration value="off"/>
              <xs:enumeration value="minimal"/>
              <xs:enumeration value="production"/>
              <xs:enumeration value="development"/>
         </xs:restriction>
   </xs:simpleType>
   <xs:element name="auditPolicy">
        <xs:complexType>
             <xs:sequence>
                  <xs:element name="activity" type="tns:Activity" minOccurs="0"
                   maxOccurs="unbounded"/>
             </xs:sequence>
             <xs:attribute name="id" type="tns:idType" use="required"/>
             <xs:attribute name="version" type="xs:string" default="1.0"/>
        </xs:complexType>
        <!-- we restrict users to provide mulitple rules for same activity -->
        <xs:key name="UniqueActivity">
             <xs:selector xpath="tns:activity"/>
             <xs:field xpath="@type"/>
             <xs:field xpath="@name"/>
        </xs:key>
     </xs:element>
</xs:schema>

The following example shows the audit policy binding schema to use.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://schemas.oracle.com/bpel/auditpolicyBinding"
     xmlns:tns="http://schemas.oracle.com/bpel/auditpolicy"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified">
        <xs:complexType name="Process">
             <xs:attribute name="auditPolicyId" type="tns:idType" use="optional"/>
             <xs:attribute name="name" type="tns:idType" use="optional"/>
             <xs:attribute name="revision" type="tns:idType" use="optional"/>
        </xs:complexType>
        <xs:simpleType name="idType">
                <xs:restriction base="xs:string">
                       <xs:minLength value="1"/>
                </xs:restriction>
        </xs:simpleType>
        <xs:element name="auditPolicyBinding">
                <xs:complexType>
                       <xs:sequence>
                            <xs:element name="process" type="tns:Process"
                             minOccurs="0" maxOccurs="unbounded"/>
                        </xs:sequence>
                        <xs:attribute name="version" type="xs:string"
                         default="1.0"/>
                 </xs:complexType>
                 <xs:key name="UniqueActivity">
                       <xs:selector xpath="tns:process"/>
                       <xs:field xpath="@name"/>
                       <xs:field xpath="@revision"/>
                 </xs:key>
         </xs:element>
</xs:schema>