Använda konfigurationstabeller för att definiera det faktiska arbetsflödet

Den första delen av den här serien introducerade några grundläggande steg för att hantera livscykeln för alla enheter i en databas. Vår andra och sista del kommer att visa dig hur du definierar det faktiska arbetsflödet med hjälp av ytterligare konfigurationstabeller. Det är här användaren presenteras med tillåtna alternativ varje steg på vägen. Vi kommer också att visa en teknik för att kringgå strikt återanvändning av "sammansättningar" och "undersammansättningar" i en styckliststruktur.

Definiera alternativen

Del 1 introducerade de centrala arbetsflödestabellerna och hur dessa enkelt kan införlivas i din databas. Vad vi behöver nu är något som vägleder användaren att välja nästa logiska tillstånd – något som definierar ett logiskt arbetsflöde .

Diagrammet nedan definierar alla komponenter i en arbetsflödesdatabasmodell:

Två konfigurationstabeller, workflow_state_option och workflow_state_context , har lagts till i modellen. Vi börjar med alternativtabellen, som definierar de tillåtna nästa tillstånden . När dess funktion har förståtts återgår vi till kontexttabellen och förklarar rollen den spelar.

Tillåtna nästa stater

Tabellerna som följer är lite som en SQL-vy över våra konfigurationstabeller. Här har vi gömt tabellkopplingarna och vi tittar bara på kombinationerna av type_keys . Så låt oss överväga varje STATE.OUTCOME kombination och definiera alternativen tillgänglig för användaren:

Eftersom vi ignorerar sammanhang för tillfället, State Context och Barn inaktiverat? är nedtonade. Jag har också begränsat antalet alternativ i det här exemplet till två för korthetens skull, även om det i praktiken inte finns någon gräns.

Så hur fungerar det här?

Föreställ dig att intervjun precis har genomförts och intervjuaren spelar in resultatet. Den underliggande tabellen som uppdateras är managed_entity_state . Det finns två logiska resultat:godkänd och misslyckad. Så den nuvarande managed_entity_state uppdateras med det valda resultatet (wf_state_type_outcome_id ). I exempelmodellen kan intervjuaren även inkludera några anteckningar om intervjun.

Om intervjuaren väljer PASSED, presenteras de för ytterligare två alternativ:MAKE_OFFER och SEEK_REFERENCES. Det här är nästa stater i vårt arbetsflöde. De liknar go to uttalanden i programmering. För båda alternativen infogas en ny rad i managed_entity_state , flyttar jobbansökan till nästa tillstånd i arbetsflödesprocessen. Användaren kan ställa in en deadline för detta genom att ange en due_date .

Å andra sidan, om intervjuaren väljer FAILED, finns det bara ett alternativ:APPLICATION_CLOSED. Så en ny managed_entity_state rad infogas med tillståndet APPLICATION_CLOSED (wf_state_type_state_id ).

Du kommer att se att det inte finns några tillgängliga alternativ för tillståndet APPLICATION_CLOSED. Detta betyder att slutet av arbetsflödesprocessen har nåtts.

Kontexttabellen

Låt oss titta på konfigurationen för den tekniska jobbansökningsprocessen för att se vilken roll sammanhangstabellen spelar:

Här är sammanhanget TECHNICAL_JOB_APPLICATION. Varför är detta viktigt? Eftersom det tillåter oss att åsidosätta resultat. Kom ihåg att vi tidigare har sagt att vi kan återanvända "sammansättningar" och "undersammansättningar" i en stycklista (Bom of Materials). Detta är användbart när vi definierar något en gång och återanvänder det, men det kan också vara för stelt. Tänk om vi inte vill återanvända allt?

Genom att infoga workflow_state_context mellan workflow_state_hierarchy och workflow_state_option , kan vi både återanvända och åsidosätta resultat. I den här modellen kan vi definiera om ett resultat är aktiverat eller inaktiverat för olika processer.

I exemplet ovan är kombinationen INTERVIEW.CANDIDATE_CANCELLED inaktiverad. Med andra ord, vi säger att det helt enkelt inte är ett tillåtet resultat för tekniska jobbansökningar. Följaktligen kommer intervjuaren inte att kunna välja det när han spelar in resultatet av en teknisk anställningsintervju eftersom vår fråga endast väljer alternativ där workflow_state_context.child_disabled = ‘N’ .

Eftersom workflow_state_option är inte ett direkt underordnat workflow_state_hierarchy , måste vi definiera en separat uppsättning alternativ varje gång ett tillstånd används. Men denna avvägning gör att vi kan finjustera alternativen för varje process.

Kvalificerande resultat

Vi har också möjlighet att definiera mer detaljerade kvalspel för resultat. Det finns två sätt att göra detta:

1. Du kan skapa en fjärde nivå i din BOM för att definiera kvalificeringar under resultat i hierarkin. Due diligence bör vidtas med detta tillvägagångssätt. Till exempel används FAILED-resultatet för olika tillstånd. Vill du ha samma kvalificeringar för olika FAILED-tillstånd? Kanske inte.
2. Du kan definiera dina kvalificerare i workflow_state_type men inte binda dem till någon hierarki; de är fristående. Du använder sedan workflow_state_option för att lista kvalificeringarna för det specifika resultatkontexten. Det här är vad konfigurationen ovan visar, där OVER_QUALIFIED- och INSUFFICIENT_EXPERIENCE-kvalificeringarna är listade som alternativ för APPLICATION_CLOSED.NOT_HIRED-resultatet.

I båda fallen måste applikationen känna igen att en kvalificering har valts snarare än ett tillstånd eller ett resultat – workflow_level_type kommer att indikera detta – och uppdatera managed_entity_state.wf_state_type_qual_id med det valda värdet.

Vissa tabellkonfigurationsdata

Du kanske vill se de underliggande konfigurationsdata, tabell för tabell. Här har vi ids och type_keys de hänvisar till inom parentes. För korthetens skull presenteras endast värden relaterade till artikeln.

workflow_level_type

workflow_state_type

workflow_state_hierarchy

workflow_state_context

workflow_state_option

Det är klart att det är ganska knepigt att ställa in det här. Det ska helst administreras via en applikation med ett användarvänligt gränssnitt.

Alternativa sekvenser

Du kommer att notera att ett antal tabeller har en kolumn som heter alt_sequence . Detta används för att beställa värdelistan för de olika valen som presenteras för användaren. Vanligtvis kommer detta att vara i fallande ordning baserat på användning, med de mest använda alternativen överst.

Även om den här artikeln beskrev jobbansökningar, kan modellen användas för många typer av arbetsflöden där tillståndet för en enhet måste hanteras över tid. Alternativt kan modellen fungera som ett mönster att anpassa för dina egna specifika krav.