Database Reference
In-Depth Information
•
Identifying transactions that have not been completed successfully to de-
termine further action
•
Ensuring that the transactions do not experience poor performance
When a payload is received by the SOA Infrastructure, it may pass through mul-
tiple components within your infrastructure and may even traverse multiple ex-
ternal systems as well. For example, a sales order may be received by a BPEL
process, which in turns places it into a queue. Afterwards, it may be consumed
by some third-party application that processes the sales order, before sending it
back to another Mediator service, which routes it to the final order management
application. If any one of the above steps in this particular integration fails, how
can you identify where the message is? What would also be important to you is
to know the time taken by each component to determine if it is inline with your
predefined SLAs.
In this section, we will cover different areas and topics that provide you with the
tools necessary for effective transaction monitoring.
Monitoring instances
To monitor composite instances, you should first understand a few key concepts:
•
Every transaction displayed on Oracle Enterprise Manager Fusion Middle-
ware Control is a composite instance. Each composite instance is desig-
nated a unique composite instance ID.
•
Every composite may consist of one or more components (for example,
BPEL, BPMN, Mediator, and so on). You must navigate to the composite in-
stance and drill down to the component to view its details. Every component
has its own component instance ID.
•
The
Execution Context ID (ECID)
is a global unique identifier of a particular
transaction. It is injected into the header of the payload when the instance is
first created and is included throughout the lifecycle of the payload. Thus, the
ECID may appear in multiple composites and components. The ECID should
not be confused with either of the instance IDs described above.
