Versioning Through Code

Listing 6-3 shows the code used to set the latest version of the workflow service that should be hosted using the WorkflowServiceHost. By calling CurrentWorkflowService(), the version of WorkflowService is set to 2.0.0.0 using the DefinitionIdentity property, which is of type WorkflowIdentity described earlier in in Table 6-1. The WorkflowServiceHost has a new SupportedVersions property, which is of type ICollection<WorkflowService>. After the WorkflowServiceHost is initialized, each additional version of the workflow it supports is also added through the WorkflowServiceHost SupportedVersions property.

Listing 6-3.  Supporting Multiple Workflow Versions Through Code

using System;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel.Activities;
using System.Web;
using System.Activities;
using System.Collections.ObjectModel;

namespace Apress.Chapter7
{
    public static class HostWorkflowService
    {
        public static void StartServiceHost()
        {
            using (WorkflowServiceHost wfServiceHost
                        = new WorkflowServiceHost(CurrentWorkflowService(),
                            new Uri("http://localhost:8080/EquipmentRentalService")))
            {
                var supportedServices = SupportedWorkflowServices();
                foreach(var wfService in supportedServices)
                {//add each supported version
                    wfServiceHost.SupportedVersions.Add(wfService);
                }

                wfServiceHost.Open();
            }
        }

        public static WorkflowService CurrentWorkflowService()
        {
            var v2Workflow = new WorkflowService
            {
                Body = new TeachingApplicationService(),
                DefinitionIdentity = new WorkflowIdentity
                {
                    Name = "SimpleApplication",
                    Version = new Version(2, 0, 0, 0) //set the current version of the workflow
                }
            };

            return v2Workflow;
        }

        public static Collection<WorkflowService> SupportedWorkflowServices()
        {
            var services = new Collection<WorkflowService>();

            var v1Workflow = new WorkflowService
            {
                Body = new TeachingApplicationService(),
                 DefinitionIdentity = new System.Activities.WorkflowIdentity
                {
                    Name = "SimpleApplication",
                    Version = new Version(1, 0, 0, 0) //set the initial version of the workflow
                }
            };

            services.Add(v1Workflow);

            var v15Workflow = new WorkflowService
            {
                Body = new TeachingApplicationService(),
                DefinitionIdentity = new System.Activities.WorkflowIdentity
                {
                    Name = "SimpleApplication",
                    Version = new Version(1, 5, 0, 0) //set the updated minor version of the workflow
                }
            };

            services.Add(v15Workflow);
             
            return services;
        }
    }
}

Versioning Workflow Applications

Workflows that are not intended to be delivered as WCF services can be versioned in a similar way. Listing 6-3 illustrates the WorkflowServiceHost versioning hosted workflow services, but the WorkflowApplication can also be used for versioning workflows hosted within applications, as shown in Listing 6-4.

Listing 6-4.  Setting the Versions for a Workflow Hosted Through WorkflowApplication

WorkflowIdentity v1WorkflowIdentity = new WorkflowIdentity
{
    Name = "SimpleApplication",
    Version = new Version(1, 0, 0, 0) //set the current version of the workflow
};

WorkflowApplication wfApp = new WorkflowApplication(new TeachingApplication(),v1WorkflowIdentity);

// Setup the WorkflowApplication
WorkflowApplicationFactory(wfApp);

// Execute the workflow.
wfApp.Run();

After the workflow goes idle and is persisted, at a later time the workflow can be reloaded from its persisted store. As the workflow is reloaded, the same WorkflowIdentity properties used when the workflow was persisted must be used for loading the workflow. If the WorkflowIdentity is different, then a VersionMismatchException is thrown. Listing 6-5 illustrates the contents for the message based on the WorkflowIdentity set in Figure 6-4.

Listing 6-5.  Error Message Thrown When a Version Is Loaded with the Wrong Version

