Почему рабочие процессы Windows не сохраняются после перезапуска сервера?

Question

У меня есть простой рабочий процесс Windows Workflow 4.5 (снимок экрана в конце сообщения), размещенный как служба WCF в IIS. Я настроил сохранение, используя хранилище SQL Server, предоставленное Microsoft.

Рабочий процесс принимает идентификатор документа и логическое значение, указывающее, нужно ли ему приостанавливать и ждать активности человека (обзор человека). Если рабочий процесс должен ждать, он имеет операцию Receive(), которая коррелирует с идентификатором документа и паузами (что создает закладку за кулисами). Иначе он подходит к завершению и маршрутизирует документ.

Все работает отлично до тех пор, пока мы не перезагружаем сервер или не делаем что-то вроде утилизации пула приложений для этой службы. Поскольку я понимаю упорство, рабочий процесс должен сохраняться после настраиваемого периода «Время ожидания», например, встреченного, КОГДА ОЖИДАЕТСЯ ПОЛУЧИТЬ СООБЩЕНИЕ ... Я установил это значение на очень агрессивную секунду.

Однако в случаях, которые вы ожидаете в реальном мире для долговременного рабочего процесса, если мы имитируем сбои сервера, перезагружая или перерабатывая пул приложений, рабочие процессы, ожидающие с Receive(), никогда не отвечают. Предполагается ли, что мы делаем что-то особенное, чтобы «перезагрузить» рабочий процесс после восстановления сервера? Не коррелирует ли корреляция между рабочими процессами, которые сохраняются?

прием(), который никогда не срабатывает после перезагрузки сервера будет выделена желтым цветом в рабочем процессе ниже:

Answer 1

Я думаю, что я нашел ответ на этот.

Когда вы создаете приложение Worflow для WCF в Visual Studio 2013, оно запускает вас с помощью приложения-шаблона, которое содержит предварительно подключенные действия Receive() и Send(). Именно это получает, с CanCreateInstance установлено значение true, что позволяет создавать рабочий процесс при получении сообщения WCF.

Проблема заключается в том, что прием и передача, связанные друг с другом, считаются операцией, которая должна быть выполнена до того, как рабочий процесс может простаивать. То есть, хотя у меня есть второй вызов Receive() в рабочем процессе, и этот прием действительно создает закладку и приводит к тому, что рабочий процесс ожидает ввода, он не может фактически вступить в состояние ожидания. Непрерывный означает, что рабочий процесс не может быть сохранен.

Вы можете видеть, как сообщение «Отправить»() обернуто в конце моментального снимка рабочего процесса, который я загрузил. Я взял этот Отправить, рабочий процесс теперь ждет, сохраняется, коррелирует и возобновляется отлично.

В ретроспективе, я считаю, что ошибался, думая, что предварительно подключенный Send был там, чтобы предоставить некоторую информацию о WORKFLOW, когда на самом деле имеет смысл думать об этом как ответ на сообщение, которое KICKED OFF workflow- -и больше ничего. Вставив логику рабочего процесса между первоначальной функцией Receive() и спаренной отправкой(), предоставленной в качестве шаблона Visual Studio, я непреднамеренно предотвращаю работу рабочего процесса, потому что прием/отправка представляется рассмотренной атомной операцией - по крайней мере, как холостой/упорный.