Jconlon (13) [Avatar] Offline
#1
Figure 7.21 shows parsing code for the Script task. What if the parse methods fail to convert a string to an int and throw an exception? Questions:

How can one validate form input and give feed back to users on errors so they can reenter data?

What is the pattern for throwing exception events from a Script task?
Eric D. Schabell (16) [Avatar] Offline
#2
Jconlon wrote:Figure 7.21 shows parsing code for the Script task. What if the parse methods fail to convert a string to an int and throw an exception? Questions:

How can one validate form input and give feed back to users on errors so they can reenter data?

What is the pattern for throwing exception events from a Script task?


Thanks for the good questions. I will have to expand to address these in chapter 7 when I first introduce the issue. For now here is how I see it being addressed.

The pattern is to ensure through the use of validation before you allow data to reach such a point in your process. You have two options:

1. Submit data to your process from a front end custom task UI that then includes the same sort of fields you see generated in the task forms here. This data is validated in the front end UI code, in this case an integer, to ensure the string to integer never fails.

2. It's also possible to use rule tasks as shown in chapter 5 to validate data. This is not really practical throughout the process when using user tasks, but works very well when applied at the start of a process. See the Travel Agency in Chapter 2, there is data validation to ensure the front end UI submits proper data and the process will fail to start if data is not valid.

This is as deep as I will take this topic in this book. Does that help?
Jconlon (13) [Avatar] Offline
#3
Yes, that helps. Custom UI Task sounds interesting. Although the rules approach would work well too, if it was the first task of the process and the process was being fed by a custom web client like you show in chapter 2, then the HTML client could also do validation.