No More Hidden SOA Performance Problems by Kevin King

 

clip_image002For anyone who has done performance and load testing in Oracle SOA suite, you know it can be frustrating and time consuming. However, our lives have just gotten much easier! Originally, quite a bit of manual work was needed to find or calculate how long composites took, what the problematic components were, and why instances just took too long. Fortunately, Oracle has introduced a new monitoring tool, Integration Workload Statistics (IWS). This tool creates a report very similar to an AWR report, but focuses on the SOA infrastructure. This feature was released with the new 12.2.1 version of SOA.

Integration Workload Statistics

clip_image004The IWS report is intended for reactive monitoring of your system. Enterprise Manager provides a few different tools for monitoring real-time performance and other metrics, however IWS was introduced to post-process poorly performing periods. Running a report over a one hour period where performance is a constant issue allows you to see what components are causing delays. The report details out statistics on components, composites, processes, adapters, endpoints, queues and more!

IWS works by taking periodic, configurable snapshots of server metrics. These metrics are stored to the database and are available for reporting. The reports are generated based on a start and end time and further filtering can be done by server, partition, and even specific composites. Oracle has provided an easy way to view this data with a generated HTML report and they also provide a CSV file, or XML file with the data requested. 

The report (assuming FINEST level collection) consists of:

Error Resilient Adapters – SOA 12.2.1 Resiliency Feature by Kevin King

 

clip_image001New to SOA 12.2.1 is the concept of Resiliency.  Oracle has introduced functionality that shuts down adapters when their composite failure meets a certain threshold. In effect, an error circuit breaker!  This is extremely helpful to prevent filling up the error hospital with an abundance of errors.  When suspended, the failed composite will retry the composite at a defined interval in an attempt to un-suspend the service adapter.  The idea is to suspend any inbound adapters so that messages can be queued whenever an error is present and then processed later when the service is fixed.

Currently, resiliency currently only works for a small subset of adapters.  These adapters include EDN, File, FTP, AQ, and JMS. 

My Example – File Adapter

I deployed a sample project that used a file adapter to read a file and insert those records into a database table.  Once the global resiliency policy was configured for the server, there is no special setup or additional configuration needed at the process/project level. 

I dropped a few files into the staging area that the file adapter read, and off they went.  All the records were inserted into the database as expected.  To cause a failure, I renamed the database table.  Now, my database adapter will no longer be able to find the table it needs to insert into.  I copied a few more files into the staging directory and, as expected, they disappeared and faulted instances showed up.  However, because I had configured the global resiliency to trigger with three errors in two minutes the file adapter now shows as suspended. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki