Do przepływu pracy czy nie do przepływu pracy?

Odpowiadam za zespół programistów, który za chwilę rozpocznie prace nad lekkim systemem roszczeń ubezpieczeniowych. System obejmuje wiele ręcznych zadań i biznesowych przepływów pracy, a my rozważamy wykorzystanie Windows Workflow (.NET 4.0).

Przykład domeny biznesowej jest następujący: Posiadacz polisy dzwoni do centrum kontaktowego w celu złożenia reklamacji. To „zdarzenie” uruchamia dwa pod-zadania, które są wykonywane ręcznie równolegle i ich ukończenie może zająć dużo czasu;

1. Sprawdź klienta pod kątem oszustwa - ręczny proces, w ramach którego operator dzwoni do różnych firm kredytowych w celu sprawdzenia i oceny potencjału oszukańczego klienta. W tym miejscu zadanie podrzędne może wprowadzić szereg statusów podrzędnych (sprawdzanie w toku, sprawdzanie referencji zakończonych niepowodzeniem, sprawdzanie referencji zaliczonych itp.)
2. Wyślij element do centrum napraw - proces ręczny, w ramach którego element, którego dotyczy roszczenie, jest wysyłany do centrum napraw w celu naprawy. Z tego miejsca zadanie podrzędne może wprowadzić szereg statusów podrzędnych (oczekuje na naprawę, w toku, naprawiony, wysłany itp.). Roszczenie może być kontynuowane tylko wtedy, gdy stan każdego zadania podrzędnego osiągnie wstępnie zdefiniowany stan (na podstawie reguł biznesowych).

Na pierwszy rzut oka wydaje się, że przepływ pracy jest rzeczywiście najlepszym wyborem technologii; jednak mam kilka obaw związanych z używaniem WF 4.0.

1. Zestaw umiejętności - patrząc na średni zestaw umiejętności programistów, nie widzę wielu programistów, którzy rozumieją lub znają przepływ pracy.
2. Łatwość utrzymania - wydaje się, że społeczność ma niewielkie poparcie dla projektów WF ​​4.0, co w połączeniu z brakiem zestawu umiejętności budzi obawy dotyczące łatwości konserwacji.
3. Bariera wejścia - mam wrażenie, że Windows Workflow ma stromą krzywą uczenia się i nie zawsze jest to łatwe do opanowania.
4. Nowy produkt - ponieważ Workflow został całkowicie przepisany na .NET 4.0, postrzegam ten produkt jako produkt pierwszej generacji i może nie mieć wymaganej stabilności.
5. Reputacja - poprzednie wersje Workflow nie były dobrze przyjmowane, uważane za trudne do opracowania i skutkowały słabym zainteresowaniem biznesowym.

Moje pytanie brzmi więc, czy w tej sytuacji powinniśmy używać systemu Windows Workflow (WF) 4.0, czy też istnieje alternatywna technologia (np. Simple State Machine itp.) Lub nawet lepszy silnik przepływu pracy?

Zrobiłem kilka projektów WF4, więc zobaczmy, czy mogę dodać przydatne informacje do innych odpowiedzi.

Z opisu twojego problemu biznesowego wynika, że ​​WF4 dobrze pasuje, więc nie ma problemów.

Jeśli chodzi o twoje obawy, masz rację. Zasadniczo WF4 jest nowym produktem i brakuje mu niektórych ważnych funkcji i ma pewne szorstkie krawędzie. Jest krzywa uczenia się, niektóre rzeczy trzeba robić inaczej. Głównym punktem jest długa praca i serializacja, do której przeciętny programista nie jest przyzwyczajony i wymaga pewnego przemyślenia, ponieważ zbyt często słyszę, że ludzie mają problemy z serializacją kontekstu danych struktury jednostek.

