Czasami istnieje potrzeba zapisania stanu aktualnie wykonywanego workflow’a. Domyślnie wszelkie dane zapisywane są w pamięci ulotnej. W przypadku awarii komputera odtworzenie ostatnio wykonywanego stanu jest niemożliwe. Nie jest to problem w przypadku gdy wykonanie workflow’a zajmuje tylko kilka sekund. W sytuacji w której zakończenie workflow’a może potrwać kilka godzin lub tygodni, niezbędne jest zapisywanie informacji w pamięci trwałej np. w bazie danych SQL Server.

WWF dostarcza specjalną usługę, SqlWorkflowPersistenceService, która większość brudnej roboty wykona za nas. Dzięki usłudze nie musimy kłopotać się z ręcznym projektowaniem struktury bazy danych i zapisem stanu. Wszystko wykona za nas gotowa usługa. Naszym zadaniem jest jedynie odpalenie skryptów generujących bazę danych oraz podpięcie usługi do środowiska uruchomieniowego.

Pierwszym etapem jest zatem utworzenie bazy danych:

1. Otwieramy SQL Server Management Studio. W okienku wykonywania skryptów wpisujemy zapytanie generujące pustą bazę danych:

   CREATE DATABASE WorkflowPersistenceStore
   

2. Następnie musimy stworzyć niezbędne tabele, procedury oraz schema. Wystarczy odpalić skrypt SqlPersistenceService_Logic.sql oraz SqlPersistenceService_Schema.sql. Oba znajdują się w folderze “%WINDIR%\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\<language>\SqlPersistence_Schema”. W zależności od konfiguracji systemowej może to być np. ścieżka “C:\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\en”.

Kolejnym krokiem jest konfiguracja aplikacji:

1. Otwieramy plik app.config  lub web.config i wstawiamy nową sekcję dla workflow:

   <configSections>
       <section
        name="PersistenceRuntimeExample"
         type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, 
               System.Workflow.Runtime, Version=3.0.00000.0, 
              Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    </configSections>

2. Dodajemy usługę persystencji oraz parametr zawierający connectionstring. Plik konfiguracyjny powinien zatem zawierać poniższy kod:

   <?xmlversion="1.0"encoding="utf-8" ?>
   <configuration>
    
    <configSections>
       <section
        name="PersistenceRuntimeExample"
         type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, 
               System.Workflow.Runtime, Version=3.0.00000.0, 
              Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    </configSections>
    
    <PersistenceRuntimeExample>    
       <CommonParameters>
         <add name="ConnectionString"value="Initial Catalog=WorkflowPersistenceStore;Data Source=localhost;Integrated Security=SSPI;" />
       </CommonParameters>
       
       <Services>
         <add
           type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService,
                 System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral,
                 PublicKeyToken=31bf3856ad364e35"
                 UnloadOnIdle="true"/>
       </Services>
    </PersistenceRuntimeExample>
    
   </configuration>

3. Środowisko uruchomieniowe będzie skonfigurowane automatycznie po przekazaniu nazwy sekcji:

   WorkflowRuntime runtime = new WorkflowRuntime("PersistenceRuntimeExample");

4. Od tej chwili stan workflow’a jest zapisywany w bazie danych SQL Server.

Alternatywnym ale mniej elastycznym podejściem jest dołączenie usługi persystencji za pomocą kodu:

WorkflowRuntime runtime = new WorkflowRuntime();
SqlWorkflowPersistenceService persistenceService = new SqlWorkflowPersistenceService("Initial Catalog=WorkflowPersistenceStore;Data Source=localhost;Integrated Security=SSPI;");
runtime.AddService(persistenceService);

Odradzam jednak powyższy sposób. Dołączenie usługi za pomocą pliku konfiguracyjnego pozwala na modyfikacje connectionstring’a bez potrzeby ponownej kompilacji co stanowi ogromną zaletę.