February 2008 - Posts

Keeping WF Runtime Alive While Hosted In IIS

There are a many benefits for hosting a Workflow Runtime through Windows Communication Foundation services in IIS. Most importantly, WCF services can leverage the functionality that IIS already does, for instance health management. IIS has the ability to recycle worker processes that enable it to run smoothly, but this can also affect long running workflows. There are some ways of getting around this, depending on how long a workflow can run, because IIS has a management tool for when it's processes get recycled. One way to do this is to recycle processes at certain times when you know client activity is going to be next to none, however if workflows are scheduled to run longer than a 24 hour period, you will still have problems.

Here is where the problem lies, when IIS recycles the runtime is stopped and not restarted, and since the persistence service is running within the runtime the polling stops for looking for expired workflow instance timers. The only hope you have is for a client to hit IIS and restart the Workflow Runtime, but for weekends and holidays, this can become a problem unless you can control a client request. There are many ways to manage the Workflow Runtime, but I am going to show you one that takes very little code. The ingredients' consist of a scripting file and Windows Task Scheduler. Here is a great link for understanding how the Task Scheduler works.

Follow these instructions for creating the script file and running it.

  1. Create a new notepad file and rename the extension from .txt to .vbs
  2. Add the following code to the file. All this code does is open Internet Explorer(IE) and call the WCF service hosted in IIS. Once the service is called IE is closed.
    Set objIE = CreateObject
    ("InternetExplorer.Application") objIE.Navigate("http://ServerAddress/Folder/ServiceName.svc")
    Do Until objIE.ReadyState = 4
    If (Wscript.Version > 5) Then
    Wscript.Sleep 100
    End If
    Loop
    Set objIE = Nothing
  3. Now that the script file is completed it can be scheduled to execute by following the instructions for setting up a task within the Task Scheduler

So getting back to recycling IIS, once you set the schedule of when IIS needs to be recycled (usually when there is no traffic), the script file can be scheduled through the Task Scheduler to run maybe a couple of minutes(30) after IIS is recycled. The Workflow Runtime is now started back up after the recycle.

Jax Architects SIG Meets February 26, 2007

If your job as a Software Architect is to research and exploit technology to help achieve business results - then you need to take a look at what has just been released in Visual Studio 2008 and the .NET Framework 3.5. Microsoft's Jeff Barnes, will be presenting on some of the many new features you need to understand and explore to be able to fully leverage these new capabilities within VS2008.

Register for this event here!

Presenting At SqlSaturday This Saturday

This Saturday I am loading up the kids and the wife and headed to SQLSaturday, in Tampa, Florida. I am speaking on "Persisting and Tracking Workflows Using SqlServer". Yeah I know... you might be wondering how WF fits into a SQL event but if you talk to DBA's like I "occasionally" do, you will quickly find out that most do not know how to deal with these runtime services, while working with applications powered with WF.

This event is free so please come by and check it out if you are in the Tampa, Fl. area!

The object with ID ### implements the IObjectReference interface

Tired of getting an error similar to "The object with ID implements the IObjectReference interface...", then try having different environments for testing workflows and another for developing them. This error is prevalent when you persist data through a workflow and then make some minor changes to it (Let's say when making a fix to a bug:) then publishing out a new workflow. The persisted data then becomes stale. It is important, for all IT development to have different environments, that way the data is separated. Once changes are made to an actual workflow in your development environment which persists data, that data should be removed, so the whole workflow can be tested again.

I was able to find a post within the forums which also may be helpful.