W większości przypadków korzystanie z usług przepływu pracy hostowanych w usługach IIS / WAS jest najlepszą trasą podczas wykonywania tych długotrwałych przepływów pracy. To sprawia, że ​​rozwiązanie problemu z wersjami również nie jest trudne, wystarczy, że pierwsza wiadomość zwróci wersję przepływu pracy i uczyni ją częścią każdej kolejnej wiadomości. Następnie umieść router WCF między, który kieruje komunikat do odpowiedniego punktu końcowego na podstawie wersji. Podstawą jest to, aby nigdy nie zmieniać istniejącego przepływu pracy, zawsze tworzyć nowy.

Więc jaka jest moja rada? Nie ryzykuj dużego ryzyka na nieznanej i niesprawdzonej technologii. Wykonaj mały, niekrytyczny fragment aplikacji za pomocą WF4. W ten sposób, jeśli zadziała, możesz go rozszerzyć, ale jeśli zawiedzie, możesz go wyrwać i zastąpić bardziej tradycyjnym kodem .NET. W ten sposób zdobędziesz prawdziwe doświadczenie z WF4 zamiast opierać decyzję na informacjach z drugiej ręki i nauczysz się nowej i potężnej technologii. Jeśli to możliwe, weź udział w kursie na WF4, ponieważ pozwoli ci to zaoszczędzić dużo czasu na przyspieszeniu (bezwstydna wtyczka własna tutaj ).

O Simple State Machine. Nie korzystałem z niego, ale miałem wrażenie, że to działa na krótko, w pamięci, maszynach stanowych. Jedną z głównych zalet WF4 są aspekty długoterminowe.

Kilkakrotnie doszedłem do tego dylematu i zdecydowałem się nie używać podkładu Work Flow. Niektóre z rozważań (podobnych do twoich) były

1. Zaangażowane przepływy pracy były o wiele prostsze (połączenie automatu stanowego i działań sekwencyjnych), a robienie tego w WF wydaje się przesadzać ze względu na wysiłki.
2. Krzywa uczenia się dla programistów, aby zrozumieć i skutecznie używać WF, została uznana za wysoką. Tabela zmian statusu opisująca prawidłowe przejścia i działania, które należy podjąć, zapewnia dodatkową elastyczność, a programiści byli z nią komfortowo, łatwo rozumiejąc koncepcję i cel.
3. Szanse na zmiany procesów biznesowych były niewielkie, a podstawowe zmiany były łatwo możliwe przy pomocy tabeli przejść. Zmiana w przejściu oznaczałaby skrypt bazy danych, podczas gdy zmiana działań skutkowałaby nowym wydaniem / poprawką. Jednak prawdopodobieństwo takiego zdarzenia uznano za niskie.

Patrząc wstecz po 13-14 miesiącach nadal uważam, że decyzja o niestosowaniu WF była słuszna. IMO, WF ma sens tam, gdzie istnieje duże prawdopodobieństwo, że przepływ pracy może się zmienić i / lub zasady biznesowe mogą się zmienić. WF pozwala wyodrębnić przepływ pracy w osobnym pliku, dzięki czemu łatwiej będzie go konfigurować przez użytkowników.

