Для рабочего процесса или не для рабочего процесса?

Я отвечаю за команду разработчиков, которая вот-вот начнет разрабатывать систему страховки с легкими весами. Система включает в себя множество ручных задач и бизнес-процессов, и мы рассматриваем использование Windows Workflow (.NET 4.0).

Пример бизнес-домена выглядит следующим образом: Владелец политики звонит в контакт-центр для подачи иска. Это "событие" запускает две вспомогательные задачи, которые вручную выполняются параллельно и могут занять длительное время;

Проверка клиента на мошенничество. Ручной процесс, посредством которого оператор звонит в различные кредитные компании, чтобы проверить и оценить потенциал мошеннического клиента. Отсюда подзадача может вводить несколько под-статусов (проверка в процессе, ошибка проверки ссылок, проверка пройденного задания и т.д.)
Отправлять товар в центр ремонта. Ручной процесс, при котором предмет, за который держатель политики подал иск, отправляется на ремонт ремонтного центра. Отсюда подзадача может вводить ряд под-статусов (ожидание ремонта, выполнения, ремонта, отправки и т.д.). Требование может действовать только после того, как статус каждой подзадачи достиг предопределенного статуса (на основе бизнес-правил).

На первый взгляд кажется, что Workflow действительно лучший выбор технологий; однако у меня есть несколько проблем с использованием WF 4.0.

Набор навыков - Посмотрите на средний набор навыков разработчика. Я не вижу многих разработчиков, которые понимают или знают Workflow.
Поддержание работоспособности. В сообществах мало поддержки для проектов WF 4.0, и в сочетании с отсутствием набора навыков возникают проблемы, связанные с ремонтопригодностью.
Барьер для входа - я чувствую, что Windows Workflow имеет крутую кривую обучения, и ее не всегда легко найти.
Новый продукт. Поскольку Workflow полностью переписан для .NET 4.0, я вижу продукт как продукт первого поколения и может не иметь необходимой стабильности.
Репутация - Прошлые версии Workflow не были хорошо восприняты, считались сложными для разработки и привели к плохому восприятию бизнеса.

Итак, мой вопрос в том, должен ли мы использовать Windows Workflow (WF) 4.0 для этой ситуации или есть альтернативная технология (IE, Simple State Machine, и т.д.) или даже лучший механизм рабочего процесса для использования?

Ответ 1

Я сделал несколько проектов WF4, поэтому давайте посмотрим, могу ли я добавить любую полезную информацию к другим ответам.

Из описания вашей бизнес-проблемы кажется, что WF4 - хорошее совпадение, поэтому проблем нет.

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

В большинстве случаев использование служб рабочего процесса, размещенных в IIS/WAS, является лучшим путем при выполнении этих длинных рабочих процессов. Это также затрудняет решение проблемы с версией, просто первое сообщение возвращает версию рабочего процесса и делает ее частью каждого последующего сообщения. Затем поместите маршрутизатор WCF между ними, который направляет сообщение на нужную конечную точку на основе версии. Основное никогда не должно изменять существующий рабочий процесс, всегда создавайте новый.

Так что я тебе советую? Не делайте большой азарт на неизвестном, а для вас недоказанный, технологический. Сделайте небольшую, не критическую часть приложения, используя WF4. Таким образом, если он работает, вы можете расширить его, но если он не сработает, вы можете его уничтожить и заменить его более традиционным кодом .NET. Таким образом, вы получаете реальный опыт работы с WF4 вместо того, чтобы основывать решение о подержанной информации, и вы изучаете новую и мощную технологию в этом процессе. Если возможно, возьмите курс на WF4, так как это позволит вам сэкономить много времени на ускорение (бесстыдная самозатухание здесь).

О машине простого состояния. Я не использовал его, но у меня создалось впечатление, что это было на короткое время, в памяти, на государственных машинах. Одним из основных преимуществ WF4 являются долгосрочные аспекты.

Ответ 2

Я пришел к этой дилемме пару раз, и я решил не использовать Work Flow Foundation. Некоторые из соображений (похожих на ваши) были

