Building the Order Lifecycle process

We now have an application that has a functional user interface, at least one good enough to start adding some of the business logic of the application. We can always come back and improve the user interactions, but once the basics are in place, each one can be worked on and improved in parallel. 

There is a lot to learn about building a business process; if you need help along the way, all the activities are documented in Defining-the-application-business-logic-through-processes. This tutorial will try to show the trickier steps in a step-by-step fashion.

We will start by copying a new process from the Simple Order Lifecycle that we created in Module 1, and incrementally enhance it, testing along the way, to build out the behavior called for by the requirements we analyzed in Module 1.

To recall where we were, we last saw Simple Order Lifecycle just supporting two phases, something like this:

You may notice that the labels of the activities don't match exactly what we did in the Quick Start exercise, where the example included the type of the activity within the label as a convention to help understand what it was doing. In fact, the labels are up to you, as long as they are unique. Also, note the annotations are optional.

This process updates the date information, but only after the Status field value changes to Delivered. In truth, if this is all we wanted to do, it would have been easier just to create a rule that triggers After Update to perform the same action. We didn't do that, because we knew that applications like this will typically have a much more complex lifecycle for their records, and that building up a large collection of interacting rules would become very difficult to maintain or even understand. One of the key lessons here is that using the process designer allows us to visually orchestrate the fulfillment of requests in a straightforward fashion.

Consider the five Status values that now exist, and consider the implications for the Order Lifecycle, including these behaviors:

• More phases, including In Progress and a concept of Closed
• Automatic closure of an order some period of time after it's Status field value becomes Delivered
• Notifications to the submitter, and to all consuming employees, when certain phases are reached
• The ability to cancel an order and send a notification

The final process we are building will take care of these requirements. We will build it out, step by step, so that as we go the process can be saved, tested, and troubleshooted.

When the process is fully developed, it will visually tell the complete story of the business logic for ordering.

Along the way we will learn about some powerful concepts:

• The Exclusive Gateway for branching the flow based on a Condition
• The Send Message activity for generating a "bell icon" notification for the shell
• The ability to loop over a list of things, in this case, the associated Employee records
• A Timer for doing something based on elapsed time
• Throwing a Business Error that can be caught by some wrapper process, for error handling

There is a lot to learn here. Rather than take this all in one gulp, we will start with the first requirement: adding an In Progress phase and a notification for that.