Jestem również stronniczy, ponieważ jestem głównym autorem StonePath .
Opracowałem aplikacje przepływu pracy dla Departamentu Stanu USA, Centrum Humanitarnego Rozminowywania w Genewie, kilku klientów z listy Fortune 500, a ostatnio systemu szkół publicznych w Waszyngtonie. Za każdym razem, gdy widziałem „silnik przepływu pracy”, który starał się być jedynym głównym punktem odniesienia dla procesów biznesowych, widziałem organizację walczącą o obejście tego narzędzia. Może to wynikać z faktu, że rozwiązania te zawsze były ukierunkowane na sprzedawcę / produkt, a następnie kończyły się na taktycznym zespole `` konsultantów '' stale zasilających aplikację ... ale z tego powodu zwykle reaguję negatywnie, gdy słyszę korzyści wynikające z narzędzi opartych na procesach, które obiecują „scentralizować definicje przepływu pracy w jednym miejscu i zapewnić ich powtarzalność”.
To powiedziawszy, bardzo lubię Ruote - śledzę ten projekt od jakiegoś czasu i gdybym potrzebował takiego rozwiązania, będzie to następne narzędzie, które będę chciał wypróbować. StonePath ma zupełnie inny cel niż ruote - tam, gdzie Ruote jest ogólnie przydatne dla Rubiego, StonePath jest skierowane do Rails, frameworka internetowego napisanego w Rubim. Tam, gdzie Ruote dotyczy długotrwałych procesów biznesowych i związanych z nimi definicji, StonePath zajmuje się zarządzaniem przepływem pracy i zadaniami opartymi na stanie. Szczerze mówiąc, myślę, że rozróżnienie z zewnątrz, patrząc do środka, może być subtelne - często te same rodzaje procesów biznesowych mogą być reprezentowane w obie strony - jednak model oparty na stanie i zadaniach ma tendencję do mapowania na mój model mentalny.
Pozwólcie, że opiszę najważniejsze cechy przepływu pracy opartego na stanie. Krótko mówiąc, wyobraź sobie przepływ pracy obracający się wokół przetwarzania czegoś takiego jak pożyczka hipoteczna lub odnowienie paszportu. Gdy dokument przemieszcza się „po biurze”, przechodzi od stanu do stanu. Wyobraź sobie, że jesteś odpowiedzialny za dokument, a Twój szef prosił Cię co kilka godzin o aktualizację statusu i chciał krótkiej odpowiedzi ... powiedziałbyś na przykład „To jest we wpisie danych” ... ”Sprawdzamy referencje kandydata teraz „…” czekamy na ocenę jakości ”…„ Skończyliśmy ”… i tak dalej. Są to stany w przepływie pracy opartym na stanach. Przechodzimy od stanu do stanu poprzez przejścia - takie jak „zatwierdź”, „zastosuj”, „odrzuć”, „odmów” itd. Zwykle są to czasowniki określające czynności.
Kolejną częścią przepływu pracy opartego na stanach / zadaniach jest tworzenie zadań. Zadanie to jednostka pracy, zwykle z terminem wykonania i instrukcjami dotyczącymi obsługi, która łączy element pracy (na przykład wniosek o pożyczkę lub odnowienie paszportu) z użytkownikiem „w skrzynce”. Zadania mogą być wykonywane równolegle lub sekwencyjnie, a my możemy tworzyć zadania automatycznie, gdy wchodzimy w stany, tworzyć zadania ręcznie, gdy ludzie zdają sobie sprawę, że praca musi zostać wykonana, i wymagać zakończenia zadań, zanim będziemy mogli przejść do nowego stanu. Wszystkie tego rodzaju zachowania są opcjonalne i stanowią część definicji przepływu pracy.
Królicza nora może sięgać znacznie głębiej i napisałem o tym artykuł w numerze 4 PragPub, Pragmatic Programmer's Magazine. Sprawdź powyższy link do ponownego odtworzenia, aby uzyskać zaktualizowany plik PDF tego artykułu.
Pracując z StonePath w ciągu ostatnich kilku miesięcy, odkryłem, że model oparty na stanie naprawdę dobrze odwzorowuje spokojne architektury internetowe - w szczególności zadania i przejścia stanów ładnie odwzorowują się jako zagnieżdżone zasoby. Spodziewaj się, że w przyszłości napiszę ode mnie na ten temat.