Designer Metadata

In order to get the drag-and-drop capabilities for building workflows, metadata for the designer must be included as well. Without adding the designer metadata, the Sequence activity in Figure 10-1 would resemble the same Sequence activity in Figure 10-2 except without any drag-and-drop capabilities.

DesignerMetadata is provided from the System.Activities.Core.Presentation.DesignerMetadata namespace. Calling the Register() method registers metadata for the runtime, which will be demonstrated in the first exercise in this chapter, Rehosting WF Components.

Viewing Workflow XAML

As workflows are being built through the rehosted WF designer, it would be nice to see the XML that the WF designer generates as changes to the workflow are declaratively made. The custom workflow designer can be extended so that it adds a tab for representing a declarative workflow as XAML, too. The functionality for viewing the XAML produced while authoring workflows in Visual Studio is also provided by right-clicking on a workflow file that has a .XAML file extension and selecting View Code (see Figure 10-10).

Instead of needing to right-click on a workflow file, maybe a better experience would be to provide a way for clients to tab back and forth from a declarative model for the workflow and to its XAML representation. Figure 10-11 shows how tabs can be added to handle this functionality tastefully.

Clicking on the XAML tab will show the XAML that the WF designer builds behind the scene while authoring a workflow declaratively through activities (see Figure 10-12).

Gaining WF4.5 Designer Features

The only features provided with WF4 for visually exploring a workflow within the WF designer were

• Magnify a workflow
• Fit to screen
• Overview

In addition to the features illustrated in Figure 10-13, WF 4.5 offered some new features. You might think that the new features would automatically be inherited when rehosting the WF designer in VS2012 when using the WF4.5 assemblies, but this is not the case. In order for a rehosted WF designer to take advantage of these features, the code in Listing 10-9 must be set after instantiating a WorkflowDesigner object.

Listing 10-9.  Enabling the New Features in WF 4.5

WorkflowDesigner WF designer = new WorkflowDesigner();

 WF designer .Context.Services.GetService<DesignerConfigurationService>().AnnotationEnabled = true;
 WF designer .Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName = new
 System.Runtime.Versioning.FrameworkName(".NET Framework", new Version(4, 5));

 WF designer.Load(new Sequence());

The three new lines of code represent setting the AnnotationEnabled property to true and indicating to the WF designer that target .NET Framework is set to the .NET 4.5 version. Running the application built in the Rehosting WF Components exercise after adding the lines of code in Listing 10-9 enables the following features:

• Panning for workflows
• Multi-select of activities
• Auto-surround with the Sequence activity
• Toolbox search (available without the code in Listing 10-9)
• Designer annotations
• Workflow outline view

These features provide functionality for visually managing workflows through the WF designer. Since WF invests heavily in declaratively building workflows, features released for building workflows in WF4.5 provide essential tools that allow workflow authors to manage the visibility of large workflows.

Rehosting Arguments

At this point, thanks to the custom WPF application that was built in the Rehosting WF Components exercise plus the new features for WF 4.5 and the WF designer that were added in Figure 10-25, the custom application for building workflows is starting to look similar and provide some of the same features for authoring workflows within Visual Studio.  The main difference is that now the developer is in control of what features are provided to the end user for building workflows. Before going any further, Listing 10-10 shows the complete XAML for building the application illustrated in Figure 10-25. The added markup for the XAML includes

• Tabs for toggling the XAML that represents the workflow and the workflow itself.
• New ColumnDefinitions and RowDefinitions for laying out the different WF components within the application.

Listing 10-10.  Complete XAML for Rehosting the Designer

