新的甚至是有一定经验的 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 域此刻看起来毫无用处），并且执行若干数据导入的试验来确保您拥有所有获得一个可以接受的结果的格式变更的文档。
文章来源于领测软件测试网 https://www.ltesting.net/
