IBM Rational ClearQuest unterstützt die Verwendung von VBScript oder Perl zum Schreiben von benutzerdefiniertem Hook-Code. Bei der Auswahl der Scripting-Sprache und der Operationen für die Hooks müssen jedoch Kompromisse hinsichtlich der Leistung und Funktionalität eingegangen werden. Dieses Thema wird hier zwar nicht in aller Ausführlichkeit diskutiert, die folgenden Richtlinien sollten aber bei allen Schemaänderungen berücksichtigt werden. Weitere Informationen zur Leistung von Rational-ClearQuest-Schemas finden Sie auf der IBM developerWorks-Website.
Für Rational-ClearQuest-Systeme, die eine Mischung aus verschiedenen Clientplattformen unterstützen, ergeben sich durch die neue Anwendung Rational ClearQuest Web Leistungsvorteile.
Rational ClearQuest Web kann unter Windows, UNIX oder Linux implementiert werden.
Jede Clientkomponente von Rational ClearQuest Windows einschließlich der Serverkomponente von Rational ClearQuest Web kann Hooks ausführen, die in VBScript oder Perl geschrieben sind. Die Clientkomponenten von Rational ClearQuest für UNIX oder für Linux können jedoch nur Perl-Scripts ausführen. Wenn also eine Rational-ClearQuest-Implementierung Clientkomponenten für UNIX oder Linux erfordert, müssen Hooks in Perl geschrieben werden.
Der Zugriff auf die Datenbank ist normalerweise die zeitaufwändigste Operation eines Hooks. Beispiele für Operationen mit Datenbankzugriff:
Das Abrufen einer Entität (Datensatz) erfordert mindestens eine Abfrage der Datenbank bezüglich des primären Datensatzes, plus eine Abfrage für jedes REFERENCE_LIST-Feld. Entitäten werden explizit durch Session-Methoden wie GetEntity oder LoadEntity abgerufen, können aber auch implizit durch Zugriff auf den Feldwert eines REFERENCE-Feldes abgerufen werden. Im folgenden Beispiel wird die Entität, auf die das Feld product verweist, implizit geladen. Dann wird der Wert des Felds component aus dem geladenen Datensatz product abgerufen:
$component = $entity->GetFieldValue("product.component")->GetValue();
Die erforderliche Zeit zum Laden einer Entität ist von der Komplexität des Schemas abhängig, vor allem von der Anzahl der Referenzlistenfelder in der ausgewählten Entität. Wenn nur ein Teil der Felder einer Entität benötigt werden, ist es vielen Fällen effizienter, nur diese Feldwerte abzufragen, anstatt die gesamte Entität abzurufen.
Obwohl Abfragen effizienter sind als das Abrufen kompletter Datensätze, ist dennoch ein Datenbankzugriff erforderlich, der Auswirkungen auf die Gesamtleistung der Schemas hat. Alle Bemühungen sollten deshalb dahin gehen, die Anzahl der Datenbankumläufe zu minimieren. Beispielsweise können Sie eine Abfrage nur einmal ausführen und die ResultSet-Werte in einer Sitzungsvariablen (bei VBScript) zwischenspeichern, anstatt die Abfrage mehrmals an verschiedenen Positionen im Hook-Code auszuführen. Rufen Sie außerdem nur die Felder ab, die für die einzelnen Datensätze relevant sind. Vermeiden Sie die Angabe von mehrzeiligen Textfeldern in den Ergebnislisten von Abfragen, da für jedes abzurufende mehrzeilige Textfeld ein zusätzlicher Datenbankumlauf erforderlich ist.
Wenn Sie die Option Recalculate Choice List in den Eigenschaften einer Auswahlliste auswählen, wird der Hook-Code für das erneute Füllen der gültigen Auswahlliste jedes Mal ausgeführt, wenn ein anderes Feld des Datensatzes einen anderen Wert annimmt. Dies kann zu einer hohen Anzahl unnötiger Abfragen in die bzw. aus der Datenbank führen. Es gibt eine effizientere Methode, um sicherzustellen, dass die Auswahlliste gültig ist. Stellen Sie fest, welche anderen Felder sich auf die Werte in der Auswahlliste auswirken können, und lassen Sie eine erneute Berechnung der Auswahlliste nur dann zu, wenn sich diese Feldwerte ändern.
Wenn Sie beispielsweise Daten in einem Datensatz namens Auto sammeln, ist möglicherweise ein Feld für den Hersteller und ein Feld für das Modell vorhanden. Die gültige Auswahlliste für das Feld Modell hängt nur vom auswähltenHersteller ab. Es ist ineffizient, für das Feld Modell die Option Recalculate Choice List auszuwählen, um sicherzustellen, dass die Auswahlliste für dieses Feld stets gültig ist. Stattdessen können Sie einen Hook für die Änderung des Werts im Feld Hersteller schreiben, der die Auswahlliste für das Feld Modell inaktiviert. Weitere Informationen zur Verwendung dieser Methode finden Sie im Beispiel zu InvalidateFieldChoiceList.
Kaskadierende Hooks treten auf, wenn mehrere abhängige oder verschachtelte Beziehungen zwischen Feldern bestehen. Im obigen Beispiel besteht eine Abhängigkeit zwischen dem Feld Hersteller und dem Feld Modell. Als Erweiterung dieses Beispiels nehmen wir an, dass sich nach Auswahl von Modell die Liste mit gültigen Auswahlmöglichkeiten für Karrosserie, Farbe oder Motor ändert. Es ist einfach zu erkennen, dass als Folge der Änderung eines Feldwerts in einem Formular Kaskaden von Hooks für die anderen Felder ausgeführt und dann erneut ausgeführt werden könnten. Die Tiefe der Beziehungen zwischen diesen verschachtelten Feldern sollte minimiert werden; ferner sollte das Schema mit Vorsicht implementiert werden, um eine unnötige oder redundante Ausführung von Hook-Code zu vermeiden. Beispiele finden Sie im Abschnitt zur Methode GetFieldStringValues und in den Beschreibungen anderer verwandter Methoden.
Das Abrufen von AdminSession-Objekten hat Auswirkungen auf die Leistung, und möglicherweise gibt es Alternativen für den Datenabruf. Anstelle der Verwendung des AdminSession-Objekts und der zugrunde liegenden Methoden des User- und Group-Objekts zum Abrufen von Benutzer- oder Gruppeninformationen können Sie Abfragen für Benutzer- und Gruppendatensätze (statusunabhängige Satztypen) erstellen, die sich in einer Benutzerdatenbank befinden.