Puede utilizar scripts globales para definir funciones comunes a las que puede llamar desde cualquier enganche del esquema. Los scripts globales son como una biblioteca de subrutinas; el software Rational ClearQuest no las invoca directamente.
Los scripts globales resultan útiles cuando tiene varios tipos de registro que llaman al mismo código de enganche. Le permiten centralizar el mantenimiento del código del enganche y le ahorra el tener que copiar el código del enganche en varios sitios. Por ejemplo, el script global que se incluye en el paquete Email de Rational ClearQuest permite que varias acciones envíen una notificación llamando a un script global.
El único modo de ejecutar un script global es llamarlo desde otro script. Por último hay que tener en cuenta que se debe realizar un seguimiento de una llamada a un script global con una llamada a un enganche basado en registro, como un enganche de campo, un enganche de acción o un script de registro. Puesto que las llamadas a un script global se pueden rastrear siempre hasta un enganche basado en registro, cada script global cuenta con un objeto de entidad implícito que se pasa al enganche basado en registro que ha originado la llamada.
Puede grabar sus scripts utilizando tanto VBScript como Perl, pero un tipo de lenguaje no puede llamar a otro tipo de lenguaje. Cuando grabe un script global, grábelo en el mismo lenguaje que el script que lo llama.
Utilice funciones sólo en un enganche global, puesto que se ejecuta todo el código de un script global a no ser que se trate de una función.
Para obtener más información, consulte Escritura de scripts y Contexto operativo para la utilización de scripts.
Para ver ejemplos de scripts relevantes, consulte Ejemplo de script global
Para Perl, las variables $entity y $session son variables globales que se activan cuando se ejecuta un enganche. Estas variables están definidas en el tiempo de ejecución y se pueden utilizar en el código de script global. Sin embargo, no se utilizan estas variables para llamar a los métodos de los objetos Entity o Session dentro del contexto de un script global.
$info = $session->GetProductInfo();No es suficiente colocar la llamada $session en una subrutina global. Por ejemplo, el siguiente código falla por la misma razón porque intenta solucionar $productInfo en el tiempo de compilación:
$productInfo = GetProductInfo(); sub GetProductInfo { return $session->GetProductInfo(); }
En lugar de utilizar variables globales como $productInfo, llame a la variable GetProductInfo() para recuperar el valor.
Mientras se ejecutan los enganches Perl, la variable $session siempre está establecida en la sesión actual. Sin embargo, para conseguir el mejor rendimiento, evite definir variables globales que sean sensibles a los datos de los objetos Session o Entity; en lugar de eso, grabe funciones globales del objeto usuario (por ejemplo, GetUserLoginName()) para recuperar los valores.
Los scripts globales están pensados para que se utilicen como una colección de subrutinas a las que se puede llamar desde otros enganches (como los enganches de control de accesos, los enganches de inicialización y los enganches de validación). Para permitirlo, todo el código del script global se incluye como parte del código Perl que se utiliza para cada ejecución del enganche. Sin embargo, el código de script global puede incluir sentencias que estén fuera del ámbito de las subrutinas (en el ámbito de los archivos).
Empezando por la versión 7.0.1, hay disponible una nueva mejora del enganche Perl que clona los scripts globales. Cuando esta mejora se habilita, se crea un entorno de enganche Perl; todo el código del script global se compila y, a continuación, se clona para crear nuevos entornos de enganche. El proceso de clonación evita tener que volver a compilar el código y permite que los entornos de enganche compartan el árbol de análisis. La clonación de scripts permite ahorrar tiempo y memoria en el entorno de enganches Perl, que proporciona un mejor rendimiento (con mejoras significativas para la web de Rational ClearQuest).
Los desarrolladores de esquemas deberían tener en cuenta cómo utilizar la clonación al grabar scripts globales. Si la clonación se habilita para los enganches globales, las sentencias del ámbito de los archivos en scripts globales se ejecutan sólo una vez. A continuación, los resultados se clonan a los posteriores intérpretes de Perl. Si la clonación se inhabilita, este código se ejecuta cada vez que el entorno del enganche se crea (una vez por acción de registro y una vez por cada llamada de script de registro).
our $run_once; sub DoSetup { return if defined($run_once); $run_once = 1; # realizar aquí la configuración }
sub Defect_Initialization { DoSetup(); # … # … #código para el restablecimiento de Defect_Initialization…. # … }
En este ejemplo de código, la variable $run_once no está definida cuando se crea el entorno de enganche. Cuando se cola, la variable sigue sin estar definida. Cuando los enganches se ejecutan por primera vez y llaman a DoSetup(), se ejecuta el código de configuración.
use Win32::OLE;no debe usarse en código de enganche clonado (pero puede usarse en código de enganche no clonado, incluyendo enganches de acción, enganches de campo y enganches de registro). Win32::OLE no es segura con respecto a hebras pero puede usarse fuera de un entorno multihebra de ClearQuest Web. Por ejemplo, puede utilizar
require Win32::OLE; import Win32::OLE;dentro del script global para impedir que el módulo Win32::OLE se clone, pero el módulo no debe usarse en esquemas que se utilicen con Rational ClearQuest Web.