IBM Rational ClearQuest supporta l'utilizzo di VBScript e Perl per la scrittura del codice hook personalizzato. Tuttavia, ci sono trade-off funzionali e delle prestazioni che devono essere considerati quando si sceglie il linguaggio di script e i tipi di operazioni da utilizzare nelle funzioni hook. Sebbene questa non sia una discussione esauriente sull'argomento, le seguenti indicazioni dovrebbero essere applicate a qualsiasi modifica dello schema. Per ulteriori informazioni relative a Rational ClearQuest Schema Performance, consultare il sito Web IBM developerWorks.
Per ogni sistema Rational ClearQuest che supporta più piattaforme client, si otterrà un miglioramento delle prestazioni utilizzando il nuovo Rational ClearQuest Web.
Il nuovo Rational ClearQuest Web può essere distribuito su Windows, sul sistema UNIX o su sistemi Linux.
Qualsiasi client Rational ClearQuest Windows, incluso il server Web Rational ClearQuest, è in grado di eseguire hook scritti in VBScript o Perl. Tuttavia, i client Rational ClearQuest per il sistema UNIX o per Linux sono in grado di eseguire solo script Perl. Per questo motivo, se una distribuzione Rational ClearQuest richiede client per il sistema UNIX o per Linux, è necessario che gli hook siano scritti in Perl.
L'accesso al database è, solitamente, l'operazione che richiede più tempo eseguita da una funzione hook. Esempi di operazioni che richiedono l'accesso al database sono:
Richiamare un'entità (record) richiede almeno una query del database per il record principale, più una query per ogni campo REFERENCE_LIST. Le entità vengono richiamate esplicitamente tramite i metodi sessione come GetEntity o LoadEntity, ma possono essere richiamate anche implicitamente accedendo al valore di campo di un campo REFERENCE. Il seguente esempio carica implicitamente l'entità a cui si fa riferimento dal campo prodotto, e quindi richiama il valore del campo componente dal record prodotto caricato:
$component = $entity->GetFieldValue("product.component")->GetValue();
Il tempo necessario per caricare un'entità è determinato dalla complessità dello schema, prima di tutto dal numero di campi elenco di riferimento nell'entità selezionata. In molti casi, se è richiesta solo una sottoserie dei campi di entità, è più utile eseguire una query per questi valori di campo piuttosto che richiamare l'intera entità.
Sebbene siano più efficienti che richiamare i record di entità interi, le query richiedono ancora l'accesso al database e perciò influiscono sulle prestazioni dell'intero schema. Ogni lavoro dovrebbe essere fatto per ridurre il numero di movimenti del database. Ad esempio, piuttosto che eseguire la stessa query più volte in vari punti del codice hook, una query può essere eseguita una sola volta e i valori ResultSet possono essere memorizzati nella cache in una variabile sessione (per VBScript). Inoltre, richiamare solo i campi essenziali per ogni record. Evitare di specificare campi di testo multiriga nei gruppi di risultati della query poiché questo richiede un movimento aggiuntivo del database per ogni campo di testo multiriga da richiamare.
Quando si seleziona l'opzione Calcola nuovamente l'elenco selezioni nelle proprietà di un elenco selezioni, il codice hook richiesto per inserire i dati nell'elenco valido di selezioni viene eseguito ogni volta che un qualsiasi altro campo del record modifica il valore. Ciò potrebbe causare una grande quantità di traffico di query non necessario, verso e proveniente dal database. Un metodo più efficiente per assicurarsi che l'elenco selezioni sia valido è di determinare gli altri campi che possono influire sui valori in questo elenco selezioni e imporre il ricalcolo dell'elenco selezioni solo quando tali valori di campo cambiano.
Ad esempio, se si stanno raccogliendo dati in un record Automobile potrebbe esserci un campo per il Produttore dell'automobile e un altro campo per il Modello. L'elenco di selezioni valido per il campo Modello dipende solo dal Produttore selezionato. Il metodo inefficiente di assicurare che l'elenco selezioni per il campo Modello sia sempre valido è di selezionare l'opzione Calcola nuovamente l'elenco selezioni per questo campo. Invece, è possibile scrivere una funzione hook di valore campo modificato per il campo Produttore che invalidi l'elenco selezioni per il campo Modello. Consultare l'Esempio InvalidateFieldChoiceList per ulteriori informazioni sull'utilizzo di questo metodo.
Le funzioni hook a catena sono causate dalla presenza di diverse relazioni nidificate o dipendenti tra i campi. Considerare la dipendenza tra il Produttore e il Modello dell'automobile trattata precedentemente in questa sezione. Per estensione, supporre che dopo aver selezionato un Modello, l'elenco delle selezioni valide per Stile, Colore o Motore potrebbe cambiare. È facile vedere come la modifica di un valore campo su un modulo può causare l'esecuzione e la riesecuzione di una catena di funzioni hook per gli altri campi. L'intensità di queste relazioni campo nidificate deve essere ridotta ed è necessario fare attenzione nell'implementare lo schema per evitare l'esecuzione non necessaria o eccessiva del codice hook. Ad esempio, consultare il metodo GetFieldStringValues e altri metodi correlati.
Il conseguimento di oggetti AdminSession ha un'influenza sulle prestazioni e ci sono delle alternative per richiamare i dati. Ad esempio, piuttosto che utilizzare l'oggetto AdminSession e evidenziare i metodi dell'oggetto gruppo e utente per richiamare informazioni sul gruppo o sull'utente, è possibile creare query per i record gruppo e utente (tipi di record stateless) che si trovano in un database utente.