The WorkflowIdentity ('SimpleApplication; Version=1.0.0.0') of the loaded instance does not match the
WorkflowIdentity ('SimpleApplication; Version=2.0.0.0') of the provided workflow definition. The
instance can be loaded using a different definition, or updated using Dynamic Update.

A new object called WorkflowApplicationInstance is returned while retrieving a persisted workflow instance using WorkflowApplication.GetInstance. It has a DefinitionIdentity of type WorkflowIdentity that can be used to check that that the workflow definition version is being used.

Configuring Versioning within Visual Studio

Figure 6-10 illustrates how Visual Studio can be used to configure workflow versions through the WF designer. The new property of DefinitionIdentity is being set within Visual Studio to a WorkflowIdentity. The workflow version has been set to 1.0.0.0 and it has been given the name SimpleApplication. After setting these properties of the WorkflowIdentity, the workflow can be run.

To check that the workflow has been properly persisted, SQL Server Management Studio can be used to connect to the database used for persisting workflow instances. The System.Activities.DurableInstancing.Instances view can be run to view persisted workflow instances. Figure 6-11 indicates that the workflow instance has been persisted and that the version of the workflow definition has been stored.

The business now mandates that the workflow must be changed. The first thing to do is copy the workflow and move it within the App_Code folder of the project. In this case, another folder called SimpleApproval is created and used to hold older versions of the same type of workflow (older versions, in other words). Although Figure 6-12 only shows the workflow file v1SimpleApproval.xamx, other versions of the same type of workflow can be added as well.

The original workflow, SimpleApproval, can have its version updated to 2.0.0.0 by changing the workflow’s DefinitionIdentity property for the root of the workflow. The workflow can now be updated to implement the logic within Figure 6-5, which mandates that a candidate must have more than 4 years of experience. The code in Listing 6-1 must accommodate a new YearsOfExperience property:

[DataMember]
public int YearsOfExperience {get; set;}

This time, as the updated workflow is run, the new property, YearsOfExperience, can be set to indicate the years of experience for the candidate. In this case, Linda Owen only has 3 years of experience, as shown in Figure 6-13.

Now two workflow instances have been persisted, but the second persisted instance indicates that it uses version 2.0.0.0 of the SimpleApplication workflow (see Figure 6-14).

When the workflow is run again, the logic will check that the candidate has more than 4 years of experience even if the candidate is approved, as illustrated in Figure 6-15. The workflow instance will then be removed from the persistence store by the WF runtime because the workflow will have completed.

Now the other workflow instance can be run using the previous version of the workflow, which does not factor in years of experience for approval. Figure 6-16 illustrates that the candidate application has been approved without taking into account the years of experience.

Decoupling Workflow Implementation from Workflow Updates

This section will demonstrate how a workflow application can be decoupled from a different application that prepares a workflow to be updated. A separate application can be used to create an update map that is used to update a workflow dynamically at a later point in time. In this scenario, a workflow that models a movie rental process will be built. Later I will show how the rental process can be updated dynamically so that customers who have movies still rented are able to experience added functionality within the rental process.

Renting movies has changed quite a bit in the last few years, so the process will be based on those movie rental machines that have become quite popular. I recently had my first experience renting a movie from a machine rather than walking into a store, and I thought to myself that this scenario would be a fun exercise to model with WF. Here are the steps I took to rent a movie.

1. Searching for one or more movies.
2. Confirming when I was done searching for movies.
3. Inserting my credit card to pay for selected rentals.
4. Confirming my rental order.

Once I had finished watching the rented movies, I brought them back to the rental machine and entered my credit card so the rental machine knew that I had returned the movies; my credit card was charged the amount of the rentals.

Now that the steps for renting a movie have been identified, the next thing to do is to model the process. Since this process is mainly human driven, a state machine control flow will be used.

Figure 6-19 illustrates the state machine that will be used to model the movie rental process, and the flow models each of the steps mentioned for renting a movie. When the workflow is run, the first state that the workflow will execute is the MovieSearch state.

Setting Up the Workflow

While the current state of the workflow is MovieSearch, there are two transitions that can be made by the customer:

