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:
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.
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.
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.
This section discusses how instance tracking is handled in the case of the Retry, Batching, and Resubmit message events.
In the case of channel level or document level retry, the FlowID is related or associated to the parent message's FlowID.
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 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
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
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 H-1.
Figure H-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 H-2.
In a B2B High Availability environment, the Enterprise Management SOA Composite Flow Trace link the B2B Reports does not work.
Figure H-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 H-3.
Figure H-3 Detailed Flow Trace Report
Instance tracking is not supported for AQ in the current release. Instance tracking is supported for only in-memory and JMS back end.
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.
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.
Configure this property on the Oracle Enterprise Manager Fusion Middleware Control instance to point to the Oracle B2B URL.
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.
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.
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.
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:
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.
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.