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:
-
Otwieramy SQL Server Management Studio. W okienku wykonywania skryptów wpisujemy zapytanie generujące pustą bazę danych:
CREATE DATABASE WorkflowPersistenceStore
-
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:
- 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>
- 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>
- Środowisko uruchomieniowe będzie skonfigurowane automatycznie po przekazaniu nazwy sekcji:
WorkflowRuntime runtime = new WorkflowRuntime("PersistenceRuntimeExample");
- 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ę.