• DoneSearching
• SelectAMovie

Each of these transitions add a System.Activities.Statements.Transition to the MovieSearch System.Activities.Statement.State, and each transition uses the custom activity of WaitForResponse to set up a bookmark for each transition (see Listing 6-11).

Listing 6-11.  WaitForResponse Custom Activity

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Activities;

namespace Apress.Chapter7.Activities
{
    public sealed class WaitForResponse<TResult> : NativeActivity<TResult>
    {
        public WaitForResponse()
            : base()
        {

        }

        public string ResponseName { get; set; }

        protected override bool CanInduceIdle
        { //override when the custom activity is allowed to make he workflow go idle
            get
            {
                return true;
            }
        }

        protected override void Execute(NativeActivityContext context)
        {
            context.CreateBookmark(this.ResponseName, new BookmarkCallback(this.ReceivedResponse));
        }

        void ReceivedResponse(NativeActivityContext context, Bookmark bookmark, object obj)
        {
            this.Result.Set(context, (TResult)obj);
        }
    }
}

Figure 6-20 illustrates that the WaitForResponse activity has been added within the Trigger section of the SelectAMovie transition and the object type Movie will be passed through the bookmark from the workflow host to make the transition occur. This event will indicate that the customer has made their first movie selection. Listing 6-12 indicates the properties associated with the Movie object:

• MovieName
• Rating
• Price

Listing 6-12.  Movie Class That Identifies Properties for a Movie

using System;
using System.Collections.Generic;
using System.Linq;

using System.Text;
using System.Threading.Tasks;

namespace MovieRental.DataModel
{
    [Serializable]
    public class Movie
    {
       public string MovieName { get; set; }
       public string Rating { get; set; }
       public Decimal Price { get; set; }
    }
}

Since the SelectAMovie transition points to the same State MovieSearch, the event SelectAMovie can be fired multiple times indicating that a customer can rent as many movies as they would like for a rental order.

The bookmark’s ResponseName property indicates the name of the bookmark that needs to be called from the workflow host and the Result property that is used to set an existing property or argument within the workflow. The workflow has a property called holdSelectedMovie of type Movie, and this property accepts the value that is passed into the workflow so it can be used to process logic. The Condition section of the transition checks that the workflow property holdSelectedMovie is not null based on the Movie object that was passed in from the workflow host (see Figure 6-20).

Finally, an AddToCollection activity is added to create a collection of movies that the customer intends to rent. Figure 6-21 indicates the properties that are set within the activity.

There is a TypeArgument property that is set to type Movie. The Item property is set to holdSelectedMovie for the movie that is passed in through the bookmark, and the Collection property is used to hold a collection of movies. This property is set to holdNewRental.Movies, and holdNewRental is another workflow property of type CustomerRental that is indicated in Figure 6-20. Listing 6-13 shows the CustomerRental class.

Listing 6-13.  CustomerRental Class

using System;
using System.Collections.Generic;
using System.Linq;

using System.Text;
using System.Threading.Tasks;

namespace MovieRental.DataModel
{
    [Serializable]
    public class CustomerRental
    {
        public CustomerRental()
        {
            Movies = new List<Movie>();
        }
         
        public Guid RentalId { get; set; }
        public List<Movie> Movies { get; set; }
        public CreditCard PaymentCard { get; set; }
       }
}

The other transition, DoneSearching, also uses a WaitForResponse activity; however, it is not intended to do much other than indicate when a customer is done searching and selecting movies to rent. The WaitForResponse accepts a Boolean type that will be passed in from the workflow host to the workflow (see Figure 6-22).

