This appendix describes instance tracking and error hospital tracking functionality.
This appendix contains the following sections:
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 then use the following properties:
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.
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. Also, note that this property is equivalent to the healthcare property of b2b.b2bReportsURL.
These properties are described in more detail in the following chapters of Oracle Fusion Middleware User's Guide for Oracle B2B:
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 Healthcare. 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:
Negative Acks that are received on Healthcare mark the message as in "error". However, this does not update the composite state back to "error".
Ack time outs are not tracked. The Healthcare message itself is in the "error" state, but the composite remains in the "complete" state.
Resubmitting a completed message results in an error. In this case the flow instance state shows up as "complete" despite Healthcare 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 Healthcare 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.