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
I've been playing around with this as well, and what I've done may be of some use to you. We are having terrible network connectivity problems here, where the LiveCycle DB server is just randomly dropping from the network. Since no one can seem to figure out why this is happening, we have had to try to be proactive about it in any way we can. I have set up a process with an Exception Event Start Point. From this start point I am then grabbing the FaultName, FaultSource, FaultMessage, and emailing that information to myself.
To set this up drag the Exception Event element to a blank process.
Next set up your process variables to capture the Fault information you wish grab.
Then set up an email component to email yourself. I've used a simple concat function to send all three Fault values to myself in the email:
concat('An exception occurred on the LiveCycle DEV server. The exception that happened was: ', /process_data/@FaultName, ' The Source of the fault is: ', /process_data/@FaultSource,' The message associated with this exception is: ', /process_data/@FaultMessage)
You can set filters up on your start point so that you are only catching those exception that you want to be notified on, or set decision paths after the start point to do whatever you want. Hope this helps, or gives you some ideas.