影响分析就是可能会受到其他项目变更影响的开发项目的识别。因为识别项目之间关系的自动化功能在开发过程中可以节省大量时间和麻烦，所以项目之间的链接可能并不明显。
例如，在 IBM® WebSphere® Message Broker（以后称作 Message Broker）环境中，如果您有一个使用名为 input 的消息的消息映射，则在消息映射和 input 之间存在一个关系。如果将名称 input 变更为 request，则消息映射所指的消息将不再被发现，因为在消息映射和消息 input 之间存在依赖关系，所以将在消息映射上导致验证错误。
如果您是一位准备更改开发项目的应用程序开发人员，影响分析可告诉您除了最初的变更以外还需要执行什么操作，以便在依赖的项目上消除并避免潜在的验证错误。Message Broker 变更那些支持影响分析的操作，包括：
- 在项目内重新命名项目或构造
- 在项目内将项目或构造移动到另外的位置
扩展前面的例子，如果您正在与使用了消息 input 的消息映射一起工作，您就需要重新命名该消息为 request，影响分析功能将报告重新命名 input 为 request 的要求，该要求可更新消息映射。
影响分析只报告什么项目可能会受到变更的影响 — 其不执行变更。此外，影响分析只报告那些直接依赖可能变更的构造的项目。例如，如果您拥有使用消息映射的消息流，因为这是一种间接的关系，所以重新命名的 input 将不把消息流作为潜在的影响列出。
因为关系信息在索引系统内被编目，所以影响分析可在工作空间内识别依赖关系。为了充实此目录，在工作空间的项目上将执行一个被称作索引的流程。
为了说明在 Message Broker 上使用影响分析的优点，我提供了一个 zip 文件的示例，您可以在本文的底部 下载 它。在此示例中，两种银行操作（存款和提款）已经被模式化。这些操作可通过发送一个 SOAP 消息给消息流来启动。该 SOAP 消息的格式通过 WSDL 定义，如图 1 所示：
在调用存款或提款操作时，Message Broker 将输入信息转换成可被银行后端系统接受的消息格式。在这个示例中，为了简单起见，一个子流程模拟连接到银行后端系统。
通过使用 ESQL 代码，来自银行后端系统的响应被返回且一个 SOAP 消息已构造，以便为该操作产生一个回复消息。图 2 显示了消息流的概况，BankOperationFlow.msgflow 实现了刚才所描述的场景：
图 1 中描述的 WSDL 被导入到消息集中，且 MXSD 定义包含了 transferIn 和 transferOut 消息的 ops.mxsd，其通过导入创建。在执行存款时 transferIn 是输入消息，而在请求提款时 transferOut 是被使用的消息。
模拟的后端系统采用消息 changeRequest 作为输入并返回 updateConfirmation。这些都在文件 BackendOperationMessages.mxsd 中被定义。
根据被调用的操作，消息 transferIn 或 transferOut 必须被映射到消息 changeRequest 中以便将变更持久化到存储系统中。此映射的示例如图 3 所示：
来自 transferOut 消息的映射是相似的。因为本文的重点不是映射，所以仅使用一个直观的映射示例进行说明。
一旦消息流通过调用模拟子流程更新了后端上的信息，则主流程会传递控制到 Compute（计算）节点，其在 ESQL 内调用模块以确定变更是否成功。
ESQL 的第二个功能是通过从 updateConfirmation 消息复制字段来构建 SOAP 回复消息。以下是 ESQL 代码：
虽然这个应用程序没有任何验证错误，但是建立它是为了反映正在开发的应用程序的状态；也就是说，项目的一些位置并没有遵循最佳实践，且一些构造没有清晰地命名。本文为您展示了如何使用影响分析来帮助您修改保持应用程序最终有效状态的项目和构造。
为了正常运行，影响分析需要建立并维持一个在开发工作空间上各项目之间关系的索引。如果没有这个索引，影响分析就无法运行，因为它无法在项目之间识别关系。同样，它无法识别新创建的依赖关系，也无法报告那些不再存在的对项目的修改的依赖关系。为了保持当前的索引，无论何时建立项目 Message Broker 都将索引一个项目，并启动已提供的此索引。
在新的工作空间，或从以前版本的 Message Broker 迁移而来的工作空间，在默认情况下禁用索引，且在建立项目时索引将不会发生。当从一个新的或迁移的工作空间处工作时，您必须在使用影响分析以前启动索引。在 Development Toolkit（开发工具包）的 Window（窗口）菜单下，转到 Preferences（首选项）对话框并选择 Broker Development => Impact Analysis：
图 5. 控制索引是否在 Message Broker 中发生的首选项页面
此 Impact Analysis 子菜单列出了影响分析可以为所选项目进行分析的变更。如果该项目不支持影响分析，则此子菜单将不显示。
调用影响分析的第二种方法是在编辑器内选择构造并调用与上下文相关的 Impact Analysis 菜单。正如第一种选择那样，它只出现在那些支持影响分析的构造上。在 Message Broker V7.0 中，来自编辑器内的影响分析支持仅在消息定义编辑器 (Message Definition Editor) 中可用。
调用影响分析的示例如下面的图 7 所示。引用构造（如元素引用和组引用）无法通过其他项目引用，因此在引用项目上 Impact Analysis 子菜单不出现。为了说明此概念，请查看如图 7 所示的消息 transferIn 上的元素引用 tns:id。这不是一个全局性的元素定义而是一个全局性元素 id（列于 Elements and Attributes（元素和属性）下）的元素引用。如果您在 transferIn 下的 tns:id 上单击右键，则上下文菜单中将不会有 Impact Analysis 子菜单。然而，如果您在 Elements and Attributes 下的 id 上单击右键，您将会在上下文菜单内看到 Impact Analysis 子菜单：
您可以在应用程序示例内对许多不同类型的对象调用影响分析。本文重点介绍两个重新命名的变更和一个移动的变更以便提供 Message Broker V7.0 功能的概述。在本文的后面，您可以作出一系列其他的变更以了解有关影响分析的更多信息。
本部分为您显示如何重新命名一个项目，即您可以这样做的原因，如当前的名称不是描述正在执行的功能。通过 transferIn 消息，该名称不描述实际操作（存款），因此您可能想要将它重新命名为一个更合乎逻辑且直观的名称。重新命名的另外一个原因可能是 Web 服务的外部调用方可能已经为输入的 SOAP 消息要求了不同的格式，即将会要求变更 transferIn 名称。
为了检查重新命名的 transferIn 可能会影响其他的项目和构造什么，您可以在 transferIn 消息上进行影响分析：
- 在消息定义编辑器内打开消息定义 ops.mxsd。
- 在 Overview 标签中的 Messages 部分下的 transferIn 定义上单击右键。
- 选择 Impact Analysis 子菜单上的 Rename。
一旦执行了这些操作，一个要求构造新名称的对话框就会打开，如下面的图 8 所示。在这种情况下，请输入名称 depositRequest 并选择 Analyze Impact：
图 8. 影响分析 — 要求构造新名称的 Rename Artifact 对话框
下列图 9 显示带有分析结果的模式对话框。在此窗口内有三个表，用带颜色的数字 1、2 和 3 表示，每一个描述如下：
- 表 1 列出了这些分析结果所属的操作。
- 表 2 列出了初始的变更（也称作主要变更），它们是为执行第一张表中指定的操作而必须执行的操作。初始变更表上的每一行都表示一个单一的操作，包括其上必须执行变更的文件的位置，以及必须做什么的描述。在此示例中，该操作就是重新命名
transferIn为depositRequest且因此必须执行的操作是将消息定义名称从transferIn变更为depositRequest。前两个表都没有提供有关将被此变更影响的项目的任何信息（在执行影响分析时这是我们最感兴趣的事情）。 - 表 3 列出了潜在的影响（也称为次要影响）。此表中的项目依赖正在经历变更的构造。像表 2 那样，除主要变更以外，表 3 中的每一行都描述了一个应该执行的单一操作以避免验证错误。同样地，每一行上的信息可准确地识别哪个文件必须更新且在此文件中需要更新什么。滚动表到右侧以显示每项操作的更多详细说明。例如，消息映射的变更所包含的详细信息：
Renaming message '{http://ImpactAnalysis/Bank}transferIn' will impact file
'/BankMF/impactanalysis/bank/BankOperationsFlow_Convert_Withdrawal.msgmap', in message
map 'BankOperationsFlow_Convert_Withdrawal', at location '$source, accountID, amount
|
在某些情况下，不是所有的次要影响都会被报告。图 9 中名为数字 4 的链接链接到信息中心中对一些限制的描述。
重要事项： WebSphere Message Broker 影响分析无法实际地执行任何变更。使用影响分析报告作为指南以确定什么需要变更。
如果您点击上面图 9 中 Impact Analysis 对话框底部的 Copy Analysis To Clipboard 按钮，则整个报告将会被复制到剪贴板，从那里您可以粘贴报告到外部应用程序以作为一个清单来执行变更。如果您将报告粘贴到支持表的应用程序中，如字处理或电子表格应用程序，则将以表格式输出，如图 10 所示：
如果您粘贴报告到通用文本编辑器，则表格式可能不存在。
影响分析报告非常适用于识别需要做出的变更。现在尝试变更消息定义名称（初始变更）和全局性元素（在这种情况下，当消息被重新命名时会自动重新命名全局性元素）。请注意在您做出了这两个变更以后，在消息集中会出现一个错误，如图 11 所示。
由于您刚刚做出了变更，因此在可部署的 WSDL 上会有一个错误，这是因为元素 transferIn 被重新命名为 depositRequest（还记得吗，影响分析是在消息而非元素上执行的）。
此示例说明影响分析的一个限制 — 它只报告那些直接依靠正在被变更的构造的项目。在这种情况下，WSDL 依靠元素 transferIn，反过来则要依靠重新命名的消息 depositRequest。为了防止出现这种情况，请在重新命名元素以前执行第二个影响分析以检测将要出现的次要影响，如图 12 所示：
在重新命名元素 transferIn 时，可部署的 WSDL BankOperations.wsdl 如所预期的那样被列为次要影响。虽然消息定义 transferIn 也被列为次要影响，但这是因为消息定义和元素的名称必须一致。
移动项目和构造是可以从影响分析中获益的另外一种变更。在移动中执行影响分析类似于在重新命名上执行影响分析。第一步是强调项目或构造将被移动，而后调用影响分析。移动操作的一个不同之处在于可选择多个项目或构造（但不能同时），如图 13 所示：
在此示例中，消息映射 BankOperationsFlow_Convert_Withdrawal.msgmap 和 ESQL 文件 BankOperationsFlow.esql 都属于一个名为 testing 的 Broker 架构。这些文件已经被测试过且需要把他们移动到 Broker 架构 impactanalysis.bank 中。但是在移动它们以前，您需要确定此移动是否会影响其他的项目。
图 14 显示了 Impact Analysis — Move Artifact 模式对话框。它显示了将要被分析的项目和构造并让您指定目标位置而后再点击 Analyze Impact。
图 14. Impact Analysis — Move Artifact 对话框
下一个窗口显示，基于项目如何移动的分析在前一个页面中指定。该接口类似于重新命名操作，但是因为不同的场景而使内容不同。因为选择了多个文件，所以表 1 拥有多个操作。表 2 列出了主要更改，它们是一些将要被移动的文件和构造。表 3 列出了次要影响：
在此示例中存在四个次要影响。两个影响在 ESQL 文件自身内，因为这里有一些对将要被移动的架构范围常量的引用。在移动一个 ESQL 文件时，也会移动在 ESQL 文件内的所有构造。
更重要的次要影响关心的是消息流 BankOperationFlow.msgflow。消息流使用消息映射和 ESQL 文件二者来转换消息格式，因此如果功能已经移动到一个新的位置，则消息流必须知道其在哪里。在移动文件以后，为了使应用程序正确地验证，消息流也必须被更新。
以上的示例显示了，在您对项目和构造进行结构性变更时如何在 Message Broker Toolkit 中使用影响分析来识别并解决工作空间内的潜在错误。本文中的示例仅显示少数可变更的项目。对于一系列完整的影响分析的支持构造，请参考下面的 附录。
为了进一步了解影响分析，使用附加示例对各种构造进行变更并观察效果。表 1 列出了示例应用程序内的影响分析示例和次要影响应该是什么：
| 项目 | 构造 | 次要影响 |
|---|---|---|
| BankOperations.wsdl | 需要更新 BankOperationsBinding.wsdl 中的 WSDL 导入 | |
| CommonTypes.mxsd | successType |
|
| BackendOperationMessages.mxsd | updateConfirmation |
|
| BackendOperationMessages.mxsd | transactionDetails | BackendOperationMessages.mxsd 内的复杂类型 |
| ops.mxsd | BankOperations.wsdl 中的架构指令 | |
| ops.mxsd | transferInType | 元素 transferIn 的类型 |
| ops.mxsd | success（全局性元素） |
|
| ops.mxsd | id |
|
| BankOperationsFlow.esql | DB_SYSTEM_ID | BankOperationsFlow.esql 中的模块 |
| BankOperationsFlow.esql | ns | BankOperationsFlow.esql 中的模块 |
| BankOperationsFlow.esql | BankOperationsFlow_ Convert_to_SOAP | 消息流 BankOperationsFlow.msgflow |
| BankOperationsFlow_ Convert_Deposit.msgflow | 消息流 BankOperationsFlow.msgflow | |
| BankOperationsFlow_ Convert_Withdrawal.msgflow | 消息流 BankOperationsFlow.msgflow | |
| Update.msgflow | 消息流 BankOperationsFlow.msgflow |
在 Message Broker 中的项目之间经常有依赖关系。在重新命名或移动一个项目时，依赖其初始名称或位置的其他项目将报告验证错误。修复这些错误是耗费时间的，因此使用 Message Broker V7.0 影响分析功能以便在变更项目以前了解针对依赖项目的变更范围，这可以为您节省大量的时间和工作。影响分析功能可以生成一份需要在次要项目上执行的附加操作的外部报告并充当那些需要进行的变更的记录。
表 2 列出了那些在 Message Broker V7.0 中支持影响分析的项目和构造（换句话说，这些项目和构造可能是主要变更），表 2 还显示每种项目类型可以在哪里调用影响分析：
表 2. 可以执行影响分析的项目和构造以及在何处调用影响分析
| 变更 | 入口点 | |||
|---|---|---|---|---|
| 项目/构造 | 重新命名 | 移动 | Broker Development View | 消息定义编辑器 |
| 消息定义文件 | 是 | 否 | 是 | 否 |
全局性 XSD 构造
| 是 | 否 | 是 | 是 |
本地 XSD 构造
| 是 | 否 | 否 | 是 |
| 可部署的 WSDL | 是 | 否 | 是 | 否 |
| 消息流 | 是 | 是 | 是 | 否 |
| 消息映射 | 是 | 是 | 是 | 否 |
| ESQL 文件 | 否 | 是 | 是 | 否 |
ESQL 构造
| 是 | 是 | 是 | 否 |
相反，表 3 列出了对表 2 中项目有依赖关系的项目和构造。表 3 中的这些项目可报告为次要影响：
| 项目/构造 |
|---|
| 消息定义文件 |
全局性 XSD 构造
|
本地 XSD 构造
|
| 可部署的 WSDL |
可部署的 WSDL 构造
|
| 消息流和子流程 |
消息流构造
|
| 消息映射和子映射 |
| ESQL 文件 |
ESQL 构造
|
| 描述 | 名字 | 大小 | 下载方法 |
|---|---|---|---|
| 本文介绍的项目交换文件 | impactanalysis.zip | 14 KB | HTTP |
扫一扫
525
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
