View data for one failed SCA event and perform other tasks such as deleting, resubmitting, modifying, and setting the trace for the event.
To view this page in the administrative console, click Integration Applications > Failed Event Manager , then perform a search for failed SCA events. After failed events are returned, click the name of an event that is listed in the Search Results page.
The Failed Event details page provides the event ID, session ID and event qualifiers associated with the failed event, as well as information about the event's source, destination, time of failure, and cause of failure.
Links marked (online) require access to the Internet. Each link launches a search for the topic in the online information center. When search results are listed, select the topic that corresponds best to your configuration.
Check for updates to this topic (online)
This field displays the type of event that failed. The value is SCA for all failed SCA events.
The event type is assigned automatically by the Recovery subsystem; you cannot edit it.
This field displays the status of the failed event. For SCA events, the only available status type is Failed.
The event status is assigned automatically by the Recovery subsystem; you cannot edit it.
This field displays the unique ID for the failed event. This ID persists even after the event is resubmitted; if the resubmission fails, the event is returned to the failed event manager with the same event ID.
The event ID is assigned automatically by the Recovery subsystem; you cannot edit it.
This field displays the unique session ID for the failed event.
Every event executes in a session; the session includes all of the information that is needed to process an event. If an event fails, the failed event manager encapsulates specific session information for the failed execution branch in the Session ID parameter.
Note that any Common Base Events and business process instances that are related to a particular failed event have the same session ID, which makes them easy to identify and examine for more information about the failure.
The session ID is assigned automatically by the Recovery subsystem; you cannot edit it.
This field displays the type of service invocation between SCA components. The three supported invocation models are asynchronous request-deferred response, asynchronous request with callback, and asynchronous one-way.
You cannot edit this field.
This field displays the name of the module from which the event originated.
You cannot edit this field.
This field displays the name of the component from which the event originated.
You cannot edit this field.
This field displays the name of the destination module for the event (where the event was going when it failed).
You cannot edit this field.
This field displays the name of the destination component for the event (the component to which the event was going when it failed).
You cannot edit this field.
This field displays the name of the destination method for the event.
You cannot edit this field.
This field displays the date and time when the event failed. The displayed time is local to the process server, and the value is formatted for the current locale.
You cannot edit this field.
This field displays the deployment target for the event. Its value includes the name of the target node, server, and cluster (if applicable).
You cannot edit this field.
This field displays the text of the exception that was generated when the event failed.
You cannot edit this field.
Specify the amount of time that can elapse before a failed event expires and can no longer be resubmitted. The displayed time is local to the process server.
If you specified an expiration with the asynchronous call that sent the event, that expiration data persists even if the event fails, and the expiration time appears in the Resubmit expiration time field.
You can edit this field to specify a new expiration time for the failed event. The value for this field must be a date and time formatted for your locale. A locale-appropriate example is provided above the field.
Specify the level of tracing to be used on a resubmitted event.
If you set the tracing on the failed event, the Trace control field displays that value. Otherwise, it displays the suggested default value of SCA.LOG.INFO;COMP.LOG.INFO, which specifies that no trace occurs when the session calls a SCA service or executes a component.
You can edit this field to assign a different trace level for the failed event. Tracing can be set for a service or a component, and the results can be sent to a log or the Common Event Infrastructure (CEI) server. For detailed information about setting and viewing trace, see the Monitoring topics in the WebSphere Business Process Management Information Center.
This field displays the setting of the event sequencing qualifier for the failed event.
This field displays the setting of the failed events that caused store to be started.
This field displays the failed events that are captured because the system was unable to send a failure response to a business process.