Управление версиями рабочего процесса WF4 с использованием WorkflowServiceHost - PullRequest
3 голосов
/ 12 марта 2010

Относится к этому вопросу .

Я понимаю, как реализовать управление версиями рабочих процессов, используя WorkflowApplication. Если вы сохраните исходное определение XAML для более старых версий вашего рабочего процесса, вы можете загрузить их, используя правильный конструктор WorkflowApplication.

Как вы могли бы убедиться, что WorkflowServiceHost использует правильное определение рабочего процесса, когда вы хотите разместить свои рабочие процессы в IIS?

Существует конструктор WorkflowServiceHost, который можно использовать для загрузки определения рабочего процесса, но когда вы размещаете внутри IIS через файл XAMLX, вы сами не вызываете WorkflowServiceHost, это как-то обрабатывается IIS. Так как же убедиться, что для правильной версии моего рабочего процесса загружено правильное определение рабочего процесса?

1 Ответ

8 голосов
/ 14 марта 2010

Подход, использующий WorkflowServiceHost, не совсем другая форма, использующая WorkflowApplication. Основы хранения различных версий XAML (X) по-прежнему применяются. Таким образом, в случае WorkflowServiceHost вам нужно создать несколько WorkflowServiceHost, каждый из которых содержит свою версию XAMLX. Каждый с другой конечной точкой. Таким образом, в основном конечная точка en обращается и к сервису рабочего процесса, и к его версии.

Так как же получать сообщения от клиента на правильный WorkflowServiceHost? Здесь служба маршрутизации WCF - ваш друг. Вместо того чтобы клиент напрямую связывался с WorkflowServiceHost, он использует промежуточную службу маршрутизации WCF. Это, в свою очередь, проверяет сообщения и направляет их в WorkflowServiceHost, где размещается соответствующий файл XAMLX. Так как это узнать. Есть несколько способов сделать это. Например, поиск в базе данных с использованием идентификатора корреляции сообщений с запросами новых рабочих процессов, всегда идущими к последней версии. Самый простой способ - заставить службу рабочего процесса возвращать номер версии как часть первоначального запроса и сделать это обязательной частью каждого последующего запроса. Таким образом, служба маршрутизации WCF может выполнять всю свою работу только с отправкой данных сообщения.

Примером этого может быть:

  1. Клиент отправляет сообщение о запуске нового рабочего процесса с использованием идентификатора заказа 7 и получает обратно версию 3. Клиентское приложение использует URL-адрес httl: //localhost/MyWorkflow.xaml, а служба маршрутизации переадресует на httl: //localhost/MyWorkflow.v3.xamlx, который является последней версией.
  2. Следующее сообщение, отправляемое в рабочий процесс, содержит как orderid, так и версию 3. Клиентское приложение использует URL-адрес httl: //localhost/MyWorkflow.xaml, а служба маршрутизации пересылает в httl: //localhost/MyWorkflow.v3.xamlx, указанная версия.
  3. Клиентское приложение хочет отправить сообщение в старый рабочий процесс. Он использует orderid 2 и версию 1 (ответил, когда этот рабочий процесс был запущен). Клиентское приложение использует URL-адрес httl: //localhost/MyWorkflow.xaml, и служба маршрутизации переадресует на httl: //localhost/MyWorkflow.v1.xamlx, которая является заложенной версией.

Проверьте эти скринкасты для получения дополнительной информации о службе маршрутизации WCF.

...