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

Я отвечаю за команду разработчиков, которые собираются приступить к разработке облегченной системы страховых выплат. Система включает в себя множество ручных задач и бизнес-процессов, и мы рассматриваем возможность использования 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 в этой ситуации или есть альтернативная технология (например, Simple State Machine и т. Д.) Или даже лучший механизм рабочего процесса для использования?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако у меня есть одна большая проблема с WF 4.0 - это комментарий Мориса:

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

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

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

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

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

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