IBM Rational ClearQuest da soporte para la utilización de VBScript y Perl para escribir código de enganche personalizado. Sin embargo, existen intercambios de rendimiento y funcionales que se deben tener en cuenta al escoger el lenguaje de script y los tipos de operaciones a utilizar en los enganches. Aunque esta no es una discusión exhaustiva sobre el tema, se deben aplicar las directrices siguientes a cualquier modificación del esquema. Para obtener más información sobre el tema del rendimiento de esquema de Rational ClearQuest, consulte el sitio web de IBM developerWorks.
Para todos los sistemas Rational ClearQuest que dan soporte a una combinación de plataformas cliente, existen ventajas de rendimiento al utilizar el nuevo Rational ClearQuest Web.
El nuevo Rational ClearQuest web se puede desplegar en Windows, en el sistema UNIX y en sistemas Linux.
Cualquier cliente de Rational ClearQuest Windows, incluido el servidor web de Rational ClearQuest, puede ejecutar enganches escritos en VBScript o Perl. Sin embargo, los clientes de Rational ClearQuest para el sistema UNIX o Linux sólo pueden ejecutar scripts de Perl. Por lo tanto, si un despliegue de Rational ClearQuest requiere clientes para el sistema UNIX o para Linux, los enganches se deben escribir en Perl.
Por lo general, el acceso a la base de datos es la operación que consume más tiempo de las que lleva a cabo un enganche. Los ejemplos de las operaciones que requieren acceso a la base de datos son:
Recuperar una entidad (registro) requiere, como mínimo, una consulta de la base de datos para el registro principal, además de una consulta para cada campo REFERENCE_LIST. Las entidades se recuperan explícitamente a través de métodos de Session como, por ejemplo, GetEntity o LoadEntity, pero también se pueden recuperar de modo implícito accediendo al valor de campo de un campo REFERENCE. En el ejemplo siguiente se carga, implícitamente, la entidad a la que hace referencia el campo product y, a continuación, se recupera el valor del campo component del registro de product cargado:
$component = $entity->GetFieldValue("product.component")->GetValue();
La complejidad del esquema y, básicamente, el número de campos de lista de referencia de la entidad seleccionada, determina el momento de cargar una entidad. En muchas instancias, si sólo se necesita un subconjunto de campos de una entidad, resulta más eficaz consultar los valores de campo, en lugar de recuperar la entidad completa.
Aunque resulten más eficaces que recuperar los registros de entidad completa, las consultas todavía requieren el acceso a la base de datos y, por lo tanto, tienen un impacto directo en el rendimiento del esquema global. Se deben minimizar al máximo las búsquedas directas e inversas en la base de datos. Por ejemplo, en lugar de ejecutar la misma consulta varias veces en varias ubicaciones del código de enganche, se puede ejecutar una consulta una vez, y los valores de ResultSet se pueden colocar en la antememoria en una variable de sesión (para VBScript). Asimismo, recupere sólo los campos que son esenciales para cada registro. Evite especificar campos de texto de múltiples líneas en conjuntos de resultados de la consulta, ya que esto requiere una búsqueda directa e inversa adicional en la base de datos para cada campo de texto de varias líneas a recuperar.
Cuando selecciona la opción Recalcular lista de opciones en las propiedades de una lista de opciones, el código de enganche necesario para rellenar la lista de opciones válida se ejecuta cada vez que cambia el valor de cualquier otro campo del registro, lo que puede provocar una gran cantidad de tráfico de consulta innecesario hacia y desde la base de datos. Un método más eficaz para garantizar la validez de la lista de opciones consiste en determinar los otros campos que pueden afectar a los valores de la lista de opciones, y forzar que la lista de opciones se recalcule sólo cuando cambien los valores de campo.
Por ejemplo, si está recopilando datos en un registro Automóvil, puede tener un campo para el Fabricante del automóvil, y otro campo para el Modelo. La lista válida de opciones del campo Model depende sólo del Manufacturer seleccionado. Un método ineficaz para garantizar que la lista de opciones del campo Modelo siempre es válida es seleccionar Recalcular lista de opciones para este campo. En su lugar, puede grabar un enganche de valor de campo cambiado para el campo Fabricante que invalide la lista de opciones del campo Modelo. Consulte el apartado ejemplo de InvalidateFieldChoiceList para obtener más información sobre la utilización de este método.
Los enganches en cascada se producen cuando se tienen varias relaciones dependientes o anidadas entre campos. Imagine el Fabricante del automóvil y la dependencia de Modelo que se ha comentado anteriormente en esta sección. Ampliando este ejemplo, imagine que después de seleccionar un Modelo, la lista de opciones válidas para Estilo de cuerpo o Color o Motor pueden cambiar. Es fácil ver cómo cambiando un valor de campo en un formulario, puede producirse que una cascada de enganches se ejecute y vuelva a ejecutar en los otros campos. La profundidad de estas relaciones de campo anidadas debe minimizarse, y es necesario tener cuidado en la implementación del esquema para evitar ejecuciones innecesarias o redundantes del código de enganche. Para obtener ejemplos, consulte el apartado del método GetFieldStringValues y otros métodos relacionados.
Obtener objetos AdminSession tiene un impacto en el rendimiento y pueden existir alternativas para recuperar los datos. Por ejemplo, en lugar de utilizar el objeto AdminSession y los objetos User y Group subyacentes para recuperar la información de usuario y de grupo, puede crear consultas para los registros de usuario y de grupo (tipos de registro sin estado) que se encuentran en una base de datos de usuario.