Het eerste deel van deze serie introduceerde enkele basisstappen voor het beheren van de levenscyclus van elke entiteit in een database. Ons tweede en laatste deel laat u zien hoe u de daadwerkelijke workflow kunt definiëren met behulp van aanvullende configuratietabellen. Hier krijgt de gebruiker bij elke stap toegestane opties te zien. We zullen ook een techniek demonstreren om het strikte hergebruik van 'assemblages' en 'sub-assemblages' in een stuklijststructuur te omzeilen.
De opties definiëren
Deel 1 introduceerde de kernworkflowtabellen en hoe deze eenvoudig in uw database kunnen worden opgenomen. Wat we nu nodig hebben, is iets om de gebruiker te begeleiden bij het selecteren van de volgende logische status - iets dat een logische workflow definieert .
Het onderstaande diagram definieert alle componenten van een workflowdatabasemodel:
Twee configuratietabellen, workflow_state_option en workflow_state_context , zijn toegevoegd aan het model. We beginnen met de optietabel, die de toegestane volgende toestanden definieert . Zodra de functie ervan begrepen is, keren we terug naar de contexttabel en leggen we uit welke rol deze speelt.
Toegestane volgende staten
De tabellen die volgen, lijken een beetje op een SQL-weergave in onze configuratietabellen. Hier hebben we de tabel-joins verborgen en kijken we alleen naar de combinaties van type_keys . Dus laten we eens kijken naar elke STATE.OUTCOME combinatie en definieer de opties beschikbaar voor de gebruiker:
| STATE.OUTCOME-combinatie (van staatshiërarchie) | Staatscontext | Kind uitgeschakeld | Optie 1 | Optie 2 |
|---|---|---|---|---|
| APPLICATION_RECEIVED .ACCEPTED | STANDARD_JOB _APPLICATION | N | APPLICATION_REVIEW | |
| APPLICATION_RECEIVED .REJECTED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| APPLICATION_REVIEW .GESLAAGD | STANDARD_JOB _APPLICATION | N | INVITED_TO_INTERVIEW | |
| APPLICATION_REVIEW .FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| INVITED_TO_INTERVIEW .ACCEPTED | STANDARD_JOB _APPLICATION | N | INTERVIEW | |
| INVITED_TO_INTERVIEW .DECLINED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED .NOT_HIRED | |
| INTERVIEW .GESLAAGD | STANDARD_JOB _APPLICATION | N | MAKE_OFFER | SEEK_REFERENCES |
| INTERVIEW.FAILED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | |
| INTERVIEW .CANDIDATE_CANCELLED | STANDARD_JOB _APPLICATION | N | APPLICATION_CLOSED | INVITED_TO_INTERVIEW |
| INTERVIEW .NO_SHOW | 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 .GESLAAGD | 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 |
Omdat we de context voorlopig negeren, Context aangeven en Kind uitgeschakeld? zijn grijs weergegeven. Ik heb het aantal opties in dit voorbeeld ook beperkt tot twee kortheidshalve, hoewel er in de praktijk geen limiet is.
Dus hoe werkt dit?
Stel je voor dat het interview net is afgenomen en de interviewer de uitkomst aan het opnemen is. De onderliggende tabel die wordt bijgewerkt, is managed_entity_state . Er zijn twee logische uitkomsten:GESLAAGD en MISLUKT. Dus de huidige managed_entity_state wordt bijgewerkt met de geselecteerde uitkomst (wf_state_type_outcome_id ). In het voorbeeldmodel kan de interviewer ook enkele aantekeningen over het interview opnemen.
Als de interviewer GESLAAGD selecteert, krijgen ze nog twee opties te zien:MAKE_OFFER en SEEK_REFERENCES. Dit zijn de volgende staten in onze werkstroom. Ze lijken op go to uitspraken in de programmering. Voor beide opties wordt een nieuwe rij ingevoegd in managed_entity_state , de sollicitatie naar de volgende status in het workflowproces verplaatsen. De gebruiker kan hiervoor een deadline instellen door een due_date . in te voeren .
Aan de andere kant, als de interviewer FAILED selecteert, is er maar één optie:APPLICATION_CLOSED. Dus een nieuwe managed_entity_state rij wordt ingevoegd met de status APPLICATION_CLOSED (wf_state_type_state_id ).
U zult zien dat er geen opties beschikbaar zijn voor de status APPLICATION_CLOSED. Dit betekent dat het einde van het workflowproces is bereikt.
De contexttabel
Laten we eens kijken naar de configuratie voor het technische sollicitatieproces om te zien welke rol de contexttabel speelt:
| STATE.OUTCOME-combinatie (van staatshiërarchie) | Staatscontext | Kind uitgeschakeld | Optie 1 | Optie 2 |
|---|---|---|---|---|
| APPLICATION_RECEIVED .ACCEPTED | TECHNICAL_JOB _APPLICATION | N | TOEPASSING _REVIEW | |
| APPLICATION_RECEIVED .REJECTED | TECHNICAL_JOB _APPLICATION | N | APPLICATIE _CLOSED | |
| APPLICATION_REVIEW .GESLAAGD | TECHNICAL_JOB _APPLICATION | N | INVITED_TO _INTERVIEW | |
| APPLICATION_REVIEW .FAILED | TECHNICAL_JOB _APPLICATION | N | APPLICATIE _CLOSED | |
| INVITED_TO_INTERVIEW .ACCEPTED | TECHNICAL_JOB _APPLICATION | N | TEST_APTITUDE | |
| INVITED_TO_INTERVIEW .DECLINED | TECHNICAL_JOB _APPLICATION | N | APPLICATIE _CLOSED | |
| TEST_APTITUDE .GESLAAGD | TECHNICAL_JOB _APPLICATION | N | INTERVIEW | ZOEKEN _REFERENCES |
| TEST_APTITUDE .FAILED | TECHNICAL_JOB _APPLICATION | N | TOEPASSING _CLOSED | |
| INTERVIEW .GESLAAGD | TECHNICAL_JOB _APPLICATION | N | MAKE_OFFER | ZOEKEN _REFERENCES |
| INTERVIEW .FAILED | TECHNICAL_JOB _APPLICATION | N | APPLICATIE _CLOSED | |
| INTERVIEW .CANDIDATE_CANCELLED | TECHNICAL_JOB _APPLICATION | J | - | - |
| INTERVIEW .NO_SHOW | TECHNICAL_JOB _APPLICATION | N | APPLICATIE _CLOSED | INVITED_TO _INTERVIEW |
| MAKE_OFFER .GEACCEPTEERD | TECHNICAL_JOB _APPLICATION | N | ZOEKEN _REFERENCES | |
| MAKE_OFFER .DECLINED | TECHNICAL_JOB _APPLICATION | N | APPLICATIE _CLOSED | |
| SEEK_REFERENCES .GESLAAGD | TECHNICAL_JOB _APPLICATION | N | APPLICATIE _CLOSED.SUCCESS | |
| SEEK_REFERENCES .FAILED | TECHNICAL_JOB _APPLICATION | N | APPLICATIE _CLOSED | |
| APPLICATION_CLOSED .HIRED | TECHNICAL_JOB _APPLICATION | N | ||
| APPLICATION_CLOSED .NOT_HIRED | TECHNICAL_JOB _APPLICATION | N | ONVOLDOENDE _ERVARING | OVER _KWALIFIED |
Hier is de context TECHNICAL_JOB_APPLICATION. Waarom is dit belangrijk? Omdat het ons in staat stelt om de resultaten te overschrijven. Vergeet niet dat we eerder hebben aangegeven dat we 'assemblages' en 'sub-assemblages' kunnen hergebruiken in een Bill of Materials (BOM)-structuur. Dit is handig als we iets eenmalig definiëren en hergebruiken, maar het kan ook te rigide zijn. Wat als we niet alles opnieuw willen gebruiken?
Door workflow_state_context . in te voegen tussen workflow_state_hierarchy en workflow_state_option , kunnen we uitkomsten zowel hergebruiken als overschrijven. In dit model kunnen we definiëren of een uitkomst is ingeschakeld of uitgeschakeld voor verschillende processen.
In het bovenstaande voorbeeld is de combinatie INTERVIEW.CANDIDATE_CANCELLED uitgeschakeld. Met andere woorden, we zeggen dat het gewoon geen toelaatbare uitkomst is voor technische sollicitaties. Bijgevolg kan de interviewer het niet selecteren bij het opnemen van de uitkomst van een technisch sollicitatiegesprek, omdat onze vraag alleen opties selecteert waarbij workflow_state_context.child_disabled = ‘N’ .
Omdat workflow_state_option is geen direct kind van workflow_state_hierarchy , moeten we elke keer dat een status wordt gebruikt een aparte set opties definiëren. Maar deze afweging stelt ons in staat om de opties voor elk proces nauwkeurig af te stemmen.
Kwalificerende resultaten
We hebben ook de mogelijkheid om meer gedetailleerde kwalificaties te definiëren voor resultaten. Er zijn twee manieren om dit te doen:
- U kunt een vierde niveau in uw stuklijst maken om kwalificaties te definiëren onder resultaten in de hiërarchie. Bij deze benadering moet zorgvuldigheid worden betracht. De uitkomst FAILED wordt bijvoorbeeld gebruikt voor verschillende staten. Wilt u dezelfde kwalificaties hebben voor verschillende FAILED-statussen? Misschien niet.
- U kunt uw kwalificaties definiëren in
workflow_state_typemaar bind ze niet aan een hiërarchie; ze zijn vrijstaand. Je gebruikt danworkflow_state_optionom de kwalificaties voor de specifieke uitkomstcontext op te sommen. Dit is wat de bovenstaande configuratie laat zien, waar de kwalificaties OVER_QUALIFIED en INSUFFICIENT_EXPERIENCE worden weergegeven als opties voor de uitkomst APPLICATION_CLOSED.NOT_HIRED.
In beide gevallen moet de toepassing erkennen dat er een kwalificatie is geselecteerd in plaats van een staat of een resultaat - workflow_level_type geeft dit aan – en update managed_entity_state.wf_state_type_qual_id met de geselecteerde waarde.
Enkele tabelconfiguratiegegevens
Misschien wilt u de onderliggende configuratiegegevens per tabel bekijken. Hier hebben we de ids en de type_keys ze verwijzen naar tussen haakjes. Kortheidshalve worden alleen waarden weergegeven die betrekking hebben op het artikel.
workflow_level_type
| id | type_key |
|---|---|
| 1 | PROCES |
| 2 | STAAT |
| 3 | RESULTAAT |
| 4 | KWALIFICATIE |
workflow_state_type
| id | type_key | workflow_level_type_id |
|---|---|---|
| 1 | STANDARD_JOB_APPLICATION | 1 (PROCES) |
| 2 | TECHNICAL_APPLICATION | 1 (PROCES) |
| 3 | INTERVIEW | 2 (STAAT) |
| 4 | GESLAAGD | 3 (UITKOMST) |
| 5 | MISLUKT | 3 (UITKOMST) |
| 6 | MAKE_OFFER | 2 (STATE) |
| 7 | SEEK_REFERENCES | 2 (STATE) |
| 8 | APPLICATION_CLOSED | 2 (STATE) |
| 9 | INGEHUURD | 3 (UITKOMST) |
| 10 | NOT_HIRED | 3 (UITKOMST) |
| 11 | ONVOLDOENDE_ERVARING | 4 (KWALIFICATIE) |
| 12 | OVER_GEKWALIFICEERD | 4 (KWALIFICATIE) |
workflow_state_hiërarchie
| id | state_type_parent_id | state_type_child_id |
|---|---|---|
| 1 | 1 (STANDARD_JOB_APPLICATION) | 3 (INTERVIEW) |
| 2 | 2 (TECHNICAL_JOB_APPLICATION) | 3 (INTERVIEW) |
| 3 | 3 (INTERVIEW) | 4 (GESLAAGD) |
| 4 | 3 (INTERVIEW) | 5 (MISLUKT) |
| 5 | 1 (STANDARD_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
| 6 | 2 (TECHNICAL_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
| 7 | 8 (APPLICATION_CLOSED) | 9 (GEHUURD) |
| 8 | 8 (APPLICATION_CLOSED) | 10 (NOT_HIRED) |
workflow_state_context
| id | state_type_id | state_hierarchy_id | child_disabled |
|---|---|---|---|
| 1 | 1 (STANDARD_JOB_ APPLICATION) | 3 (INTERVIEW.GESLAAGD) | N |
| 2 | 1 (STANDARD_JOB_ APPLICATION) | 4 (INTERVIEW.FAILED) | N |
| 3 | 1 (STANDARD_JOB_ APPLICATION) | 7 (APPLICATION_CLOSED. HIRED) | N |
| 4 | 1 (STANDARD_JOB_ APPLICATION) | 5 (APPLICATION_CLOSED. NOT_HIRED) | N |
| 5 | 2 (TECHNICAL_APPLICATION) | 6 (APPLICATION_CLOSED. NOT_HIRED) | N |
workflow_state_option
| id | state_context_id | state_type_id |
|---|---|---|
| 1 | 1 (STANDARD_JOB_ APPLICATION. INTERVIEW. GESLAAGD) | 6 (MAKE_OFFER) |
| 2 | 1 (STANDARD_JOB_ APPLICATION. INTERVIEW. GESLAAGD) | 7 (SEEK_REFERENCES) |
| 3 | 2 (STANDARD_JOB_ APPLICATION. INTERVIEW. MISLUKT) | 8 (APPLICATION_CLOSED) |
| 4 | 5 (TECHNICAL_JOB_ APPLICATION. APPLICATION_CLOSED. NOT_HIRED) | 11 (INSUFFICIENT_EXPERIENCE) |
| 5 | 5 (TECHNISCHE _JOB_ APPLICATION. APPLICATION_CLOSED. NOT_HIRED) | 12 (OVER_QUALIFIED) |
Het is duidelijk dat het opzetten hiervan behoorlijk lastig is. Het moet bij voorkeur worden beheerd via een applicatie met een gebruiksvriendelijke interface.
Alternatieve reeksen
U zult zien dat een aantal tabellen een kolom hebben met de naam alt_sequence . Dit wordt gebruikt om de lijst met waarden te ordenen voor de verschillende selecties die aan de gebruiker worden gepresenteerd. Meestal is dit in aflopende volgorde op basis van gebruik, met de meest gebruikte opties bovenaan.
Hoewel in dit artikel sollicitaties worden beschreven, kan het model worden gebruikt voor veel soorten werkstromen waarbij de status van een entiteit in de loop van de tijd moet worden beheerd. Als alternatief kan het model dienen als een patroon om aan uw eigen specifieke vereisten aan te passen.