Globale Scripts

Dieser Artikel erläutert das Konzept der globalen ClearQuest-Scripts.

Mit globalen Scripts können Sie einheitliche Funktionen definieren, die Sie in jedem Hook Ihres Schemas aufrufen können. Globale Scripts sind vergleichbar mit einer Bibliothek der Subroutinen. Sie werden von Rational ClearQuest nicht direkt aufgerufen.

Globale Scripts sind nützlich, wenn Sie über mehrere Datensatztypen verfügen, die den gleichen Hook-Code aufrufen. Sie ermöglichen die zentralisierte Pflege von Hook-Code und vermeiden das Kopieren des Hook-Codes an viele verschiedene Positionen. Beispielsweise ermöglicht das globale Script im Paket "Email" von Rational ClearQuest mehreren Aktionen das Senden von Benachrichtigungen durch Aufrufen eines einzigen globalen Scripts.

Die einzige Methode zum Aufrufen eines globalen Scripts ist das Aufrufen in einem anderen Script. Der Aufruf eines globalen Scripts muss jedoch letztlich bis zum Aufruf eines datensatzabhängigen Hooks (z. B. eines Feld-Hooks oder eines Datensatz-Scripts) zurückverfolgt werden können. Da Aufrufe eines globalen Scripts immer bis zu einem Aufruf eines datensatzabhängigen Hooks zurückverfolgt werden können, wird jedem globalen Script ein implizites Entitätsobjekt zur Verfügung gestellt, das an den datensatzabhängigen Hook übergeben wird, von dem der Aufruf ausgegangen ist.

Sie können Ihre Scripts entweder mit VBScript oder mit Perl schreiben, aber innerhalb eines Sprachtyps darf kein anderer Sprachtyp aufgerufen werden. Ein globales Script muss immer in der gleichen Sprache geschrieben werden wie das Script, von dem es aufgerufen wird.

In einem globalen Hook sollten ausschließlich Funktionen verwendet werden, da jeder Code in einem globalen Script ausgeführt wird, es sei denn, er ist in einer Funktion enthalten.

Weitere Informationen finden Sie in den Abschnitten Scripts schreiben und Betriebskontext für die Verwendung von Scripts.

Beispiele für relevante Scripts finden Sie im Abschnitt Global script example.

Subroutinen für globale Scripts verwenden

In Perl sind die Variablen "$entity" und "$session" globale Variablen, die aktiv werden, wenn ein Hook ausgeführt wird. Diese Variablen werden zur Laufzeit definiert und können im Code globaler Scripts verwendet werden. Diese Variablen werden im Kontext eines globalen Scripts jedoch nicht zum Aufrufen von Methoden der Objekte "Entity" und "Session" verwendet.

Wenn der Code des globalen Scripts diese Variablen zum Aufrufen einer Methode (z. B. $entity->GetSession) verwendet, schlägt die Schemavalidierung fehl, da "$session" und "$entity" zum Ausführungszeitpunkt nicht definiert sind. Der Grund ist, dass die Methode nicht für einen nicht definierten Wert ($session) aufgerufen werden kann.
$info = $session->GetProductInfo();
Es ist nicht ausreichend, den Aufruf "$session" in eine globale Subroutine zu stellen. Der folgende Code schlägt aus demselben Grund fehl, da er versucht, "$productInfo" zur Kompilierzeit aufzulösen:
$productInfo = GetProductInfo();
   sub GetProductInfo
   {
       return $session->GetProductInfo();
   }

Verwenden Sie zum Abrufen des Werts nicht globale Variablen wie "$productInfo", sondern GetProductInfo().

Bei der Ausführung von Perl-Hooks wird $session immer auf die aktuelle Sitzung gesetzt. Die beste Leistung erzielen Sie jedoch, wenn Sie es vermeiden, globale Variablen, die auf Daten der Objekte "Session" oder "Entity" reagieren, zu definieren. Schreiben Sie stattdessen globale Zugriffsfunktionen (z. B. GetUserLoginName()), um die Werte abzurufen.

Globale Scripts klonen