Używaliśmy WF 4.0 przez ostatnie kilka miesięcy. Muszę powiedzieć, że trudno jest myśleć w sposób Workflow. Jednak mogę powiedzieć, że warto. Kiedy zaczynaliśmy, wiedzieliśmy bardzo mało. Kupiliśmy książkę dla początkujących i profesjonalistów dla WF 4.0, która pomogła. Ja sam obejrzałem wiele filmów online i śledziłem PDC 2009, aby zapoznać się z ich przełomowymi wiadomościami na temat WF 4.0 i tego, jak różni się on od poprzednich, nieco kiepskich wersji. Jedną z głównych rzeczy, dla których musieliśmy zaproponować rozwiązanie, jest sposób, w jaki możemy radzić sobie z argumentami w / naszymi w przepływie pracy bez ograniczania naszych niestandardowych działań do określonych typów danych i przekazywania parametrów między działaniami. Wymyśliłem na to dobre rozwiązanie, a dotychczasowe doświadczenia z przepływem pracy nie są wcale złe. Tak właściwie, mamy aplikację wymagającą intensywnej pracy, która jest coraz większa i naprawdę nie wyobrażam sobie rozwiązania tego problemu w innym środowisku. Uwielbiam efekt wizualny, jaki ma: trzyma mnie z daleka od szczegółów konstrukcji if / else etc i sprawia, że ​​reguły biznesowe są widoczne w sposób, który nie zmusza cię do zanurzania się w linijkach kodu, aby wiedzieć, co się dzieje lub jak naprawić jakiś błąd. Nawiasem mówiąc, projekt, nad którym pracowaliśmy, jest bardzo podobny do tego, co opisałeś i jest to projekt średniej wielkości. Z moich słów wynika, że ​​mi się podoba i polecam, chociaż wiąże się to z pewnym ryzykiem, ponieważ jest to nowa technologia i trzeba wymyślić kilka innowacyjnych pomysłów. trzyma mnie z daleka od szczegółów konstrukcji if / else etc i sprawia, że ​​reguły biznesowe są widoczne w sposób, który nie zmusza cię do zagłębiania się w linie kodu, aby wiedzieć, co się dzieje lub jak naprawić jakiś błąd. Nawiasem mówiąc, projekt, nad którym pracowaliśmy, jest bardzo podobny do tego, co opisałeś i jest to projekt średniej wielkości. Z moich słów wynika, że ​​mi się podoba i polecam, chociaż wiąże się to z pewnym ryzykiem, ponieważ jest to nowa technologia i trzeba wymyślić kilka innowacyjnych pomysłów. trzyma mnie z daleka od szczegółów konstrukcji if / else etc i sprawia, że ​​reguły biznesowe są widoczne w sposób, który nie zmusza cię do zagłębiania się w linie kodu, aby wiedzieć, co się dzieje lub jak naprawić jakiś błąd. Nawiasem mówiąc, projekt, nad którym pracowaliśmy, jest bardzo podobny do tego, co opisałeś i jest to projekt średniej wielkości. Z moich słów wynika, że ​​mi się podoba i polecam, chociaż wiąże się to z pewnym ryzykiem, ponieważ jest to nowa technologia i trzeba wymyślić kilka innowacyjnych pomysłów.

moje 2 centy ...

Zrobiłem trzy projekty w WF 3.5 i muszę powiedzieć, że nie jest to łatwe. Zmusza cię do myślenia w zupełnie nowy sposób, zwłaszcza gdy używasz wytrwałości. Aktualizacja aplikacji, która zawiera setki niekompletnych, utrwalonych przepływów pracy, jest trudna. Pojedyncza zmiana w serializacji powoduje ich awarię. Wprowadzanie wielu wersji tej samej biblioteki do obsługi nowych i starych uruchomionych przepływów pracy jest powszechne. To było trudne.

Nie próbowałem jeszcze WF 4.0, ale na podstawie doświadczeń z BizTalk i WF 3.5 myślę, że będzie podobnie.

W każdym razie najlepszym podejściem, jakie możesz podjąć, jest wykonanie weryfikacji koncepcji. Weź pojedynczy WF ze swoich wymagań i spróbuj wdrożyć go w WF 4.0. Spędzisz z tym trochę czasu, ale udowodnisz, czy jesteś w stanie to zrobić w WF 4.0 i czy są jakieś widoczne korzyści.

Jeśli zdecydujesz się użyć WF 4.0, nalegam, abyś sprawdził możliwość uruchamiania WF jako usługi WCF hostowanej w Windows AppFabric. AppFabric zapewnia niektóre gotowe funkcje do hostowania WF.

Myślę, że dzisiaj nie ma sensu mówić o przepływie pracy w WF4 jako technologii wyboru dla tego rodzaju problemów. To, co jest naprawdę odpowiednie, jak wspomniał wyżej Ladislav Mrnka, to usługi WCF WF hostowane w AppFabric.

