В рабочий процесс или не в рабочий процесс?

Question

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

Ниже приведен пример бизнес-сферы: держатель политики звонит в контакт-центр для подачи претензии.Это «событие» запускает две подзадачи, которые выполняются вручную параллельно и может занять много времени;

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

Answer 5

Я сделал три проекта в 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.

Answer 6

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

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

Answer 7

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

Answer 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, чтобы выпустить систему, в которой из коробки вы не можете исправить ошибкибез труда.Им следовало разработать технику повторного связывания экземпляра с новым xamlx.