<Window x:Class="Exercise1.RehostedWFThroughMarkup"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:WFC="clr-namespace:System.Activities.Presentation.Toolbox;assembly=System.Activities.Presentation"
        xmlns:sys="clr-namespace:System;assembly=mscorlib"
        Title="WF designer" Height="350" Width="650">
    <Window.Resources>
        <sys:String x:Key="WFAssembly">System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</sys:String>
    </Window.Resources>
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="1.6*"/>
            <ColumnDefinition Width="1.6"/>
            <ColumnDefinition Width="4*"/>
            <ColumnDefinition Width="1.5*"/>
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition></RowDefinition>
            <RowDefinition></RowDefinition>
        </Grid.RowDefinitions>
        <Border Grid.Column="0" Grid.Row="0">
            <WFC:ToolboxControl>
                <WFC:ToolboxCategory CategoryName="Basic">
                    <WFC:ToolboxItemWrapper AssemblyName="{StaticResource WFAssembly}">
                        <WFC:ToolboxItemWrapper.ToolName>
                            System.Activities.Statements.Sequence
                        </WFC:ToolboxItemWrapper.ToolName>
                    </WFC:ToolboxItemWrapper>
                    <WFC:ToolboxItemWrapper  AssemblyName="{StaticResource WFAssembly}">
                        <WFC:ToolboxItemWrapper.ToolName>
                            System.Activities.Statements.WriteLine
                        </WFC:ToolboxItemWrapper.ToolName>

                    </WFC:ToolboxItemWrapper>
                    <WFC:ToolboxItemWrapper  AssemblyName="{StaticResource WFAssembly}">
                        <WFC:ToolboxItemWrapper.ToolName>
                            System.Activities.Statements.If
                        </WFC:ToolboxItemWrapper.ToolName>

                    </WFC:ToolboxItemWrapper>
                    <WFC:ToolboxItemWrapper  AssemblyName="{StaticResource WFAssembly}">
                        <WFC:ToolboxItemWrapper.ToolName>
                            System.Activities.Statements.Flowchart
                        </WFC:ToolboxItemWrapper.ToolName>

                    </WFC:ToolboxItemWrapper>
                </WFC:ToolboxCategory>
            </WFC:ToolboxControl>
        </Border>
        <Border Grid.Column="0" Grid.Row="1" Name="WFOutline" />
        <Grid Grid.Column="2" Grid.RowSpan="2"  Margin="2" Width="Auto">
            <TabControl x:Name="DesignerXamlTabDeck"  SelectionChanged="DesignerXamlTabDeck_SelectionChanged">
                <TabItem Name="DesignerTab" Header="Designer">
                    <Border Name="CenterBorder" />
                </TabItem>
                <TabItem Name="XamlTab" Header="XAML">
                    <TextBox AcceptsReturn="True" VerticalScrollBarVisibility="Auto" x:Name="XamlEditor"/>
                </TabItem>
            </TabControl>
        </Grid>
        <Border Grid.Column="3" Grid.RowSpan="2" Name="PropertyBorder"/>
    </Grid>
 </Window>

Listing 10-11 contains the code used to write the XAML representation of workflows and to add the XAML and workflow within tabs. It also shows the new code for hosting the new features provided by WF4.5 within the WF designer and the new Outline View for managing activities within a workflow.

Listing 10-11.  OnIntialized Event for Rehosting the Designer and WF Components

public partial class RehostedWFThroughMarkup : Window
 {
        WorkflowDesigner _wd = new WorkflowDesigner();
        public RehostedWFThroughMarkup()
        {
            InitializeComponent();
        }

        protected override void OnInitialized(EventArgs e)
        {
            base.OnInitialized(e);
            // registering metadata
            (new DesignerMetadata()).Register();

            Activity wf = new Sequence(){ Activities ={new Assign<int>()}};
             
           //Adding annotations
            _wd.Context.Services.GetService<DesignerConfigurationService>().AnnotationEnabled = true;
           //Targeting the .NET 4.5 Framework for the configuration service for the WF Designer control
            _wd.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName = new
             System.Runtime.Versioning.FrameworkName(".NET Framework", new Version(4, 5));
            _wd.Load(wf);
            PropertyBorder.Child = _wd.PropertyInspectorView;
            DesignerTab.Content = _wd.View;
           //Loads the outline view for the workflow
        //Adds the Outline View
            WFOutline.Child = _wd.OutlineView;
        }
 }

One thing that you may have noticed through all of the illustrations up to this point is that WF arguments have not been available in the rehosted designer. In some cases, business users might need the ability to customize or create WF arguments, so I want to describe how to add functionality of providing arguments and give a technical explanation as to why WF arguments have not been available within the rehosted WF designer application thus far. The code in Listing 10-11 shows the WF designer control loading an Activity object that contains a Sequence activity that contains an Assign activity:

