Navigation

Search

Categories

On this page

Restarting Persisted Workflow Instances in Windows Workflow Foundation
'Sink'ing with the Windows SMTP Service - Updated
Windows Workflow Foundation Configuration
v.01

Archive

Blogroll

Disclaimer
None - these are my opinions and they're also my employer's!

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 14
This Year: 0
This Month: 0
This Week: 0
Comments: 15

Sign In

 Monday, November 27, 2006
Tuesday, November 28, 2006 12:12:41 AM (Mountain Standard Time, UTC-07:00) ( )

Well, it's kind of a hack but it works.  If your workflow runtime host goes away for whatever reason, whether it be ASP.NET, a Forms or Console application, or a Windows service you can peer into the persistence database using the LoadExpiredTimerWorkflowIds method on the SqlWorkflowPersistenceService instance associated with your runtime.  The code snippet below gets the persistence service instance from the runtime and resumes the processing on each workflow.  This allows the timer events to fire which in turn will cause your workflows to flow once more.

ReadOnlyCollection<SqlWorkflowPersistenceService> sqlSvc = 
   _workflowRuntime.GetAllServices<SqlWorkflowPersistenceService>();
 
IList<Guid> readyWorkflows = sqlSvc[0].LoadExpiredTimerWorkflowIds();
foreach (Guid wfGuid in readyWorkflows)
{
   _workflowRuntime.GetWorkflow(wfGuid).Resume();
}

I haven't fully tested it in a practical sense where I've got many runtimes sharing a persistence repository but I'll know more as the week progresses.

Matt Milner posted in the MSDN Workflow Foundation forum that the LoadIntervalSeconds setting on the SqlWorkflowPersistenceService will automatically load any persisted workflows based on that interval.  So the only reason to directly resume the workflows is if you feel that delay would be a problem for some reason.  Thanks, Matt.

Comments [1] | | # 
 Saturday, November 25, 2006
Saturday, November 25, 2006 11:33:20 PM (Mountain Standard Time, UTC-07:00) ( )

I needed to get to SMTP messages in the most efficient way possible without the overhead of POP3, etc.  When I searched around I found a great Microsoft article on how to create managed event sinks using some pre-fabbed event interop and wrapper code.  For the most part the instructions are self-explanatory but I did run into some issues with the samples.

