You are viewing limited content. For full access, please sign in.

Question

Question

How do I trigger a try-catch exception when a multistatus error 9017 is triggered?

asked on January 28

Hi all,

I have a workflow that that is passed a list of string fields to be used to populate a template. The list if ever changing. Some of these string string values are effectively just integers. 

Workflow has nop problems assigning the integer values to interger fields in LF. If the field incorrectly contains an alphanumeric, I'd like to be able to trap the error and send a notification to support & devs. 

I don't want to test individual fields, because that's effectively hard-code a field list (do-able but much prefer to avoid this approach).

I though I could create a Task Error Handler for "any" error from "any source" with an error code of 9017 and trap it but no luck.

I tried to set the error handler as "critical" to see if I could trigger a try-catch but the error is still just a "warning."

I tried to set the retry timeout to 20 minutes, to use a deadline to trap it, but not luck.

It seems that my Task Error Handler configuration is simply being ignored. Am I using it correctly?

screenshot.png
screenshot.png (9.18 KB)
0 0

Replies

replied on January 28

9017 is not a "multi-status" exception. It's "bad field value", so it's not retriable. Workflow tries to set as many fields as possible and skips the ones where the value does not match the field type. There is no way to convert it from a warning into an error in Assign Fields activity.

Task error handlers are meant to do the opposite of what you want: convert fatal errors into warnings by specifying a retry pattern.

1 0
replied on January 28

Ah ha! 

How would you approach the situation? imagine you have an dictionary array (or JSON data, or multivalue token) of field_name/string_value pairs that will be used to populate a template. If the upstream developers have cleansed their data, the values will always be of the correct data-type and size. However, I'm implementing a solution to protect the workflow against bad field values. 

In the past, I've solved this problem by using a parallel branch and regex to test each value. That means having to add (or modify) branches as the specification changes. 

Another option is to use some SDK to test the values. Whilst this allows me to write a generic solution. However, the customer and I have a policy of avoiding code (in workflows) as much as possible. 

-Ben

0 0
replied on January 28

The "Critical Error" option should make it trigger the try-catch; I have a few custom task error handlers, and I've changed settings on some of the default handlers, using this option.

The only noticeable difference with mine is that I also included LFSOException as the error type. A screenshot of the workflow warning with the full error message might provide some other clues.

0 0
replied on January 28

I've tried that as well.. No luck.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.