To Workflow или Not to Workflow?

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

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

Answer 7

Пойдите с технологией, которую ваша команда знает и чувствует себя комфортно. Workflow Foundation - это не продукт, который вы можете использовать сразу - это скорее набор элементов, которые вы можете встроить в свое приложение, чтобы создать систему документооборота. IMHO логика рабочего процесса является наименее важной технологией, прежде всего вам нужно сосредоточиться на графическом интерфейсе, поскольку владельцы бизнеса не видят ничего, кроме графического интерфейса. Но если ваша система успешна, тогда вы должны быть готовы к бесконечным запросам на изменение и новым требованиям, поэтому вам необходимо реализовать свою бизнес-логику, чтобы ее легко изменить и легко разделить на отдельные процессы в соответствии с различными потребностями пользователей (иногда это противоречит) , BPM помогает в этой задаче, поскольку она позволяет вам иметь отдельные, несколько версий бизнес-процессов, соответствующих различным бизнес-потребностям. Для этого вам не нужен полноценный BPM-движок, но полезно кодировать вашу бизнес-логику, чтобы его можно было версировать и разделять на отдельные бизнес-процессы - самое страшное, что нужно иметь, - это непревзойденный и перепутанный blob кода, который обрабатывает «все», и что никто не может понять. Для этого существует много идей: государственные машины, 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.

Answer 9

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

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

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