The first sample describes building a sink that basically does nothing but access the parameters passed through the wireup interface.  The article walks you through setting the project build property Register for COM interop which basically runs RegAsm behind the scenes.  Well, if you forget to put the ComVisible attribute on your class you won't actually register any types which of course means you can't register with the SMTP service to be called via COM.  Running RegAsm directly will alert you to this fact, so I recommend not setting the property until you know your COM goo is in place correctly.

   [ComVisible(true), Guid("B3AEF136-3064-429c-8D61-4D8AA8EE8B29")]
   public class EventSink : ISmtpInCommandSink, IEventIsCacheable
   {

A key piece to making all this work is the registration with the SMTP service of your new COM type.  This is accomplished using the handy smtpreg.vbs script.  The /enum option is great for displaying all currently registered sinks.  Your assembly must be RegAsm'd first which, of course, requires strong naming.

The second sample has a more practical use in that it will actually terminate any SMTP session based on the EHLO request being received.  There is a code typo, though:

   if (null != pCcontext OOPS!)
   {
       Marshal.ReleaseComObject(pContext);
   }

In the ShieldsUp sample they also implement the IEventIsCacheable interface method IsCacheable().  This implementation allows the SMTP Service Extension Objects (SEO) process to avoid tearing down and recreating your component thus avoiding the overhead of CoCreateInstance() on each call.

Once I worked through the samples and got my feet wet creating and registering the SEO components, I was able to build what I needed pretty quickly.  In essence, my sink needed to intercept the messages that were inbound to my SMTP server and send them to a transactional MSMQ queue.  I found some help related to handling incoming messages using IMailTransportSubmission here

I also found some System.Messaging MSMQ optimization tips here that I followed since this process will need to be able to handle thousands of messages.  The event sink wrappers exposed a CopyContentToStream() method on the Message object which worked well with the serialization optimization strategies outlined in the document.  I basically took the message and after verifying that it isn't too long (over 1,000,000 bytes) sent the entire contents to a queue as you can see below: 

using System;
using System.Diagnostics;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
using System.IO;
using MSMQ = System.Messaging;
using Mail = System.Net.Mail;
using Microsoft.Exchange.Transport.EventInterop;
using Microsoft.Exchange.Transport.EventWrappers;
 
namespace SMTPEventSink
{
   [ComVisible(true), Guid("AD1F3BB9-22E9-4207-BBAC-F767DB32FA0D")]
   public class QueueMailMessage : IMailTransportSubmission, IEventIsCacheable
   {
      #region IMailTransportSubmission Members
      void IMailTransportSubmission.OnMessageSubmission(
         MailMsg pIMailMsg, 
         IMailTransportNotify pINotify, 
         IntPtr pvNotifyContext)
      {
         MSMQ.MessageQueueTransaction msmqTran = new MSMQ.MessageQueueTransaction();
         try
         {
            Message msg = new Message(pIMailMsg);
            if (msg.GetContentSize() < 1000000)
            {
               MemoryStream contentStream = new MemoryStream(Convert.ToInt32(msg.GetContentSize()));
               msg.CopyContentToStream(contentStream);
               MSMQ.MessageQueue msmqQueue = 
                  new MSMQ.MessageQueue(
                     @".\private$\SMTPInBoundMessages", 
                     System.Messaging.QueueAccessMode.Send);
               msmqTran.Begin();
               using (MSMQ.Message msmqMsg = new MSMQ.Message())
               {
                  msmqMsg.BodyStream = contentStream;
                  msmqMsg.Label = msg.Rfc822MsgId;
                  msmqMsg.Recoverable = false;
                  msmqQueue.Send(msmqMsg, msmqTran);
               }
               msmqTran.Commit();
 
               // abort message processing so message is intercepted
               msg.MessageStatus = Message.MessageStatusEnum.AbortDelivery;
               throw new COMException("Abort delivery");
            }
            else
            {
               LogEvent(string.Format(
                  "QueueMailMessage - message too long ({0} bytes)", 
                  msg.GetContentSize()));
            }
         }
         catch (COMException)
         {
            // ignore - we want this to bubble up
         }
         catch (Exception ex)
         {
            msmqTran.Abort();
            LogEvent(ex.ToString());
         }
         finally
         {
            if (null != pIMailMsg)
            {
               Marshal.ReleaseComObject(pIMailMsg);
            }
            if (null != pINotify)
            {
               Marshal.ReleaseComObject(pINotify);
            }
            if (null != pvNotifyContext)
            {
               Marshal.ReleaseComObject(pvNotifyContext);
            }
         }
      }
      #endregion
 
      #region IEventIsCacheable Members
      void IEventIsCacheable.IsCacheable()
      {
         // returns S_OK by default
      }
      #endregion
 
      private void LogEvent(string message)
      {
         if (!EventLog.SourceExists("SMTPEventSink"))
         {
            EventLog.CreateEventSource("SMTPEventSink", "Application");
         }
         EventLog.WriteEntry("SMTPEventSink", message);
      }
   }
}

Another gotcha that I experienced while debugging and building this managed SMTP event sink is that once the SMTP service has accessed your assembly file you will have to do IISReset to get it freed again.  I tried removing the binding using smtpreg.vbs and stopping the SMTP service in the IIS management MMC but to no avail.  Guess that's a small price to pay for such close to the edge control.

I used the following command lines to add and remove the binding for this new event sink with SMTP SEO:

cscript smtpreg.vbs /add 1 OnTransportSubmission SMTP2MSMQ SMTPEventSink.QueueMailMessage "mail from=*"

cscript smtpreg.vbs /remove 1 OnTransportSubmission SMTP2MSMQ

Overall, I was impressed with how easy it was to build this event sink and found the documentation pretty straightforward and reliable.  Now all I have to do is move everything to the appropriate environment and harden it a bit.

Comments [1] | | # 
 Wednesday, November 22, 2006
Wednesday, November 22, 2006 10:54:04 PM (Mountain Standard Time, UTC-07:00) ( )
So I've flattened my forehead trying to get the configuration section for WF set the way I wanted.  The trick is to learn what the actual named parameters each service is expecting and then adding those as attributes to the <Services><add> element.

I'm sure others have already forged a trail here but I couldn't find any significant information about using the application config file to drive WF runtime configuration settings.  The MSDN documentation give some hints but unfortunately there isn't nearly as much detail in the documentation for Workflow Foundation as there is for Windows Communication Foundation.

The best place I've found to see what named parameters are available to a service is to Reflector the workflow runtime assembly (System.Workflow.Runtime.dll ) which is located in the reference assemblies folder "\Program Files\Reference Assemblies\Microsoft\Framework\v3.0".  I was looking for the settings I could configure for the SqlWorkflowPersistenceService so I drilled down to the constructor that accepted a NameValueCollection.  Then I could see in the disassembly what settings would be read (screenshot below) in that constructor.

Click to enlarge

Using the names as indicated in the constructor I was able to add attributes to the element configuring the SqlWorkflowPersistenceService.  The key one I was trying to figure out how to add was the OwnershipTimeoutSeconds which tells the service how to behave when locking instances in a common persistence database.

The configuration that I'm starting with is below.  Eventually I'll be changing to a different palette of services but this meets the needs for now.

   <configSections>
      <section name="WorkflowRuntime" 
           type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, 
           System.Workflow.Runtime, Version=3.0.00000.0, 
           Culture=neutral, 
           PublicKeyToken=31bf3856ad364e35" />
   </configSections>
   <WorkflowRuntime Name="WorkflowMultiHost">
      <CommonParameters>
         <add name="ConnectionString" 
            value="Initial Catalog=WorkflowStore;Data Source=(local);Integrated Security=SSPI;" />
         <add name="EnableRetries" 
            value="True" />
      </CommonParameters>
      <Services>
         <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, 
            System.Workflow.Runtime, 
            Version=3.0.00000.0, 
            Culture=neutral, 
            PublicKeyToken=31bf3856ad364e35" />
         <add type="System.Workflow.Runtime.Hosting.SharedConnectionWorkflowCommitWorkBatchService,
            System.Workflow.Runtime, 
            Version=3.0.00000.0, 
            Culture=neutral, 
            PublicKeyToken=31bf3856ad364e35" />
         <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
            System.Workflow.Runtime, 
            Version=3.0.00000.0, 
            Culture=neutral, 
            PublicKeyToken=31bf3856ad364e35" 
            UnloadOnIdle="True"
            LoadIntervalSeconds="5" 
            OwnershipTimeoutSeconds="90" />
         <add type="System.Workflow.Runtime.Tracking.SqlTrackingService, 
            System.Workflow.Runtime, 
            Version=3.0.00000.0, 
            Culture=neutral, 
            PublicKeyToken=31bf3856ad364e35" />
      </Services>
   </WorkflowRuntime>

Notice that I'm using the SharedConnectionWorkflowCommitWorkBatchService which allows the storage of persistence and tracking data to the same database.  This allows non-DTC transactions which of course will perform better.  I'll know more as I begin load testing and I'll be doing a post on what I find.  Some folks at MS did a great writeup on various WF performance issues here.

Go with the flow...

Comments [0] | | # 
Wednesday, November 22, 2006 10:52:03 PM (Mountain Standard Time, UTC-07:00) ( )

Well, I decided I needed to get out there with my rambling thoughts and misguided attempts at solving the world's problems with the limited technical skills I possess.  Welcome to the journey...

Comments [1] | | #