Once the customer is done selecting movies to be rented, the next state that is activated is CompletedMovieSearch. Once CompletedMovieSearch is set as the current state for the workflow, a customer can then insert their credit card to process and confirm the order. The InsertCard transition is initiated from the workflow host once the customer is ready to process the order. The WaitForResponse activity for this transition accepts a CreditCard object and sets it to holdNewRental.PaymentCard. There is also a custom activity that inherits from CodeActivity<T>, which simulates processing a credit card. If this was real, a third-party reference could be made and the code that uses the third party code could be added here. Instead, Listing 6-14 shows the custom activity code for RunCreditCard that simulates a credit card being successfully run by returning a transaction number and assigning the number to the CreditCard object that was passed in. The RunCreditCard activity accepts a CreditCard object and then returns the object with a hard-coded transaction number.

Listing 6-14.  RunCreditCard Custom Activity

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Activities;
using MovieRental.DataModel;

namespace Apress.Chapter7.Activities
{
    [Serializable]
         public class RunCreditCard : CodeActivity<CreditCard>
    {
         [RequiredArgument]
         public InArgument<CreditCard> inCreditCard { get; set; }
         protected override CreditCard Execute(CodeActivityContext context)
         {
             var ccWithTransNo = inCreditCard.Get(context);
             ccWithTransNo.TransactionNumber = 1542514612;
             return ccWithTransNo;
         }
    }
}

The CreditCard object used is indicated in Listing 6-15, which contains the property TransactionNumber. It also implements IEquatable<T> so a CreditCard object can be compared to another CreditCard object based on certain its properties. The Equals function purposely omits checking the TransactionNumber because later when a customer comes back to return the movies, the same credit card that was entered to process the order will be used to check that it was the same credit card charged for the rental.

Listing 6-15.  CreditCard Class Used to Pass Credit Card Data to the Workflow

using System;
using System.Collections.Generic;
using System.Linq;

using System.Text;
using System.Threading.Tasks;

namespace MovieRental.DataModel
{
    [Serializable]
    public class CreditCard:IEquatable<CreditCard>
    {
         
        public string CCNumber { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int ExpireMonth { get; set; }
        public int ExpireYear { get; set; }
        public int TransactionNumber  { get; set; }
        public bool Equals(CreditCard other)
        {
            if (this.CCNumber == other.CCNumber
                && this.ExpireMonth == other.ExpireMonth
                && this.ExpireYear == other.ExpireYear
                && this.FirstName == other.FirstName
                && this.LastName == other.LastName)
                return true;
            else
                return false;
        }
    }

After the customer’s credit card is charged, a Persist activity is used to persist the workflow instance within the persistence store in SQL Server; this way memory is released for customer movie rental until the customer returns the movies, allowing other customer rental orders to be processed. The Condition section for the transition checks that a transaction number has been added and that it has been charged (see Figure 6-23).

Once the customer decides to return the movies, they will enter the same credit card they used to place the movie rental. The transition ReturnMovie is used to indicate that a customer has entered their credit card by using another WaitForResponse activity. The activity accepts the CreditCard object and sets it to another workflow property called holdReturnMovieCard. Although the ResponseName is also set to ReturnMovie, which is the same name as the transition, it does not have to be. The condition for the transition uses the CreditCard.Equals function to check that the CreditCard object that was passed in is the same CreditCard object that was used to process the rental, but of course the Equals function does not care about the TransactionNumber property since the CreditCard object that is passed in to return the movie will not have a transaction number set (Figure 6-24).

The last state of the workflow uses a FinalState state. This indicates the last state of the workflow and also sets the OutArgument OutMovieRental associated to the workflow. Here the holdNewRental CustomerRental type is set to OutMovieRental argument, which is also a CustomerRental type. The OutMovieRental argument will be returned back to the workflow host to indicate that the workflow has completed and specific properties were set for the argument inside the workflow (see Figure 6-25).

Creating a Workflow Host

Now that the workflow has been built to create movie rentals, a workflow host needs to be built to make sure the workflow works as intended. This workflow relies on using the WF runtime to manage workflow execution like persistence and versioning. Since the workflow will execute solely within the rental machine’s software, the WorkflowApplicationHost will be used to manage the workflow as a hosted application. Figure 6-26 shows the steps that were defined within the workflow, and now code needs to be written to interact with the workflow and test its execution before the solution can be loaded onto the rental machines hardware.

When the application to simulate how a customer will rent one or more movies is started using the workflow illustrated in Figure 6-26, a new rental is initiated when the “New Rental” button is selected. The next step is to add a movie that a customer would like to rent. After the movie is entered then the “Select Movie” button is pressed to store the movie selection. Remember that the workflow in Figure 6-19 is built so that multiple movies are allowed to be rented at one time; however, after the customer has decided that they are done adding movies to rent, the “Selection Complete” button is pressed.

At this point payment is required, so the customer needs to select the “Insert Card” button, which will take the credit card information and process the card. Finally, the workflow is unloaded from the WF runtime when the customer selects the  “Finish” button. At this point the application can stop its execution to simulate a later time when the customer will bring back the movies. This workflow is considered to be long-running because a customer may take hours or even days to return the one or more of the rented movies.

To simulate a customer returning one or more movies, the Guid that was generated through the persistence store is used to track the original rental. The Guid is then added to the RentalTransactionId textbox and the button called “Insert Card to Return Movie” is then pressed to complete the workflow. When the workflow has completed, a pop-up window indicates that the movie has been returned. Figure 6-27 illustrates how workflow instances can be monitored using the Server Explorer within VS2012 to see the Instances database view that is created within the SQL Server persistence store.

The next few pages will walk through the code used to host the movie rental workflow. The custom workflow host application in Figure 6-26 is a simple WPF application that is its own project within the solution. The application uses the namespaces illustrated in Listing 6-16. The using statements after System.Activities indicate some of the references that are required to be made to the project.

Listing 6-16.  Initiating the Workflow Host Application

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;

using System.Activities;
using System.Runtime.DurableInstancing;
using System.Activities.DurableInstancing;
using System.Threading;
using MovieRental.DataModel;
namespace Apress.Chapter7.Host
{
    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        private WorkflowApplication _wfApp;
        private SqlWorkflowInstanceStore _instanceStore;

