La prima parte di questa serie ha introdotto alcuni passaggi di base per la gestione del ciclo di vita di qualsiasi entità in un database. La nostra seconda e ultima parte ti mostrerà come definire il flusso di lavoro effettivo utilizzando tabelle di configurazione aggiuntive. È qui che all'utente vengono presentate le opzioni consentite in ogni fase del processo. Dimostreremo anche una tecnica per aggirare il riutilizzo rigoroso di "assiemi" e "sottoassiemi" in una struttura di distinta base.
Definizione delle opzioni
La parte 1 ha introdotto le tabelle del flusso di lavoro di base e come queste possono essere facilmente incorporate nel database. Ciò di cui abbiamo bisogno ora è qualcosa che guidi l'utente nella selezione dello stato logico successivo, qualcosa che definisca un flusso di lavoro logico .
Il diagramma seguente definisce tutti i componenti di un modello di database del flusso di lavoro:
Due tabelle di configurazione, workflow_state_option e workflow_state_context , sono stati aggiunti al modello. Inizieremo con la tabella delle opzioni, che definisce gli stati successivi consentiti . Una volta compresa la sua funzione, torneremo alla tabella contestuale e spiegheremo il ruolo che svolge.
Stati successivi consentiti
Le tabelle che seguono sono in qualche modo come una vista SQL nelle nostre tabelle di configurazione. Qui abbiamo nascosto i join della tabella e stiamo solo guardando le combinazioni di type_keys . Consideriamo quindi ogni STATE.OUTCOME combinazione e definire le opzioni a disposizione dell'utente:
| Combinazione STATE.OUTCOME (dalla gerarchia di stato) | Contesto di stato | Bambino disabile | Opzione 1 | Opzione 2 |
|---|---|---|---|---|
| APPLICATION_RECEIVED .ACCEPTED | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_REVIEW | |
| APPLICATION_RECEIVED .REJECTED | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_CLOSED .NOT_HIRED | |
| APPLICATION_REVIEW .PASSED | STANDARD_JOB _APPLICAZIONE | N | INVITED_TO_INTERVIEW | |
| APPLICATION_REVIEW .FAILED | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_CLOSED .NOT_HIRED | |
| INVITED_TO_INTERVIEW .ACCEPTED | STANDARD_JOB _APPLICAZIONE | N | INTERVISTA | |
| INVITED_TO_INTERVIEW .DECLINED | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_CLOSED .NOT_HIRED | |
| INTERVISTA .PASSED | STANDARD_JOB _APPLICAZIONE | N | MAKE_OFFER | CERCA_REFERENZE |
| INTERVISTA.FAILED | STANDARD_JOB _APPLICAZIONE | N | APPLICAZIONE_CHIUSA | |
| INTERVISTA .CANDIDATE_CANCELLED | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_CLOSED | INVITED_TO_INTERVIEW |
| INTERVISTA .NO_SHOW | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_CLOSED | |
| MAKE_OFFER.ACCEPTED | STANDARD_JOB _APPLICAZIONE | N | CERCA_REFERENZE | |
| MAKE_OFFER.DECLINED | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_CLOSED | |
| CERCA_REFERENZE .PASSED | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_CLOSED .assunto | |
| CERCA_REFERENZE .FAILED | STANDARD_JOB _APPLICAZIONE | N | APPLICATION_CLOSED | |
| APPLICATION_CLOSED .HIRED | STANDARD_JOB _APPLICAZIONE | N | ||
| APPLICATION_CLOSED .NOT_HIRED | STANDARD_JOB _APPLICAZIONE | N |
Poiché per ora stiamo ignorando il contesto, Stato contesto e Bambino disabile? sono in grigio. Ho anche limitato a due il numero di opzioni in questo esempio per brevità, anche se in pratica non c'è limite.
Allora come funziona?
Immagina che l'intervista sia appena stata condotta e che l'intervistatore stia registrando il risultato. La tabella sottostante da aggiornare è managed_entity_state . Ci sono due risultati logici:PASSATO e FALLITO. Quindi l'attuale managed_entity_state viene aggiornato con il risultato selezionato (wf_state_type_outcome_id ). Nel modello di esempio, l'intervistatore può anche includere alcune note sull'intervista.
Se l'intervistatore seleziona PASSED, gli vengono presentate altre due opzioni:MAKE_OFFER e SEEK_REFERENCES. Questi sono i prossimi stati nel nostro flusso di lavoro. Sono simili a go to affermazioni in programmazione. Per entrambe le opzioni, viene inserita una nuova riga in managed_entity_state , spostando la domanda di lavoro allo stato successivo nel processo del flusso di lavoro. L'utente può fissare una scadenza per questo inserendo un due_date .
D'altra parte, se l'intervistatore seleziona FAILED, c'è solo un'opzione:APPLICATION_CLOSED. Quindi un nuovo managed_entity_state la riga viene inserita utilizzando lo stato APPLICATION_CLOSED (wf_state_type_state_id ).
Vedrai che non ci sono opzioni disponibili per lo stato APPLICATION_CLOSED. Ciò significa che è stata raggiunta la fine del processo di flusso di lavoro.
La tabella contestuale
Diamo un'occhiata alla configurazione per il processo di candidatura tecnica per vedere quale ruolo ha la tabella di contesto gioca:
| Combinazione STATE.OUTCOME (dalla gerarchia di stato) | Contesto di stato | Bambino disabile | Opzione 1 | Opzione 2 |
|---|---|---|---|---|
| APPLICATION_RECEIVED .ACCEPTED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _REVISIONE | |
| APPLICATION_RECEIVED .REJECTED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CHIUSA | |
| APPLICATION_REVIEW .PASSED | LAVORO_TECNICO _APPLICAZIONE | N | INVITO_A _INTERVISTA | |
| APPLICATION_REVIEW .FAILED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CHIUSA | |
| INVITED_TO_INTERVIEW .ACCEPTED | LAVORO_TECNICO _APPLICAZIONE | N | TEST_APTITUDE | |
| INVITED_TO_INTERVIEW .DECLINED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CHIUSA | |
| TEST_APTITUDE .PASSED | LAVORO_TECNICO _APPLICAZIONE | N | INTERVISTA | CERCA _RIFERIMENTI |
| TEST_APTITUDE .FAILED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CHIUSA | |
| INTERVISTA .PASSED | LAVORO_TECNICO _APPLICAZIONE | N | MAKE_OFFER | CERCA _RIFERIMENTI |
| INTERVISTA .FAILED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CHIUSA | |
| INTERVISTA .CANDIDATE_CANCELLED | LAVORO_TECNICO _APPLICAZIONE | Y | - | - |
| INTERVISTA .NO_SHOW | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CHIUSA | INVITO_A _INTERVISTA |
| FARE_OFFERTA .ACCETTATO | LAVORO_TECNICO _APPLICAZIONE | N | CERCA _RIFERIMENTI | |
| FARE_OFFERTA .DECLINED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CHIUSA | |
| CERCA_REFERENZE .PASSED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CLOSED.SUCCESS | |
| CERCA_REFERENZE .FAILED | LAVORO_TECNICO _APPLICAZIONE | N | APPLICAZIONE _CHIUSA | |
| APPLICATION_CLOSED .HIRED | LAVORO_TECNICO _APPLICAZIONE | N | ||
| APPLICAZIONE_CHIUSA .NON_ASSUNTA | LAVORO_TECNICO _APPLICAZIONE | N | INSUFFICIENTE _ESPERIENZA | OLTRE _QUALIFICATO |
Qui il contesto è TECHNICAL_JOB_APPLICATION. Perché questo è importante? Perché ci consente di ignorare i risultati. Ricorda, in precedenza abbiamo affermato che possiamo riutilizzare "assiemi" e "sottoassiemi" in una struttura Distinta materiali (BOM). Questo è utile quando definiamo qualcosa una volta e lo riutilizziamo, ma può anche essere troppo rigido. E se non vogliamo riutilizzare tutto?
Inserendo workflow_state_context tra workflow_state_hierarchy e workflow_state_option , possiamo sia riutilizzare che ignorare i risultati. In questo modello, possiamo definire se un risultato è abilitato o disabilitato per diversi processi.
Nell'esempio sopra, la combinazione INTERVIEW.CANDIDATE_CANCELLED è disabilitata. In altre parole, stiamo dicendo che semplicemente non è un risultato ammissibile per le domande di lavoro tecniche. Di conseguenza, l'intervistatore non sarà in grado di selezionarlo durante la registrazione dell'esito di un colloquio di lavoro tecnico perché la nostra query seleziona solo le opzioni in cui workflow_state_context.child_disabled = ‘N’ .
Perché workflow_state_option non è un figlio diretto di workflow_state_hierarchy , dobbiamo definire un insieme separato di opzioni ogni volta che viene utilizzato uno stato. Ma questo compromesso ci consente di mettere a punto le opzioni per ogni processo.
Risultati di qualificazione
Abbiamo anche la possibilità di definire qualificatori più dettagliati per i risultati. Ci sono due modi per farlo:
- Puoi creare un quarto livello nella tua distinta base per definire le qualificazioni sotto i risultati nella gerarchia. La due diligence dovrebbe essere presa con questo approccio. Ad esempio, il risultato FAILED viene utilizzato per diversi stati. Vuoi avere gli stessi qualificatori per diversi stati FAILED? Forse no.
- Puoi definire i tuoi qualificatori in
workflow_state_typema non legarli a nessuna gerarchia; sono indipendenti. Quindi usiworkflow_state_optionper elencare i qualificatori per il contesto di risultato specifico. Questo è ciò che mostra la configurazione sopra, dove i qualificatori OVER_QUALIFIED e INSUFFICIENT_EXPERIENCE sono elencati come opzioni per il risultato APPLICATION_CLOSED.NOT_HIRED.
In entrambi i casi, l'applicazione deve riconoscere che è stato selezionato un qualificatore piuttosto che uno stato o un risultato – workflow_level_type indicherà questo – e aggiornerà managed_entity_state.wf_state_type_qual_id con il valore selezionato.
Alcuni dati di configurazione della tabella
Potresti voler vedere i dati di configurazione sottostanti, tabella per tabella. Qui abbiamo gli ids e i type_keys si riferiscono tra parentesi. Per brevità vengono presentati solo i valori relativi all'articolo.
workflow_level_type
| id | tipo_chiave |
|---|---|
| 1 | PROCESSO |
| 2 | STATO |
| 3 | RISULTATO |
| 4 | QUALIFICATORE |
workflow_state_type
| id | tipo_chiave | workflow_level_type_id |
|---|---|---|
| 1 | STANDARD_JOB_APPLICATION | 1 (PROCESSO) |
| 2 | APPLICAZIONE_TECNICA | 1 (PROCESSO) |
| 3 | INTERVISTA | 2 (STATO) |
| 4 | PASSATO | 3 (RISULTATO) |
| 5 | FALLITO | 3 (RISULTATO) |
| 6 | MAKE_OFFER | 2 (STATO) |
| 7 | SEEK_REFERENCES | 2 (STATE) |
| 8 | APPLICATION_CLOSED | 2 (STATE) |
| 9 | ASSUNTO | 3 (RISULTATO) |
| 10 | NON_ASSUNTO | 3 (RISULTATO) |
| 11 | ESPERIENZA_INSUFFICIENTE | 4 (QUALIFICATORE) |
| 12 | OVER_QUALIFIED | 4 (QUALIFICATORE) |
workflow_state_gerarchy
| id | state_type_parent_id | state_type_child_id |
|---|---|---|
| 1 | 1 (APPLICAZIONE_LAVORO_STANDARD) | 3 (INTERVISTA) |
| 2 | 2 (APPLICAZIONE_LAVORO_TECNICA) | 3 (INTERVISTA) |
| 3 | 3 (INTERVISTA) | 4 (PASSEGGIATO) |
| 4 | 3 (INTERVISTA) | 5 (FAILED) |
| 5 | 1 (STANDARD_JOB_APPLICATION) | 8 (APPLICATION_CLOSED) |
| 6 | 2 (APPLICAZIONE_LAVORO_TECNICA) | 8 (APPLICATION_CLOSED) |
| 7 | 8 (APPLICATION_CLOSED) | 9 (ASSUNTO) |
| 8 | 8 (APPLICATION_CLOSED) | 10 (NON_ASSUNTO) |
workflow_state_context
| id | state_type_id | state_hierarchy_id | bambino_disabile |
|---|---|---|---|
| 1 | 1 (APPLICAZIONE STANDARD_LAVORO_) | 3 (INTERVISTA. SUPERATA) | N |
| 2 | 1 (APPLICAZIONE STANDARD_LAVORO_) | 4 (INTERVISTA.FALLITA) | N |
| 3 | 1 (APPLICAZIONE STANDARD_LAVORO_) | 7 (APPLICATION_CLOSED. ASSUNTO) | N |
| 4 | 1 (APPLICAZIONE STANDARD_LAVORO_) | 5 (APPLICATION_CLOSED. NOT_HIRED) | N |
| 5 | 2 (APPLICAZIONE_TECNICA) | 6 (APPLICATION_CLOSED. NOT_HIRED) | N |
opzione_stato_di_lavoro
| id | state_context_id | state_type_id |
|---|---|---|
| 1 | 1 (APPLICAZIONE STANDARD_JOB_. INTERVISTA. SUPERATA) | 6 (MAKE_OFFER) |
| 2 | 1 (APPLICAZIONE STANDARD_JOB_. INTERVISTA. SUPERATA) | 7 (SEEK_REFERENCES) |
| 3 | 2 (APPLICAZIONE STANDARD_JOB_. INTERVISTA. FALLITA) | 8 (APPLICATION_CLOSED) |
| 4 | 5 (TECHNICAL_JOB_APPLICATION. APPLICATION_CLOSED. NOT_HIRED) | 11 (ESPERIENZA_INSUFFICIENTE) |
| 5 | 5 (APPLICAZIONE _JOB_ TECNICA. APPLICAZIONE_CLOSED. NON_ASSUNTA) | 12 (OVER_QUALIFIED) |
Chiaramente, impostare questo è piuttosto complicato. Dovrebbe essere preferibilmente amministrato tramite un'applicazione con un'interfaccia intuitiva.
Sequenze alternative
Noterai che un certo numero di tabelle ha una colonna chiamata alt_sequence . Viene utilizzato per ordinare l'elenco dei valori per le diverse selezioni presentate all'utente. In genere questo sarà in ordine decrescente in base all'utilizzo, con le opzioni utilizzate più di frequente in alto.
Sebbene questo articolo descriva le domande di lavoro, il modello può essere utilizzato per molti tipi di flussi di lavoro in cui lo stato di un'entità deve essere gestito nel tempo. In alternativa, il modello può fungere da modello da personalizzare in base alle proprie esigenze particolari.
