OSB: Deploy Service Level Agreement (SLA), akna Alert Rules

A great feature of the Oracle Service Bus is the usage of a Service Level Agreement (SLA). This will give you operational information when services are running and are not compliant with your SLA. For example a service may not take longer than 50 ms or a service must be executed 500 times during a certain period.

The SLA, or Alert Rules, are created via the Service Bus Console. It can not be done via Oracle Workshop (Eclipse).

The big issue with these SLA's, is the deployment. If you have dozens of services, with multiple operations, and you have a lot of environments it takes a while to create them. There is no way to define them, export and load them into another environment, apart of using the web console.

Workarround

A have a nice workaround this a relative easy to implement into multiple environments.The tasks you have to do are:

• Export the OSB Configuratie from Eclipse/ANT to a configuration file (ex. sbconfig.jar)
• Unzip de sbconfig.jar into temporary directory
• Inject the SLA rulez into the proxy files just before the </xml-fragment>
• Create new sbconfig.jar
• Import the file via console using advanced options: unchecked option “Preserve Operational Values”
• Activate

Injecting the SLA rules...

Before you can inject the SLA rules, you have to create them. :-). Creating is done via the normal way. You do this via the console. Now comes the trick. If the SLA is defined, tested etc, you export the all the services that contains SLA's.

The export is also done via the Service Bus Console. The resulted file, sbconfig.jar is downloaded to your workstation.
Unzip this file into a temporary directory. Now open all the proxy files in your favourite editor. Take a look at the end of the file. and copy all the code between the tags :

<ser:alertRules>
     <ser:alertRule enabled="true" name="CountRule">
       <aler:description>CountRule</aler:description>
       <aler:AlertFrequency>every-time</aler:AlertFrequency>
       <aler:AlertSeverity>normal</aler:AlertSeverity>
       <aler:StopProcessing>false</aler:StopProcessing>
       <aler:Condition type="statistics">
         <aler:config xmlns:mon="http://www.bea.com/wli/monitoring/alert/condition/monitoring  statistic" aggregation-interval="1" xsi:type="mon:monitoringConditionType">
           <mon:monCondExpr>
             <mon:function>count</mon:function>
             <mon:lhs>Folder$MyServiceProxy$ProxyService/PS_MyService_v0r0/Operation/ReadData/message-count</mon:lhs>
             <mon:lhs-operand-type xsi:nil="true"/>
             <mon:lhsDisplayName>Operation.ReadData.Message Count</mon:lhsDisplayName>
             <mon:operator>=</mon:operator>
             <mon:rhs>1</mon:rhs>
           </mon:monCondExpr>
         </aler:config>
       </aler:Condition>
       <aler:AlertDestination ref="SharedObjects/alert/errorDestination"/>
       <aler:AlertSummary>CountRule</aler:AlertSummary>
     </ser:alertRule>
   </ser:alertRules>
</xml-fragment>

Save this piece of code for each service into a sla.xml file. For example, you could create a new folder into the OSB project named 'sla' for this service.

A minor change need to be made in this file, the  needs to completed with the namespace.

<ser:alertRules xmlns:aler="http://www.bea.com/wli/monitoring/alert" xmlns:ser="http://www.bea.com/wli/sb/services" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

Now you can use this file to inject it in your proxies during deployment to various environments.

I want also thanks Eric Elzinga  on discussing this issue to find a proper solution.

Exporting the SOA MDS

A cool feature from SOA 11g Enterprise Manager is manageing the MDS. You can export and import the MDS to the file system.

SOA-Infra -> Administration -> MDS Configuration

Select Export and point to a directory, on the server, in which EM is able to write.

After you press OK, it will take a while, depending on the size of your MDS, when it is finished/
When you have export the data into a location on the server you can view it off course. It will contain the shared objects of the SOA 11g; Fault Policies, XML Schemas etc. But it also contains the complete SOA 11g configuration of all the settings; 

• Composite properties
• BPEL  properties
• Mediator properties
• Workflow  properties
• Rule  properties

This is a nice to have when you want to discover your environment settings quickly.

$ tree -d -L 2
.
|-- apps
|   `-- faultPolicies
|-- deployed-composites
|   `-- default
`-- soa
    |-- b2b
    |-- configuration
    `-- shared

It also contains all the composites with their artifacts; WSDL, BPEL, XSL, XLST, etc. You are able to view whate the result is from your deployment. How are the files manipulated from the SAR file to MDS.

Purging SOA Suite: Not fully completed

As we have purge scripts loaded in the dehyradtion database to clean up the data, we saw that not all the data is removed. The table AUDIT_COUNTER grows.  I assume it is a bug/feature of the frabric package.

You should update your fabric package, or create your own :-), to delete this data as well. But this can only be done if the CIKEY doe not exists in the CUBE_INSTANCE table.

delete from audit_counter ac

where ac.cikey not in 

(

   select ci.cikey from cube_instance ci

);