When DriveWorks works, it’s great. And when it doesn’t work, it’s a challenge for solution architects to solve.  That’s why one of the biggest differences between good DriveWorks projects and great DriveWorks projects is how we handle and preemptively avoid any kind of errors or problems. These don’t have to be app-shaking, crash-inducing errors. Still, something as simple as looking in a table for a value that isn’t there or calling out an item in a list that isn’t long enough can result in problems that could be unsightly (i.e., ugly) or, even worse, completely invisible. This article will give you the information you need to create reliability and predictability in your implementations to ensure that your users will enjoy their experience.

Error and event handling involve running a quick validation step before and after you perform an important task. A perfect example could be something as simple as writing a value to a table. Before you try to write to the table, you want to ensure that you have all the information required and that the data is all good, valid information.

Whether this table is in DriveWorks or an outside source, like a database, in most cases, DriveWorks will just plow through and do what you tell it to do. If the data is bad, DriveWorks will most likely try to write it anyway. Therefore, it is critical for you to validate before performing your tasks. If you don’t perform this validation, your table write could fail or, worse; you could write bad information into your table.

Validate the Success of the Task Performed

But equally important is validating that the task performed as you expected it to. From a strictly ease-of-implementation perspective, the DriveWorks tasks like Released Document are very fast and easy to use when writing to a table (for example). What they don’t do, however, is report back to the DriveWorks project in a way that allows us to validate that the task was executed correctly.

With the release of DriveWorks 19, all standard specification flow tasks now implement the Status Output Connection Points, those Success/Warning/Error nodes at the bottom of the task that provide navigation paths based on task result. Using these nodes is a great first step towards validating your macro tasks. However, these connection points do not report back the warnings or errors that caused the condition. Additionally, these nodes may report back success for a process where the desired result was not achieved. For example, you may try to write to a table, but no row was added to the table because your control column was being fed a blank. As far as DriveWorks was concerned, the task went off without a hitch. But you did not get the results that you expected.

This brings up the need to validate the success of your tasks after the fact. This can be done by something as simple as searching for the data that you expect to now exist in your table or counting rows to ensure that the table now contains the expected number of rows. Many tasks and functions now also provide outputs. For example, the Delete Simple Table Rows task shown here returns the number of rows deleted by the task. By taking that output and pass