As a follow up to my 2 minute Tech Tip https://youtu.be/14gEIXhCwbk taken by @BobRhubart about SOA Suite monitoring I'd like to give you some more context than that fuzzy performance of me during Oracle Open World 2016.

Monitoring your SOA Suite is a tough job because of the complexity of the environment. Usually Adminstrators stick to some CPU, memory, disk and basic WebLogic Monitoring, some have monitoring in place for some more advanced stuff such as JVM, JMS, JDBC, but when it comes to "Who monitors the Error Hospital on Business Faults?" or "Who is looking after SOA housekeeping?", than no one knows what i'm talking about.

 

And, in many cases, the necessary SOA Management pack hasn't been licensed, or switched on to make use of all the nice features you can get out of this pack. This pack transforms your local Fusion Middleware Console into an EM dashboard, can monitor the Error Hospital, trace on Instance flows and even monitor the Dehydration Store Performance the SOA Suite repository. So, who needs the local Fusion Middleware Console(EM)?

 

Impression of the screens in Enterprise Manager Cloud Control

However, if you are not licensed to use the SOA Suite management pack, than you are not permitted to use al these nice features.

 

As I told in the video, Oracle Enterprise Manager Cloud control has a feature called metric extensions. These are extensions if collected metrics which are delivered in a certain pack are not sufficient enough or maybe are not there at all. I did some research for a customer who used the SOA Suite but had no management pack for it.

Using the metric extension the customer was able to collect all the metric data from all the SOA environments and do the same stuff with as if it was a metric from a monitoring template. So setting thresholds, collection schemes, alert rules and notifications, and trending analysis also were possible.

The more difficult task in this case was that I had to gather and tweak  some useful SQL queries to get the information out of the SOA repository; in fact a lot of the truth about a SOA environment lies in it's database.

 

Way of working

 

I created a view extensions. Within EM, select Enterprise--> Monitoring --> Metric Extensions

 

Name Metric Extension ME$SOA_INFRA_MDS_COUNT; for having operational statistics about Instances Running, Closed, Stale, etc

 

I used the following query, as I'am not an SQL Guru, found it somewhere ( thanks to the creator ) to build my extensions

Next step is to create columns for displaying the values I would like to see, in this case the number if instances over the past 2 days and their state:

 

 

 

 

There was no need to have some alert for this, it was pure informational.

Next is to test uf the this gives the desired result:

When finished, you need to save the extension as a deployable target, publish it, and either deploy it to an individual target or attach it to a template.

 

The following metric extensions are used now:

ME$SOA_INFRA_BPEL_STATE

This monitors the BPEL states in the composite and alerts if it gets aborted ( need to set a date limit, todo action )

 

 

ME$SOA_INFRA_BUSS_FAULTS_NON_RECOVER

Monitors on non recoverable Business Faults

 

ME$SOA_INFRA_MED_STATE

Monitors om States of Mediators, same as BPEL States

ME$SOA_INFRA_RUNNING_INSTANCE_FAULTS

Monitors on open instances if faults occur

 

ME$SOA_REPOS_SIZE

Gives a daily report of the size and growth of the SOA Suite repository

 

 

There are lots more to think of so this will be extended with more useful information.