Z mojego doświadczenia wynika, że ​​przynosi to duże zyski i jest bardzo przyjemne, ale na początku pojawiają się problemy, ponieważ nie docenia się tego, że dla wielu programistów jest to bardziej zmiana metodologii niż zmiana technologii. Z drugiej strony, ogólniści i osoby nastawione na rozwiązywanie problemów postrzegały WCF WF AppFabric jako zestaw ekscytujących możliwości. Więc jeśli mieszanka ludzi w projekcie to dość konserwatywni programiści C # przywiązani do swojego codziennego zestawu obiektów obiektowych i wzorców, będzie to trudne do wprowadzenia. Jeśli zespół jest bardziej innowacyjny, adopcja będzie znacznie łatwiejsza, ponieważ potencjał i nowe możliwości pomnażają się z każdym odkryciem.

Dwa główne problemy koncepcyjne, które programiści napotkali podczas przechodzenia na tę technologię, to: a) Korelacja komunikatów i wzorce wymiany komunikatów b) Przepływy pracy i testy jednostkowe Na przykład w standardowych systemach w języku C # przepływ pracy rzadko jest jawny i dlatego rzadko jest testowany jednostkowo. Cały przepływ pracy pozostawia się do testowania według scenariuszy akceptacji lub integracji. Wprowadź wyraźny WF jako artefakt oprogramowania i nagle deweloperzy standardu chcą spróbować go przetestować jednostkowo, co zwykle nie jest warte robienia.

Aspekt korelacji wiadomości to pewna zmiana sposobu myślenia dla tych, którzy nie są zaznajomieni z wzorcami wymiany wiadomości. Większość programistów zajmowała się wywołaniami procesowymi i zdalnymi, usługami sieciowymi i SOAP i zwykle skupiała się na jednym lub dwóch z nich. Abstrahowanie ponad tym wszystkim i praca z ogólnym systemem opartym na komunikatach może być początkowo mylące.

Z drugiej strony efekt końcowy to coś, co oszczędza dużo czasu i stwarza wiele możliwości. Najważniejsze jest to, że worfklow, jeśli jest wizualnie przejrzysty, jest czymś, nad czym może pracować wspólnie użytkownik końcowy, programista i analityk, eliminując niepotrzebne kroki w cyklu rozwoju i skupiając strony na jednym artefakcie. Ponadto zniechęca do wysp funkcjonalności w dedykowanych aplikacjach z dedykowanymi warstwami kleju, zachęcając do zestawu procesów biznesowych w WF na domenę biznesową. Co więcej, dzięki AppFabric instalacja hydrauliczna zapewniająca trwałość, logowanie i budzenie zaplanowanych działań jest wykonywana za Ciebie. Wydajność WF4 jest również znakomita.

Moim zaleceniem byłoby znalezienie najbardziej innowacyjnego lub odkrywczego członka zespołu, który przeprowadzi wstępne rozpoznanie, aby odkryć trudne części, uruchomić podstawowe funkcje i poprosić tę początkową osobę, która będzie odpowiedzialna za oddzielenie pozostałej pracy.

Aby stworzyć system roszczeń ubezpieczeniowych o dowolnej złożoności, który obejmuje role i „podzadania”, naprawdę potrzebujesz rozwiązania BPM, a nie tylko przepływu pracy. Workflow Foundation 4.0 jest zgrabna, ale tak naprawdę nie zbliża się do funkcjonalności produktu BPM.

Rozwiązania BPM, takie jak Metastorm BPM, Global360 i K2.NET, zapewniają zorientowany na człowieka przepływ pracy, zadania, role i integrację systemów, które mogą modelować i usprawniać procesy biznesowe, takie jak system roszczeń ubezpieczeniowych. Użyj ASP.NET, aby zbudować interfejs, który integruje się z silnikiem przepływu pracy BPM, ponieważ ich wbudowani projektanci są zwykle ograniczeni i zmuszają Cię do korzystania z ich niestandardowych formantów sieci Web, które zwykle nie są tak w pełni funkcjonalne, jak formanty internetowe ASP.NET.

