新的甚至是有一定經驗的 ClearQuest 設計人員可能被 API Guide 中所略述的，利用一個操作的通知特性直接在 ClearQuest 的圖表內部執行電子郵件通知這一功能所困惑。
經常有人嘗試使用內部的基于 hook 的電子郵件規則，并且繞過電子郵件包和相應的電子郵件規則所提供的“即時可用”的通知功能。這是典型的“三思而后行”，因為執行基于 hook 的電子郵件規則反映了您的 ClearQuest 實施的復雜性中的重要跳躍。
有一種情況是，與我一起工作的客戶端想要一封電子郵件，其內容是定制的，而不是“即時可用”的包可以完成的。由于用戶要提交變更要求，所以他們想要發送給用戶一封措辭更好的電子郵件。比如 “親愛的 <提交者姓名>, 您的請求號 <ID 號碼> 已經被收到。您的請求將被好好處理。如果需要額外信息的話，會有一名團隊成員與您取得聯系。謝謝您使用 Acme ClearQuest Change Management 系統”。
在這個例子中，對于那些“即時可用”的通知所提供的被稱之為 “秘密的” 格式沒有其他選擇，基于 hook 的規則被使用。
然而，這個例子是該規則的一個例外。在大多數情況下，基于 hook 的電子郵件規則同基于電子郵件規則包的規則的目的是一樣的�；� hook 的規則的靈活性（以及更新規則所要求的煩人的圖表變更）應當同前面所提的“即時可用”的電子郵件規則包的易用性相比較。（請見圖3）
圖 3: 基于 hook 的電子郵件能夠通過功能強大的 ClearQuest API 被定制。
現在比較一下，哪一個能夠不費力的將域添加到一個無狀態的電子郵件規則記錄中。簡單的方法允許您將一個電子郵件規則記錄設置為活動的或者非活動的。每一種對于基于 hook 的規則的簡單變更都將需要描述圖表和更新用戶數據庫。如果您從另外一個設計者那里 “繼承了” 圖表，并且對您的前任所編寫的 hook 并不熟悉的話，您就會增加一個額外的復雜級別。
  |
|
這幾年來，我經常遇到這樣的情況：一些 IBM Rational FAQ 引發新手犯錯誤。經驗欠缺的 ClearQuest Administrators 將會在以下兩種情景下開始配置 ClearQuest：
- “我們對于每一個項目都將從用戶數據庫起步。如果管理層決定將這些數據庫同一個企業級用戶數據庫（基于報告或者數據管理方面的原因）結合起來將會有價值的話，那么我們就會將它們結合起來�！�
或者
- “我們對于所有項目都將從同一個用戶數據庫起步。如果該項目要求特定的定制，或者該數據庫變得太笨拙了，那么我們就創建一個為項目定做的用戶數據庫，并且從用戶數據庫中引入相應的數據�！�
這兩種理由充分的選項都是基于同一件事：在不同的 ClearQuest 用戶數據庫之間可以輕易的移動數據。如果了解到該過程有時會提出挑戰的話，您就會為您的機構設定一個更加合理的預期。
使用所提供的 ClearQuest Import 和 Export 功能，您就肯定可以從一個用戶數據庫導出數據（即使是基于一個查詢），并且將其導入到另一個用戶數據庫中（即使這些用戶數據庫是基于不同的圖表的）。只要在源和目的數據庫中都支持您所要求的源和目的域，該導入工具就將支持它。
然而，和許多情形中所出現的情況一樣，細節最令人頭疼。如果您擁有一個多行的域——例如 Description （請見圖4）——多行字符串中的每一個回車符都扮演了一個記錄分隔符的角色，這就意味著源數據庫中所呈現的域的格式最終和目的數據庫中的不一樣。
圖 4: 使用導入向導可以很容易的完成映射。允許數據被導入所要求的格式需要計劃和測試。
請記住，由于記錄 ID 是系統創建的域，所以無法在用戶數據庫之間移植 ID。為了緩解這一矛盾，您可以創建一個新的域，例如可將其稱作 old_id，并且從源用戶數據庫中將原來的 ID 導入到目的數據庫中，同時將所有相關的信息也一并導入。參考信息域同樣需要在不同數據庫之間加以區別。如果我的登錄 ID 在源數據庫中是 giliod 而在目的數據庫中是 dg1111，那么諸如擁有者和提交者之類的參考信息域就將變得沒有意義了。
在不同的用戶數據庫之間移植數據當然是可以做到的，但是做起來會很痛苦。最好事先與出資方就數據的限制和變更問題進行溝通（您的 Notes_Log 域此刻看起來毫無用處），并且執行若干數據導入的試驗來確保您擁有所有獲得一個可以接受的結果的格式變更的文檔。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
