Los enganches son puntos de entrada, como desencadenantes, para scripts que se ejecutan en tiempos especificados para controlar el modo en que los usuarios trabajan en un entorno de Rational ClearQuest.
Los enganches se ejecutan con privilegios de superusuario y, por lo tanto, no están sujetos al control de accesos ni a las restricciones de comportamiento de campo habituales. Puede utilizar enganches para establecer y restablecer valores en campos que, por lo general, son de sólo lectura. (No puede restablecer campos del sistema como, por ejemplo, el campo de historial). Los campos obligatorios siguen siendo obligatorios. Para obtener más información, consulte el manual IBM Rational ClearQuest API Reference y el apartado Acciones y controles de acceso.
Se da soporte a cuatro tipos de enganches:
Los enganches de campo permiten comprobar un valor de campo en tiempo de ejecución y ajustar otros campos según se requiera. Por ejemplo, puede validar el contenido de un campo o asignarle un valor predeterminado.
Los enganches de acción permiten realizar tareas en puntos clave del ciclo de vida de un registro. Por lo general, los enganches de acción se asocian a sucesos que afectan a todo el registro. Por ejemplo, puede validar el registro completo y enviar notificaciones cuando la acción se completa.
Los scripts de registro permiten realizar tareas específicas en tiempo de ejecución. Son específicos de un tipo de registro y suelen estar asociados a controles de formulario.
Los scripts globales permite definir bibliotecas de rutinas que pueden compartir todos los tipos de registro del esquema. Por ejemplo, puede escribir una subrutina, como una notificación por correo electrónico, a la que se pueda llamar desde cualquier enganche de cualquier tipo de registro.
Puede escribir enganches en VBScript (para Windows) y Perl (para el sistema) Windows) y Perl (para el sistema UNIX y Windows). De manera predeterminada, los enganches se ejecutan en VBScript en Windows. Para obtener información sobre la ejecución de enganches en Perl para Windows, consulte el apartado Lenguajes de creación de scripts.
Puede añadir un script escrito en VBScript o Perl a enganches de acción y de campo. Si va a crear scripts globales o scripts de registro, debe utilizar VBScript o Perl.
Para facilitar su almacenamiento y consulta, puede escribir scripts VBScript y Perl en el mismo esquema. Sin embargo, un esquema sólo ejecuta scripts en el lenguaje especificado para ese esquema. Para obtener más información, consulte el apartado Lenguajes de creación de scripts.
Escriba o edite los scripts en el editor de scripts. Cuando define un nuevo script, el Diseñador añade la sintaxis de llamada para dicho enganche a la ventana del editor de scripts. La sintaxis de llamada no se puede editar. El Diseñador también añade texto de ejemplo que se puede editar según se requiera. (El texto inicial aparece comentado y no se ejecuta a menos que se eliminen los marcadores de comentario).
El Diseñador proporciona un editor de scripts diferente para VBScript y Perl, e indica el tipo de editor en la barra de título de la ventana. Verifique si utiliza el editor correcto antes de escribir el código.
Se ha simplificado el proceso de creación de enganches de VBScript y Perl debido a la coherencia del contexto operativo. Antes de que un enganche llame a un script VBScript o Perl, el software Rational ClearQuest crea un objeto Session e inicia la sesión de usuario en el sistema. Puesto que todos los enganches (incluidos los enganches globales) se ejecutan desde el contexto del registro actual, se proporciona un objeto Entity que corresponde a dicho registro. (Los scripts globales comparten el objeto Entity asociado al enganche que lo ha llamado).
Dentro de un script, puede llamar a los métodos de Entity sin especificar un identificador inicial. Por ejemplo, puede llamar al método GetSession de Entity de la siguiente forma:
set curSession = GetSession
Al llamar a métodos de este modo, el software Rational ClearQuest presupone que se está llamando a un método del objeto Entity implícito que se ha pasado al enganche. Si desea hacer referencia a este objeto Entity de forma explícita, puede utilizar el nombre del tipo de registro como identificador para el objeto. La utilización de este identificador puede ayudar a clarificar código que manipula más de un objeto Entity a la vez, como en el siguiente ejemplo, que marca una entidad como duplicado de otra:
set curSession = GetSession
idName = GetFieldValue("id").GetValue
set currentObj = curSession.GetEntity("defect", idName)
' Marque la entidad con ID="SAMPL00000031" como duplicado de esta entidad.
' Utilice la acción denominada "duplicate".
set dupEntityObj = curSession.GetEntity("defect", "SAMPL00000031")
curSession.MarkEntityAsDuplicate dupEntityObj, currentObj, "duplicate"
Puesto que los scripts pueden afectar al comportamiento de un campo, diseñe y pruebe el código de enganche detenidamente. Por ejemplo, si un enganche necesita que un campo contenga algún tipo de valor, el campo se convierte en obligatorio aunque su comportamiento no esté establecido en MANDATORY.
El código de enganche puede presentar errores imperceptibles en tiempo de ejecución si no se escribe correctamente. Un enganche se compilará cuando valide el esquema y se indicarán los errores de sintaxis y de gramática. Antes de incorporar el esquema, pruébelo con una base de datos de prueba y haga una copia de seguridad de la base de datos antes de aplicar cambios al mismo. Para obtener más información, consulte Prueba del esquema con una base de datos de prueba.
Tenga en cuenta lo siguiente cuando planifique los enganches:
Muchas cuestiones relativas a los enganches que se ejecutan en un entorno duplicado son las mismas que las cuestiones de bloqueo de bases de datos de un solo sitio. La prueba funcional de enganches es también la misma en un solo sitio o un entorno duplicado. Sin embargo, la ejecución de algunos enganches de ClearQuest puede ser diferente en un entorno duplicado que en un entorno de un solo sitio. Por ejemplo, los enganches que actualizan otros registros en el contexto de la acción de un solo registro pueden encontrar errores si el otro registro no está controlado en el sitio actual y, por tanto, no es modificable.
Cada uno de los registros de la base de datos sólo puede actualizarse en el sitio en que está controlado actualmente (esto se indica mediante el nombre del sitio de réplica en el campo ratl_mastership del registro). En las aplicaciones complejas, pueden actualizarse varios registros como parte de una sola transacción de complejo. Al diseñar y probar enganches para un entorno duplicado, es preciso tener en cuenta estos principios.
Consulte también Bloqueo de registro y Validación de esquemas.
Cuando se instala un paquete, es posible que se añadan enganches de campo o scripts de registro al esquema. Estos scripts forman parte del paquete, no del código de enganche.
No se pueden suprimir ni modificar los scripts de propiedad de un paquete puesto que no forman parte del código que pertenece el esquema. Por este motivo, no hay ninguna relación entre el valor predeterminado de lenguaje que elija para el código de enganche y el lenguaje en el que se han implantado los enganches propiedad de un paquete.