Hooks sind Einstiegspunkte (wie Auslöser) für Scripts, die zu bestimmten Zeiten ausgeführt werden und steuern, wie Benutzer in einer Rational-ClearQuest-Umgebung arbeiten.
Bitte beachten Sie, dass Hooks mit der Berechtigung "super user" ausgeführt werden und daher nicht den sonst üblichen Einschränkungen für Zugriffssteuerung oder Feldverhalten unterliegen. Sie können daher mit Hooks Werte in Feldern, die normalerweise schreibgeschützt sind, festlegen und zurücksetzen. (Sie können jedoch keine Systemfelder, wie das Feld "History", zurücksetzen.) Obligatorische Felder bleiben obligatorisch. Weitere Informationen hierzu finden Sie in der Veröffentlichung IBM Rational ClearQuest API-Referenz im Abschnitt Aktionen und Zugriffssteuerung.
Vier Hook-Typen werden unterstützt:
Feld-Hooks ermöglichen das Prüfen eines Feldwerts zur Laufzeit sowie das Anpassen weiterer Felder nach Bedarf. Beispielsweise können Sie den Inhalt eines Felds validieren oder ihm einen Standardwert zuordnen.
Aktions-Hooks ermöglichen die Ausführung von Tasks an Schlüsselstellen im Lebenszyklus eines Datensatzes. Im Allgemeinen werden Aktions-Hooks Ereignissen zugeordnet, die sich auf den gesamten Datensatz auswirken. Beispielsweise können Sie den gesamten Datensatz validieren und Benachrichtigungen senden, wenn die Aktion abgeschlossen ist.
Datensatz-Scripts ermöglichen das Ausführen spezieller Tasks während der Laufzeit. Sie beziehen sich auf einen bestimmten Datensatztyp und werden in der Regel Formularsteuerelementen zugeordnet.
Globale Scripts ermöglichen das Definieren von Bibliotheken mit Routinen, die von allen Datensatztypen in Ihrem Schema gemeinsam genutzt werden können. Beispielsweise können Sie eine Subroutine (z. B. eine E-Mail-Benachrichtigung) schreiben, die von jedem Hook in jedem Datensatztyp aufgerufen werden kann.
Sie können Hooks in VBScript (für Windows) und in Perl (für UNIX-Systeme und Windows) schreiben. Standardmäßig werden Hooks in VBScript unter Windows ausgeführt. Informationen zum Ausführen von Perl-Hooks für Windows finden Sie im Abschnitt Script-basierte Sprachen.
Sie können ein in VBScript oder Perl geschriebenes Script zu Feld- und Aktions-Hooks hinzufügen. Zum Erstellen globaler Scripts oder Datensatz-Scripts müssen Sie VBScript oder Perl verwenden.
Um das Speichern und Referenzieren zu vereinfachen, können Sie sowohl VBScript- als auch Perl-Scripts im selben Schema schreiben. Ein Schema führt jedoch nur Scripts in der Sprache aus, die für dieses Schema angegeben ist. Weitere Informationen finden Sie im Abschnitt Script-basierte Sprachen.
Zum Schreiben und Bearbeiten von Scripts können Sie den Script-Editor verwenden. Beim Definieren eines neuen Scripts fügt Designer im Script-Editorfenster automatisch die Aufrufsyntax für den Hook hinzu. Die Aufrufsyntax kann nicht bearbeitet werden. Designer fügt außerdem Beispieltext für den Hauptteil hinzu, den Sie nach Bedarf bearbeiten können. (Der vorgeschlagene Hauptteiltext ist auf Kommentar gesetzt und wird nur ausgeführt, wenn Sie die Kommentarzeichen entfernen.)
Designer stellt zwei verschiedene Script-Editoren für VBScript und Perl zur Verfügung und gibt den Editortyp in der Titelleiste des Fensters an. Vergewissern Sie sich vor dem Schreiben des Codes, dass Sie den richtigen Editor verwenden.
Das Schreiben von VBScript- und Perl-Hooks wird vereinfacht, da der Betriebskontext konsistent ist. Bevor ein Hook ein VBScript- oder ein Perl-Script aufruft, erstellt Rational ClearQuest ein Objekt "Session" und meldet den Benutzer beim System an. Da alle Hooks (dies gilt auch für globale Scripts) im Kontext des aktuellen Datensatzes ausgeführt werden, wird automatisch ein diesem Datensatz entsprechendes Objekt "Entity" zur Verfügung gestellt. (Globale Scripts nutzen gemeinsam das Entitätsobjekt, das dem aufrufenden Hook zugeordnet ist.)
Innerhalb eines Scripts können Sie die Methoden für "Entity" aufrufen, ohne eine Kennung voranzustellen. Beispielsweise können Sie die Methode "GetSession" für "Entity" wie folgt aufrufen:
set curSession = GetSession
Beim Aufrufen von Methoden in dieser Weise geht Rational ClearQuest automatisch davon aus, dass Sie eine Methode des impliziten Objekts "Entity" aufrufen, das an den Hook übergeben wurde. Zum expliziten Verweisen auf dieses Objekt "Entity" können Sie den Namen des Datensatztyps als Kennung für das Objekt verwenden. Durch Verwenden dieser Kennung können Sie Code, der gleichzeitig mehrere Objekte des Typs "Entity" bearbeitet, transparenter gestalten, wie im folgenden Beispiel, in dem eine Entität als Duplikat einer anderen Entität markiert wird:
set curSession = GetSession
idName = GetFieldValue("id").GetValue
set currentObj = curSession.GetEntity("defect", idName)
' Mark the entity with ID="SAMPL00000031" as a duplicate of this entity.
' Use the action named "duplicate".
set dupEntityObj = curSession.GetEntity("defect", "SAMPL00000031")
curSession.MarkEntityAsDuplicate dupEntityObj, currentObj, "duplicate"
Da Scripts das Verhalten eines Felds beeinflussen können, sollten Sie Ihren Hook-Code mit besonderer Sorgfalt entwerfen und testen. Ist für einen Hook beispielsweise eine bestimmte Art von Wert in einem Feld erforderlich, wird das Feld damit verbindlich, auch wenn das Feldverhalten nicht auf "MANDATORY" gesetzt ist.
Nachlässig geschriebener Hook-Code kann zu schwer erkennbaren Laufzeitfehlern führen. Ein Hook wird kompiliert, wenn Sie das Schema validieren, und alle Syntax- oder Grammatikfehler werden markiert. Vor dem Einchecken sollten Sie das Schema unbedingt mit einer Testdatenbank testen sowie Ihre Benutzerdatenbank sichern, bevor Sie Schemaänderungen darauf anwenden. Weitere Informationen hierzu finden Sie im Abschnitt Schema mit einer Testdatenbank testen.
Beim Planen von Hooks sind folgende Punkte zu beachten:
Viele Probleme im Zusammenhang mit Hooks, die in einer replizierten Umgebung ausgeführt werden, treten in gleicher Form beim Sperren von Datenbanken einzelner Standorte auf. Auch die Funktionsprüfung von Hooks in einer replizierten Umgebung entspricht der Prüfung an einem einzelnen Standort. Die Ausführung einiger ClearQuest-Hooks in einer replizierten Umgebung kann sich jedoch von der Ausführung an einem einzelnen Standort unterscheiden. Beispielsweise können in Hooks, die andere Datensätze im Kontext einer Datensatzaktion aktualisieren, Fehler auftreten, wenn der aktuelle Standort nicht Master des anderen Datensatzes ist und der Datensatz daher nicht geändert werden kann.
Jeder Datenbanksatz kann nur an dem Standort aktualisiert werden, der gegenwärtig sein Master ist (angezeigt durch den Namen des replizierten Standorts im Feld "ratl_mastership" des Datensatzes). In komplexen Anwendungen können mehrere Datensätze im Rahmen einer komplexen Transaktion aktualisiert werden. Diese Prinzipien sollten beim Entwurf und Test von Hooks für eine replizierte Umgebung berücksichtigt werden.
Siehe auch Satzsperren und Schemas validieren.
Beim Installieren eines Pakets werden möglicherweise Feld-Hooks oder Datensatz-Scripts zu Ihrem Schema hinzugefügt. Diese Scripts sind jedoch Teil des Pakets und nicht Teil Ihres Hook-Codes.
Die Scripts können nicht gelöscht werden, sie sind nicht Teil des Schema-Codes. Daher besteht keine Beziehung zwischen der voreingestellten Sprache, die Sie für Ihren Hook-Code auswählen, und der Sprache, in der Hooks, die zu einem Paket gehören, implementiert werden.