Принятые рабочие потоки были намного проще (комбинация конечных автоматов и последовательных действий), и выполнение этого в WF, по-видимому, слишком велико для усилий.
Кривая обучения разработчиков для понимания и эффективного использования WF считалась высокой. Таблица перехода состояния, описывающая действительные переходы и действия, которые необходимо предпринять, используется для дополнительной гибкости, и разработчикам было удобно с ней, легко понимая концепцию и цель.
Шансы изменения бизнес-процессов были незначительными, и рудиментарные изменения были легко возможны с помощью таблицы перехода. Изменение перехода означало бы базу данных script, в то время как изменение в действиях привело бы к новому выпуску/патчу. Однако вероятность такого возникновения считалась низкой.

Оглядываясь назад после 13-14 месяцев, я все еще думаю, что решение о нецелесообразности WF было правильным. IMO, WF имеет смысл, когда существует сильная вероятность того, что рабочий поток может измениться и/или могут измениться бизнес-правила. WF позволяет изолировать рабочий процесс в отдельном файле, поэтому его настройка пользователем будет проще.

Ответ 3

Мы используем WF 4.0 последние пару месяцев. Я должен сказать, что это сложно подумать о пути Workflow. Однако я могу сказать, что это того стоит. Когда мы начали, мы очень мало знали. Мы купили новичка и профессиональную книгу для WF 4.0, которая помогла. Я, сам, смотрел много видео в Интернете и следил за PDC 2009 за их последние новости о WF 4.0 и о том, как он отличается от предыдущих несколько сочных версий. Одна важная вещь, на которую мы должны были предложить решение, - это то, как мы можем иметь дело с In/Our Arguments в рабочем процессе, не ограничивая наши пользовательские действия определенными типами данных и как передавать параметры между действиями. Я придумал хорошее решение для этого, и опыт работы, который у нас есть до сих пор, неплохо. На самом деле, у нас есть приложение с интенсивным рабочим процессом, которое становится все больше и больше, и я действительно не могу себе представить, как я его решаю в другой среде. Мне нравится визуальный эффект, который он имеет: он удерживает меня от деталей конструкций if/else и делает бизнес-правила очевидными таким образом, чтобы вы не заставляли вас погружаться в строки кода, чтобы знать, что происходит или как исправить ошибку. Кстати, проект, над которым мы работали, очень похож на то, что вы описали, и это проект среднего размера. Вы можете сказать по моим словам, что мне это нравится, и я рекомендую его, хотя он включает в себя некоторые риски, поскольку это новая технология, и вам нужно придумать некоторые инновационные идеи.

мои 2 цента...

Ответ 4

Я сделал три проекта в WF 3.5, и я должен сказать, что это непросто. Это заставляет вас думать по-новому, особенно когда используется сопротивление. Обновление приложения, которое содержит сотни неполных сохраненных рабочих процессов, является сложной задачей. Однократное изменение сериализации приводит к их краху. Общепринято введение нескольких версий одной и той же библиотеки для поддержки новых и старых рабочих процессов. Это было сложно.

Я еще не пробовал WF 4.0, но на основе опыта BizTalk и WF 3.5 я думаю, что он будет похож.

В любом случае лучший подход, который вы можете предпринять, - это сделать "Доказательство концепции". Возьмите один WF из своих требований и попробуйте внедрить его в WF 4.0. Вы потратите на это некоторое время, но вы докажете, сможете ли вы это сделать в WF 4.0 и, если есть какие-либо видимые преимущества.

Если вы решите использовать WF 4.0, я настаиваю на том, что вы проверяете возможность запуска WF в качестве службы WCF, размещенной в Windows AppFabric. AppFabric предоставляет некоторые из функциональных возможностей для размещения WF.

Ответ 5

Думаю, сегодня нет смысла говорить о Workflow в WF4 как о выборе технологии для такого рода проблем. Что действительно уместно, как упоминал Ладислав Мрнка выше, это WCF WF Services, размещенные в AppFabric.

