rss
SOATUBE
Oracle
Custom Search SOABYTE here

Wednesday, January 25, 2012

SOA composite states

COMPOSITE_INSTANCE

State
Description
0
Running
1
Completed
2
Running with faults
3
Completed with faults
4
Running with recovery required
5
Completed with recovery required
6
Running with faults and recovery required
7
Completed with faults and recovery required
8
Running with suspended
9
Completed with suspended
10
Running with faults and suspended
11
Completed with faults and suspended
12
Running with recovery required and suspended
13
Completed with recovery required and suspended
14
Running with faults, recovery required, and suspended
15
Completed with faults, recovery required, and suspended
16
Running with terminated
17
Completed with terminated
18
Running with faults and terminated
19
Completed with faults and terminated
20
Running with recovery required and terminated
21
Completed with recovery required and terminated
22
Running with faults, recovery required, and terminated
23
Completed with faults, recovery required, and terminated
24
Running with suspended and terminated
25
Completed with suspended and terminated
26
Running with faulted, suspended, and terminated
27
Completed with faulted, suspended, and terminated
28
Running with recovery required, suspended, and terminated
29
Completed with recovery required, suspended, and terminated
30
Running with faulted, recovery required, suspended, and terminated
31
Completed with faulted, recovery required, suspended, and terminated
32
Unknown
64
Stale

Note:
SOA 11g Composite soainfra.composite_instances states you can calculate the states beyond the ones in the table above.
Example: state 80 (64+16) meaning STATE_STALE and STATE_TERMINATED_BY_USER


CUBE_INSTANCE
State
Description
0
STATE_INITIATED
1
STATE_OPEN_RUNNING
2
STATE_OPEN_SUSPENDED
3
STATE_OPEN_FAULTED
4
STATE_CLOSED_PENDING_CANCEL
5
STATE_CLOSED_COMPLETED
6
STATE_CLOSED_FAULTED
7
STATE_CLOSED_CANCELLED
8
STATE_CLOSED_ABORTED
9
STATE_CLOSED_STALE
10
STATE_CLOSED_ROLLED_BACK

DLV_MESSAGE
State
Description
0
STATE_UNRESOLVED
1
STATE_RESOLVED
2
STATE_HANDLED
3
STATE_CANCELLED
4
STATE_MAX_RECOVERED

DLV_TYPE
State
Description
1
Invoke Message
2
DLV Message

MEDIATOR_INSTANCE
State
Description
0
No faults but there still might be running instances
1
At least one case is aborted by user
2
At least one case is faulted (non-recoverable)
3
At least one case is faulted and one case is aborted
4
At least one case is in recovery required state
5
At least one case is in recovery required state and at least one is aborted
6
At least one case is in recovery required state and at least one is faulted
7
At least one case is in recovery required state, one faulted and one aborted
 >=8 and < 16
Running
>= 16
Stale
Mediator Instance Tracking

There are in total 5 tables which are used by mediator instance tracking:
  • Mediator_instance - One row for each mediator message flow.
  • Mediator_case_instance - One row for each mediator case (~ routing rule).
If a mediator component has two routing rules then this should have 2 records for that mediator instance.
  • Mediator_case_detail - Captures mediator audit trail for each mediator routing rule. Number of records may vary based on the nature of mediator component.
Eg:  if mediator component is having a async req-resp routing rule then this would contain 2 rows for the corresponding mediator routing rule.
  • Mediator_document - Stores the payload for routing rules which are configured as deferred (~ parallel in jdev). So if all the routing rules are "sequential" then this will not contain any records.
  • Mediator_audit_document - Stores the payload for audit trail and only when "instanceTrackingLevel" for mediator is "Complete".

In nutshell, of you want to know the number of messages getting past mediator then mediator_instance should be sufficient which captures the no of messages executed by Mediator.

Audit Trail Tracking

There are 2 audit trail tables used in BPEL: audit_trail and audit_details.
All audit trail events are inserted into audit_trail.  audit_details is used for the details section of an event (ie. payload); if a payload exceeds a
certain size, it is inserted into audit_details instead of being inlined in the audit_trail event.

There are 2 configuration settings for auditing:

auditLevel:
  • off - absolutely no logging performed whatsoever; may result in a slight performance boost for processing instances.
  • minimal - all events are logged; however, no audit details are logged.
  • production - all events are logged.  The audit details for assign activities are not logged; the details for all other nodes are logged.
  • development - all events are logged; all audit details for all activities are logged.
               
auditDetailThreshold:
                The maximum size (in bytes) an audit trail details string can be before it is stored separately from the audit trail.  If a details string is larger than the threshold it will not be immediately loaded when the audit trail is initially retrieved; a link will be displayed with the size of the details  string.  Typically, the details string will contain the contents of a BPEL variable.  In cases where the variable is very large performance may be  severely impacted by logging it to the audit trail. The default value is 50  kilobytes.


There is no relation between instance tracking and BPEL auditing.  Instance tracking logs messages between components and on inbound/outbound wires.
BPEL auditing only pertains to BPEL instances and activities.

Links
  • 10g / 11g SOA composite <schema> States (Doc ID 1362028.1)
  • Validating SOA Middleware Connections (Doc ID 1338603.1)
  • Oracle SOA Suite 11g Composite Validation, Runtime Monitoring and Audit Trail Review (Doc ID 1340515.1)
  • How to enable TRACE / DEBUG logging in Oracle SOA Suite 11g (Doc ID 1325672.1)
Posted by Unknown at 3:18:00 AM
Labels: , ,

2 comments:

Post a Comment

Subscribe to: Post Comments (Atom)
 
Blogger Profile