Taking Care – Error Handling - Applied SOA Patterns on the Oracle Platform - page 498

the developers. Traditionally, last-minute changes weren't logged on the ops wiki
(that's never happened in your organization, right?).
• After deployment in Production, considerable changes in performance became
obvious. Stabilization attempts had no positive effect (or little).
• Even if said otherwise, obviously we have three different SOA runtime environ-
ments (assuming that VMs or physical servers are the same).
Dumping the MBeans attributes (as XML, for instance) and automatically comparing the
static configs and runtime metrics under the same load from the servers in question will
reveal the difference. The problem can be fixed without the traditional swop ORT <->
Prod by RDA. In any case, creating and keeping the healthy dump as a reference will be a
good start for proactive monitoring.
Actually, by default, you'll be provided with the ability to automatically collect and store
diagnostic dumps along with SOA Suite, and it will be provided by Oracle Diagnostic
Framework (DFW). As it is primarily related to SOA Suite, it does not cover the WLS
configuration and runtime metrics, but it can seamlessly work with WebLogic Diagnostic
Framework (WLDF), which will supply DFW with notifications about exceptions. You
even get a preconfigured FMWDFW Notification in your DFW after the SOA Suite is de-
ployed.
With this, you understand that these dumps must be stored somewhere, and Automatic
Diagnostic Repository (ADR) exists in every managed server in a domain for this purpose
(look at <SERVER_HOME>/adr ). Bear in mind that ADR is not the SOA Suite log you
usually read every time you look for the initial diagnosis records. Oracle Diagnostic Log-
ging (ODL) is the basic and primary means of any OFM applications' logging, recording
every single step in great detail.
In addition to the traditional Timestamp (actually, several of them), Message ID, and Mes-
sage text, you will get MODULE_ID , THREAD_ID , and PROCESS_ID that can be correl-
ated to the MBean data acquired using JMX/WLST from other preventive monitoring
flows (see the previous figure). Talking about correlation, what's particularly interesting is
that it presents us with the Execution Context ID (ECID) , a global unique identifier for a
service request, and an execution environment for handling this request. The main pur-
pose of this ID is to link error messages from different components, and it will be a good
idea to also use it as the basis for your Business Correlation ID within your SCA. We will
show you how to do this a little later.