W pierwszej części tej serii przedstawiono kilka podstawowych kroków związanych z zarządzaniem cyklem życia dowolnego podmiotu w bazie danych. Nasza druga i ostatnia część pokaże Ci, jak zdefiniować rzeczywisty przepływ pracy za pomocą dodatkowych tabel konfiguracyjnych. W tym miejscu użytkownik jest prezentowany z dozwolonymi opcjami na każdym kroku. Zademonstrujemy również technikę obejścia ścisłego ponownego użycia „zespołów” i „podzespołów” w strukturze wykazu materiałów.
Definiowanie opcji
W części 1 przedstawiono podstawowe tabele przepływu pracy i sposób, w jaki można je łatwo włączyć do bazy danych. Teraz potrzebujemy czegoś, co poprowadzi użytkownika do wyboru następnego stanu logicznego – czegoś, co definiuje logiczny przepływ pracy .
Poniższy diagram definiuje wszystkie elementy modelu bazy danych przepływu pracy:
Dwie tabele konfiguracji, workflow_state_option i workflow_state_context , zostały dodane do modelu. Zaczniemy od tabeli opcji, która definiuje dopuszczalne kolejne stany . Po zrozumieniu jego funkcji wrócimy do tabeli kontekstowej i wyjaśnimy rolę, jaką odgrywa.
Dozwolone następne stany
Poniższe tabele przypominają widok SQL w naszych tabelach konfiguracyjnych. Tutaj ukryliśmy łączenia tabel i patrzymy tylko na kombinacje type_keys . Rozważmy więc każdy STAN.WYNIK kombinację i zdefiniuj opcje dostępne dla użytkownika:
| Kombinacja STAN.WYNIK (z hierarchii stanów) | Kontekst stanu | Dziecko wyłączone | Opcja 1 | Opcja 2 |
|---|---|---|---|---|
| APPLICATION_RECEIVED .ZAAKCEPTOWANE | STANDARD_JOB _APPLICATION | N | APPLICATION_REVIEW | |
| APPLICATION_RECEIVED .ODRZUCONY | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| APPLICATION_REVIEW .PASSED | STANDARD_JOB _APPLICATION | N | INVITED_TO_INTERVIEW | |
| APPLICATION_REVIEW .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| INVITED_TO_INTERVIEW .ZAAKCEPTOWANE | STANDARD_JOB _APPLICATION | N | WYWIAD | |
| INVITED_TO_INTERVIEW .DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| WYWIAD .ZDANE | STANDARD_JOB _APPLICATION | N | MAKE_OFFER | SEEK_REFERENCES |
| WYWIAD.NIEUDANY | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| WYWIAD .CANDIDATE_CANCELLED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | INVITED_TO_INTERVIEW |
| WYWIAD .NIE_POKAŻ | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| MAKE_OFFER.ACCEPTED | STANDARD_JOB _APPLICATION | N | SEEK_REFERENCES | |
| MAKE_OFFER.DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| SEEK_REFERENCES .PASSED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .HIRED | |
| SEEK_REFERENCES .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| APPLICATION_CLOSED .HIRED | STANDARD_JOB _APPLICATION | N | ||
| APPLICATION_CLOSED .NOT_HIRED | STANDARD_JOB _APPLICATION | N |
Ponieważ na razie ignorujemy kontekst, Kontekst stanu i Dziecko wyłączone? są wyszarzone. Ograniczyłem również liczbę opcji w tym przykładzie do dwóch ze względu na zwięzłość, chociaż w praktyce nie ma ograniczeń.
Jak to działa?
Wyobraź sobie, że rozmowa została właśnie przeprowadzona, a osoba przeprowadzająca wywiad rejestruje wynik. Aktualizowana tabela bazowa to managed_entity_state . Istnieją dwa logiczne wyniki:PASSED i FAILED. Tak więc obecny managed_entity_state jest aktualizowany o wybrany wynik (wf_state_type_outcome_id ). W przykładowym modelu osoba przeprowadzająca rozmowę kwalifikacyjną może również dołączyć notatki dotyczące rozmowy kwalifikacyjnej.
Jeśli ankieter wybierze PASSED, zostaną mu przedstawione dwie dodatkowe opcje:MAKE_OFFER i SEEK_REFERENCES. To są następne stany w naszym obiegu pracy. Są podobne do go to oświadczenia w programowaniu. W przypadku obu opcji nowy wiersz jest wstawiany do managed_entity_state , przenosząc aplikację o pracę do następnego stanu w procesie przepływu pracy. Użytkownik może ustawić termin na wykonanie tego, wprowadzając due_date .
Z drugiej strony, jeśli ankieter wybierze FAILED, jest tylko jedna opcja:APPLICATION_CLOSED. A więc nowy managed_entity_state wiersz jest wstawiany przy użyciu stanu APPLICATION_CLOSED (wf_state_type_state_id ).
Zobaczysz, że nie ma dostępnych opcji dla stanu APPLICATION_CLOSED. Oznacza to, że osiągnięto koniec procesu przepływu pracy.
Tabela kontekstu
Przyjrzyjmy się konfiguracji procesu aplikacji o pracę techniczną, aby zobaczyć, jaką rolę odgrywa tabela kontekstowa gra:
| Kombinacja STAN.WYNIK (z hierarchii stanów) | Kontekst stanu | Dziecko wyłączone | Opcja 1 | Opcja 2 |
|---|---|---|---|---|
| APPLICATION_RECEIVED .ZAAKCEPTOWANE | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _PRZEGLĄD | |
| APPLICATION_RECEIVED .ODRZUCONY | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTA | |
| APPLICATION_REVIEW .PASSED | PRACA TECHNICZNA _APLIKACJA | N | INVITED_TO _WYWIAD | |
| APPLICATION_REVIEW .FAILED | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTA | |
| INVITED_TO_INTERVIEW .ZAAKCEPTOWANE | PRACA TECHNICZNA _APLIKACJA | N | TEST_APTITUDE | |
| INVITED_TO_INTERVIEW .DECLINED | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTA | |
| TEST_APTITUDE .PASSED | PRACA TECHNICZNA _APLIKACJA | N | WYWIAD | SZUKAJ _REFERENCJI |
| TEST_APTITUDE .FAILED | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTA | |
| WYWIAD .ZADANE | PRACA TECHNICZNA _APLIKACJA | N | MAKE_OFFER | SZUKAJ _REFERENCJI |
| WYWIAD .NIEUDANY | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTA | |
| WYWIAD .CANDIDATE_CANCELLED | PRACA TECHNICZNA _APLIKACJA | T | - | - |
| WYWIAD .NIE_POKAŻ | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTA | INVITED_TO _WYWIAD |
| MAKE_OFFER .ZAAKCEPTOWANE | PRACA TECHNICZNA _APLIKACJA | N | SZUKAJ _REFERENCJI | |
| MAKE_OFFER .ODRZUCONA | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTA | |
| SEEK_REFERENCES .PASSED | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTE.SUKCES | |
| SEEK_REFERENCES .FAILED | PRACA TECHNICZNA _APLIKACJA | N | APLIKACJA _ZAMKNIĘTA | |
| APPLICATION_CLOSED .HIRED | PRACA TECHNICZNA _APLIKACJA | N | ||
| APPLICATION_CLOSED .NOT_HIRED | PRACA TECHNICZNA _APLIKACJA | N | NIEWYSTARCZAJĄCE _DOŚWIADCZENIE | PONAD _KWALIFIKOWANE |
Tutaj kontekst to TECHNICAL_JOB_APPLICATION. Dlaczego to jest ważne? Ponieważ pozwala nam nadpisać wyniki. Pamiętaj, że wcześniej stwierdziliśmy, że możemy ponownie wykorzystać „zespoły” i „podzespoły” w strukturze zestawienia komponentów (BOM). Jest to przydatne, gdy raz coś definiujemy i wykorzystujemy ponownie, ale może to być również zbyt sztywne. A co, jeśli nie chcemy używać wszystkiego ponownie?
Wstawiając workflow_state_context między workflow_state_hierarchy i workflow_state_option , możemy zarówno ponownie używać, jak i zastępować wyniki. W tym modelu możemy zdefiniować, czy wynik jest włączony, czy wyłączony dla różnych procesów.
W powyższym przykładzie kombinacja INTERVIEW.CANDIDATE_CANCELLED jest wyłączona. Innymi słowy, mówimy, że jest to po prostu niedopuszczalny wynik w przypadku aplikacji o pracę techniczną. W związku z tym osoba przeprowadzająca rozmowę kwalifikacyjną nie będzie mogła jej wybrać podczas rejestrowania wyniku technicznej rozmowy kwalifikacyjnej, ponieważ nasze zapytanie wybiera tylko opcje, w których workflow_state_context.child_disabled = ‘N’ .
Ponieważ workflow_state_option nie jest bezpośrednim dzieckiem workflow_state_hierarchy , musimy zdefiniować osobny zestaw opcji za każdym razem, gdy używany jest stan. Ale ten kompromis pozwala nam precyzyjnie dostroić opcje dla każdego procesu.
Wyniki kwalifikujące
Mamy również możliwość zdefiniowania bardziej szczegółowych kwalifikatorów dla wyników. Można to zrobić na dwa sposoby:
- Możesz utworzyć czwarty poziom w swoim zestawieniu komponentów, aby zdefiniować kwalifikatory pod wynikami w hierarchii. Przy takim podejściu należy dołożyć należytej staranności. Na przykład wynik FAILED jest używany dla różnych stanów. Czy chcesz mieć te same kwalifikacje dla różnych stanów FAILED? Może nie.
- Możesz zdefiniować swoje kwalifikatory w
workflow_state_typeale nie przywiązuj ich do żadnej hierarchii; są wolnostojące. Następnie używaszworkflow_state_optionaby wyświetlić kwalifikatory dla konkretnego kontekstu wyniku. To właśnie pokazuje powyższa konfiguracja, gdzie kwalifikatory OVER_QUALIFIED i INSUFFICIENT_EXPERIENCE są wymienione jako opcje dla wyniku APPLICATION_CLOSED.NOT_HIRED.
W obu przypadkach aplikacja musi rozpoznać, że wybrano kwalifikator, a nie stan lub wynik — workflow_level_type wskaże to – i zaktualizuje managed_entity_state.wf_state_type_qual_id z wybraną wartością.
Niektóre dane konfiguracji tabeli
Możesz chcieć zobaczyć podstawowe dane konfiguracyjne, tabela po tabeli. Tutaj mamy ids i type_keys odnoszą się do nawiasów. Ze względu na zwięzłość prezentowane są tylko wartości związane z artykułem.
workflow_level_type
| id | type_key |
|---|---|
| 1 | PROCES |
| 2 | STAN |
| 3 | WYNIK |
| 4 | KWALIFIKATOR |
workflow_state_type
| id | type_key | workflow_level_type_id |
|---|---|---|
| 1 | STANDARD_JOB_APPLICATION | 1 (PROCES) |
| 2 | TECHNICAL_APPLICATION | 1 (PROCES) |
| 3 | WYWIAD | 2 (STAN) |
| 4 | ZALICZONE | 3 (WYNIK) |
| 5 | NIEUDAŁO SIĘ | 3 (WYNIK) |
| 6 | MAKE_OFFER | 2 (STAN) |
| 7 | SEEK_REFERENCES | 2 (STAN) |
| 8 | APPLICATION_CLOSED | 2 (STAN) |
| 9 | ZATRUDNIONY | 3 (WYNIK) |
| 10 | NOT_HIRED | 3 (WYNIK) |
| 11 | NIESUFFICIENT_EXPERIENCE | 4 (KWALIFIKATOR) |
| 12 | OVER_QUALIFIED | 4 (KWALIFIKATOR) |
workflow_state_hierarchy
| id | state_type_parent_id | state_type_child_id |
|---|---|---|
| 1 | 1 (STANDARD_JOB_APPLICATION) | 3 (WYWIAD) |
| 2 | 2 (TECHNICAL_JOB_APPLICATION) | 3 (WYWIAD) |
| 3 | 3 (WYWIAD) | 4 (ZALICZONE) |
| 4 | 3 (WYWIAD) | 5 (NIEUDANE) |
| 5 | 1 (STANDARD_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
| 6 | 2 (TECHNICAL_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
| 7 | 8 (APPLICATION_CLOSED) | 9 (ZAJĘTY) |
| 8 | 8 (APPLICATION_CLOSED) | 10 (NOT_HIRED) |
workflow_state_context
| id | state_type_id | state_hierarchy_id | child_disabled |
|---|---|---|---|
| 1 | 1 (STANDARD_JOB_ APLIKACJA) | 3 (WYWIAD.ZADANE) | N |
| 2 | 1 (STANDARD_JOB_ APLIKACJA) | 4 (WYWIAD. NIEUDANY) | N |
| 3 | 1 (STANDARD_JOB_ APLIKACJA) | 7 (APPLICATION_CLOSED. ZAJĘTY) | N |
| 4 | 1 (STANDARD_JOB_ APLIKACJA) | 5 (APPLICATION_CLOSED. NOT_HIRED) | N |
| 5 | 2 (APLIKACJA TECHNICZNA) | 6 (APPLICATION_CLOSED. NOT_HIRED) | N |
workflow_state_option
| id | state_context_id | state_type_id |
|---|---|---|
| 1 | 1 (STANDARD_JOB_ APLIKACJA. WYWIAD. ZALICZONY) | 6 (MAKE_OFFER) |
| 2 | 1 (STANDARD_JOB_ APLIKACJA. WYWIAD. ZALICZONY) | 7 (SEEK_REFERENCES) |
| 3 | 2 (APLIKACJA STANDARD_JOB_. WYWIAD. NIEUDANE) | 8 (APPLICATION_CLOSED) |
| 4 | 5 (TECHNICAL_JOB_ APPLICATION. APPLICATION_CLOSED. NOT_HIRED) | 11 (INSUFFICIENT_EXPERIENCE) |
| 5 | 5 (TECHNICAL _JOB_ APPLICATION. APPLICATION_CLOSED. NOT_HIRED) | 12 (OVER_QUALIFIED) |
Oczywiście konfiguracja tego jest dość trudna. Powinien być najlepiej zarządzany za pomocą aplikacji z przyjaznym dla użytkownika interfejsem.
Alternatywne sekwencje
Zauważysz, że wiele tabel ma kolumnę o nazwie alt_sequence . Służy do porządkowania listy wartości dla różnych wyborów prezentowanych użytkownikowi. Zazwyczaj będzie to w kolejności malejącej w zależności od użycia, z najczęściej używanymi opcjami u góry.
Chociaż w tym artykule opisano aplikacje o pracę, model może być używany w wielu typach przepływów pracy, w których stan encji musi być zarządzany w czasie. Alternatywnie model może służyć jako wzór do dostosowania do własnych szczególnych wymagań.
