Configuring event catches attached to an operation
Asynchronous events and timer events can be directly attached to an operation. You cannot attach exception events to an operation, but many operation types have built-in exception events. (See Handling an exception event attached to an operation.)
When an event is directly attached to an operation, it is called an event catch and it listens for events while the operation it is attached to is running.
To configure an event catch attached to an operation:
(1) Right-click an event attached to an operation and select Event Properties. The Event Catch Configuration dialog box appears.
(2) (Optional) In the Name box, modify the name of the event.
(3) Create a filter for the event. (See Creating filters and data maps for events.)
(4) Create a data map for the event. (See Creating filters and data maps for events.)
I'm trying to play around events myself (thanks for your help in another post Jasmin) and am just having a little trouble assigning data into variables in the Process Data Map. Unless I'm mistaken, thats what its for, right?
About "Where did you get the following steps from?", as I wrote in my initial post, this is a help topic I found in "Adobe LiveCycle Workbench ES" version 8.0.3187.1 by navigating in the help contents following this path:
"Creating Processes" > "Implementing Business Logic" > "Configuring events to control flow in a process" > "Configuring events attached to an operation"
Maybe there is some confusion about what exactly an "event catch" is, but the documentation I refer to above says:
"When an event is directly attached to an operation, it is called an event catch ..."
This documentation refers to a FaultName, a FaultSource and a FaultMessage as event data.
Do you know what that means and how these could be used?
You also write "As far as I know, the best you can do is to determine the type of exception that was thrown.".
Do you agree that only "the type of exception" would not be very informative in a log or e-mail about what went wrong? Typically the most interresting information about an exception is in the exception message or even in the causing exception.
About "... you would find the exception information in the server logs ...", yes, but from my experience only when there is no fault route for the exception from an event catch.
So, it seems to be kind of "contradictory" (mutually exclusive):
(1) or no fault route, and exception details in the log but no e-mail notification possible
(2) or a fault route, but no exception details available (not even in the logs) but e-mail notification (without details) possible