Служба постоянства
Когда рабочий поток выполняется, он может достичь состояния ожидания - такое может случиться, когда выполняетсядействие ожидания или когда вы ждете внешнего ввода в действии прослушивания. В этот момент говорят, что рабочий поток простаивает (idle), и потому является кандидатом на сохранение.
Предположим, что вы начали выполнение 1000 рабочих потоков на сервере, и каждый из этой тысячи потоков попал в состояние простоя. В этот момент нет необходимости поддерживать данные всех этих экземпляров в памяти, так что в идеале было бы иметь возможность выгрузить рабочий поток и освободить ресурсы для других задач. Служба постоянства (persistence service) предназначена специально для этого.
Когда рабочий поток достигает состояния простоя, исполняющая среда проверяет существование службы, унаследованной от класса WorkflowPersistenceService. Если такая служба существует, ей передается экземпляр рабочего потока, и она затем может зафиксировать текущее состояние рабочего потока и сохранить его в постоянном хранилище. Вы можете сохранить состояние рабочего потока на диске или в файле либо в базе данных, такой как SQL Server.
Библиотеки рабочих потоков содержат реализацию службы постоянства, которая сохраняет данные в базе SQL Server - это SqlWorkflowPersistenceService. Для того чтобы использовать упомянутую службу, вам нужно запустить два сценария на экземпляре SQL Server: один из них конструирует схему, а другой создает хранимые процедуры, используемые службой постоянства. Эти сценарии по умолчанию расположены в каталоге C:\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\EN.
Сценарии для выполнения в базе данных называются 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 минуты |
Служба отслеживания
Во время выполнения рабочего потока может возникнуть необходимость записать, какие действия уже были выполнены, и в случае составного действия наподобие 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. Путь выполнения рабочего потока