Brug af konfigurationstabeller til at definere den faktiske arbejdsgang

Den første del af denne serie introducerede nogle grundlæggende trin til styring af livscyklussen for enhver enhed i en database. Vores anden og sidste del vil vise dig, hvordan du definerer den faktiske arbejdsgang ved hjælp af yderligere konfigurationstabeller. Det er her, brugeren præsenteres for tilladte muligheder hvert trin på vejen. Vi vil også demonstrere en teknik til at omgå den strenge genbrug af "samlinger" og "undersamlinger" i en styklistestruktur.

Definition af muligheder

Del 1 introducerede kernearbejdsgangstabellerne, og hvordan disse nemt kan inkorporeres i din database. Det, vi har brug for nu, er noget til at guide brugeren til at vælge den næste logiske tilstand – noget, der definerer en logisk arbejdsgang .

Diagrammet nedenfor definerer alle komponenterne i en workflow-databasemodel:

To konfigurationstabeller, workflow_state_option og workflow_state_context , er blevet tilføjet til modellen. Vi starter med indstillingstabellen, som definerer de tilladelige næste tilstande . Når dens funktion er forstået, vender vi tilbage til konteksttabellen og forklarer den rolle, den spiller.

Tilladte næste stater

Tabellerne, der følger, ligner lidt en SQL-visning på tværs af vores konfigurationstabeller. Her har vi skjult tabelsammenføjningerne, og vi ser bare på kombinationerne af type_keys . Så lad os overveje hvert STATE.OUTCOME kombination og definer indstillingerne tilgængelig for brugeren:

Fordi vi ignorerer kontekst for nu, Statskontekst og Børn deaktiveret? er nedtonede. Jeg har også begrænset antallet af muligheder i dette eksempel til to for korthedens skyld, selvom der i praksis ikke er nogen grænse.

Så hvordan virker dette?

Forestil dig, at interviewet netop er blevet gennemført, og at intervieweren optager resultatet. Den underliggende tabel, der opdateres, er managed_entity_state . Der er to logiske udfald:BESTÅET og IKKE. Så den nuværende managed_entity_state er opdateret med det valgte resultat (wf_state_type_outcome_id ). I eksempelmodellen kan intervieweren også inkludere nogle noter om interviewet.

Hvis intervieweren vælger PASSED, præsenteres de for yderligere to muligheder:MAKE_OFFER og SEEK_REFERENCES. Dette er de næste stater i vores arbejdsgang. De ligner go to udsagn i programmering. For begge muligheder indsættes en ny række i managed_entity_state , flytte jobansøgningen til den næste tilstand i workflow-processen. Brugeren kan sætte en deadline for dette ved at indtaste en due_date .

På den anden side, hvis intervieweren vælger FAILED, er der kun én mulighed:APPLICATION_CLOSED. Så en ny managed_entity_state række er indsat ved hjælp af APPLICATION_CLOSED-tilstanden (wf_state_type_state_id ).

Du vil se, at der ikke er nogen tilgængelige muligheder for tilstanden APPLICATION_CLOSED. Dette betyder, at slutningen af ​​workflow-processen er nået.

Konteksttabellen

Lad os se på konfigurationen for den tekniske jobansøgningsproces for at se, hvilken rolle konteksttabellen spiller:

Her er konteksten TECHNICAL_JOB_APPLICATION. Hvorfor er dette vigtigt? Fordi det giver os mulighed for at tilsidesætte resultater. Husk, at vi tidligere har udtalt, at vi kan genbruge 'samlinger' og 'undersamlinger' i en styklistestruktur (Bom of Materials). Dette er nyttigt, når vi definerer noget én gang og genbruger det, men det kan også være for stift. Hvad hvis vi ikke vil genbruge alt?

Ved at indsætte workflow_state_context mellem workflow_state_hierarchy og workflow_state_option , kan vi både genbruge og tilsidesætte resultater. I denne model kan vi definere, om et resultat er aktiveret eller deaktiveret for forskellige processer.

I ovenstående eksempel er kombinationen INTERVIEW.CANDIDATE_CANCELLED deaktiveret. Med andre ord siger vi, at det simpelthen ikke er et tilladt resultat for tekniske jobansøgninger. Som følge heraf vil intervieweren ikke være i stand til at vælge det, når han optager resultatet af en teknisk jobsamtale, fordi vores forespørgsel kun vælger muligheder, hvor workflow_state_context.child_disabled = ‘N’ .

Fordi workflow_state_option er ikke et direkte underordnet workflow_state_hierarchy , er vi nødt til at definere et separat sæt af muligheder, hver gang en tilstand bruges. Men denne afvejning giver os mulighed for at finjustere mulighederne for hver proces.

Kvalificerende resultater

Vi har også mulighed for at definere mere detaljerede kvalifikationer for resultater. Der er to måder at gøre dette på:

1. Du kan oprette et fjerde niveau i din stykliste for at definere kvalifikationer under resultater i hierarkiet. Due diligence bør tages med denne tilgang. For eksempel bruges FAILED-resultatet til forskellige tilstande. Vil du have de samme kvalifikationer for forskellige FAILED-tilstande? Måske ikke.
2. Du kan definere dine kvalifikationer i workflow_state_type men ikke binde dem til noget hierarki; de er fritstående. Du bruger derefter workflow_state_option at liste kvalifikationerne for den specifikke resultatkontekst. Dette er, hvad ovenstående konfiguration viser, hvor OVER_QUALIFIED- og INSUFFICIENT_EXPERIENCE-kvalifikationerne er angivet som muligheder for APPLICATION_CLOSED.NOT_HIRED-resultatet.

I begge tilfælde skal applikationen genkende, at der er valgt en kvalifikation i stedet for en tilstand eller et resultat – workflow_level_type vil indikere dette – og opdatere managed_entity_state.wf_state_type_qual_id med den valgte værdi.

Nogle tabelkonfigurationsdata

Du vil måske gerne se de underliggende konfigurationsdata, tabel for tabel. Her har vi ids og type_keys de henviser til i parentes. For kortheds skyld præsenteres kun værdier relateret til artiklen.

workflow_level_type

workflow_state_type

workflow_state_hierarchy

workflow_state_context

workflow_state_option

Det er klart, at det er ret vanskeligt at sætte dette op. Det skal helst administreres via en applikation med en brugervenlig grænseflade.

Alternative sekvenser

Du vil bemærke, at en række tabeller har en kolonne kaldet alt_sequence . Dette bruges til at bestille listen over værdier for de forskellige valg, der præsenteres for brugeren. Dette vil typisk være i faldende rækkefølge baseret på brug, med de mest brugte muligheder øverst.

Mens denne artikel beskrev jobansøgninger, kan modellen bruges til mange typer arbejdsgange, hvor en enheds tilstand skal styres over tid. Alternativt kan modellen fungere som et mønster til at tilpasse til dine egne særlige krav.