WorkflowDesigner _wd = new WorkflowDesigner();
 //Activity object requires using System.Activities
 Activity wf = new Sequence(){ Activities ={new Assign<int>()}};
 _wd.Load(wf);

By passing in an Activity object to the WF designer, the designer thinks that the workflow is nothing more than an activity, even though additional activities can be added for creating a workflow that looks no different than any other workflow. The difference is in the XAML that is created. Without making any changes to the default activities that the designer loads up, the activities within the designer represent a basic workflow (see Figure 10-26).

Clicking the XAML tab to look at the XAML that was created reveals that the root element is <Sequence>. This indicates to the WF designer that this is not a workflow but a logical connection of activities (see Figure 10-27).

Now let’s check out the XAML for a new workflow within Visual Studio and add a Sequence activity with a child Assign activity. To view the XAML for a workflow in Visual Studio, right-click on the XAML file within the Solution Explorer that represents the workflow and select View Code. Notice that Figure 10-28 shows different XAML for the same activities added within the WF designer as represented in Figure 10-25.

The XAML in Figure 10-28 has a starting element of <Activity>, which means that the WF designer interprets the added activities as generic workflow activities rather than a specific activity, depending if the activity is out of the box or custom. Even though a particular activity can have arguments, the WF designer uses the Arguments tab for adding arguments that are meant for adding or returning data from a workflow rather than a workflow activity. Instead of loading an Activity object within a rehosted WF designer, an ActivityBuilder object can be loaded instead. Loading an ActivityBuilder object into the WF designer will generate the same XAML as in Figure 10-29 and will use the <Activity> root for the XAML instead of using a particular activity as the root, as illustrated in Figure 10-27.

Now the when you tab back to the Designer tab, the Arguments tab appears, indicating that WF arguments can be added to the workflow for trafficking data in and out of the workflow. Figure 10-30 shows how the Arguments tab is now viewable and how a new WF argument can be added to the workflow. An In argument called inArgEmployee is being created and the Argument Type is being searched on within the solution.

The code for creating the ActivityBuilder object is not too difficult. Listing 10-12 illustrates how to add a new Sequence activity and a child Assign activity to the workflow.

Listing 10-12.  OnIntialized Event for Rehosting the Designer and WF Components

private ActivityBuilder BuildBaseActivity()
 {
    try
    {
        ActivityBuilder builder = new ActivityBuilder
        {

            Name = "CustomWorkflow",
            Implementation = new Sequence()
            {
                Activities =
                 {
                    new Assign<Int32>()
                 }
            }
        };

        return builder;
    }
    catch (Exception)
    {
        throw;
    }
 }

The code in Listing 10-12 is a function that returns an ActivityBuilder object. Once the ActivityBuilder object is instantiated, the first things to set are the Name and Implementation properties. The Name property will identify the workflow, as illustrated in Figure 10-30 at the top of the workflow and just underneath the Designer tab. The Implementation property sets the activities that will be used within the workflow. First, a Sequence activity is instantiated and then its Activities property is used to add child activities to the Sequence activity. In this case, an instantiated Assign<Int32> activity is added. Finally, to get the WorkflowDesigner to load the ActivityBuilder, the line of code in Figure 10-9,

 _wd.Load(wf)

can be changed to load the ActivityBuilder object that is returned in Listing 10-10 by using

 _wd.Load(BuildBaseActivity())

instead. Most importantly, in order to use the ActivityBuilder object, you must add System Activities as a using statement.

 using System.Activities.Presentation.View;

        _wd.Context.Services.GetService<DesignerView>().WorkflowShellBarItemVisibility = ShellBarItemVisibility.None;

ActivityBuilder builder = new ActivityBuilder
         {

            Name = "CustomWorkflow",
            Implementation = new Sequence()
            {
                Activities =
                 {
                     new Assign<Int32>()
                 }
            },
            Properties =
            {
                 new DynamicActivityProperty
                 {
                      Name = "inArgFullName",
                      Type = typeof(InArgument<string>),
                      Attributes =
                      {
                          new RequiredArgumentAttribute(),
                      },
                      Value
                      = new InArgument<string>
                         {
                             Expression =
                             new InArgument<string>("Bayer White")
                         }
                }
            }
        };

Setting Up the UI for Managing Workflows

