I Tracking Business Message Flow

This appendix discusses the process of tracking and managing the flow of business messages between an Oracle SOA composite and Oracle B2B.

The appendix contains the following sections:

• Introduction to Business Flow Events

• Tracking Oracle B2B Message Events

• Tracing Flow By Using Oracle B2B Console

• Instance Tracking and Error Hospital Integration

I.1 Introduction to Business Flow Events

A business flow involves one or more messages being exchanged.

A typical business flow involves:

• A single message exchange such as a purchase order

• Multiple message exchanges such as request/response

• A separate notification flow in case of any error

• An additional flow in case of retry/resubmit

Different types of business flows, such as error, retry, and request/response, can be distinguished by an ID called flow events or FlowID.

I.1.1 What You Need to Know About Flow Events?

A flow event contains the following information:

• FlowID, which uniquely identifies the underlying Business Flow.

• ECID, which uniquely identifies a synchronous subflow associated with the underlying Business Flow. A Business Flow can possibly include many synchronous and asynchronous subflows, and therefore can comprise Events associated with different ECIDs. An asynchronous subflow can be created when a BPEL process is dehydrated and then re-hydrated.

• InstanceID, which uniquely identifies the service, reference, or component instance associated with the event.

• SCAEntityID, which uniquely identifies the type of the service, reference, or component instance referenced by the InstanceID. The SCAEntityID corresponds to values of the ID column stored in the sca_entity table. Using SCAEntityID is much less verbose than the alternative information such as:

  • Domain name associated with the service, reference, or component instance described by the event

  • Name of the composite that contains the service, reference, or component instance described by the event

  • Revision of the composite that contains the service, reference, or component instance described by the event

  • Label for the Composite that contains the service, reference, or component instance described by the event

  • Name of the service, reference, or component instance described by the event

• FlowEventID, which is a unique ID associated with the flow event. It is used to build the parent or child relationship between flow events.

• ParentFlowEventID, which uniquely identifies the parent of the flow event under consideration. This is the FlowEventID value for the parent flow event. If the flow event under consideration does not have any parent, the Parent FlowEventID is set to null.

• TransactionID, which identifies the transaction associated with flow event under consideration, or null if the flow event under consideration is not associated with any transaction.

• CorrelatedFlowID, which uniquely identifies the business flow that needs to be correlated with the current business flow.

• FaultID, which corresponds to the Fault associated with flow event under consideration. This ID is associated with a common fault that is stored in the common_fault table. The value is set to null if no Fault is associated with flow event under consideration.

• ExceptionTrace, which corresponds to the Exception stack trace for the Fault associated with flow event under consideration. The value is set to null if no Fault is associated with flow event under consideration, or if no stack trace could be obtained.

• FaultPolicyAction, which represents the triggered Fault policy action.

• ParentAuditEventID, which uniquely identifies the component-specific AuditEvent, which is the parent event (occurred prior) of flow event under consideration. This is used to stitch together events from different Audit Traces.

Note:

In the case of an Oracle SOA composite calling Oracle B2B, the correlationFlowId is retrieved from the Oracle SOA composite itself. However, in the case of Oracle B2B calling Oracle SOA, Oracle B2B need to generate the correlationFlowId and provide the ID to the composite for integration with the common instance tracking framework.

I.2 Tracking Oracle B2B Message Events

This section discusses how instance tracking is handled in the case of the Retry, Batching, and Resubmit message events.

Retry

In the case of channel level or document level retry, the FlowID is related or associated to the parent message's FlowID.

Batching

In the case of batching, the FlowEventID is associated with every individual message. Even though there is only one Wire Message in this case, the same will be shown for all the individual messages.

In the case of de-batching, the batch case is identified and it is updated for every individual message with a new FlowEvent ID after de-batch operation. With this, the error-related scenarios of a particular message in batch can also be updated. However, typically, during the inbound processing, the FlowID is be generated at the entry point (during Wire Message creation).

Resubmit

Resubmit is a manual process. So, a new FlowID is created and associated with the original message.

• Outbound Application Message - A new FlowID is created and stored in the EXT_BUSINESS_MESSAGE table.

• Inbound Application Message - A new FlowID is created and stored in the EXT_BUSINESS_MESSAGE table. The default approach is to track the FlowID created in Wire Message and send it all the way to back end. However, because this is a resubmit of the inbound Application Message, a new FlowID is created and the parent FlowEventID stores the value of original message.

• Outbound Wire Message - In this case, a new FlowID is created that stores the original message reference. The default approach is that a FlowID is created during the Application Message creation during outbound process. However, in this case, the new FlowID is created at the Wire Message creation level.

• Inbound Wire Message - A new FlowID is created and stored in the B2B_WIRE_MESSAGE table.

I.3 Tracing Flow By Using Oracle B2B Console

