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

Read more: http://www.soabyte.com/