First, you must make some UI changes to handle the functionality for creating, saving, and loading a workflow. Listing 10-14 demonstrates how to add a ToolBar control within a DockPanel control so it can be placed at the top left corner of the application. The Toolbar control contains four buttons for creating a new workflow or updating, loading, or deleting an existing workflow. There is also a Label and Textbox control used to indicate the name of a workflow that is intended to be managed.

Listing 10-14.  Adding a Toolbar for Managing Workflows

<Grid Grid.Column="0" Grid.Row="0">
            <DockPanel LastChildFill="True" VerticalAlignment="Top">
                <ToolBar DockPanel.Dock="Top">
                    <Button Name="cmdNew" Click="cmdNew_Click">Create</Button>
                    <Button Name="cmdSave" Click="cmdSave_Click">Save</Button>
                    <Button Name="cmdDelete" Click="cmdDelete_Click">Delete</Button>
           <Button Name="cmdLoad" Click="cmdLoad_Click">Load</Button>
                </ToolBar>
                <Label DockPanel.Dock="Top">Workflow Name:</Label><TextBox Name="txtWorkflowName"  DockPanel.Dock="Top"></TextBox>
                <WFC:ToolboxControl DockPanel.Dock="Bottom">
                    <WFC:ToolboxCategory CategoryName="Basic">
                        <WFC:ToolboxItemWrapper AssemblyName="{StaticResource WFAssembly}">
                            <WFC:ToolboxItemWrapper.ToolName>
                                System.Activities.Statements.Sequence
                            </WFC:ToolboxItemWrapper.ToolName>
                        </WFC:ToolboxItemWrapper>
                        <WFC:ToolboxItemWrapper  AssemblyName="{StaticResource WFAssembly}">
                            <WFC:ToolboxItemWrapper.ToolName>
                                System.Activities.Statements.WriteLine
                            </WFC:ToolboxItemWrapper.ToolName>

                        </WFC:ToolboxItemWrapper>
                        <WFC:ToolboxItemWrapper  AssemblyName="{StaticResource WFAssembly}">
                            <WFC:ToolboxItemWrapper.ToolName>
                                System.Activities.Statements.If
                            </WFC:ToolboxItemWrapper.ToolName>

                        </WFC:ToolboxItemWrapper>
                        <WFC:ToolboxItemWrapper  AssemblyName="{StaticResource WFAssembly}">
                            <WFC:ToolboxItemWrapper.ToolName>
                                System.Activities.Statements.Flowchart
                            </WFC:ToolboxItemWrapper.ToolName>

                        </WFC:ToolboxItemWrapper>
                    </WFC:ToolboxCategory>
                </WFC:ToolboxControl>
            </DockPanel>
        </Grid>

Code can now be added to create the functionality for managing workflows through the UI. The code has been changed a bit to accommodate functionality for managing workflows. Workflows will be stored as XAML files within the same file path as the application’s execution file. Listing 10-15 shows the code for managing the folder where the workflows will be stored.

Listing 10-15.  Managing the Workflow Folder

