Verwenden von Konfigurationstabellen zum Definieren des tatsächlichen Arbeitsablaufs

Im ersten Teil dieser Serie wurden einige grundlegende Schritte zum Verwalten des Lebenszyklus einer beliebigen Entität in einer Datenbank vorgestellt. Unser zweiter und letzter Teil zeigt Ihnen, wie Sie den eigentlichen Workflow mithilfe zusätzlicher Konfigurationstabellen definieren. Hier werden dem Benutzer bei jedem Schritt zulässige Optionen präsentiert. Wir werden auch eine Technik demonstrieren, mit der die strikte Wiederverwendung von „Baugruppen“ und „Unterbaugruppen“ in einer Stücklistenstruktur umgangen werden kann.

Definieren der Optionen

Teil 1 stellte die wichtigsten Arbeitsablauftabellen vor und erläuterte, wie diese einfach in Ihre Datenbank integriert werden können. Was wir jetzt brauchen, ist etwas, das den Benutzer bei der Auswahl des nächsten logischen Zustands anleitet – etwas, das einen logischen Arbeitsablauf definiert .

Das folgende Diagramm definiert alle Komponenten eines Workflow-Datenbankmodells:

Zwei Konfigurationstabellen, workflow_state_option und workflow_state_context , wurden dem Modell hinzugefügt. Wir beginnen mit der Optionstabelle, die die zulässigen nächsten Zustände definiert . Sobald seine Funktion verstanden ist, kehren wir zur Kontexttabelle zurück und erläutern die Rolle, die sie spielt.

Zulässige nächste Zustände

Die folgenden Tabellen sind so etwas wie eine SQL-Ansicht unserer Konfigurationstabellen. Hier haben wir die Tabellenverknüpfungen ausgeblendet und schauen uns nur die Kombinationen von type_keys an . Betrachten wir also jedes STATE.OUTCOME Kombination und definieren Sie die Optionen für den Benutzer verfügbar:

Weil wir den Kontext vorerst ignorieren, Zustandskontext und Kind behindert? sind ausgegraut. Ich habe auch die Anzahl der Optionen in diesem Beispiel der Kürze halber auf zwei beschränkt, obwohl es in der Praxis keine Begrenzung gibt.

Wie funktioniert das also?

Stellen Sie sich vor, das Interview wurde gerade durchgeführt und der Interviewer zeichnet das Ergebnis auf. Die zugrunde liegende Tabelle, die aktualisiert wird, ist managed_entity_state . Es gibt zwei logische Ergebnisse:PASSED und FAILED. Also der aktuelle managed_entity_state wird mit dem ausgewählten Ergebnis aktualisiert (wf_state_type_outcome_id ). Im Beispielmodell kann der Interviewer auch einige Notizen zum Interview hinzufügen.

Wenn der Interviewer BESTANDEN auswählt, werden ihm zwei weitere Optionen präsentiert:MAKE_OFFER und SEEK_REFERENCES. Dies sind die nächsten Zustände in unserem Arbeitsablauf. Sie ähneln go to Anweisungen in der Programmierung. Für beide Optionen wird eine neue Zeile in managed_entity_state eingefügt , Verschieben der Stellenbewerbung in den nächsten Status im Workflow-Prozess. Der Nutzer kann hierfür eine Frist setzen, indem er ein due_date eingibt .

Wenn der Interviewer dagegen FAILED auswählt, gibt es nur eine Option:APPLICATION_CLOSED. Also ein neuer managed_entity_state Zeile wird mit dem Status APPLICATION_CLOSED eingefügt (wf_state_type_state_id ).

Sie werden sehen, dass für den Zustand APPLICATION_CLOSED keine Optionen verfügbar sind. Dies bedeutet, dass das Ende des Workflow-Prozesses erreicht wurde.

Die Kontexttabelle

Schauen wir uns die Konfiguration für den technischen Bewerbungsprozess an, um zu sehen, welche Rolle die Kontexttabelle hat spielt:

