Použití konfiguračních tabulek k definování skutečného pracovního postupu

První díl této série představil některé základní kroky pro správu životního cyklu libovolné entity v databázi. Naše druhá a poslední část vám ukáže, jak definovat skutečný pracovní postup pomocí dalších konfiguračních tabulek. Toto je místo, kde se uživateli na každém kroku zobrazí přípustné možnosti. Také si ukážeme techniku, jak obejít striktní opětovné použití „sestav“ a „podsestav“ ve struktuře kusovníku.

Definování možností

Část 1 představila základní tabulky pracovních postupů a to, jak je lze snadno začlenit do vaší databáze. Nyní potřebujeme něco, co uživatele povede k výběru dalšího logického stavu – něco, co definuje logický pracovní postup .

Níže uvedený diagram definuje všechny součásti databázového modelu pracovního postupu:

Dvě konfigurační tabulky, workflow_state_option a workflow_state_context , byly přidány do modelu. Začneme tabulkou možností, která definuje další povolené stavy . Jakmile pochopíme jeho funkci, vrátíme se ke kontextové tabulce a vysvětlíme, jakou roli hraje.

Povolené další stavy

Následující tabulky jsou trochu jako pohled SQL napříč našimi konfiguračními tabulkami. Zde jsme skryli spojení tabulek a právě se díváme na kombinace type_keys . Podívejme se tedy na každý STATE.OUTCOME kombinaci a definujte možnosti k dispozici uživateli:

Protože kontext prozatím ignorujeme, State Context a Dítě se zdravotním postižením? jsou zašedlé. Kvůli stručnosti jsem také omezil počet možností v tomto příkladu na dvě, i když v praxi neexistuje žádné omezení.

Jak to tedy funguje?

Představte si, že rozhovor právě proběhl a tazatel zaznamenává výsledek. Aktualizovaná podkladová tabulka je managed_entity_state . Existují dva logické výsledky:PASSED a FAILED. Tedy aktuální managed_entity_state se aktualizuje o vybraný výsledek (wf_state_type_outcome_id ). Ve vzorovém modelu může tazatel také zahrnout několik poznámek k rozhovoru.

Pokud tazatel vybere PASSED, zobrazí se mu další dvě možnosti:MAKE_OFFER a SEEK_REFERENCES. Toto jsou další stavy v našem pracovním postupu. Jsou podobné jako go to příkazy v programování. Pro obě možnosti se do managed_entity_state vloží nový řádek , přesunutí aplikace úlohy do dalšího stavu v procesu workflow. Uživatel může nastavit konečný termín zadáním due_date .

Na druhou stranu, pokud tazatel vybere FAILED, existuje pouze jedna možnost:APPLICATION_CLOSED. Takže nový managed_entity_state řádek je vložen pomocí stavu APPLICATION_CLOSED (wf_state_type_state_id ).

Uvidíte, že pro stav APPLICATION_CLOSED nejsou k dispozici žádné možnosti. To znamená, že bylo dosaženo konce pracovního postupu.

Kontextová tabulka

Podívejme se na konfiguraci pro proces technické žádosti o zaměstnání, abychom viděli, jakou roli hraje kontextová tabulka hraje:

Zde je kontext TECHNICAL_JOB_APPLICATION. Proč je toto důležité? Protože nám to umožňuje přepsat výsledky. Pamatujte, že jsme již dříve uvedli, že můžeme znovu použít „sestavy“ a „podsestavy“ ve struktuře kusovníku (BOM). To je užitečné, když něco definujeme jednou a znovu to použijeme, ale také to může být příliš rigidní. Co když nechceme všechno znovu použít?

Vložením workflow_state_context mezi workflow_state_hierarchy a workflow_state_option , můžeme výsledky znovu použít i přepsat. V tomto modelu můžeme definovat, zda je výsledek povolen nebo zakázán pro různé procesy.

Ve výše uvedeném příkladu je kombinace INTERVIEW.CANDIDATE_CANCELLED zakázána. Jinými slovy, říkáme, že to prostě není přípustný výsledek pro technické žádosti o zaměstnání. V důsledku toho jej tazatel nebude moci vybrat při zaznamenávání výsledku technického pohovoru, protože náš dotaz vybere pouze možnosti, kde workflow_state_context.child_disabled = ‘N’ .

Protože workflow_state_option není přímým potomkem workflow_state_hierarchy , musíme při každém použití stavu definovat samostatnou sadu možností. Ale tento kompromis nám umožňuje jemně vyladit možnosti pro každý proces.

Kvalifikační výsledky

Máme také možnost definovat podrobnější kvalifikátory pro výsledky. Existují dva způsoby, jak to udělat:

1. Můžete vytvořit čtvrtou úroveň v kusovníku a definovat kvalifikátory pod výsledky v hierarchii. S tímto přístupem by měla být provedena náležitá péče. Například výsledek FAILED se používá pro různé stavy. Chcete mít stejné kvalifikátory pro různé stavy FAILED? Možná ne.
2. Své kvalifikátory můžete definovat v workflow_state_type ale nevázat je na žádnou hierarchii; jsou volně stojící. Poté použijete workflow_state_option k seznamu kvalifikátorů pro konkrétní kontext výsledku. To je to, co ukazuje výše uvedená konfigurace, kde jsou kvalifikátory OVER_QUALIFIED a INSUFFICIENT_EXPERIENCE uvedeny jako možnosti pro výsledek APPLICATION_CLOSED.NOT_HIRED.

V obou případech musí aplikace rozpoznat, že byl vybrán kvalifikátor, nikoli stav nebo výsledek – workflow_level_type toto označí – a aktualizuje managed_entity_state.wf_state_type_qual_id s vybranou hodnotou.

Některá konfigurační data tabulky

Možná byste chtěli vidět základní konfigurační data tabulku po tabulce. Zde máme ids a type_keys odkazují v závorkách. Z důvodu stručnosti jsou uvedeny pouze hodnoty související s článkem.

workflow_level_type

workflow_state_type

workflow_state_hierarchy

workflow_state_context

workflow_state_option

Je jasné, že toto nastavení je docela složité. Měl by být přednostně spravován prostřednictvím aplikace s uživatelsky přívětivým rozhraním.

Alternativní sekvence

Všimněte si, že řada tabulek má sloupec nazvaný alt_sequence . Toto se používá k uspořádání seznamu hodnot pro různé výběry prezentované uživateli. Obvykle to bude v sestupném pořadí podle použití, přičemž nejčastěji používané možnosti budou nahoře.

I když tento článek popisoval pracovní aplikace, model lze použít pro mnoho typů pracovních postupů, kde je třeba řídit stav entity v průběhu času. Alternativně může model sloužit jako vzor k přizpůsobení pro vaše vlastní konkrétní požadavky.