Мой опыт в этом заключается в том, что он платит большие дивиденды и очень приятен, но проблемы возникают в начале, потому что неправильно оценивают, что для многих программистов это методологический сдвиг больше, чем технологический сдвиг. С другой стороны, обобщающие и те, у кого проблемы с решением проблем, увидели WCF WF AppFabric как набор захватывающих возможностей. Поэтому, если сочетание людей в проекте довольно консервативно, С# devs прилагается к их ежедневному набору OO и шаблонов, это будет сложно представить. Если команда будет более инновационной, то усыновление будет намного проще, потому что потенциальные и новые двери увеличиваются с каждым открытием.

Две основные концептуальные проблемы, с которыми программисты сталкивались при переходе к этой технологии, были: a) Корреляция сообщений и обменные шаблоны обмена сообщениями b) Рабочие процессы и модульные испытания В стандартных системах на С#, например, рабочий процесс редко бывает явным и, следовательно, редко тестируется на единицу. Общий рабочий процесс остается для тестирования сценариями принятия или интеграции. Внесите явный WF в качестве артефакта программного обеспечения, и вдруг стандартные разработчики захотят попробовать и unit test, что обычно не стоит делать.

Аспект корреляции сообщений - это немного смещения мышления для тех, кто не знаком с шаблонами обмена сообщениями. Большинство разработчиков имеют дело с процессами и удаленными вызовами, веб-сервисом и SOAP и обычно сосредоточены на одном или двух из них. Чтобы абстрагироваться от всего этого и работать с общей системой, основанной на сообщениях, вначале может сбивать с толку.

Однако с положительной стороны конечный результат - это то, что экономит много времени и создает много возможностей. Главное, что worfklow, если визуально понятно, - это то, над чем могут работать разработчики, разработчики и аналитики вместе, устраняя ненужные шаги в жизненном цикле разработки и фокусируя стороны на одном артефакте. Кроме того, он обескураживает острова функциональности в специализированных приложениях с выделенными слоями клея, поощряя набор бизнес-процессов в WF для каждого бизнес-домена. Кроме того, с AppFabric, сантехника для настойчивости, ведения журналов и пробуждения запланированных действий - все это сделано для вас. Отличная производительность WF4.

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

Ответ 6

Чтобы система страховой защиты любой сложности, которая включает в себя роли и "подзадачи", вам действительно нужно решение BPM, а не только рабочий процесс. Workflow Foundation 4.0 является гладким, но он действительно не приближается к функциям продукта BPM.

Решения BPM, такие как Metastorm BPM, Global360 и K2.NET, обеспечивают человеческий ориентированный рабочий процесс, задачи, роли и системную интеграцию, которые могут моделировать и оптимизировать бизнес-процессы, такие как система страховых требований. Используйте ASP.NET для создания интерфейса, который интегрируется с механизмом рабочего процесса BPM, поскольку их встроенные дизайнеры обычно ограничены и заставляют вас использовать свой настраиваемый веб-элемент управления, который обычно не так полно, как веб-элементы управления ASP.NET.

Ответ 7

Пойдите с технологией, которую ваша команда знает и чувствует себя комфортно. Workflow Foundation - это не продукт, который вы можете использовать сразу - это скорее набор элементов, которые вы можете встроить в свое приложение, чтобы создать систему документооборота. IMHO логика рабочего процесса является наименее важной технологией, прежде всего вам нужно сосредоточиться на графическом интерфейсе, поскольку владельцы бизнеса не видят ничего, кроме графического интерфейса. Но если ваша система имеет успех, вы должны быть готовы к бесконечным запросам на изменение и новым требованиям, поэтому вам необходимо реализовать свою бизнес-логику, чтобы ее легко изменить и легко разделить на отдельные процессы в соответствии с различными потребностями пользователей (иногда это противоречит), BPM помогает в этой задаче, поскольку она позволяет вам иметь отдельные, несколько версий бизнес-процессов, соответствующих различным бизнес-потребностям. Для этого вам не нужен полноценный BPM-движок, но он полезен для кодирования вашей бизнес-логики, чтобы его можно было версировать и разделять на отдельные бизнес-процессы - самое страшное, что нужно иметь, - это непревзойденный и перепутанный blob кода, который обрабатывает "все", и что никто не может понять. Для этого существует много идей: государственные машины, DSL (языки, специфичные для домена), скрипты и т.д. - вы решаете, какова должна быть реализация. Но вы всегда должны думать о бизнес-процессах и соответствующим образом упорядочивать свою логику, чтобы она отражала эти процессы. И будьте готовы к сосуществованию многих вариантов бизнес-логики и структур данных - это самая сложная задача дизайна imho.