        public MainWindow()
        {
            InitializeComponent();
            CreatePersistenceStore();
        }

The SqlWorkflowInstanceStore is initiated first as a private variable to be used throughout the code; as the class loads, its constructor creates and configures the persistence store defined as the private variable. To initialize the SqlWorkflowInstanceStore, its ConnectionString property needs to be set. Optionally its InstanceCompletionAction property can be set, and for the application it is set to InstanceCompletionAction.DeleteNothing. This setting indicates that after a workflow instance persists and later completes, it will not be removed from the persistence store (see Listing 6-17).

Listing 6-17.  Configuring the Persistence Store

private void CreatePersistenceStore()
        {
            try
            {
                _instanceStore = new SqlWorkflowInstanceStore();
                _instanceStore.ConnectionString =
                    @"Data Source=(LocalDB)v11.0;Initial Catalog=WFPersist;Integrated Security=True";
                _instanceStore.InstanceCompletionAction = InstanceCompletionAction.DeleteNothing;
            }
            catch (Exception)
            {
                throw;
            }
        }

After the persistence store is configured, the WorkflowApplication is then instantiated. Listing 6-18 illustrates that after instantiating the MovieRentalProcess workflow as an Activity object, it is passed into a new WorkflowApplication as the workflow that will be managed by the WF runtime. In WF4.5, a WorkflowApplication object now accepts a WorkflowIdentity object. Here the Name property is set to a meaningful name and a new Version object indicating the current version of the workflow.

Since the WorkflowApplication allows workflow instances to be run asynchronously, this application will only run workflow instances using the same thread that the WPF application uses. This is enforced by setting the WorkflowApplication object’s SynchronizationContext property to SynchronizationContext.Current. The WorkflowApplication object’s InstanceStore property is also set to use the persistence store that was set up in Listing 6-18.

Listing 6-18.  Configuring the WorkflowApplication Variable

private void InitiateWorkflowRuntime()
        {
            try
            {
                Activity rentalWorkflow = new MovieRentalProcess();
                _wfApp = new WorkflowApplication(rentalWorkflow,
                    new WorkflowIdentity
                    {
                        Name = "v1MovieRentalProcess",
                        Version = new System.Version(1, 0, 0, 0)
                    });
                _wfApp.SynchronizationContext = SynchronizationContext.Current;
                _wfApp.OnUnhandledException = OnUnhandledException;
                _wfApp.Completed = OnWorkflowCompleted;
                _wfApp.Idle = OnWorkflowIdle;
                _wfApp.InstanceStore = _instanceStore;
                _wfApp.Unloaded = OnWorkflowUnloaded;
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

Next, a couple of WF runtime events are also wired up using the WorkflowApplication events. For instance, OnUnhandledExeption is an important delegate to wire up because it is important to know when a workflow instance has thrown an exception. I cannot stress the amount I have wasted while building workflow applications in the past without wiring up this delegate and not knowing when a workflow instance was failing. The OnWorkflowCompleted event fires when a workflow instance finishes, of course. An OnWorkflowIdle event fires while the workflow waits, and OnWorkflowUnloaded fires once the workflow is unloaded from the WF runtime. In some cases, like in Listing 6-19, it is not important to add code; however, it is nice to have the event fire when these different events occur.

Listing 6-19.  Declaring How the WF Runtime Events Will Be Handled

private void OnWorkflowIdle(WorkflowApplicationEventArgs args)
{
}

private void OnWorkflowUnloaded(WorkflowApplicationEventArgs args)
{
}

private void OnWorkflowCompleted(WorkflowApplicationCompletedEventArgs wc)
{
    var createdRental =
        wc.Outputs["OutMovieRental"] as CustomerRental;
    MessageBox.Show(
        string.Format("New rental for {0} {1} has been returned!",createdRental.PaymentCard.FirstName,createdRental.PaymentCard.LastName));
}

private UnhandledExceptionAction OnUnhandledException(WorkflowApplicationUnhandledExceptionEventArgs uh)
        {
            return UnhandledExceptionAction.Terminate;
        }

Now the application starts getting into the button events that will drive the workflow. Listing 6-20 indicates that when the cmdStartRentalProcess button is pressed, the WorkflowApplication is initialized by calling InitiateWorkflowRuntime() and running the code in Listing 6-18.

Listing 6-20.  Starting the Workflow

private void cmdStartRentalProcess_Click(object sender, RoutedEventArgs e)
        {
            InitiateWorkflowRuntime();
           _wfApp.Run();
        }

After a new workflow instance is started, the customer can start adding movie titles that they want to rent. As each new movie title is added, the movie’s price and rating is hard-coded, as illustrated with the code in Listing 6-21. Once a Movie object is created, the workflow host indicates to the workflow that it is ready to pass it some information. The SelectMovie bookmark is called using the WorkflowApplication method of ResumeBookmark and passing to the workflow the Movie object that was created. Once the customer is done adding movie titles to rent, the FinishSearching bookmark is called. The bookmark accepts a Boolean, which is not really significant; however, if additional logic needed to be built off of the bookmark or another bookmark with the same name needed to be added to define another transition, it could be applied based on the Boolean value that is passed. Here the code simply passes in true, indicating that the customer has finished entering movies.

Listing 6-21.  Adding Movies To Be Rented Using the SelectMovie Bookmark

private void cmdSelectMovie_Click(object sender, RoutedEventArgs e)
        {
            var movie = new Movie
            {
                MovieName = txtMovieName.Text,
                Rating = "PG",
                Price = Convert.ToDecimal(4.50)
            };
            _wfApp.ResumeBookmark("SelectMovie", movie);
        }
private void cmdSelectionComplete_Click(object sender, RoutedEventArgs e)
        {
            _wfApp.ResumeBookmark("FinishedSearching", true);
        }

After one or more movies have been selected to be rented, the workflow host needs to initiate when a payment card is entered in order to process a movie rental. Figure 6-21 shows the cmdInsertCard button click event that builds a new CreditCard object and passes it to the workflow by calling the ScanPaymentCard bookmark. Listing 6-22 indicates that the values have been hard-coded.

Listing 6-22.  Passing a CreditCard Object to be Processed for the Rental Order

private void cmdInsertCard_Click(object sender, RoutedEventArgs e)
        {
            var creditCard = new CreditCard()
            {
                CCNumber = "1235626427465",
                FirstName = "Bayer",
                LastName = "White",
                ExpireMonth = 10,
                ExpireYear = 14
            };

            _wfApp.ResumeBookmark("ScanPaymentCard", creditCard);
        }

The last button required to unload the workflow instance from memory is the cmdUnload button. The button is labeled as Finished; however, its click event, which is defined in Listing 6-23, illustrates that the WorkflowApplication object’s Unload method is called. Since the workflow instance is persisted, it no longer needs to run in memory while waiting for the customer to return rented movies.

Listing 6-23.  Unloading the Workflow Instance from Memory

private void cmdUnload_Click(object sender, RoutedEventArgs e)
{
       _wfApp.Unload();
}

After running the application illustrated in Figure 6-26 to create a new movie rental, the Instances database view should contain a new record. Figure 6-28 illustrates some of the fields that indicate that the workflow instance has become idle and is waiting on the ReturnMovie bookmark to be resumed. The last couple of fields on the record also indicate the values for the fields IdentityName, IdentityPackage, Build, Major, Minor, and Revision that were given to the workflow when it was created using the code in Listing 6-18.

Updating the Workflow Snapshot

After the workflow snapshot is created, the workflow may look a little rough through the WF designer. Figure 6-32 illustrates the workflow snapshot when compared to the workflow in Figure 6-19. While interrogating the XML used to build the workflow snapshot generated within the wfReadyToUpdate.xaml file, I don’t believe the original locations for the states and transitions is being accounted for as they were laid out in Figure 6-19.

By clicking on the CompletedMovieRental FinalState of the workflow, the MoviesJustReleased activity can be added. The inBasedOnMovie argument needs to be set to the movie that the customer is returning using the holdNewRental.Movies(0). This value represents the first movie that was rented and set earlier when the movie rental was created. The Result argument will be set to holdNewRental.Movies (see Figure 6-33).

Now that the workflow has been updated, it is important to recompile the solution and update the references that the workflow-updating application will use. In this case, the references that are indicated as being stale in Figure 6-34 will be updated.

Now that the changes to the workflow have been updated, a DynamicUpdateMap can be created so it can later be used to update a persisted workflow instance. Figure 6-35 illustrates that that selecting the “Save Update Map” button creates the wfReadytoUpdate.map file.

The code used to generate the DynamicUpdateMap is shown in Listing 6-26. Specifically, the code in cmdSaveUpdateMap_Click is used to load the updated workflow snapshot from disk, create a DynamicUpdateMap file by calling DynamicUpdateServices.CreateUpdateMap, and then save the map to disk.

Listing 6-26.  Creating the Update Map

private void cmdSaveUpdateMap_Click(object sender, RoutedEventArgs e)
        {

            DeltaWF = LoadActivityBuilder(txtWorkflowSnapshot.Text);
            updateMap = DynamicUpdateServices.CreateUpdateMap(DeltaWF);

            SaveUpdateMap(updateMap, txtWorkflowSnapshot.Text);
        }
                 

        public ActivityBuilder LoadActivityBuilder(string fileName)
        {
            ActivityBuilder builder;
            using (var xamlReader = new XamlXmlReader(fileName))
            {
                var builderReader = ActivityXamlServices.CreateBuilderReader(xamlReader);
                builder = (ActivityBuilder)XamlServices.Load(builderReader);
                xamlReader.Close();
            }
            return builder;
        }

        public void SaveUpdateMap(DynamicUpdateMap map, string fileName)
        {
            var path = System.IO.Path.ChangeExtension(fileName, "map");
            DataContractSerializer serialize = new DataContractSerializer(typeof(DynamicUpdateMap));
            using (FileStream fs = File.Open(path, FileMode.Create))
            {
                serialize.WriteObject(fs, map);
            }

            txtUpdateMapFile.Text = path;
        }

After the map file is created, it can be used to update any workflow instances that have been persisted using the original workflow for renting movies. The code in Listing 6-26 is used to update a workflow instance associated by a Guid that is added in the textbox, as illustrated in Figure 6-35. Listing 6-27 indicates that the persistence store must be configured first using a connection string.

Next, a WorkflowApplicationInstance is created using the SqlWorkflowInstanceStore object that was configured and the Guid identifying which workflow instance needs to be updated. The DynamicUpdateMap is then read from file and created into memory. A WorkflowApplication object is then instantiated using a new MovieRentalProcess, representing the workflow definition that will be used. It is important to set this since the MovieRentalProcess workflow is reflected based on the referenced DLLs from the workflow project and when the workflow project was compiled, it was using an updated workflow snapshot during compilation.

The WorkflowApplication also takes a WorkflowIdentity object. You may have noticed that the workflow application host was creating workflow instances using v1MovieRentalProcess as the name of the workflow and version 1.0.0.0. This information was saved to the persistence store each time a workflow was persisted. Listing 6-27 shows that the workflow instance should now be updated to the workflow named v2MovieRentalProcess, and its version is now 2.0.0.0. This will now be reflected in the persistence store after the workflow is unloaded from memory. Once the workflow is loaded using the WF runtime and updated within the persisted store, it is simply unloaded again so it can later be loaded when a customer returns their movies.

Listing 6-27.  Updating a Persisted Workflow Instance to the New Version

private void cmdUpdateInstance_Click(object sender, RoutedEventArgs e)
        {
             
           SqlWorkflowInstanceStore instanceStore = new SqlWorkflowInstanceStore();
             
            instanceStore.ConnectionString =
                @"Data Source=(LocalDB)v11.0;Initial Catalog=WFPersist;Integrated Security=True";

            WorkflowApplicationInstance wfInstance =
                WorkflowApplication.GetInstance(new Guid(txtUpdateInstance.Text), instanceStore);

            DataContractSerializer s = new DataContractSerializer(typeof(DynamicUpdateMap));
            using (FileStream fs = File.Open(txtUpdateMapFile.Text, FileMode.Open))
            {
                updateMap = s.ReadObject(fs) as DynamicUpdateMap;
            }
             
            var wfApp =
                new WorkflowApplication(new MovieRentalProcess(),
                     new WorkflowIdentity
                     {
                         Name = "v2MovieRentalProcess",
                         Version = new Version(2, 0, 0, 0)
                     });

            IList<ActivityBlockingUpdate> act;
            if(wfInstance.CanApplyUpdate(updateMap, out act))
            {
                wfApp.Load(wfInstance, updateMap);
                wfApp.Unload();
            }
        }

Running the Correct Workflow Version

Earlier I mentioned that the workflow host was creating workflow instances under a different workflow name and version, as illustrated in Listing 6-18. If you simulated a customer returning movie and received the error in Figure 6-37, that means that the WF runtime is smart enough to check and make sure that the right version of the workflow is being run.

What’s happening here is that the workflow instance version has been updated as illustrated by looking at the values pertaining to versioning within the persistence store. To resume workflow instances that have been updated, the WF runtime in WF4.5 now has a safety mechanism that checks to see if you want to run an existing workflow instance against an updated workflow version or run it using the same workflow that was used to initiate the workflow. In the scenario for the customer returning a movie, Figure 6-17 needs to be updated so that version 2.0.0.0 is used for completing the workflow.

Once the update is made, Figure 6-38 illustrates that the workflow is now calling out the MoviesJustReleased activity as the workflow is debugged during execution. The workflow instance still has the record within the persistence store because we indicated to the WF runtime to keep completed workflow instance records in the persistence store.