Workflow с сообщениями в MVC

Просьба одобрить приходит в виде сообщения на автобусе (rapidMQ)
Абонент читает сообщение и начинает рабочий процесс, если требуется
Документооборот состояние машины рабочий который начинается как Unassigned
Unassigned элемент добавляется в очередь рабочего элемента
Пользователь назначает элемент для себя
Workflo ш продолжается -> переходит в назначенный
Пользователю будет предложено утвердить
Пользователь утверждает/отклоняет
Workflow продолжается -> Пункт обновляется и переходы Одобрено/Отклонено. Сообщения, отправленные для дальнейшей обработки, могут произойти.

Я хочу использовать quickMQ как свою шину обмена сообщениями, я также буду использовать web api и wcf. Я хочу, чтобы все контролировалось через шину сообщений, поэтому утверждение/отклонение/назначение пользователя приведет к сообщению на шине, рабочий процесс которого должен поднять и действовать.

Возможно ли использовать основание рабочего процесса с интерфейсом mvc и ответить на шину сообщений? то есть рабочий процесс должен размещать сообщения на шине и считывать сообщение с шины и перехода соответственно?

Просим вас указать мне в правильном направлении? Я открыт для использования другого решения для документооборота, если это будет лучше соответствовать моим потребностям.

источник

2016-12-22 newbie_86

Как часто вы ожидаете изменения бизнес-правил рабочего процесса? Если бизнес-аналитики могут изменить рабочий процесс, то WF будет вариантом, чтобы вы могли предоставить пользовательский интерфейс, чтобы позволить им изменять его каждый раз (много работы, но возможно). – ajawad987

Если разработчики будут поддерживать аспекты бизнес-правил вашего процесса, возможно, лучше не реализовывать WF и просто иметь стороннее действие со стороны окна элементов в очередях. Конечно, это означает, что вам нужно будет поддерживать состояние продолжительного процесса самостоятельно по-своему. – ajawad987

@ ajawad987 разработчики будут поддерживать его, не обязательно для других пользователей. Я ищу решение для рабочего процесса, у меня есть несколько сложных процессов –

Вам сначала нужно решить вашу ситуацию с ходом рабочего процесса. Возможно, вы сможете принять участие в mvc, но вам это не понравится. Обычно хост - это служба Windows, отображающая конечную точку WCF для точки входа в рабочий процесс. После выполнения хостинга вы можете обращаться к сообщениям и шине.

источник

2016-12-22 23:39:03

Я управлял рабочими процессами из очередей сообщений.
Основная концепция заключается в том, чтобы рабочий процесс размещался как служба и любые другие приложения или веб-сайты как полностью отдельные решения. Затем все они общаются через очереди.

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

При отправке в очереди я получаю Workflow Activities для вызова класса очереди в решении рабочего процесса. Я добавляю класс обработки очереди в рабочий процесс, передавая его в рабочий процесс во входных параметрах при запуске рабочего процесса.

источник

2016-12-23 10:51:59 Richard210363

Лучше изолировать рабочий процесс от бизнес-логики. механизм документооборота выставляет API снаружи и поддерживает узел задачи и состояние.
Если у вас есть работоспособный механизм документооборота, вы можете сделать прокси-слой для перевода сообщения в API-интерфейс рабочего процесса.
Когда клиент получил сообщение от MQ, переадресуйте его на уровень прокси и переведите сообщение на вызов API рабочего процесса.В этом случае сообщение является другой формой вызова API.

источник

2017-01-10 10:41:11

ответ

Смежные вопросы