Hier ist der Kontext TECHNICAL_JOB_APPLICATION. Warum ist das wichtig? Weil es uns erlaubt, Ergebnisse zu überschreiben. Denken Sie daran, dass wir zuvor erklärt haben, dass wir „Baugruppen“ und „Unterbaugruppen“ in einer Stücklistenstruktur (BOM) wiederverwenden können. Dies ist nützlich, wenn wir etwas einmal definieren und wiederverwenden, aber es kann auch zu starr sein. Was ist, wenn wir nicht alles wiederverwenden möchten?

Durch Einfügen von workflow_state_context zwischen workflow_state_hierarchy und workflow_state_option , können wir Ergebnisse sowohl wiederverwenden als auch überschreiben. In diesem Modell können wir definieren, ob ein Ergebnis für verschiedene Prozesse aktiviert oder deaktiviert ist.

Im obigen Beispiel ist die Kombination INTERVIEW.CANDIDATE_CANCELLED deaktiviert. Mit anderen Worten, wir sagen, dass es für technische Bewerbungen einfach kein zulässiges Ergebnis ist. Folglich kann der Interviewer es nicht auswählen, wenn er das Ergebnis eines technischen Bewerbungsgesprächs aufzeichnet, da unsere Abfrage nur Optionen auswählt, bei denen workflow_state_context.child_disabled = ‘N’ .

Da workflow_state_option ist kein direktes Kind von workflow_state_hierarchy , müssen wir jedes Mal, wenn ein Status verwendet wird, einen separaten Satz von Optionen definieren. Aber dieser Kompromiss ermöglicht es uns, die Optionen für jeden Prozess fein abzustimmen.

Qualifizierende Ergebnisse

Wir haben auch die Möglichkeit, detailliertere Qualifier zu definieren für Ergebnisse. Dafür gibt es zwei Möglichkeiten:

1. Sie können eine vierte Ebene in Ihrer Stückliste erstellen, um Qualifizierer unter Ergebnissen in der Hierarchie zu definieren. Bei diesem Ansatz sollte mit der gebotenen Sorgfalt vorgegangen werden. Beispielsweise wird das Ergebnis FAILED für verschiedene Zustände verwendet. Möchten Sie die gleichen Qualifikationsmerkmale für verschiedene FAILED-Zustände haben? Vielleicht nicht.
2. Sie können Ihre Qualifizierer in workflow_state_type definieren aber binden Sie sie nicht an irgendeine Hierarchie; sie sind freistehend. Sie verwenden dann workflow_state_option um die Qualifizierer für den spezifischen Ergebniskontext aufzulisten. Dies ist, was die obige Konfiguration zeigt, wo die Qualifizierer OVER_QUALIFIED und INSUFFICIENT_EXPERIENCE als Optionen für das Ergebnis APPLICATION_CLOSED.NOT_HIRED aufgeführt sind.

In jedem Fall muss die Anwendung erkennen, dass ein Qualifizierer statt eines Status oder Ergebnisses ausgewählt wurde – workflow_level_type zeigt dies an – und aktualisiert managed_entity_state.wf_state_type_qual_id mit dem ausgewählten Wert.

Einige Tabellenkonfigurationsdaten

Möglicherweise möchten Sie die zugrunde liegenden Konfigurationsdaten Tabelle für Tabelle anzeigen. Hier haben wir die ids und die type_keys sie beziehen sich auf in Klammern. Der Kürze halber werden nur artikelbezogene Werte dargestellt.

workflow_level_type

workflow_state_type

workflow_state_hierarchy

workflow_state_context

workflow_state_option

Es ist klar, dass die Einrichtung ziemlich schwierig ist. Es sollte vorzugsweise über eine Anwendung mit einer benutzerfreundlichen Oberfläche verwaltet werden.

Alternative Sequenzen

Sie werden feststellen, dass einige Tabellen eine Spalte namens alt_sequence haben . Dies wird verwendet, um die Werteliste für die verschiedenen Auswahlen zu ordnen, die dem Benutzer präsentiert werden. In der Regel ist dies in absteigender Reihenfolge nach Nutzung, wobei die am häufigsten verwendeten Optionen ganz oben stehen.

Während dieser Artikel Bewerbungen beschrieb, kann das Modell für viele Arten von Workflows verwendet werden, bei denen der Status einer Entität im Laufe der Zeit verwaltet werden muss. Alternativ kann das Modell als Muster dienen, das Sie an Ihre eigenen speziellen Anforderungen anpassen können.