Wybierz technologię, którą Twój zespół zna i z którą czuje się komfortowo. Workflow Foundation nie jest produktem, z którego możesz korzystać od razu - to raczej zestaw elementów, które możesz osadzić w swojej aplikacji w celu zbudowania systemu przepływu pracy. IMHO logika przepływu pracy jest najmniej ważnym elementem technologii, przede wszystkim musisz skoncentrować się na GUI, ponieważ właściciele firm nie zobaczą niczego poza GUI. Ale jeśli Twój system odniósł sukces, musisz być przygotowany na niekończące się żądania zmian i nowe wymagania, więc musisz wdrożyć logikę biznesową tak, aby była łatwa do zmiany i łatwa do podzielenia na oddzielne procesy w celu dostosowania do różnych potrzeb użytkowników (czasami sprzeczne) . BPM pomaga w tym zadaniu, ponieważ pozwala na posiadanie oddzielnych, wielu wersji procesów biznesowych odpowiadających różnym potrzebom biznesowym. Jesteś skończony' do tego potrzebny jest pełnoprawny silnik BPM, ale warto zakodować logikę biznesową, aby można ją było wersjonować i dzielić na poszczególne procesy biznesowe - najgorszą rzeczą jest niemożliwa do utrzymania i splątana plama kodu, która obsługuje `` wszystko '' i że nie można zrozumieć. Pomysłów na to jest wiele - maszyny stanowe, DSL (języki specyficzne dla domeny), skrypty itp. - Ty decydujesz, jaka powinna być implementacja. Zawsze jednak należy myśleć w kategoriach procesów biznesowych i odpowiednio organizować swoją logikę, aby odzwierciedlała te procesy. I bądź przygotowany na współistnienie wielu wariantów logiki biznesowej i struktur danych - to najtrudniejsze zadanie projektowe imho. przydaje się kodowanie logiki biznesowej, tak aby można ją było wersjonować i dzielić na poszczególne procesy biznesowe - najgorszą rzeczą jest niemożliwa do utrzymania i splątana plama kodu, która obsługuje „wszystko” i której nikt nie może zrozumieć. Pomysłów na to jest wiele - maszyny stanowe, DSL (języki specyficzne dla domeny), skrypty itp. - Ty decydujesz, jaka powinna być implementacja. Zawsze jednak należy myśleć w kategoriach procesów biznesowych i odpowiednio organizować swoją logikę, aby odzwierciedlała te procesy. I bądź przygotowany na współistnienie wielu wariantów logiki biznesowej i struktur danych - to najtrudniejsze zadanie projektowe imho. przydaje się kodowanie logiki biznesowej, tak aby można ją było wersjonować i dzielić na poszczególne procesy biznesowe - najgorszą rzeczą jest niemożliwa do utrzymania i splątana plama kodu, która obsługuje „wszystko” i której nikt nie może zrozumieć. Pomysłów na to jest wiele - maszyny stanowe, DSL (języki specyficzne dla domeny), skrypty itp. - Ty decydujesz, jaka powinna być implementacja. Zawsze jednak należy myśleć w kategoriach procesów biznesowych i odpowiednio organizować swoją logikę, aby odzwierciedlała te procesy. I bądź przygotowany na współistnienie wielu wariantów logiki biznesowej i struktur danych - to najtrudniejsze zadanie projektowe imho. DSL (języki specyficzne dla domeny), skrypty itp. - Ty decydujesz, jaka powinna być implementacja. Zawsze jednak należy myśleć w kategoriach procesów biznesowych i odpowiednio organizować swoją logikę, aby odzwierciedlała te procesy. I bądź przygotowany na współistnienie wielu wariantów logiki biznesowej i struktur danych - to najtrudniejsze zadanie projektowe imho. DSL (języki specyficzne dla domeny), skrypty itp. - Ty decydujesz, jaka powinna być implementacja. Zawsze jednak należy myśleć w kategoriach procesów biznesowych i odpowiednio organizować swoją logikę, aby odzwierciedlała te procesy. I bądź przygotowany na współistnienie wielu wariantów logiki biznesowej i struktur danych - to najtrudniejsze zadanie projektowe imho.

