Scripts globaux

Cette rubrique décrit le concept des scripts globaux ClearQuest.

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.

Utilisation de sous-routines pour des 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.

Si le code de script global utilise ces variables pour appeler une méthode (telle que $entity->GetSession), la validation du schéma échoue parce que $session et $entity ne sont pas définis avant l'exécution. Par exemple, en dehors d'un sous-programme global, le code suivant échouera car vous ne pouvez pas appeler la méthode pour une valeur non définie ($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.

Clonage de script global

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 (Access Control, Initialization 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).

Pour éviter toute confusion sur l'exécution du code de configuration dans des scripts globaux clonés, transférez le code de configuration placé au niveau du fichier dans un sous-programme et utilisez une variable globale our spécialement sectorisée pour contrôler le statut de configuration. Vous pouvez garantir que le code de configuration soit toujours exécuté au moins une fois dans chaque environnement de point d'ancrage et éviter les exécutions multiples. Ce sous-programme de configuration peut être appelé de n'importe quel point d'ancrage ayant besoin que la configuration soit exécutée. Par exemple :
  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….
 # …
 }

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é.

Remarque : Le clonage d'un script global Perl nécessite que toutes les bibliothèques Perl appelées par votre code autorisent les unités d'exécution multiples. Par exemple,
use Win32::OLE;
ne doit pas être utilisé dans du code de point d'ancrage cloné (mais peut être utilisé dans du code de point d'ancrage non cloné, y compris pour des points d'ancrage d'action, de zone ou d'enregistrement). Win32::OLE n'autorise pas les unités d'exécution multiples mais peut être utilisé en dehors d'un environnement à unités d'exécution multiples ClearQuest Web. Par exemple, vous pouvez utiliser
require Win32::OLE; import Win32::OLE;
dans le script global pour empêcher le module Win32::OLE d'être cloné, mais le module ne doit pas être utilisé dans des schémas utilisés avec Rational ClearQuest Web.
Avertissement : IBM® ne peut garantir qu'un module Perl autorise les unités d'exécution multiples, car les modules Perl échappent au contrôle d'IBM. Pour plus d'informations sur la sécurité des unités d'exécution, voir la documentation Perl disponible à l'adresse suivante : http://www.perl.org.

Feedback