Ответ 8

Я в ситуации, когда мне нужно использовать 4.0, поскольку .NET 4.5 еще не аккредитован для использования в нашей среде prod. У меня была большая боль, в основном понимающая, как добиться длительных рабочих процессов, которые будут соответствовать потребностям нашего бизнеса, но в итоге нашли элегантное решение. Это не то, что только кто-нибудь, кто придет позже поддержать, может просто поднять с легкостью, потому что так много о чем подумать, но я верю в WF как инструмент для управления состояниями рабочих процессов.

Одна большая вещь, которую я делаю с WF 4.0, но является комментарием Мориса:

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

Это здорово, если вы просто хотите новую версию, но что, если у вас есть 50 000 постоянных рабочих процессов и в какой-то момент осознать, что в рабочем процессе есть ошибка? Вы должны иметь возможность обновлять xamlx и по-прежнему привязываться к существующим экземплярам. Я попытался разархивировать различные столбцы метаданных в таблице экземпляров SQL Server, чтобы найти что-то, что связывает экземпляр с определением рабочего процесса без какой-либо удачи.

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

Моя рекомендация заключается в том, что вы вообще избегаете WF 4.0 и просто переходите прямо к 4.5, если вы поддерживаете его в среде. Динамические обновления и бок о бок Версия для него обеспечивает поддержку исправления ошибок и версии WF. Я еще не исследовал, как 4.5 все еще не аккредитован для использования нашим клиентом, но с нетерпением ждет этой возможности.

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

Я действительно не могу понять, что происходит с головами разработчиков WF dev, чтобы выпустить систему, в которой вы не можете легко исправить ошибки. Они должны были разработать метод повторного связывания экземпляра с новым xamlx.

Ответ 9

Похоже, ваша команда ориентирована на С#, поэтому, возможно, мои мысли не применяются. Я управляю технической компанией с довольно большим количеством сотрудников, и мы столкнулись с такой же потребностью. В отличие от многих других, у нас было много разработчиков в нашем распоряжении, поэтому решение для рабочего процесса на основе кода было идеальным.

Проблема заключается в том, что у нас нет большого количества ресурсов для настройки/поддержки системы и стоимости лицензий, если она не является достаточно ясной для нашего бизнеса. Практика Azure/Window Workflow просто не может быть и речи. Мы также попробовали немало больших комплектов BPM, которые там есть, и столкнулись с большим количеством проблем: они предлагают вам довольно продуманный опыт визуального программирования. Программирование не может быть полностью выполнено в визуальной среде. Вы можете увидеть список не-BPM-программного обеспечения, который нас действительно интересовал. Такие инструменты, как Decisions.com и IFTTT являются аккуратными. Фактически, решения могут быть очень полезны для вас, поскольку он интегрируется с продуктами Microsoft, насколько я понимаю.

Конец истории состоит в том, что мы свернули наше собственное программное обеспечение как предпринимательское приключение и для внутреннего использования. Рабочие процессы могут быть написаны и интегрированы с любым API, а также с человеческими процессами непосредственно с формами. Например, мы интегрируем рабочие процессы для размещения новых разработчиков, которые вытягивают/обновляют множество других программ. Он довольно зеленый, но чрезвычайно мощный в сценариях рабочего процесса. Здесь вы можете проверить Nebri. Поскольку основанный на правилах подход срабатывает на событиях, архитектура совсем другая. Это уменьшает количество кода, который вы должны написать, и имеет компромисс скорости. Но он может легко обрабатывать такие вещи, как complex-event-processing, поскольку Python в вашем распоряжении.