本教程详细介绍了如何在 Mirth Connect 通道中有效区分自动计划轮询与手动触发或部署时发生的轮询事件。通过利用 `globalChannelMap` 和通道的部署脚本，开发者可以设置一个标志来识别通道启动或部署后的首次轮询，从而实现基于轮询类型的条件逻辑，例如选择性地执行不同的目标连接器。
引言：区分 Mirth Connect 轮询事件的必要性
在 Mirth Connect 中，通道的源连接器通常配置为按预设时间表自动轮询数据。然而，在某些场景下，我们需要区分这些自动轮询事件与因通道部署或手动启动而触发的“首次轮询”（即“Poll Once on Start”）。例如，一个通道可能需要在一个时间段内自动执行备份操作，而在另一个时间段或手动触发时执行恢复操作。直接访问 Mirth Connect 内部的轮询设置或事件类型通常并不直接，因此需要一种机制来识别当前轮询的性质。
挑战与常见误区
尝试直接通过 Mirth Connect API 访问源连接器的轮询配置（如 CronProperty 或 PollConnectorProperties）通常会遇到方法不存在的错误，这表明这些内部方法并非设计为在通道脚本中直接调用。此外，简单地根据当前时间与配置的轮询时间进行比较，虽然可行，但会引入冗余配置，因为一旦轮询时间改变，脚本也需要手动更新。
解决方案：利用 globalChannelMap 进行轮询类型识别
Mirth Connect 提供了一个 globalChannelMap，它是一个通道级别的共享存储，可以在通道的各个脚本（部署脚本、源过滤器/转换器、目标转换器等）之间传递数据。我们可以利用部署脚本在通道启动或部署时设置一个标志，然后在每次轮询时检查并重置该标志，从而判断轮询的类型。
步骤一：在通道部署时设置标志
在通道的“部署脚本”（Deploy Script）中，我们可以在 globalChannelMap 中设置一个布尔标志。这个脚本会在通道每次部署或启动时执行一次。
操作步骤：
- 打开你的 Mirth Connect 通道。
- 导航到“脚本”选项卡。
- 在“部署脚本”区域，添加以下代码：
// 在通道部署或启动时设置一个标志，表示这是新的部署或启动事件
globalChannelMap.put('NEW_DEPLOY', true);
return;这段代码的作用是，每当通道被部署或重新启动时，NEW_DEPLOY 这个键的值就会被设置为 true。
步骤二：在源过滤器/转换器中检查并重置标志
在源连接器的过滤器或转换器脚本中，我们可以检查 NEW_DEPLOY 标志的状态。如果它为 true，则表示当前是部署或启动后的首次轮询；否则，则是常规的计划轮询。检查后，需要立即将该标志重置为 false，以便后续的计划轮询能够被正确识别。
操作步骤：
- 打开你的 Mirth Connect 通道。
- 导航到“源”连接器，然后进入“过滤器”或“转换器”选项卡。
- 在合适的脚本区域（例如，源转换器脚本），添加以下代码：
if ($gc('NEW_DEPLOY') == true) {
logger.info("NEW_DEPLOY WAS " + $gc('NEW_DEPLOY') + ", 当前为部署/启动后的首次轮询");
// 重置标志，确保后续轮询被识别为计划轮询
globalChannelMap.put('NEW_DEPLOY', false);
// 在这里执行与首次轮询（例如，手动触发或部署后）相关的逻辑
// 示例：执行恢复目标
// return true; // 如果需要继续处理消息
} else {
logger.info("NEW_DEPLOY WAS " + $gc('NEW_DEPLOY') + ", 当前为计划轮询");
// 在这里执行与计划轮询相关的逻辑
// 示例：执行备份目标，或跳过恢复目标
// return true; // 如果需要继续处理消息
}在上述代码中：
- $gc('NEW_DEPLOY') 是获取 globalChannelMap 中 NEW_DEPLOY 键值的快捷方式。
- logger.info() 用于在 Mirth Connect 日志中输出信息，便于调试和监控。
- 关键在于 globalChannelMap.put('NEW_DEPLOY', false); 这一行，它在首次轮询逻辑执行后立即将标志重置，确保后续的自动轮询不会再被误判为“新部署”事件。
步骤三：根据轮询类型执行条件逻辑
一旦我们能够区分轮询类型，就可以在通道的后续处理流程中应用条件逻辑。例如，根据 NEW_DEPLOY 标志的状态来选择性地启用或禁用某些目标连接器。
示例：条件性地执行目标连接器
假设我们有一个“备份目标”和一个“恢复目标”。我们希望在部署/启动后的首次轮询时执行“恢复目标”，而在计划轮询时执行“备份目标”。
在源转换器中，我们可以这样修改消息的 destinationSet：
// 假设 'RestoreDestination' 和 'BackupDestination' 是你的目标连接器的名称或 ID
var currentDestinations = destinationSet; // 获取当前所有目标
if ($gc('NEW_DEPLOY') == true) {
logger.info("当前为部署/启动后的首次轮询，执行恢复操作。");
globalChannelMap.put('NEW_DEPLOY', false); // 重置标志
// 清空现有目标，只添加恢复目标
destinationSet.clear();
destinationSet.add('RestoreDestination'); // 假设这是恢复目标的名称或ID
} else {
logger.info("当前为计划轮询，执行备份操作。");
// 清空现有目标，只添加备份目标
destinationSet.clear();
destinationSet.add('BackupDestination'); // 假设这是备份目标的名称或ID
}
return message; // 返回消息以继续处理注意事项：
- destinationSet.add() 方法需要目标连接器的名称或 ID。你可以在目标连接器的“常规”选项卡中找到其名称。
- 这种方法允许你在不禁用或重新部署整个通道的情况下，根据轮询事件的性质动态调整执行路径。
总结与最佳实践
通过在 Mirth Connect 的部署脚本中设置 globalChannelMap 标志，并在源过滤器/转换器中检查和重置该标志，我们能够有效地识别通道部署/启动后的首次轮询与常规的计划轮询。这种方法提供了一种灵活且可维护的方式来实现基于轮询类型的条件逻辑，从而满足复杂的通道自动化需求。
最佳实践：
- 清晰命名： 为 globalChannelMap 中的变量选择清晰、描述性的名称。
- 日志记录： 使用 logger.info() 记录轮询类型，有助于调试和监控通道行为。
- 统一管理： 如果有多个通道需要类似逻辑，可以考虑将此模式封装为 Mirth Connect 的共享库函数。
- 考虑手动“Poll Now”： 此方案主要区分“Poll Once on Start”和计划轮询。如果用户在通道已运行且 NEW_DEPLOY 为 false 的情况下，手动点击 Mirth Connect 仪表板上的“Poll Now”按钮，此方案会将其视为计划轮询。如果需要区分这种真正的“手动立即轮询”与计划轮询，可能需要更复杂的机制，例如结合外部触发器或 Mirth Connect 自身未直接暴露的内部状态。然而，对于大多数“部署/启动时一次性操作”与“日常计划操作”的区分场景，本方案已足够。
