IBM Rational ClearQuest prend en charge l'utilisation des langages VBScript et Perl pour l'écriture du code de point d'ancrage personnalisé. Toutefois, il est nécessaire d'envisager des compromis en matière de performances et de fonctionnalité lors du choix du langage de script et des types d'opération à utiliser dans les points d'ancrage. Bien qu'il ne s'agisse pas d'un traitement exhaustif du sujet, les instructions suivantes doivent être appliquées à toute modification de schéma. Pour plus d'informations sur les performances de schéma Rational ClearQuest, voir le site Web IBM developerWorks.
Pour tous les systèmes Rational ClearQuest prenant en charge une combinaison de plateformes client, l'utilisation de New Rational ClearQuest Web présente des avantages en termes de performances.
Une nouvelle version de Rational ClearQuest Web peut être déployée sur les systèmes Windows, UNIX ou Linux.
Tout client Rational ClearQuest Windows, y compris le serveur Rational ClearQuest Web, peut exécuter des points d'ancrage écrits en langage VBScript ou Perl. Toutefois, les clients Rational ClearQuest pour UNIX ou Linux peuvent uniquement exécuter des scripts Perl. Par conséquent, si un déploiement de Rational ClearQuest requiert des clients pour UNIX ou Linux, les points d'ancrage doivent être écrits en Perl.
L'accès à la base de données est généralement l'opération la plus longue effectuée par un point d'ancrage. Voici des exemples d'opérations nécessitant l'accès à la base de données :
L'extraction d'une entité (enregistrement) requiert au moins une interrogation de la base de données pour l'enregistrement principal, puis une autre interrogation pour chaque zone REFERENCE_LIST. Les entités sont extraites explicitement à l'aide de méthodes Session telles que GetEntity ou LoadEntity, mais peuvent aussi être extraites implicitement à partir de la valeur d'une zone REFERENCE. L'exemple suivant charge implicitement l'entité désignée par la zone product, puis extrait la valeur de la zone component à partir de l'enregistrement product chargé :
$component = $entity->GetFieldValue("product.component")->GetValue();
La durée de chargement d'une entité est déterminée par la complexité du schéma et notamment par le nombre de zones de liste de référence dans l'entité sélectionnée. Dans de nombreuses instances, si seul un sous-ensemble de zones d'une entité est requis, il est plus efficace de demander les valeurs de ces zones plutôt que d'extraire toute l'entité.
Même si cette méthode est plus efficace que d'extraire des enregistrements d'entité dans leur intégralité, les interrogations nécessitent un accès à la base de données et ont donc une incidence sur les performances globales des schémas. Le nombre d'allers-retours avec la base de données doit être réduit au maximum. Par exemple, plutôt que d'exécuter la même interrogation plusieurs fois, à différents emplacements du code de point d'ancrage, vous pouvez exécuter l'interrogation une fois et mettre en cache les valeurs de ResultSet dans une variable Session (pour VBScript). En outre, extrayez uniquement les zones nécessaires à chaque enregistrement. Evitez d'indiquer des zones textuelles multilignes dans les ensembles de résultats d'interrogation car l'extraction de chaque zone de texte multiligne requiert un aller-retour supplémentaire avec la base de données.
Lorsque vous choisissez l'option Recalculate Choice List dans les propriétés d'une liste d'options, le code de point d'ancrage requis pour réalimenter la liste d'options valide est exécuté chaque fois qu'une valeur est modifiée dans une autre zone de l'enregistrement. Ce mécanisme augmente considérablement le nombre d'allers-retours d'interrogation inutiles avec la base de données. Une méthode plus efficace pour vérifier que la liste d'options est valide consiste à déterminer les autres zones pouvant affecter les valeurs de la liste d'options et à forcer le calcul de cette liste uniquement lorsque les valeurs de zone sont modifiées.
Par exemple, si vous collectez des données dans l'enregistrement Automobile, vous pouvez disposer d'une zone pour le Constructeur de l'automobile et une autre zone pour le Modèle. La liste d'options valide pour la zone Modèle dépend uniquement du Constructeur sélectionné. La méthode consistant à vérifier que la liste d'options pour la zone Modèle est toujours valide en sélectionnant Recalculate Choice List est inefficace. En revanche, vous pouvez écrire un point d'ancrage de valeur de zone modifiée pour la zone Constructeur qui annule la liste d'options pour la zone Modèle. Voir l'Exemple InvalidateFieldChoiceList pour plus d'informations sur l'utilisation de cette méthode.
Les points d'ancrage en cascade sont le résultat de la présence de plusieurs relations dépendantes ou imbriquées entre des zones. Soit la dépendance Constructeur et Modèle automobiles traitée plus haut dans la présente section. Si l'on développe cet exemple, supposons qu'une fois le Modèle sélectionné, la liste des options valides pour Type de carrosserie ou Couleur ou Moteur puisse être modifiée. L'on constate alors aisément que la modification d'une valeur de zone dans un formulaire peut entraîner l'exécution et la réexécution en cascade de points d'ancrage pour les autres zones. La profondeur de ces relations de zones imbriquées doit être réduite et vous devez veiller à éviter l'exécution inutile ou redondante du code de point d'ancrage, lors de l'implémentation du schéma. Pour consulter des exemples, voir la méthode GetFieldStringValues et d'autres méthodes associées.
L'obtention d'objets AdminSession affecte les performances et vous pouvez mettre en oeuvre d'autres solutions pour extraire des données. Par exemple, plutôt que d'utiliser l'objet AdminSession et les méthodes sous-jacentes de l'objet User et de l'objet Group pour extraire des informations sur un utilisateur ou un groupe, vous pouvez créer des interrogations pour les enregistrements User et Group (types d'enregistrement sans état) se trouvant dans une base de données utilisateur.