Les scripts globaux permettent de définir des fonctions communes pouvant être appelées à partir de n'importe quel point d'ancrage du schéma. Ils sont comparables à une bibliothèque de sous-programmes ; le logiciel Rational ClearQuest ne les appelle pas directement.
Les scripts globaux sont utiles lorsque plusieurs types d'enregistrement appellent le même code de point d'ancrage. Ils évitent d'avoir à copier le code du point d'ancrage à plusieurs endroits, ce qui permet également de centraliser sa gestion. Par exemple, le script global inclus dans le package Rational ClearQuest Email permet à plusieurs actions d'envoyer des notifications.
Un script global ne peut être exécuté qu'à partir d'un autre script. Cependant, le point de départ de la fonction doit être un appel vers un point d'ancrage basé sur un enregistrement (point d'ancrage de zone, d'action, ou script d'enregistrement). Etant donné qu'il est toujours possible de remonter à un point d'ancrage basé sur un enregistrement, chaque script global se voit attribuer un objet Entity implicite qui est transmis au point d'ancrage à l'origine de l'appel.
Vous pouvez écrire des scripts en langage VBScript et en langage Perl, mais chaque script ne peut appeler qu'un script écrit dans le même langage. Lorsque vous écrivez un script global, utilisez le même langage que le script qui l'appellera.
N'utilisez des fonctions que dans un point d'ancrage global, car l'intégralité du code de ce dernier est exécutée, sauf s'il est intégré à une fonction.
Pour plus d'informations, voir Ecriture de scripts et Fonctionnement de contexte pour l'utilisation de scripts.
Pour des exemples de scripts correspondants, voir Exemple de scripts globaux
En langage Perl, les variables $entity et $session sont des variables globales qui deviennent actives lors de l'exécution d'un point d'ancrage. Ces variables sont définies au moment de l'exécution et peuvent être utilisées dans le code d'un script global, mais pas pour appeler des méthodes d'objet Entity ou Session.
$info = $session->GetProductInfo();Il ne suffit pas de placer l'appel $session dans un sous-programme global. Par exemple, le code suivant échoue pour la même raison parce qu'il essaie de résoudre $productInfo lors de la compilation :
$productInfo = GetProductInfo(); sub GetProductInfo { return $session->GetProductInfo(); }
Au lieu d'utiliser des variables globales telles que $productInfo appelez GetProductInfo() pour extraire la valeur.
Lors de l'exécution de points d'ancrage en langage Perl, $session est toujours défini sur la session en cours. Cependant, pour de meilleures performances, évitez de définir des variables globales qui sont sensibles aux données d'objets Session ou Entity, mais écrivez plutôt des fonctions d'ID d'accès global (par exemple GetUserLoginName()) pour extraire les valeurs.
Les scripts globaux sont conçus pour être utilisés comme un ensemble de sous-routines pouvant être appelées à partir d'autres points d'ancrage (Contrôle d'accès, Initialisation et Validation, par exemple). Pour cela, l'ensemble du code de ces scripts est inclus dans le code Perl utilisé pour l'exécution de chaque point d'ancrage. Ce code peut cependant contenir des instructions qui sont en dehors du niveau du sous-programme (au niveau du fichier).
Depuis la version 7.0.1, une nouvelle extension du point d'ancrage Perl qui clone les scripts globaux est disponible. Lorsque cette extension est activée, un environnement de point d'ancrage Perl est créé. Tout le code du script global est compilé, puis cloné pour créer de nouveaux environnements de point d'ancrage. Le clonage évite de recompiler le code et permet à des environnements de point d'ancrage de partager un arbre d'analyse. Le clonage des scripts permet d'économiser du temps et de la mémoire pour chaque environnement de point d'ancrage Perl, ce qui permet de meilleures performances (avec des améliorations significatives pour Rational ClearQuest Web).
Les développeurs de schéma doivent étudier comment utiliser le clonage lorsqu'ils écrivent des scripts globaux. Si le clonage est activé pour les points d'ancrage globaux, les instructions du niveau du fichier dans les scripts globaux ne sont exécutées qu'une seule fois. Les résultats sont alors clonés pour les interpréteurs Perl ultérieurs. Si le clonage est désactivé, ce code s'exécute chaque fois que l'environnement de point d'ancrage est créé (une fois par action d'enregistrement et une fois pour chaque appel de script d'enregistrement).
our $run_once; sub DoSetup { return if defined($run_once); $run_once = 1; # effectuer configuration ici }
sub Defect_Initialization { DoSetup(); # … # … #réinitialisation du code Defect_Initialization…. # … }
Dans cet exemple de code, la variable $run_once n'est pas définie lorsque l'environnement de point d'ancrage est créé. Si elle est clonée, cette variable n'est toujours pas définie. Lorsque des points d'ancrage s'exécutent d'abord et appellent DoSetup(), le code de configuration est exécuté.
use Win32::OLE;ne doit pas être utilisé dans un code de point d'ancrage cloné (mais il peut l'être dans un code de point d'ancrage d'action, de zone ou d'enregistrement non cloné). Le module Win32::OLE n'autorise pas les unités d'exécution multiples, mais il peut être utilisé en-dehors d'un environnement ClearQuest Web à unités d'exécutions multiples. Par exemple, vous pouvez utiliser
require Win32::OLE; import Win32::OLE;dans le script global pour empêcher le clonage du module Win32::OLE, mais ce dernier ne doit pas apparaître dans les schémas utilisés avec Rational ClearQuest Web.