На робочий процес чи не на робочий процес?

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

Приклад ділового домену наступний: Власник полісу телефонує контактному центру, щоб подати претензію. Ця подія запускає дві підзадачі, які вручну діють паралельно і можуть зайняти тривалий час;

1. Перевірка клієнта на шахрайство - ручний процес, під час якого оператор закликає різні кредитні компанії для перевірки та оцінки потенціалу шахрайського клієнта. Звідси підзадача може вводити ряд підпунктів (Перевірка у виконанні, Невдала перевірка довідки, Пройдена перевірка довідки тощо)
2. Надіслати товар до центру ремонту - Процес вручну, коли предмет, за яким страхувальник подав претензію, надсилається до центру ремонту, який має бути виправлений. Звідси підзадача може ввести ряд підпунктів (Очікування ремонту, У процесі виконання, Ремонт, Опубліковано тощо). Претензія може продовжуватися лише після того, як статус кожного підзадачі досяг заздалегідь визначеного статусу (виходячи з правил бізнесу).

На перший погляд здається, що Workflow - це справді найкращий вибір технології; однак у мене є деякі проблеми при використанні WF 4.0.

1. Набір навичок - дивлячись на середній набір навичок розробника, я не бачу багатьох розробників, які розуміють або знають Workflow.
2. Ремонтопридатність - Мабуть, мало підтримки в громаді для проектів WF 4.0, і це у поєднанні з відсутністю набору навичок викликає занепокоєння щодо ремонтопридатності.
3. Перешкода для вступу - у мене таке відчуття, що робочий процес Windows має круту криву навчання, і підібрати його не завжди так просто.
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. Деякі міркування (подібні до ваших) були

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

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

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

мої 2 копійки ...

Я зробив три проекти в 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.

Я думаю, що сьогодні не має сенсу говорити про Workflow у WF4 як про вибір технології для подібних проблем. Що дійсно доречно, як згадував Ладислав Мрнка вище, - це послуги WCF WF, розміщені в AppFabric.

Мій досвід щодо цього полягає в тому, що він платить великі дивіденди і це дуже приємно, але проблеми виникають на початку, оскільки це не належно оцінено, що для багатьох програмістів це зрушення методології більше, ніж зрушення технології. З іншого боку, загальні фахівці та ті, хто має роздуми щодо вирішення проблем, розглядали WCF WF AppFabric як набір захоплюючих можливостей. Тож якщо цілий ряд людей у ​​проекті є досить консервативним C # devs, приєднаним до їх щоденного набору OO та моделей, це буде важко представити. Якщо команда більш інноваційна, то прийняття буде набагато простішим, оскільки потенціал та нові дверні прорізи множиться з кожним відкриттям.

Дві основні концептуальні проблеми, які мали програмісти при переході до цієї технології, були: а) кореляція повідомлень та обмін повідомленнями; 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 - це не той продукт, який ви можете використати відразу - це скоріше набір фрагментів, які ви можете вбудувати у свою програму для створення системи робочого процесу. IMHO логіка робочого процесу - найменш важливий елемент технології, насамперед потрібно зосередитись на графічному інтерфейсі, оскільки власники бізнесу не побачать нічого, крім GUI. Але якщо ваша система має успіх, вам потрібно бути готовим до нескінченних запитів на зміни та нових вимог, тому вам доведеться реалізувати свою бізнес-логіку, щоб її було легко змінити і легко розділити на окремі процеси, щоб задовольнити різні потреби користувача (іноді суперечать) . BPM допомагає в цьому завданні, оскільки дозволяє мати окремі, декілька версій бізнес-процесів, що відповідають різним потребам бізнесу. Ви не ' для цього вам не потрібен повноцінний механізм BPM, але корисно кодувати свою ділову логіку, щоб її можна було переосмислити і розділити на окремі бізнес-процеси - найгірше, що у вас є, - це нерозбірливий і переплетений блок коду, який обробляє "все" і що ні можна зрозуміти. Для цього існує чимало ідей - державні машини, DSL (мови, визначені для домену), сценарії тощо - ви вирішите, якою має бути реалізація. Але завжди слід думати з точки зору бізнес-процесів і відповідно організувати свою логіку, щоб вона відображала ці процеси. Будьте готові до співіснування багатьох варіантів бізнес-логіки та структур даних - це найскладніше завдання дизайну. s корисно кодувати свою бізнес-логіку, щоб її можна було впорядкувати та розділити на окремі бізнес-процеси - найгірше, що є - це немислимий та переплетений згусток коду, який обробляє "все" і який ніхто не може зрозуміти. Для цього існує чимало ідей - державні машини, DSL (мови, визначені для домену), сценарії тощо - ви вирішите, якою має бути реалізація. Але завжди слід думати з точки зору бізнес-процесів і відповідно організувати свою логіку, щоб вона відображала ці процеси. Будьте готові до співіснування багатьох варіантів бізнес-логіки та структур даних - це найскладніше завдання дизайну. s корисно кодувати свою бізнес-логіку, щоб її можна було впорядкувати та розділити на окремі бізнес-процеси - найгірше, що є - це немислимий та переплетений згусток коду, який обробляє "все" і який ніхто не може зрозуміти. Для цього існує чимало ідей - державні машини, DSL (мови, визначені для домену), сценарії тощо - ви вирішите, якою має бути реалізація. Але завжди слід думати з точки зору бізнес-процесів і відповідно організувати свою логіку, щоб вона відображала ці процеси. Будьте готові до співіснування багатьох варіантів бізнес-логіки та структур даних - це найскладніше завдання дизайну. DSL (мови, що належать до домену), сценарії тощо - ви вирішите, якою має бути реалізація. Але завжди слід думати з точки зору бізнес-процесів і відповідно організувати свою логіку, щоб вона відображала ці процеси. Будьте готові до співіснування багатьох варіантів бізнес-логіки та структур даних - це найскладніше завдання дизайну. DSL (мови, що належать до домену), сценарії тощо - ви вирішите, якою має бути реалізація. Але завжди слід думати з точки зору бізнес-процесів і відповідно організувати свою логіку, щоб вона відображала ці процеси. Будьте готові до співіснування багатьох варіантів бізнес-логіки та структур даних - це найскладніше завдання дизайну.

Я знаходжусь у ситуації, коли мені доводиться використовувати 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.