IBM® Rational® ClearQuest®는 사용자 정의 후크 코드 작성을 위해 VBScript 또는 Perl 사용을 지원합니다. 그러나 스크립팅 언어 및 후크에서 사용할 오퍼레이션 유형을 선택할 때 고려해야 하는 성능 및 기능적 상충관계가 있습니다. 여기서 이 주제에 대한 모든 논의를 하는 것은 아니지만 스키마 수정에 다음 가이드라인을 적용해야 합니다. Rational ClearQuest 스키마 성능 주제에 관한 자세한 정보는 IBM developerWorks® 웹 사이트를 참조하십시오.
혼합 클라이언트 플랫폼을 지원하는 Rational ClearQuest 시스템의 경우, New Rational ClearQuest 웹을 사용하면 성능상 이점이 있습니다.
새 Rational ClearQuest 웹은 Windows®, UNIX® 시스템 또는 Linux® 시스템에 배치할 수 있습니다.
Rational ClearQuest 웹 서버를 포함한 모든 Rational ClearQuest Windows 클라이언트가 VBScript 또는 Perl로 작성된 후크를 실행할 수 있습니다. 그러나 UNIX 시스템 또는 Linux용 Rational ClearQuest 클라이언트는 Perl 스크립트만 실행할 수 있습니다. 따라서 Rational ClearQuest 배치에 UNIX 시스템 또는 Linux용 클라이언트가 필요한 경우 후크가 Perl로 작성되어야 합니다.
일반적으로 데이터베이스에 액세스하는 것은 후크가 수행하는 가장 시간이 걸리는 오퍼레이션입니다. 데이터베이스 액세스가 필요한 오퍼레이션의 예를 들면 다음과 같습니다.
엔티티(레코드)를 검색하려면 1차 레코드에 대한 최소 하나의 데이터베이스 조회와 각 REFERENCE_LIST 필드에 대한 하나의 조회가 필요합니다. GetEntity 또는 LoadEntity와 같은 Session 메소드를 통해 명시적으로 엔티티를 검색하지만 REFERENCE 필드의 필드 값에 액세스하여 암시적으로 검색할 수도 있습니다. 다음 예제는 product 필드가 참조하는 엔티티를 암시적으로 로드한 후 로드된 product 레코드에서 component 필드 값을 검색합니다.
$component = $entity->GetFieldValue("product.component")->GetValue();
엔티티 로드 시간은 스키마의 복잡도에 의해 결정되는데, 주로 선택된 엔티티의 참조 목록 필드 수에 의해 결정됩니다. 많은 경우, 엔티티 필드의 서브세트만 필요한 경우에는 전체 엔티티를 검색하는 대신 해당 필드 값을 조회하는 것이 보다 효율적입니다.
전체 엔티티 레코드를 조회하는 것보다 효율적이긴 하지만 조회에는 여전히 데이터베이스 액세스가 필요하므로 전반적인 스키마 성능에 영향을 줍니다. 데이터베이스 라운드 트립 수를 최소화하도록 모든 노력을 기울여야 합니다. 예를 들어, 후크 코드의 여러 위치에서 동일한 조회를 여러 번 실행하지 않고 조회를 한 번 실행할 수 있으며, ResultSet 값을 Session 변수로 캐시할 수 있습니다(VBScript의 경우). 또한 각 레코드에 필요한 필드만 검색하십시오. 각 다중 행 텍스트 필드를 검색하려면 추가 데이터베이스 라운드 트립이 필요하므로 조회 결과 세트에 다중 행 텍스트 필드를 지정하지 마십시오.
선택사항 목록 특성에서 선택사항 목록 다시 계산 옵션을 선택하면, 레코드의 기타 필드 값이 변경될 때마다 올바른 선택사항 목록을 다시 채우는 데 필요한 후크 코드가 실행됩니다. 이로 인해 데이터베이스로/데이터베이스로부터 불필요한 대량의 조회 트래픽이 발생할 가능성이 있습니다. 올바른 선택사항 목록이 되도록 하는 보다 효율적인 방법은 이 선택사항 목록의 값에 영향을 줄 수 있는 기타 필드를 판별하고, 해당 필드 값이 변경될 때에만 선택사항 목록을 다시 계산하도록 강제 실행하는 것입니다.
예를 들어, Automobile 레코드의 데이터를 수집 중인 경우, 자동차 Manufacturer에 대한 필드 및 Model에 대한 또 다른 필드가 있을 수 있습니다. Model 필드에 올바른 선택사항 목록은 선택한 Manufacturer에만 의존합니다. Model 필드의 선택사항 목록이 항상 올바르도록 하는 비효율적인 방법은 이 필드에 대해 선택사항 목록 다시 계산을 선택하는 것입니다. 대신, Manufacturer 필드에 대해 Model 필드에 대한 선택사항 목록을 무효화하는 필드 값 변경 후크를 작성할 수 있습니다. 이 방법 사용에 관한 자세한 정보는 InvalidateFieldChoiceList 예제를 참조하십시오.
계단식 후크는 필드 간에 여러 종속 또는 중첩 관계가 있기 때문에 발생합니다. 이 섹션에서 앞서 설명한 자동차 Manufacturer 및 Model 종속성을 고려하십시오. 해당 예제를 확장하여 Model을 선택한 후에 Body Style이나 Color 또는 Engine에 올바른 선택사항 목록이 변경될 수 있다고 가정하십시오. 양식에서 하나의 필드 값을 변경하면 어떻게 계단식 후크가 실행되고 기타 필드에 대해 재실행되는지 쉽게 확인할 수 있습니다. 이런 중첩 필드 관계의 깊이를 최소화해야 하며, 후크 코드가 불필요하게 또는 중복되어 실행되지 않도록 스키마 구현 시 유의해야 합니다. 예제는 GetFieldStringValues 메소드 및 기타 관련 메소드를 참조하십시오.
AdminSession 오브젝트를 가져오면 성능에 영향을 주며, 데이터 검색을 위한 대안이 있을 수 있습니다. 예를 들어, AdminSession 오브젝트와 기본 User 오브젝트 및 Group 오브젝트 메소드를 사용하여 사용자 또는 그룹 정보를 검색하지 않고 사용자 데이터베이스에 있는 User 및 Group 레코드(Stateless 레코드 유형)에 대한 조회를 작성할 수 있습니다.