Първата част от тази серия представи някои основни стъпки за управление на жизнения цикъл на всеки обект в база данни. Нашата втора и последна част ще ви покаже как да дефинирате действителния работен процес с помощта на допълнителни таблици за конфигурация. Това е мястото, където на потребителя се представят допустими опции на всяка стъпка от пътя. Ще демонстрираме също така техника за заобикаляне на стриктното повторно използване на „сглобки“ и „подсглобки“ в структурата на спецификацията.
Дефиниране на опциите
Част 1 представи основните таблици на работния процес и как те могат лесно да бъдат включени във вашата база данни. Това, от което се нуждаем сега, е нещо, което да насочи потребителя да избере следващото логическо състояние – нещо, което дефинира логически работен поток .
Диаграмата по-долу дефинира всички компоненти на модел на база данни на работния процес:
Две конфигурационни таблици, workflow_state_option и workflow_state_context , са добавени към модела. Ще започнем с таблицата с опции, която дефинира допустимите следващи състояния . След като функцията му бъде разбрана, ще се върнем към контекстната таблица и ще обясним ролята, която играе.
Допустими следващи състояния
Таблиците, които следват, са нещо като SQL изглед в нашите конфигурационни таблици. Тук сме скрили присъединяванията на таблицата и просто разглеждаме комбинациите от type_keys . Така че нека разгледаме всеки STATE.OUTCOME комбинация и дефинирайте опциите на разположение на потребителя:
| Комбинация STATE.OUTCOME (от йерархията на състоянието) | Контекст на състоянието | Дете с увреждания | Вариант 1 | Вариант 2 |
|---|---|---|---|---|
| ПРИЛОЖЕНИЕ_ПОЛУЧЕНО . ПРИЕТО | STANDARD_JOB _APPLICATION | N | ПРЕГЛЕД НА APPLICATION_PREGLED | |
| ПРИЛОЖЕНИЕ_ПОЛУЧЕНО .ОТХВЪРЛЕНО | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| ПРЕГЛЕД НА APPLICATION_REVIEW .ПРЕДЪЛЖЕНО | STANDARD_JOB _APPLICATION | N | INVITED_TO_INTERVIEW | |
| ПРЕГЛЕД НА APPLICATION_REVIEW .НЕУДАДЕНО | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| ПОКАНЕН_ЗА_ИНТЕРВЮ . ПРИЕТО | STANDARD_JOB _APPLICATION | N | ИНТЕРВЮ | |
| ПОКАНЕН_ЗА_ИНТЕРВЮ .ОТКЛЮЧЕН | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| ИНТЕРВЮ .ПРЕДЪЛЖАНО | STANDARD_JOB _APPLICATION | N | MAKE_OFFER | SEEK_REFERENCES |
| ИНТЕРВЮ.НЕУДАДЕНО | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| ИНТЕРВЮ .CANDIDATE_CANCELLED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | INVITED_TO_INTERVIEW |
| ИНТЕРВЮ .НЕ_ШОУ | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| MAKE_OFFER.ACCEPTED | STANDARD_JOB _APPLICATION | N | SEEK_REFERENCES | |
| MAKE_OFFER.DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| ТЪРСЕТЕ_РЕФЕРЕНЦИИ .ПРЕДЪЛЖЕНО | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .HIRED | |
| SEEK_REFERENCES .НЕУДАДЕНО | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| APPLICATION_CLOSED .НАЕТО | STANDARD_JOB _APPLICATION | N | ||
| APPLICATION_CLOSED .NOT_HIRED | STANDARD_JOB _APPLICATION | N |
Тъй като засега игнорираме контекста, Контекст на състоянието и Дете с увреждания? са оцветени в сиво. Освен това ограничих броя на опциите в този пример до две за краткост, въпреки че на практика няма ограничение.
И така, как става това?
Представете си, че интервюто току-що е проведено и интервюиращият записва резултата. Основната таблица, която се актуализира, е managed_entity_state . Има два логически резултата:ПРЕДЪРЖДАНО и НЕУСПЕШНО. Така че текущото managed_entity_state се актуализира с избрания резултат (wf_state_type_outcome_id ). В примерния модел интервюиращият може да включи и някои бележки за интервюто.
Ако интервюиращият избере ПРЕДЪРЖДАНО, му се представят още две опции:MAKE_OFFER и SEEK_REFERENCES. Това са следващите състояния в нашия работен процес. Те са подобни на go to изявления в програмирането. За всяка опция се вмъква нов ред в managed_entity_state , преместване на заявлението за работа в следващото състояние в процеса на работния процес. Потребителят може да зададе краен срок за това, като въведе due_date .
От друга страна, ако интервюиращият избере FAILED, има само една опция:APPLICATION_CLOSED. Така че нов managed_entity_state ред се вмъква с помощта на състоянието APPLICATION_CLOSED (wf_state_type_state_id ).
Ще видите, че няма налични опции за състоянието APPLICATION_CLOSED. Това означава, че краят на процеса на работния процес е достигнат.
Таблица на контекста
Нека разгледаме конфигурацията за техническия процес на кандидатстване за работа, за да видим каква роля има контекстната таблица играе:
| СЪСТАВ.ИЗХОД Комбинация (от йерархията на състоянието) | Контекст на състоянието | Дете с увреждания | Вариант 1 | Вариант 2 |
|---|---|---|---|---|
| ПРИЛОЖЕНИЕ_ПОЛУЧЕНО . ПРИЕТО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ПРЕГЛЕД | |
| ПРИЛОЖЕНИЕ_ПОЛУЧЕНО .ОТХВЪРЛЕНО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН | |
| ПРЕГЛЕД НА APPLICATION_REVIEW .ПРЕДЪЛЖЕНО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПОКАНЕН_ЗА _ИНТЕРВЮ | |
| ПРЕГЛЕД НА APPLICATION_REVIEW .НЕУДАДЕНО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН | |
| ПОКАНЕН_ЗА_ИНТЕРВЮ . ПРИЕТО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | TEST_APTITUDE | |
| ПОКАНЕН_ЗА_ИНТЕРВЮ .ОТКЛЮЧЕН | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН | |
| TEST_APTITUDE .ПРЕДЛАГАНО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ИНТЕРВЮ | ТЪРСЕТЕ _РЕФЕРЕНЦИИ |
| TEST_APTITUDE .НЕУСПЕШЕН | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН | |
| ИНТЕРВЮ .ПРЕДЪЛЖЕН | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРАВЕТЕ_ПРЕДЛОЖЕНИЕ | ТЪРСЕТЕ _РЕФЕРЕНЦИИ |
| ИНТЕРВЮ .НЕУспешно | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН | |
| ИНТЕРВЮ .CANDIDATE_CANCELLED | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | Y | - | - |
| ИНТЕРВЮ .НЕ_ШОУ | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН | ПОКАНЕН_ЗА _ИНТЕРВЮ |
| НАПРАВЕТЕ_ПРЕДЛОЖЕНИЕ . ПРИЕТО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ТЪРСЕТЕ _РЕФЕРЕНЦИИ | |
| НАПРАВЕТЕ_ПРЕДЛОЖЕНИЕ .ОТКЛАНА | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН | |
| ТЪРСЕТЕ_РЕФЕРЕНЦИИ .ПРЕДЪЛЖЕНО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН.УСПЕХ | |
| SEEK_REFERENCES .НЕУДАДЕНО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ПРИЛОЖЕНИЕ _ЗАТВОРЕН | |
| APPLICATION_CLOSED .НАЕТО | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | ||
| APPLICATION_CLOSED .NOT_HIRED | ТЕХНИЧЕСКА_РАБОТА _ПРИЛОЖЕНИЕ | N | НЕДОСТАТЪЧЕН _ОПИТ | НАД _КВАЛИФИЦИРАН |
Тук контекстът е TECHNICAL_JOB_APPLICATION. Защо това е важно? Защото ни позволява да отменяме резултатите. Не забравяйте, че по-рано заявихме, че можем да използваме повторно „сглобки“ и „подсглобки“ в структура на спецификация на материалите (BOM). Това е полезно, когато дефинираме нещо веднъж и го използваме повторно, но също така може да бъде твърде твърдо. Ами ако не искаме да използваме всичко отново?
Чрез вмъкване на workflow_state_context между workflow_state_hierarchy и workflow_state_option , можем както да използваме повторно, така и да отменяме резултатите. В този модел можем да определим дали даден резултат е активиран или деактивиран за различни процеси.
В горния пример комбинацията INTERVIEW.CANDIDATE_CANCELLED е деактивирана. С други думи, ние казваме, че това просто не е допустим резултат за технически кандидатури за работа. Следователно интервюиращият няма да може да го избере, когато записва резултата от техническо интервю за работа, тъй като нашата заявка избира само опции, където workflow_state_context.child_disabled = ‘N’ .
Тъй като workflow_state_option не е пряко дъщерно на workflow_state_hierarchy , трябва да дефинираме отделен набор от опции всеки път, когато се използва състояние. Но този компромис ни позволява да настроим фино опциите за всеки процес.
Квалифициращи резултати
Имаме и възможността да дефинираме по-подробни квалификатори за резултати. Има два начина да направите това:
- Можете да създадете четвърто ниво във вашата спецификация, за да дефинирате квалификатори под резултати в йерархията. При този подход трябва да се подложи на дължимата грижа. Например, резултатът FAILED се използва за различни състояния. Искате ли да имате едни и същи квалификации за различни FAILED състояния? Може би не.
- Можете да дефинирате своите квалификатори в
workflow_state_typeно не ги обвързвайте с никаква йерархия; те са свободно стоящи. След това използватеworkflow_state_optionза изброяване на квалификаторите за конкретния контекст на резултата. Това показва горната конфигурация, където квалификаторите OVER_QUALIFIED и INSUFFICIENT_EXPERIENCE са изброени като опции за резултата APPLICATION_CLOSED.NOT_HIRED.
И в двата случая приложението трябва да разпознае, че е избран квалификатор, а не състояние или резултат – workflow_level_type ще посочи това – и актуализира managed_entity_state.wf_state_type_qual_id с избраната стойност.
Някои данни за конфигурация на таблица
Може да искате да видите основните конфигурационни данни, таблица по таблица. Тук имаме ids и type_keys те се позовават в скоби. За краткост са представени само стойности, свързани със статията.
workflow_level_type
| id | тип_ключ |
|---|---|
| 1 | ПРОЦЕС |
| 2 | ДЪРЖАВА |
| 3 | ИЗХОД |
| 4 | КВАЛИФИКАТОР |
тип_състояние_на работен поток
| id | тип_ключ | workflow_level_type_id |
|---|---|---|
| 1 | STANDARD_JOB_APPLICATION | 1 (ПРОЦЕС) |
| 2 | ТЕХНИЧЕСКО_ПРИЛОЖЕНИЕ | 1 (ПРОЦЕС) |
| 3 | ИНТЕРВЮ | 2 (ДЪРЖАВА) |
| 4 | ПРЕДЪРЖДАНО | 3 (ИЗХОД) |
| 5 | НЕУСПЕШНО | 3 (ИЗХОД) |
| 6 | НАПРАВЕТЕ_ПРЕДЛОЖЕНИЕ | 2 (ДЪРЖАВАНЕ) |
| 7 | SEEK_REFERENCES | 2 (ДЪРЖАВАНЕ) |
| 8 | APPLICATION_CLOSED | 2 (ДЪРЖАВАНЕ) |
| 9 | НАЕТО | 3 (ИЗХОД) |
| 10 | НЕ_НАЕТИ | 3 (ИЗХОД) |
| 11 | НЕДОСТАТЪЧЕН_ОПИТ | 4 (QUALIFIER) |
| 12 | НАД_КВАЛИФИРАН | 4 (QUALIFIER) |
йерархия_на_състояние на работния поток
| id | тип_на_родител | type_type_child_id |
|---|---|---|
| 1 | 1 (STANDARD_JOB_APPLICATION) | 3 (ИНТЕРВЮ) |
| 2 | 2 (ТЕХНИЧЕСКО_ЗАДОБНО_ПРИЛОЖЕНИЕ) | 3 (ИНТЕРВЮ) |
| 3 | 3 (ИНТЕРВЮ) | 4 (ПРЕДЪРЖАНО) |
| 4 | 3 (ИНТЕРВЮ) | 5 (НЕУСПЕШЕН) |
| 5 | 1 (STANDARD_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
| 6 | 2 (ТЕХНИЧЕСКО_РАБОТА_ПРИЛОЖЕНИЕ) | 8 (APPLICATION_CLOSED) |
| 7 | 8 (APPLICATION_CLOSED) | 9 (НАЕТИ) |
| 8 | 8 (APPLICATION_CLOSED) | 10 (НЕ_НАЕТИ) |
workflow_state_context
| id | идентификатор_тип_на_състояние | jote_hierarchy_id | child_disabled |
|---|---|---|---|
| 1 | 1 (STANDARD_JOB_ APPLICATION) | 3 (ИНТЕРВЮ.ПРЕДЪЛЖАНО) | N |
| 2 | 1 (STANDARD_JOB_ APPLICATION) | 4 (ИНТЕРВЮ.НЕУДАДЕНО) | N |
| 3 | 1 (STANDARD_JOB_ APPLICATION) | 7 (APPLICATION_CLOSED. НАЕТО) | N |
| 4 | 1 (STANDARD_JOB_ APPLICATION) | 5 (APPLICATION_CLOSED. NOT_HIRED) | N |
| 5 | 2 (ТЕХНИЧЕСКО_ПРИЛОЖЕНИЕ) | 6 (APPLICATION_CLOSED. NOT_HIRED) | N |
option_state_workflow
| id | идентификатор_на_контекста на_състояние | идентификатор_тип_на_състояние |
|---|---|---|
| 1 | 1 (STANDARD_JOB_ APPLICATION. ИНТЕРВЮ. ПРЕДЪЛЖЕНО) | 6 (НАПРАВЕТЕ_ПРЕДЛОЖЕНИЕ) |
| 2 | 1 (STANDARD_JOB_ APPLICATION. ИНТЕРВЮ. ПРЕДЪЛЖЕНО) | 7 (SEEK_REFERENCES) |
| 3 | 2 (STANDARD_JOB_ APPLICATION. ИНТЕРВЮ. НЕУСПЕШЕН) | 8 (APPLICATION_CLOSED) |
| 4 | 5 (ТЕХНИЧЕСКА_РАБОТА_ ПРИЛОЖЕНИЕ. ПРИЛОЖЕНИЕ_ЗАТВОРЕНО. НЕ_НАЕТИ) | 11 (НЕДОСТАТЪЧЕН_ОПИТ) |
| 5 | 5 (ТЕХНИЧЕСКО _РАБОТА_ ПРИЛОЖЕНИЕ. ПРИЛОЖЕНИЕ_ЗАТВОРЕН. НЕ_НАЕТО) | 12 (OVER_QUALIFIED) |
Ясно е, че настройката е доста трудна. За предпочитане е да се администрира чрез приложение с удобен за потребителя интерфейс.
Алтернативни последователности
Ще забележите, че редица таблици имат колона, наречена alt_sequence . Това се използва за подреждане на списъка със стойности за различните селекции, представени на потребителя. Обикновено това ще бъде в низходящ ред въз основа на употребата, като най-често използваните опции са в горната част.
Въпреки че тази статия описва приложения за работа, моделът може да се използва за много видове работни потоци, при които състоянието на обекта трябва да се управлява във времето. Като алтернатива, моделът може да служи като модел, който да персонализирате според вашите специфични изисквания.
