本主题解释如何在“从通讯报文生成参数化消息”向导中虚拟化组消息。消息是组的方式决定了生成什么响应程序（每个消息组生成一个响应程序）。 

本章包含：

了解分组

按操作/类型虚拟化组消息的方式受到 a) Virtualize 对给定通讯报文的分析 b) 选择应用的分组标准的影响。自动选择推荐的分组策略；这些建议可以根据需要进行调整和覆盖。 

Virtualize 采用分两个阶段分析通讯报文的方法：首先，它建议应该启用哪些分组策略，然后使用所选的策略将消息划分为组。当创建 PVA 时，为每个组生成一个响应器。

根据以下启发选择推荐的分组策略：

• 在以下情况下，选择Grouping based on Request Body ：
  • SOAP 通讯报文
  • 非 XML 消息格式，包括自定义消息格式
  • 非 HTTP 通讯报文
• 在其他情况下，会选择Grouping based on HTTP Method and URL Paths ，除非 HTTP 方法仅在所提供通讯报文中的方法发生变化时才会选择。

分组时，Virtualize 会：

• 偏爱特定的，而不是一般的。Virtualize 生成尽可能特定的表达式，仅匹配该组中的所有消息（不匹配其他组中的消息）。这确保生成的响应程序正确地关联到相同的通讯报文。
• 遵循分组顺序（HTTP 方法、URL 路径、URL参数，然后是请求主体内容）。例如，如果 URL 路径足以区分组，Virtualize 就不会为这些分组标准的每个步骤创建请求体关联，等等。

按 HTTP 方法进行分组

根据 HTTP 方法（POST、GET、PUT 等）拆分生成的消息响应器。启用此策略后，每个唯一的 HTTP 方法都会生成一个消息响应器。 

例如，如果通讯报文包含 10 条 POST 消息和 15 条 GET 消息（无论顺序如何），Virtualize 将在生成的 PVA 中创建 2 个响应器：一个用于 POST 消息，一个用于 GET 消息（假设在组中进一步的分裂中没有触发其他分组策略）。 

结果组可以自定义，这样一个组可以捕获多个 HTTP 方法的消息。例如，如果在一个组中同时启用了 POST 和 PUT，那么使用 POST 方法的消息和使用 PUT 方法的消息将匹配该组并分配给该组。换句话说，基于该组生成的响应器将与 POST 和 PUT 消息相关（它将接受其中任何一条消息）。

按 URL 路径进行分组

根据 URL 路径的唯一性拆分生成的消息响应程序。每个唯一的 HTTP URL 路径都会生成一个消息响应器。按 HTTP URL 路径分组的配置本质上定义了这种唯一性。 

当基于此策略首次生成组时，将分析路径，以生成一组最能描述消息类型的路径表达式。这种描述使用了一种内在主观的路径分析算法。它的目的是考虑 REST 服务中最常见的模式，但是可能需要调整生成的路径标准以获得最佳结果。

例如，如果通讯报文包含以下 HTTP URL 路径（为了简洁起见，省略了 HTTP 方法、URL 参数和其他因素）

/service/order/v1/1/summary 
/service/order/v1/2/summary 
/service/order/v1/2/summary
/service/customer/v1/a/contact 
/service/customer/v1/b/contact 
/Foo
/Foo

Virtualize 将在生成的 PVA 中创建三个响应器：

• 响应器 1：用于 summary 路径（3 条消息）
• 响应器 2：用于 contact 路径（2 条消息）
• 响应器 3：用于 Foo 路径（2 条消息）

注意，这些响应器将使用 Ant 样式的通配符生成，其中 * 匹配零个或多个字符，** 匹配零个或多个目录。关于更多详情和示例，请查阅 URL Paths Grouping Configuration 。

配置基于路径的数据源关联

Virtualize 配置 URL 路径段索引时，创建一个新的 PVA，使每个组（响应器）可以响应相同的请求与不同的 URL 路径值。它通过提供段索引来配置 URL 路径参数。例如，给定以下 URL

/rest/api/2/version/1234/relatedIssueCounts 
/rest/api/2/version/4568/relatedIssueCounts 
/rest/api/2/version/4567/relatedIssueCounts

Virtualize 将指定要用数据源参数化的第五个路径段（带有 4 位数字的段）。然后，可以对每个 ID 的响应数据进行数据驱动，而不需要编辑 PVA。

根据 URL 参数的存在进行分组

根据 HTTP URL 参数的存在拆分生成的消息响应程序。每组一个或多个 URL 参数都会生成一个消息响应器。 

例如，如果通讯报文包含以下 URL 参数

?oid=1&category=women
?oid=2&category=women
?oid=1&category=babies
?ssn=1234567890&state=CA&category=silver 
?ssn=1234567891&state=CA&category=gold

Virtualize 将根据 oid、ssn 和 state 参数的存在在生成的 PVA 中分割响应程序，如下所示（每个响应程序具有以下响应程序相关标准）

• 响应器 1：存在 URL 参数 oid（3 条消息）
• 响应器 2：存在 URL 参数 ssn 和 state（2 条消息）

注意，这种启发式不会基于 URL 参数值生成组。如果希望基于 URL 参数值进行分组，可以手动配置。基于 URL 参数存在的分组 仅在参数列表完全匹配时使用关联进行配置，而在参数名称出现时使用关联，而不考虑值 选项。关于更多详情，请查阅 URL Parameters Grouping Configuration 。

按 URL 参数值分组

根据特定 HTTP URL 参数的列表值拆分生成的消息响应程序。每个包含一个或多个 URL 参数值的列表都会生成一个消息响应器。 

例如，如果通讯报文包含以下 URL 参数

?oid=1&category=women
?oid=2&category=women
?oid=1&category=babies
?ssn=1234567890&state=CA&category=silver 
?ssn=1234567891&state=CA&category=gold

Virtualize会根据以下响应程序关联标准拆分生成的 PVA 中的响应器：

• 响应器 1：category=women （2 条消息）
• 响应器 2：category=babies （1 条消息）
• 响应器 3：state=CA, category=silver （1 条消息）
• 响应器 4：state=CA, category=gold （1 条消息）

按请求主体内容进行分组

根据请求内容计算的 Xpath 表达式列表拆分生成的响应程序。每个 Xpath 表达式表示一个组和 XML 消息关联标准。

启用此策略时，SOAP 消息（默认情况下）根据主体下的第一个元素名称分组。对于非 SOAP XML 内容，消息根据根元素名称进行分组。 

注意，当使用自定义报文格式（或内置的非 XML 格式）时，XPath 表达式基于请求的转换 XML 格式。

按标准组合进行分组

从上面描述的用例中为匹配多个分组标准的每组消息生成一个响应器。 

例如，给定通讯报文文件中的以下消息

GET /service/order/v1/1/summary?oid=1&category=women
GET /service/order/v1/2/summary?oid=1&category=women
GET /service/order/v1/2/summary?oid=1&category=babies
POST /service/customer/v1/a/contact?ssn=1234567890&state=CA&category=silver 
POST /service/customer/v1/b/contact?ssn=1234567891&state=CA&category=gold 
POST /Foo
POST /Foo

Virtualize 将根据每个响应器/组的以下标准，将它们分组为响应器：