You can view the flow trace for a business flow event by clicking the Flow Trace link in a Business Report in the Oracle B2B console.

This is displayed in Figure I-1.

Figure I-1 The Flow Trace Link in Oracle B2B Business Message Report

Description of "Figure I-1 The Flow Trace Link in Oracle B2B Business Message Report"

When you click the link, you will be redirected to the Oracle Fusion Middleware Enterprise Management control console, where you can view the Flow Trace as displayed in Figure I-2.

Note:

In a B2B High Availability environment, the Enterprise Management SOA Composite Flow Trace link the B2B Reports does not work.

Figure I-2 The Flow Trace Window

Description of "Figure I-2 The Flow Trace Window"

You can click the BPEL component link in the Flow Trace window to view the detailed trace as displayed in Figure I-3.

Figure I-3 Detailed Flow Trace Report

Description of "Figure I-3 Detailed Flow Trace Report"

Note:

Instance tracking is not supported for AQ in the current release. Instance tracking is supported for only in-memory and JMS back end.

I.4 Instance Tracking and Error Hospital Integration

Instance tracking and error hospital tracking functionality includes two parts.

They are described in sections Tracking Messages Between the Oracle Enterprise Manager Fusion Middleware Control Flow Trace and the B2B/Healthcare Console and Tracking the State of a Message from the Oracle Enterprise Manager Fusion Middleware Control Flow Trace XML.

I.4.1 Tracking Messages Between the Oracle Enterprise Manager Fusion Middleware Control Flow Trace and the B2B/Healthcare Console

It is possible to track messages between the Oracle Enterprise Manager Fusion Middleware Control flow trace and the B2B/Healthcare console. This functionality is available for both the JMS and in-memory integration modes.

If you intend to track instances and errors across domains for JMS integration, you must continue to use the following properties that are available for ECID-based JMS integration:

• b2b.flowTraceEMURL (or specify the same at the JMS channel level)

  Use this property to specify the information about the domain that Oracle Enterprise Manager Fusion Middleware Control consumes and uses to send JMS messages from the queue.

• b2b.b2bReportsURL

  Configure this property on the Oracle Enterprise Manager Fusion Middleware Control instance to point to the Oracle B2B URL.

• hc.hcReportsURL

  Configure this property to point to the SOA Suite for healthcare URL on the instance where the Oracle Enterprise Manager Fusion Middleware Control is running.

These properties are described in more detail in Setting B2B Configuration Properties in Fusion Middleware Control.

I.4.2 Tracking the State of a Message from the Oracle Enterprise Manager Fusion Middleware Control Flow Trace XML

It is possible to track the complete state of the message from Oracle Enterprise Manager Fusion Middleware Control through the flow trace XML. This functionality is available only for in-memory integration.

In general, the composite instance state follows the application message in B2B. As soon as the application message is marked complete, the corresponding composite instance state is updated as complete.

The existing error notification mechanism (sending an exception message to the exception composite/JMS queue) continues to function normally. Whenever possible the notification message is associated with the same flow ID of the original business message.

I.4.2.1 Inbound Messages

If an inbound document and a composite are deployed to accept the document, there are two types of failure that can be reported.

• Failure before the document is identified: The document itself is not identified and composite detection is not possible, therefore no fault reporting occurs.

• Failure after the document is identified: The composite is detected and a fault instance is reported in the composite. If an exception composite deployed, the exception composite instance is part of the same flow ID as the reported fault.

I.4.2.2 Outbound Non-Batch Messages

The following apply to outbound non-batch messages:

• The message remains in the "running" state until the message is delivered to the remote TP.

• Upon successful delivery, the composite instance is marked as being in the "complete" state.

• If an exception occurs during outbound processing, the composite is marked as being in a "faulted" state with the recovery set to B2B_RECOVERY_REQUIRED. The user is expected to recover the message in the B2B/Healthcare console. Note that the recovery state is same for both B2B and healthcare errors.

• The following cases are not handled properly and cause the state to be incorrect in the composite:

  • Negative Acks that are received on B2B mark the message as in "error". However, this does not update the composite state back to "error".

  • Ack time outs are not tracked. The B2B message itself is in the "error" state, but the composite remains in the "complete" state.

  • Resubmittal of a completed message results in an error. In this case the flow instance state shows up as "complete" despite B2B showing it as an error.

  • To track errors in batching, the user must rely on an exception composite to tap into the exception notifications sent to the back-end. The exception message delivered to the back-end is processed as a part of the same flow ID.

I.4.2.3 Outbound Batch Messages

The following apply to outbound batch messages:

• As soon as the batched message is staged within B2B and the message is inserted into the pending message table, the composite instance is marked "complete". Any exceptions that occur beyond this state during the batching process do not affect the state of the original composite.

• The user must rely on an exception composite to tap into the exception notifications sent to the back-end to track batching errors.