public partial class RehostedWFThroughMarkup : Window
    {
        const string WorkflowFolder = "\CreatedWorkflows\";
        WorkflowDesigner _wd = null;

Next, you need a method to instantiate the WorkflowDesigner object each time a new workflow is loaded. This includes workflows that already exist and are loaded into the WF designer, and workflows that are being created. The WF designer no longer needs to be created as OnInitialized (see Listing 10-16).

Listing 10-16.  Instantiating the WorkflowDesigner Object Each Time a New Workflow is Loaded

private void BuildNewDesigner()
        {//Designer must be instantiated each time a workflow is loaded

            try
            {
                _wd = new WorkflowDesigner();

                _wd.Context.Services.GetService<DesignerConfigurationService>().AnnotationEnabled = true;
                _wd.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName = new
                 System.Runtime.Versioning.FrameworkName(".NET Framework", new Version(4, 5));
                //_wd.Load(wf);
                //_wd.Context.Services.GetService<DesignerView>().WorkflowShellBarItemVisibility = ShellBarItemVisibility.None;
                PropertyBorder.Child = _wd.PropertyInspectorView;
                DesignerTab.Content = _wd.View;
                WFOutline.Child = _wd.OutlineView; // Adds the Outline View

            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
        protected override void OnInitialized(EventArgs e)
        {
            base.OnInitialized(e);
            // registering metadata
            (new DesignerMetadata()).Register();
        }

Functionality for each of the buttons can now be implemented based on each of the button’s click event. Listing 10-17 illustrates code to create a new workflow. The code calls the BuildNewDesigner code illustrated in Listing 10-16 to instantiate the WorkflowDesigner object. This is important for calling the Load method on a WorkflowDesigner, because each time it is anticipating loading a new workflow, the WorkflowDesigner must be instantiated. The BuildBaseActivity defined in Listing 10-12 is then called within the Load method of the WorkflowDesigner, which returns an ActivityBuilder object that is to be loaded within the rehosted WF designer.

Listing 10-17.  Button Click Functionality for Creating a New Workflow

private void cmdNew_Click(object sender, RoutedEventArgs e)
         {
            try
            {
                if (txtWorkflowName.Text.Length == 0)
                    txtWorkflowName.Text = "CustomWorkflow";
                 
                BuildNewDesigner();
                 _wd.Load(BuildBaseActivity());
            }
            catch (Exception ex)
            {
                throw ex;
            }
         }

Listing 10-18 illustrates the code for saving a workflow that has been loaded into a WorkflowDesigner. The code first checks to see if a workflow name has been provided; if not, the user is prompted to provide a workflow name. The application’s executable file path is used for the location by declaring Directory.GetCurrentDirectory() along with the a particular folder and name provided for storing the workflow. The Flush method is executed on the WorkflowDesigner object so that the XAML representing the workflow is pushed into the WorkflowDesigner’s Text property. If the file path for saving a workflow does not exist, it is created. The WorkflowDesigner’s Save method is called to save the XAML file to the specified file path.

Listing 10-18.  Button Click Functionality for Saving a Workflow

private void cmdSave_Click(object sender, RoutedEventArgs e)
 {
    try
    {
        if (!string.IsNullOrWhiteSpace(txtWorkflowName.Text))
        {
            if (_wd!=null)
            {
                _wd.Flush();
                if (_wd.Text.Length>0)
                {
                    var wfFile = Directory.GetCurrentDirectory() + WorkflowFolder +txtWorkflowName.Text + ".xaml";

                    if (!Directory.Exists(Directory.GetCurrentDirectory() + WorkflowFolder))
                        Directory.CreateDirectory(Directory.GetCurrentDirectory() +WorkflowFolder);
                     
                    _wd.Save(wfFile);
                   MessageBox.Show("Workflow has been saved!");
                }
            }
            else
                MessageBox.Show("Please press 'Create' to build a new workflow!");
        }
        else
        {
            MessageBox.Show("Please enter a workflow name!");
        }
    }
    catch (Exception ex)
    {
        throw ex;
    }
 }

Workflows can also be deleted once they are created. Listing 10-19 illustrates that a workflow name must be provided; if the file exists, then it is deleted.

Listing 10-19.  Button Click Functionality for Deleting a Workflow

private void cmdDelete_Click(object sender, RoutedEventArgs e)
 {
    try
    {
        if (!string.IsNullOrWhiteSpace(txtWorkflowName.Text))
        {
             
            var wfFile = Directory.GetCurrentDirectory() + WorkflowFolder + txtWorkflowName.Text + ".xaml";

            if (!File.Exists(wfFile))
                MessageBox.Show("Workflow does not exist!");
            else
            {
                File.Delete(wfFile);
                MessageBox.Show("Workflow has been removed!");
            }
        }
        else
        {
            MessageBox.Show("Please enter a workflow name!");
        }
    }
    catch (Exception ex)
    {
        throw ex;
    }
 }

Finally, an existing workflow can be loaded so it can be modified further. Listing 10-20 illustrates how a workflow’s XAML file is checked to see if it exists. If the workflow exists, a new WorkflowDesigner object is again instantiated because the XAML file has to be loaded within the WorkflowDesigner. Once the workflow is loaded, the rehosted WF designer reflects the loaded workflow.

Listing 10-20.  Button Click Functionality for Loading a Workflow

        private void cmdLoad_Click(object sender, RoutedEventArgs e)
        {
            try
            {
                if (!string.IsNullOrWhiteSpace(txtWorkflowName.Text))
                {

                    var wfFile = Directory.GetCurrentDirectory() + WorkflowFolder + txtWorkflowName.Text + ".xaml";

                    if (!File.Exists(wfFile))
                        MessageBox.Show("Workflow does not exist!");
                    else
                    {
                        BuildNewDesigner();
                        _wd.Load(wfFile);
                    }
                }
                else
                {
                    MessageBox.Show("Please enter a workflow name!");
                }
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
    }
 }

Running the application after implementing the functionality for managing workflows will display the toolbox so that workflows can be created (see Figure 10-32).

Figure 10-33 shows how selecting the Create button loads a default workflow into the designer. Once the workflow is loaded, the Outline view for the workflow becomes visible based on the default activities loaded into the WF designer. I also changed the value of the Implementation property of the ActivityBuilder to Implementation = new Flowchart(). As a new workflow is loaded, it only loads a Flowchart activity that can be extended.

CustomWorkflow is the name given to the new workflow and it can now be modified by adding a new If activity to the workflow. Clicking on the Save button within the toolbar saves the workflow to the file system (see Figure 10-34).

The workflow has now been saved on the local file path where the executable running the application is located and within the specified folder of CreatedWorkflows. Figure 10-35 shows the file opened in Notepad and the XAML used to save the workflow. Shutting down the application and then restarting it again, the workflow illustrated in Figure 10-34 is loaded into the WF designer so it can be modified. After modifying the workflow, it can be saved again and reloaded again at a later time. Clicking the Delete button will remove the workflow file from the file path.

Dynamic Business Logic

Now you’re ready to see the power of building workflows within a rehosted WF designer. Leave the console application running so it can continue to collect orders. At the same time, you should reload the workflow from the file system and modify it by adding another WriteLine activity to the workflow as the last activity to be processed. Set the Text property to "Workflow has been changed!" After saving the workflow back to the file system, the console application will immediately pick up the change by writing out to the console, "Workflow has been changed!" without the need to recompile the console application. This represents a true separation between the business process and application (see Figure 10-39).

Decisions on how to manage orders that are received can now be incorporated and defined during runtime. Using the If activity provides flexibility in determining how an order is handled. In this next example, you are going to use the If activity to control the flow of a received order and use the WriteLine activity to simulate an activity by writing out to the console what should happen. This is a good way of letting a non-technical user provide a model for how a process should be performed. As an order is received, the flow of the order will be indicated through the console using the WriteLine activities that are executed.

Here is the business logic that will be applied:

1. Orders over $10.00 must be approved.
2. Customers who place orders between $2 and $5 dollars should be sent current sales reminders included in the order.
3. Customer’s that order Widget2 should receive a one year warranty for Widget2.

For orders that are over $10, an If activity is added to the workflow and its Condition property is set to inArgNewOrder.Price>10. A WriteLine activity can then be added within the Then branch of the If activity to indicate what needs to happen. In a real world application, a composite activity composed of out-of-box activities could be used to define the approval process or even better, custom activities could be developed to handle the approval process as well; however, in this case the WriteLine activity is used to simply demonstrate how the flow of an order can be changed dynamically during runtime (see Figure 10-40).

The Else branch of the If activity illustrated in Figure 10-40 will handle orders placed between $2 and $5 so that current sales reminders are sent to the customer along with the order (see Figure 10-41).

Now that the workflow checks for the appropriate price points, the last rule that needs to be implemented within the workflow is to check for orders where Widget2 was ordered so that the customer receives a one year warranty. Clicking the CustomWorkflow indicated in Figure 10-41, which is above the workflow, the workflow changes its view within the designer to the root of the workflow. Another If activity can be added beneath the existing If activity illustrated in Figure 10-42 so the last business rule can be created.

Since the last rule only needs to check for an order that includes Widget2, there is no need for this rule to be a part of the price checks dictated by the other two rules. Pressing the Save button to save the workflow, the new rules created immediately take effect (see Figure 10-43).

Figure 10-43 illustrates that the new rules are working correctly. The first message indicates that sales reminders should be sent to the customer. This is because the order price was $4.30, which is between $2 and $5 dollars. The next message indicates that an order needs approval because the order price was over $10; however the console also indicates that the same order that is over $10 was also an order for Widget2, therefore the customer should also receive a warranty.