Workflow and ServiceDesk Community

Hi,

If some error occurs during execution of workflow in any one of the components that error should be captured and it should be sent via email to respective user or admin.

I'm able to send a mail but need help in how to capture the error occured during execution and pass that through email?

Thanks.

Exception Trigger components are just what you need.

Basically you'll have your own path in your workflow that goes: Exception Trigger - Send Email - End

With this, any time theres a general exception in your flow, the Exception Trigger takes control and the flow goes from there.

There are some caveats though: first be wary of throwing exceptions in your exception handling path (much like coding)... in other words, make sure your Send Email comp is tested and failsafe.

Usually these trigger components are combined with GoTo components to jump back into the workflow at predetrmined points.

Thanks Recardo,

One question, this Exception trigger component has no input coming to it from other components. So we just have to write a component name in the exception trigger component properties will trigger the exception while error is occured from that specific component and then pass it through email.

Please let me know whther my understanding is right on the same.

I believe exception triggers will only have access to stream data related to details about the exception and any other project properties data/global data you have stored.

Exception triggers can only have paths coming out of it... there can be no paths coming into an exception trigger component (or any other trigger component, if I recall)

The "general" Exception Trigger is a catch all for ANY exception occurring in the flow. When you use the Exception Trigger By Component/Exception Trigger By Components comp, you basically restrict the exception handling to the component/components you specify - any other component that throws an exception will crash the flow (unless... you use ANOTHER Exception Trigger By Component set to handle that exception differently - email a different person for example)

As always, reecardo is right on the money. One additional point, though: regarding any additional data from the stream, you could use a "variables exist" component to get access to additional data that isn't global or related to the exception.

I occasionally get exceptions caused by the mail component.  In these cases, having another attempted email sent in the exception handling isn't very useful if the problem is external like the SMTP gateway being down.  So I also write exception data to a separate SQL database.  This has the added benefit of maintaining a historical record of exceptions.

I agree with this.  If you include components in an exception handling section between the exception component and the end point, be sure to always include specific exception handling for those in-betweener components as well.  Always have a direct path from at least one exception component to the end point to ensure that the project can always gracefully close.