Огляд робочого потоку Windows Workflow. Частина 5, Різне, Програмування, статті

Читати частина 4

Служба сталості


Коли робочий потік виконується, він може досягти стану очікування – таке може трапитися, коли виполняетсядействіе очікування або коли ви чекаєте зовнішнього введення в дію прослуховування. В цей момент кажуть, що робочий потік простоює (Idle), і тому є кандидатом на збереження.


Припустимо, що ви розпочали виконання 1000 робочих потоків на сервері, і кожен з цієї тисячі потоків потрапив в стан простою. В цей момент немає необхідності підтримувати дані всіх цих примірників в пам’яті, так що в ідеалі було б мати можливість вивантажити робочий потік і звільнити ресурси для інших завдань. Служба сталості (persistence service) призначена спеціально для цього.


Коли робочий потік досягає стану простою, виконуюча середу перевіряє існування служби, успадкованої від класу WorkflowPersistenceService. Якщо така служба існує, їй передається примірник робочого потоку, і вона потім може зафіксувати поточний стан робочого потоку і зберегти його в постійному сховище. Ви можете зберегти стан робочого потоку на диску або у файлі або в базі даних, такий як SQL Server.


Бібліотеки робочих потоків містять реалізацію служби сталості, яка зберігає дані в базі SQL Server – це SqlWorkflowPersistenceService. Для того щоб використовувати згадану службу, вам потрібно запустити два сценарії на примірнику SQL Server: один з них конструює схему, а інший створює збережені процедури, які використовуються службою сталості. Ці сценарії за замовчуванням розташовані в каталозі C:WindowsMicrosoft.NETFrameworkv3.0Windows Workflow FoundationSQLEN.


Сценарії для виконання в базі даних називаються SqlPersistenceService_ Schema.sql і SqlPersistenceService_Logic.sql. Вони повинні запускатися по порядку, спочатку – файл схеми, потім – файл логіки. Схема для служби сталості SQL містить дві таблиці: InstanceState і CompletedScope; це, по суті, закриті таблиці, які не призначені для використання поза службою сталості SQL.


Коли робочий потік простоює, його стан серіалізуются допомогою бінарної сериализации, і ці дані містяться в таблицю InstanceState. Коли робочий потік потім повторно активізується, його стан зчитується з рядка таблиці і використовується для відтворення примірника робочого потоку. Рядок таблиці позначається ідентифікатором екземпляра робочого потоку і видаляється з бази даних по завершенні цього екземпляра.


Служба сталості SQL може бути використана декількома виконуючими середовищами одночасно – вона реалізує механізм блокування, так що робочий потік доступний тільки одному примірнику виконуючого середовища за раз. Коли є декілька серверів, і всі вони виконують робочі потоки, які взаємодіють з одним і тим же постійним сховищем, це блокує поведінка стає несуттєвим.


Щоб побачити, що саме додається в постійне сховище, Сконструюйте новий проект робочого потоку і додайте до виконуючою середовищі примірник SqlWorkflowPersistenceService. Нижче наведено приклад застосування декларативного коду:





using(WorkflowRuntime workflowRuntime = new WorkflowRuntime())
{
workflowRuntime.AddService(
new SqlWorkflowPersistenceService(conn, true, new TimeSpan(1,0,0),
new TimeSpan(0,10,0)));
/ / Тут виконується робочий потік …
}

Якщо ви конструюєте робочий потік, що містить DelayActivity, і встановлюєте величину затримки близько 10 секунд, то потім ви можете побачити його дані в таблиці InstanceState. Параметри, що передаються конструктору служби сталості, перераховані в табл. 41.3.
























Параметр Опис Значення за замовчуванням
ConnectionString Рядок підключення до бази даних, яка використовується службою сталості Немає
UnloadOnIdle Визначає, чи буде робочий потік вивантажений під час простою. Завжди слід встановлювати в true, інакше ніякого постійного зберігання не відбудеться False
InstanceOwnershipDuration Визначає тривалість періоду часу, коли екземпляр робочого потоку буде належати виконуючою системі, завантаживши цей потік Немає
LoadingInterval Інтервал, який використовується для оновлення в базі даних записів постійного зберігання 2 хвилини
Таблиця 41.3. Параметри, передані конструктору служби сталості

Служба відстеження