Globale Scripts sind als Sammlung von Subroutinen gedacht, die von anderen Hooks aufgerufen werden können (z. B. Hooks für Zugriffssteuerung, Initialisierung und Validierung). Um dies zu ermöglichen, wird der Code für globale Scripts als Bestandteil des Perl-Codes eingefügt, der für jede Hook-Ausführung verwendet wird. Der Code für globale Scripts kann jedoch Anweisungen auf Dateiebene enthalten, die außerhalb des Geltungsbereichs der Subroutine liegen.

Ab Version 7.0.1 ist eine funktionale Erweiterung des Perl-Hooks verfügbar, die in der Lage ist, globale Scripts zu klonen. Ist diese Erweiterung aktiviert, wird eine Perl-Hook-Umgebung erstellt. Der gesamte Code für globale Scripts wird kompiliert und dann geklont, um neue Hook-Umgebungen zu erstellen. Der Klonprozess vermeidet die erneute Kompilierung von Code und ermöglicht Hook-Umgebungen, einen Syntaxanalysebaum gemeinsam zu nutzen. Das Klonen von Scripts spart Zeit und Speicherkapazität für alle Perl-Hook-Umgebungen, was eine bessere Leistung zur Folge hat (mit deutlichen Verbesserungen für Rational ClearQuest Web).

Schemaentwickler sollten überlegen, wie sie das Klonen beim Schreiben globaler Scripts einsetzen. Wenn das Klonen für globale Hooks aktiviert ist, werden Anweisungen auf Dateiebene in globalen Scripts nur einmal ausgeführt. Die Ergebnisse werden dann in nachfolgenden Perl-Interpretern geklont. Wenn das Klonen inaktiviert ist, wird der Code jedes Mal, wenn die Hook-Umgebung erstellt wird, ausgeführt (einmal pro Datensatzaktion und einmal pro Aufruf des Datensatz-Scripts).

Um Verwirrung zu vermeiden, wenn es darum geht, Konfigurationscode in geklonten globalen Scripts auszuführen, sollten Sie den Konfigurationscode im Geltungsbereich der Datei in eine Subroutine versetzen und eine Variable mit einem besonderen Geltungsbereich, our, zur Prüfung des Konfigurationsstatus verwenden. Sie können sicherstellen, dass der Konfigurationscode immer mindestens einmal in jeder Hook-Umgebung ausgeführt wird, und Mehrfachausführungen vermeiden. Diese Konfigurationssubroutine kann in jedem Hook aufgerufen werden, der die abgeschlossene Ausführung der Konfiguration voraussetzt. Beispiel:
  our $run_once;
   sub DoSetup
   {
       return if defined($run_once);
       $run_once = 1;
       # do setup here
   }
sub Defect_Initialization {
 DoSetup();
 # …
 # …
 #reset of Defect_Initialization code….
 # …
 }

In diesem Codebeispiel wird die Variable "$run_once" nicht definiert, wenn die Hook-Umgebung erstellt wird. Wenn die Variable geklont wird, ist sie immer noch nicht definiert. Wenn Hooks zum ersten Mal ausgeführt werden und DoSetup() aufrufen, wird der Konfigurationscode ausgeführt.

Anmerkung: Voraussetzung für das Klonen globaler Scripts mit Perl ist, dass alle Perl-Bibliotheken, die von IBM Code aufgerufen werden, sicher für Threads sein müssen. Beispiel:
use Win32::OLE;
sollte nicht in geklontem Hook-Code verwendet werden (kann jedoch in ungeklontem Hook-Code, einschließlich Aktions-Hooks, Feld-Hooks und Datensatz-Hooks verwendet werden). Win32::OLE ist nicht sicher für Threads, kann jedoch außerhalb einer Multithread-Umgebung von ClearQuest Web verwendet werden. Beispielsweise können Sie
require Win32::OLE; import Win32::OLE;
im globalen Script verwenden, um zu verhindern, dass das Modul Win32::OLE geklont wird. Das Modul darf jedoch nicht in Schemas verwendet werden, die mit Rational ClearQuest Web verwendet werden.
Achtung: IBM® kann nicht garantieren, dass ein Perl-Modul threadsicher ist, da IBM keinen Einfluss auf Perl-Module hat. Informationen zur Threadsicherheit finden Sie in der Perl-Dokumentation unter http://www.perl.org.

Feedback