Um eigene Regeln definieren zu können, müssen Sie folgende Voraussetzungen erfüllen:
Hier sind einige wichtige Tipps, mit denen Sie syntaktisch und semantisch richtige WHERE-Klauseln erstellen können.
Ihre WHERE-Klauseln erfordern vermutlich Referenzen sowohl auf IM_V_Defects als auch auf IM_DefectHistory. Die Ansicht IM_V_Defects speichert aktuelle Informationen über einen Fehler. Die Tabelle IM_DefectHistory speichert alle Aktionen, die mit dem Fehler durchgeführt wurden, und alle Auswirkungen dieser Aktionen auf bestimmte Fehlerfelder.
So finden Sie in IM_DefectHistory beispielsweise die Postfachzuordnung eines Fehlers vor und nach einer Aktion. Die entsprechenden Spalten heißen AssignedIN (Postfachzuordnung vor der Aktion) und AssignedOUT (Postfachzuordnung nach der Aktion).
Alle Aktionen mit Fehlern werden im Feld ActionCode der Tabelle IM_DefectHistory aufgezeichnet. Diese Aktionen werden als Aktionscodes in der Spalte Aktion der Registerkarte Historie angezeigt. Sie kennen solche Codes (z. B. BEHOBEN und VERIFIZIERT) aus der Beispieldatenbank.
Um sich die Aktionscodes für die meisten der Aktionen in Ihrer Datenbank anzeigen zu lassen, öffnen Sie den Dialog Aktion von Status bearbeiten für jeden Status (die Ausnahmen EINGEGEBEN, NEU ZUGEORDNET und GEÄNDERT sind hart codiert und können nicht angezeigt werden). Um den Dialog Aktion von Status bearbeiten für einen Status zu öffnen, wählen Sie . Klicken Sie auf den Namen des Status in der Spalte Schaltflächenbezeichnung. Beachten Sie den Wert im Feld Aktionscode für Historie.
Die benutzerdefinierten Felder in der Ansicht IM_V_Defects heißen Custom1, Custom2 usw., je nach ihrer Position auf den Registern. Jedes benutzerdefinierte Register hat bis zu 10 Felder, 1-10, 11-20 usw. Auf Benutzerdefiniertes Register 1 werden die ersten fünf Felder in der linken Spalte angezeigt, die Felder 6 bis 10 in der rechten Spalte (beide Male in absteigender Reihenfolge).
Den Schemanamen für ein bestimmtes benutzerdefiniertes Feld finden Sie unter . Im Dialogfeld für die Beispieldatenbank ist das Kontrollkästchen Hinweis hinzufügen? z. B. das vierte Feld in der linken Spalte von Benutzerdefiniertes Register 1. Das Gleiche gilt für Benutzerdefiniert4 in der Fehlertabelle.
Der Wert eines deaktivierten Kontrollkästchens ist ‘.’ (ein Punkt). Der Wert eines aktivierten Kontrollkästchens ist 'X' (ein großes X).
Um beispielsweise alle Fehler abzurufen, für die Hinweis hinzufügen? aktiviert ist, fügen Sie in die WHERE-Klausel die folgende Anweisung ein:
D.Custom4 = 'X'
Hier sind vier Situationen, in denen neue Regeln benötigt werden. Die beiden ersten Situationen setzen Regeln voraus, die in Benachrichtigungen für bestimmte Fehler angewendet werden. Die beiden letzten Situationen beziehen sich auf Regeln in projektweiten Benachrichtigungen. Auf jedes Beispiel folgt die WHERE-Klausel für die Beispieldatenbank.
Der technische Support und andere Gruppen verlangen Auskunft darüber, wann ein bestimmter Fehler den Status "Behoben" erhalten hat.
Die WHERE-Klausel sieht so aus:
DH.ActionCode = 'VERIFIED'
Der Wert für ActionCode in der Tabelle IM_DefectHistory wird aktualisiert, wenn ein Benutzer eine Aktion durchführt. Daher erhält der technische Support nur eine einzige E-Mail, nämlich dann, wenn die Aktion "Überprüfen" den Aktionscode "VERIFIZIERT" in die Tabelle IM_DefectHistory und in das Register Historie einträgt.
Wenn sich die Klausel auf die Begründung bezieht (Disposition in der Datenbank), würde sie so aussehen:
D.Disposition = 'FIXED'
In diesem Fall würde der technische Support mit großer Wahrscheinlichkeit mehrmals per E-Mail benachrichtigt, da die Begründung in der Datenbank weiterhin "BEHOBEN" lautet. Ein Benutzer, der nachträglich einen Kommentar hinzufügt oder den Fehler speichert, würde eine E-Mail auslösen, da die Regel immer noch erfüllt ist.
Ein gewöhnlicher Benutzer, der keine Aktionen mit Fehlern durchführt, möchte wissen, was mit einem Fehler geschehen ist, den er eingegeben hat. Er möchte per E-Mail benachrichtigt werden, wenn sich ein Entwickler dem Fehler zuwendet. Für den Workflow bedeutet dies, dass der Fehler soeben den Status Offen verlassen hat. Die WHERE-Klausel muss demzufolge prüfen, ob sich nach der Aktion der Status geändert hat.
Die WHERE-Klausel lautet:
DH.StatusIN = 'Dev-Ready' AND DH.StatusOUT <> 'Dev-Ready'
Vor der Aktion war der Status Offen. Nach der Aktion erhielt der Fehler einen anderen Status.
Die Dokumentationsabteilung lässt alle Dokumentationsfehler an das Gruppenpostfach Dok (Produkt A) und nicht an das Benutzerpostfach Judy -- Dok senden. Der Dokumentationsmanager möchte per E-Mail benachrichtigt werden, wenn ein Fehler im Gruppenpostfach abgelegt wird.
Die WHERE-Klausel lautet:
DH.AssignedIN <> 'Doc (Product A)' AND DH.AssignedOUT = 'Doc (Product A)'
Die Klausel bewirkt, dass eine E-Mail gesendet wird, wenn das Postfach vor der Aktion nicht Dok (Produkt A) war, nach der Aktion aber Dok (Produkt A) ist. Die E-Mail wird nur einmal gesendet, nämlich dann, wenn der Dokumentationsfehler dem Postfach Dok (Produkt A) zugeordnet wird.
Beachten Sie, dass der Dokumentationsmanager ohne den ersten Teil der WHERE-Klausel immer dann per E-Mail benachrichtigt wird, wenn mit dem Dokumentationsfehler eine Aktion durchgeführt wird und dieser dem Postfach "Dok (Produkt A)" zugeordnet ist. Obwohl die Regel möglicherweise zahlreiche E-Mails generiert, da die Benachrichtigung projektweit angewendet werden muss, fassen die beiden Teile der WHERE-Klausel die Regel zu einem einzigen Ereignis zusammen: wenn das Postfach zu Dok (Produkt A) wird.
Sie brauchen in dieser Regel den Fehlertyp DOK-FEHLER nicht anzugeben (obwohl es nicht falsch wäre), da das Postfach Dok (Produkt A) nur Dokumentationsfehler enthält.
Der Versionsmanager möchte im Lauf des nächsten Monats per E-Mail über schwer wiegende Fehler benachrichtigt werden, die nicht behoben werden konnten. Dies soll vor der Einführung einer größeren Versionsumstellung geschehen. Die WHERE-Klausel muss die Einstufung, Produkt B und den Aktionscode Nicht behebbar untersuchen, der zugeordnet wird, wenn ein Entwickler die Aktion Nicht behebbar durchführt.
Die WHERE-Klausel lautet:
D.Severity = '1: Fatal/Data Loss' AND DH.ActionCode = 'Cannot-Fix' AND D.ProductCode = 'Product B'
Diese Einschränkungen sind notwendig, da die WHERE-Klausel nur die Einstufung untersucht, trifft die Regel immer dann zu, wenn der Fehler geändert und gespeichert wird, denn die Einstufung ändert sich nur explizit durch eine Benutzereingabe.
Der Versionsmanager würde Unmengen von E-Mails erhalten, besonders dann, wenn die Regel in einer projektweiten Benachrichtigung zur Anwendung kommt. Er kann die Benachrichtigung allerdings einfach löschen, wenn der Versionszyklus beendet ist.
Gehen Sie vom Allgemeinen zum Speziellen vor. Überlegen Sie sich zuerst allgemeine Geschäftssituationen, die vielleicht E-Mail-Benachrichtigungsregeln erfordern. Fragen Sie beispielsweise alle Issue Manager-Benutzer, wann sie per E-Mail über Fehler benachrichtigt werden möchten. Finden Sie genau heraus, welche Informationen der Benutzer in einer E-Mail erwartet. Ein Benutzer könnte Ihnen beispielsweise erzählen, er möchte benachrichtigt werden, wenn ein Fehler behoben wurde. Bei näherer Betrachtung stellt sich jedoch heraus, dass er informiert werden möchte, wenn die Behebung des Fehlers durch einen QS-Mitarbeiter überprüft worden ist. Die beiden Ansätze erfordern möglicherweise unterschiedliche WHERE-Klauseln.
Wenn Sie glauben, die Bedürfnisse der Benutzer verstanden zu haben, übertragen Sie die Situation auf den Workflow Ihres Unternehmens.
Am Ende stellen Sie die WHERE-Klausel zusammen. Versuchen Sie, die WHERE-Klausel durch eine komplizierte Abfrage zu testen, um sicherzustellen, dass die Bedingungen auf die gewünschte Weise angegeben wurden.
Im Allgemeinen sollten Regeln für Benachrichtigungen, die sich auf einzelne Fehler beziehen, möglichst einfach und allgemein gehalten werden. Regeln für projektweite Benachrichtigungen sollten dagegen präzise und restriktiv formuliert werden, um übermäßiges E-Mail-Aufkommen zu vermeiden.
Stellen Sie sich die Frage, wie oft Benutzer E-Mails erhalten möchten – ein einziges Mal oder bei jeder Änderung. Wünscht der Benutzer nur eine einzige Mail, sollten Sie die Regeln mit mehreren Einschränkungen formulieren.