Під час виконання робочого потоку може виникнути необхідність записати, які дії вже були виконані, і в разі складного дії на зразок IfElseActivity або ListenActivity – яка саме гілка виконується. Ці дані можуть застосовуватися як протокол аудиту для екземпляра робочого потоку, який пізніше можна переглянути на предмет того, які дії були виконані і які дані використовувалися в робочому потоці. Для такого роду протоколювання може застосовуватися служба відстеження (tracking service), і при необхідності її можна налаштувати на фіксацію якомога більшої або як можна меншого обсягу інформації про виконувані робочому потоці.


Як прийнято в WF, служба відстеження реалізована у вигляді абстрактного базового класу на ім’я TrackingService, так що дуже просто замінити стандартну реалізацію відстеження вашої власної. Є одна конкретна реалізація служби відстеження, доступна в збірках Windows Workflow – це SqlTrackingService.


Щоб записати дані про стан робочого потоку, необхідно визначити TrackingProfile. Цей об’єкт визначає, які саме події мають бути записані, так що ви можете, наприклад, фіксувати тільки старт і фініш робочого потоку, пропускаючи всі інші дані, що надходять від виконується екземпляра. Більш типовий випадок – протоколювання всіх подій робочого потоку і кожної дії в ньому, що дозволяє зафіксувати повну картину профілю виконання робочого потоку.


Коли робочий потік планується механізмом виконує системи, цей механізм перевіряє існування служби відстеження робочого потоку. Якщо така знайдена, то у неї запитується профіль відстеження для виконується робочого потоку, і потім він використовується для запису роботи потоку і даних про його дії. На додаток ви можете визначити для користувача дані відстеження і зберегти їх усередині сховища для таких даних, причому без необхідності зміни схеми.


Клас профілю відстеження показаний нижче на рис. 41.19. Цей клас містить властивості-колекції для точок відстеження дій, користувача і робочого потоку в цілому. Точка відстеження – це об’єкт (на зразок WorkflowTrackPoint), який зазвичай визначає місце відповідності (Mach location) і деякі додаткові дані для запису


Рис. 41.19. Клас профілю відстеження


при попаданні в цю точку відстеження. Місце відповідності визначає, коли точка відстеження дійсна, тому, наприклад, ви можете визначити WorkflowTrackPoint, в якій буде виконуватися запис деяких даних при створенні робочого потоку, а іншу – для запису тих же даних при завершенні робочого потоку.


Після того як дані записані, може виявитися необхідним відобразити шлях виконання робочого потоку, наприклад, як показано на рис. 41.20. Тут можна бачити виконаний робочий потік, причому кожне його запущене дію позначено спеціальним значком – пташкою. Дані для цього відображення читаються зі сховища інформації про відстеження даного екземпляра робочого потоку.


Для того щоб прочитати дані, збережені за допомогою SqlTrackingService, ви можете безпосередньо надіслати запити базі даних SQL, проте Microsoft пропонує для цього клас SqlTrackingQuery, визначений у просторі імен System.Workflow. Runtime.Tracking. У наведеному нижче прикладі коду показано, як отримати список робочих потоків, які відстежувалися між двома датами:





public IList<SqlTrackingWorkflowInstance> GetWorkflows
(DateTime startDate, DateTime endDate, string connectionString)
{
SqlTrackingQuery query = new SqlTrackingQuery (connectionString);
SqlTrackingQueryOptions queryOptions = new SqlTrackingQueryOptions();
query.StatusMinDateTime = startDate;
query.StatusMaxDateTime = endDate;
return (query.GetWorkflows (queryOptions));
}

Тут використовується клас SqlTrackingQueryOptions, що визначає параметри запиту. Ви можете визначити інші властивості цього класу для додаткового обмеження вибірки робочих потоків.


На рис. 41.20 видно, що всі дії потоку Visual Studio були виконані – так може бути не завжди, якщо робочий потік все ще виконується, або якщо деякі рішення, прийняті всередині потоку, призвели до вибору різних шляхів виконання. Дані відстеження містять такі подробиці, як те, які дії були виконані, і ця інформація може бути порівняна із загальним списком дій, щоб згенерувати картинку на зразок показаної на рис. 41.20. Можна також отримати дані з робочого потоку під час виконання, які можуть бути використані для формування протоколу аудиту виконання цього робочого потоку.


Рис. 41.20. Шлях виконання робочого потоку

                                                                                                                                                                                                                     Читати частина 6

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*