Utilisation des tables de configuration pour définir le flux de travail réel

La première partie de cette série a présenté quelques étapes de base pour gérer le cycle de vie de toute entité dans une base de données. Notre deuxième et dernière partie vous montrera comment définir le flux de travail réel à l'aide de tables de configuration supplémentaires. C'est là que l'utilisateur se voit présenter les options autorisées à chaque étape du processus. Nous démontrerons également une technique permettant de contourner la réutilisation stricte des "assemblages" et des "sous-assemblages" dans une structure de nomenclature.

Définir les options

La partie 1 a présenté les tableaux de flux de travail de base et comment ceux-ci peuvent facilement être intégrés dans votre base de données. Ce dont nous avons besoin maintenant, c'est de quelque chose qui guide l'utilisateur dans la sélection de l'état logique suivant - quelque chose qui définit un flux de travail logique .

Le schéma ci-dessous définit tous les composants d'un modèle de base de données de workflow :

Deux tables de configuration, workflow_state_option et workflow_state_context , ont été ajoutés au modèle. Nous allons commencer par le tableau des options, qui définit les états suivants autorisés . Une fois sa fonction comprise, nous reviendrons au tableau de contexte et expliquerons le rôle qu'il joue.

États suivants autorisés

Les tableaux qui suivent ressemblent un peu à une vue SQL de nos tables de configuration. Ici, nous avons masqué les jointures de table et nous examinons simplement les combinaisons de type_keys . Considérons donc chaque STATE.OUTCOME combinaison et définissez les options disponible pour l'utilisateur :

Parce que nous ignorons le contexte pour l'instant, State Context et Enfant handicapé ? sont grisés. J'ai également limité le nombre d'options dans cet exemple à deux par souci de brièveté, bien qu'en pratique il n'y ait pas de limite.

Alors, comment ça marche ?

Imaginez que l'interview vient d'être menée et que l'intervieweur enregistre le résultat. La table sous-jacente mise à jour est managed_entity_state . Il y a deux résultats logiques :RÉUSSI et ÉCHEC. Ainsi, le managed_entity_state actuel est mis à jour avec le résultat sélectionné (wf_state_type_outcome_id ). Dans l'exemple de modèle, l'intervieweur peut également inclure des notes sur l'entretien.

Si l'intervieweur sélectionne PASSED, deux options supplémentaires lui sont présentées :MAKE_OFFER et SEEK_REFERENCES. Ce sont les prochains états dans notre flux de travail. Ils sont similaires à go to déclarations en programmation. Pour l'une ou l'autre option, une nouvelle ligne est insérée dans managed_entity_state , déplaçant la candidature à l'état suivant du processus de workflow. L'utilisateur peut définir une date limite pour cela en saisissant une due_date .

D'autre part, si l'intervieweur sélectionne ÉCHEC, il n'y a qu'une seule option :APPLICATION_CLOSED. Donc un nouveau managed_entity_state la ligne est insérée à l'aide de l'état APPLICATION_CLOSED (wf_state_type_state_id ).

Vous verrez qu'il n'y a pas d'options disponibles pour l'état APPLICATION_CLOSED. Cela signifie que la fin du processus de workflow a été atteinte.

Le tableau de contexte

Examinons la configuration du processus de candidature technique pour voir quel rôle la table de contexte joue :

Ici, le contexte est TECHNICAL_JOB_APPLICATION. Pourquoi est-ce important? Parce que cela nous permet de passer outre les résultats. N'oubliez pas que nous avons précédemment déclaré que nous pouvions réutiliser des « assemblages » et des « sous-assemblages » dans une structure de nomenclature (BOM). Ceci est utile lorsque nous définissons quelque chose une fois et que nous le réutilisons, mais cela peut aussi être trop rigide. Et si nous ne voulions pas tout réutiliser ?

En insérant workflow_state_context entre workflow_state_hierarchy et workflow_state_option , nous pouvons à la fois réutiliser et remplacer les résultats. Dans ce modèle, nous pouvons définir si un résultat est activé ou désactivé pour différents processus.

Dans l'exemple ci-dessus, la combinaison INTERVIEW.CANDIDATE_CANCELLED est désactivée. En d'autres termes, nous disons que ce n'est tout simplement pas un résultat acceptable pour les candidatures à un emploi technique. Par conséquent, l'intervieweur ne pourra pas le sélectionner lors de l'enregistrement du résultat d'un entretien d'embauche technique car notre requête ne sélectionne que les options où workflow_state_context.child_disabled = ‘N’ .

Parce que workflow_state_option n'est pas un enfant direct de workflow_state_hierarchy , nous devons définir un ensemble d'options distinct chaque fois qu'un état est utilisé. Mais ce compromis nous permet d'affiner les options pour chaque processus.

Résultats de qualification

Nous avons également la possibilité de définir des qualificatifs plus détaillés pour les résultats. Il existe deux manières de procéder :

1. Vous pouvez créer un quatrième niveau dans votre nomenclature pour définir des qualificateurs sous les résultats dans la hiérarchie. Une diligence raisonnable doit être prise avec cette approche. Par exemple, le résultat FAILED est utilisé pour différents états. Voulez-vous avoir les mêmes qualificatifs pour différents états FAILED ? Peut-être pas.
2. Vous pouvez définir vos qualificateurs dans workflow_state_type mais ne les rattachez à aucune hiérarchie; ils sont autonomes. Vous utilisez alors workflow_state_option pour répertorier les qualificatifs pour le contexte de résultat spécifique. C'est ce que montre la configuration ci-dessus, où les qualificatifs OVER_QUALIFIED et INSUFFICIENT_EXPERIENCE sont répertoriés en tant qu'options pour le résultat APPLICATION_CLOSED.NOT_HIRED.

Dans les deux cas, l'application doit reconnaître qu'un qualificateur a été sélectionné plutôt qu'un état ou un résultat – workflow_level_type l'indiquera - et mettra à jour managed_entity_state.wf_state_type_qual_id avec la valeur sélectionnée.

Quelques données de configuration de table

Vous aimeriez peut-être voir les données de configuration sous-jacentes, table par table. Ici nous avons les ids et les type_keys ils se réfèrent entre parenthèses. Par souci de concision, seules les valeurs liées à l'article sont présentées.

workflow_level_type

workflow_state_type

workflow_state_hierarchy

workflow_state_context

workflow_state_option

De toute évidence, la mise en place est assez délicate. Il doit être administré de préférence via une application avec une interface conviviale.

Séquences alternatives

Vous remarquerez qu'un certain nombre de tables ont une colonne appelée alt_sequence . Il permet d'ordonner la liste des valeurs des différentes sélections présentées à l'utilisateur. En règle générale, ce sera par ordre décroissant en fonction de l'utilisation, avec les options les plus fréquemment utilisées en haut.

Bien que cet article décrive les candidatures, le modèle peut être utilisé pour de nombreux types de flux de travail où l'état d'une entité doit être géré au fil du temps. Alternativement, le modèle peut servir de modèle à personnaliser selon vos propres besoins particuliers.