Zeta Components Workflow

Zeta Workflow 03: Failure Handling Walkthrough

Here we look at the nuances of start() and resume(). We walk through several components along the way.

Let’s take my usual test-first approach. Our aim is to characterize and verify Zeta Workflow’s behavior in failure scenarios.

Failure vs. Exception

Draw a careful distinction between “failure” and “exception”:

• A “failure” is when the node (or its service object) returns false indicating the workflow should NOT proceed.
• An “exception” is when the node (or its service object) throws an Exception.

As I developed the package, my primary use case has been “At this point, tell Laravel to present slide X.” We implement this by using the SlideProvider callback you have already seen. We’ll continue this approach by using the same type of scenario, but condition SlideProvider to return false, telling Zeta Workflow something failed.

The Unit Test

Our unit test tests/rollback/slideFailTest.php begins:

namespace StarTribune\Workflow\Tests\Workflow;

require_once __DIR__.'/../DbTestCase.php';
use StarTribune\Workflow\Wrapper\ZetaComponentsWrapper;
use StarTribune\Workflow\Wrapper\ZetaComponentsInterface;
class slideFailTest extends \StarTribune\Workflow\Tests\DbTestCase {

We already have lots to talk about!

Read more…

Zeta Workflow 02: Failure Handling

Here is what you need to know about workflow failure and exception handling:

• If you resume the workflow execution after the failure, it will resume with the failing node.
• Zeta Workflow has no provision for skipping a failing node and resuming execution at the next node. If you are stuck, you are stuck, and that is that.
• When the workflow fails and/or throws an exception, state should be saved up to the point of the failure.

Read more…

Zeta Workflow 01: Workflow Communication

Execution Variables

One way to communicate with the workflow is via execution variables. You can use getVariable(), setVariable(), hasVariable(), etc. to work with the execution variables. My tests show the execution variables do get correctly persisted with the database tie-in package.

Unfortunately it’s not that simple. To explain, I need to throw out a lot of details about how executions work.

Read more…