Jestem w sytuacji, w której muszę używać 4.0, ponieważ .NET 4.5 nie jest jeszcze akredytowany do użytku w naszym środowisku produkcyjnym. Ogólnie miałem duże zrozumienie, jak uzyskać długotrwałe przepływy pracy, które będą odpowiadały naszym potrzebom biznesowym, ale ostatecznie znalazłem eleganckie rozwiązanie. Nie jest to coś, co każdy, kto później przyjdzie wesprzeć, może po prostu łatwo podnieść, ponieważ jest tak wiele do przemyślenia, ale wierzę w WF jako narzędzie do zarządzania stanami przepływu pracy.

Jednak jedną wielką rzeczą, z którą nie zgadzam się na WF 4.0, jest komentarz Maurice'a:

Podstawą jest to, aby nigdy nie zmieniać istniejącego przepływu pracy, zawsze tworzyć nowy

To świetnie, jeśli potrzebujesz tylko nowej wersji, ale co, jeśli masz 50 000 utrwalonych przepływów pracy i zdasz sobie sprawę, że w pewnym momencie jest błąd w przepływie pracy? Musisz być w stanie zaktualizować xamlx i nadal być połączony z istniejącymi wystąpieniami. Próbowałem rozpakować różne kolumny metadanych w tabeli instancji SQL Server, aby znaleźć coś, co wiąże instancję z definicją przepływu pracy bez żadnego szczęścia.

Napisałem aplikację do synchronizacji do importowania danych ze starego systemu do naszego nowego opartego na WF 4.0. Zasadniczo ładujemy dane do systemu, a następnie uruchamiamy proces, który polega na automatycznym wywołaniu kroków przepływu pracy i wywołaniu metod walidacji, zasadniczo naśladując interakcję użytkownika. To naprawdę działało z nami tylko ze względu na architekturę, którą zaimplementowaliśmy w celu uzyskania dostępu do hosta usługi przepływu pracy. Jest świetny jako jednorazowy, w którym po uruchomieniu można przejść i przeprowadzić kontrole, aby zapewnić spójność procesu migracji danych, ale konieczność zastosowania tego podejścia w przypadku potencjalnie setek tysięcy przypadków, gdy system działa, nie jest tak naprawdę podejściem co dodaje pewności siebie i nadmiernie obciąża proces integracji prostych napraw błędów.

Moim zaleceniem jest całkowite uniknięcie WF 4.0 i przejście od razu do 4.5, jeśli środowisko to obsługuje. Dynamiczne aktualizacje i wersja obok siebie zapewniają naprawę błędów i wersjonowanie WF po wyjęciu z pudełka. Wciąż jeszcze nie zbadałem, dlaczego wersja 4.5 nadal nie jest akredytowana do użytku przez naszego klienta, ale z niecierpliwością czekam na tę okazję.

Desperacko liczę na to, że nasz klient nie żąda zmian w zasadach (a tym samym dostosowań przepływu pracy) i że obecne przepływy pracy działają bez żadnych błędów. Ta ostatnia jest próżną i pustą nadzieją, ponieważ błędy zawsze się pojawiają.

Naprawdę nie rozumiem, co działo się w głowach zespołu deweloperów WF, aby wypuścić system, w którym po wyjęciu z pudełka nie można łatwo naprawić błędów. Powinni byli opracować technikę ponownego wiązania instancji z nowym xamlx.