Basic Activity Operations in C#

Generate UPC-A Supplement 5 in C# Basic Activity Operations

7

4. Next, drag a Code activity from the Toolbox and drop it onto the Sequence activity you just placed.

6. Visual Studio automatically brings up the code editor. Locate the DoTaskOne method Visual Studio just added, and in that method place this code:

Console.WriteLine("Executing Task One...");

7. Perform steps 4, 5 and 6 again, twice, adding methods for DoTaskTwo and DoTaskThree, and changing the Writeline text appropriately. The workflow visual designer appears as you see here.

8. Turning to the main application, open the Program.cs file for editing and locate the Main method. In the Main method, search for the following lines of code:

// Print banner. Console.WriteLine("Waiting for workflow completion.");

9. Following the code you found in the preceding step, add this code:

WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(SequencerFlow.Workflow1)); instance.Start();

10. Of course, we need to reference the SequencerFlow workflow library from the main application project. Adding a project-level reference as we ve done in previous chapters is more than adequate. 11. Compile the application, and correct any errors you find. Press F5 or Ctrl+F5 to run the application. Set a breakpoint or run from a command prompt so you ll be able to see the output. The output is shown here:

7

As you can see from the graphic from step 11, the tasks were executed in order, as we d expect. Two things to remember are simply that the Sequence activity is a composite activity (a container for other activities) and that it executes the items it contains in sequential order.

The other activity we ve used often so far in the book is the Code activity. The Code activity is meant to execute custom code you provide for execution within your workflow. There is a way to call external methods we ll look at in the next chapter. When you place a Code activity in your workflow, the ExecuteCode property should be set to the name of the method the workflow runtime will call. Actually, if you look closely at the code Visual Studio inserted for you when you set the ExecuteCode property for the Sequencer application we just completed, it isn t a method that s called as much as it is an actual event handler. For example, here is the method we inserted for DoTaskOne:

private void DoTaskOne(object sender, EventArgs e) { Console.WriteLine("Executing Task One..."); }

As you can see, when the workflow runtime executes your Code activity, it fires an event named using the value you provided in the ExecuteCode property. The three Code activities in the preceding application (Sequencer) demonstrate this. As you can imagine, we ll be making good use of the Code activity throughout the remainder of the book.

I mentioned this very early in the book, but I haven t really reinforced this basic concept workflows model processes. Therefore, we need to be able to model a wide variety of realworld situations, including the case where we need to throw an exception. Suppose that something along the way wasn t quite right, and the situation was not one our software could deal with in any other way than to throw an exception. We could, if we wanted, just throw an exception using the C# throw keyword, but using a special activity for this allows us to also use a special activity for handling exceptions, as we ll see in the next section. If we use the C# throw keyword, the workflow runtime swallows the exception, with no notice given. This behavior is the reason for the Throw activity. When the workflow runtime encounters the Throw activity, the workflow runtime fires the WorkflowTerminated event if there is no associated fault handler. However, keep in mind that, by then, the workflow instance is terminated and the workflow runtime is halted. It s far too late to make any attempt to correct the exceptional condition at that point. We can only restart the workflow runtime and kick off a new