本文探讨了在Mirth Connect中区分通道是因部署启动而进行首次轮询，还是按计划自动轮询的问题，以便实现基于轮询类型的目的地条件执行。通过在通道部署脚本中设置一个全局通道变量作为标志，并在源过滤器/转换器中检查并更新该标志，可以有效识别通道的首次部署轮询与后续计划轮询，从而实现精细化的流程控制。
Mirth Connect通道轮询类型识别与条件执行
在Mirth Connect中，有时需要根据通道的轮询方式（例如，是因部署而进行的“启动时轮询”，还是按预定计划进行的自动轮询）来决定是否执行特定的目的地。例如，一个通道可能需要在部署后手动触发一次备份，但在夜间自动轮询时则不执行恢复操作。然而，Mirth Connect并没有直接提供一个内置变量来明确指示当前的轮询是手动触发还是自动触发。本文将介绍一种利用全局通道变量（Global Channel Map Variable）来间接实现这一区分的方法。
问题背景
Mirth Connect通道通常有两种主要的轮询触发机制：
- 启动时轮询（Poll Once on Start）：当通道部署或重新启动时，会立即执行一次轮询。这通常与手动部署操作相关联。
- 计划轮询（Scheduled Poll）：根据源连接器中定义的调度（例如，Cron表达式），在特定时间间隔自动执行轮询。
核心挑战在于如何在通道的源过滤器或转换器中识别当前正在执行的轮询属于哪种类型，以便根据此信息有条件地启用或禁用某些目的地。
解决方案：利用全局通道变量作为部署标志
Mirth Connect提供了一个globalChannelMap对象，允许在通道的各个脚本之间共享数据。我们可以利用这一点，在通道部署时设置一个标志，并在每次轮询时检查并更新这个标志。
步骤 1：在通道部署脚本中初始化部署标志
当通道被部署时，Mirth Connect会执行其“部署脚本”（Deploy Script）。我们可以在这里设置一个全局通道变量，例如NEW_DEPLOY，来指示通道刚刚被部署。
导航到部署脚本： 在Mirth Connect Administrator中，选择你的通道，然后点击“Scripts”选项卡，找到“Deploy Script”。
-
添加初始化代码： 在部署脚本中添加以下JavaScript代码：
// 设置一个标志，指示通道刚刚被部署 globalChannelMap.put('NEW_DEPLOY', true); return;这段代码将NEW_DEPLOY变量设置为true，表示通道刚刚完成部署。
deep-java-review下载Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
步骤 2：在源过滤器/转换器中检查并更新标志
在通道的源连接器（Source Connector）的过滤器或转换器中，我们可以访问这个全局通道变量。在每次轮询时，检查NEW_DEPLOY的值，并根据其状态执行不同的逻辑。
导航到源过滤器/转换器： 在Mirth Connect Administrator中，选择你的通道，然后点击“Source”选项卡，选择一个“Filter”或“Transformer”步骤。
-
添加检查和更新代码： 在该脚本中添加以下JavaScript代码：
if ($gc('NEW_DEPLOY') == true) { // 如果 NEW_DEPLOY 为 true，则表示这是部署后的首次轮询（"Poll Once on Start"） logger.info("NEW_DEPLOY WAS " + $gc('NEW_DEPLOY') + ", 这是部署后的首次轮询"); // 执行与首次部署轮询相关的逻辑，例如，启用特定目的地 // 重置 NEW_DEPLOY 标志为 false，以便后续轮询被识别为计划轮询 globalChannelMap.put('NEW_DEPLOY', false); } else { // 如果 NEW_DEPLOY 为 false，则表示这是后续的计划轮询 logger.info("NEW_DEPLOY WAS " + $gc('NEW_DEPLOY') + ", 这是计划轮询"); // 执行与计划轮询相关的逻辑，例如，禁用特定目的地 }- $gc('NEW_DEPLOY')是Mirth Connect中用于获取全局通道变量值的快捷方式。
- 首次执行时，NEW_DEPLOY为true，进入if块，执行首次轮询逻辑，并将其重置为false。
- 后续的计划轮询，NEW_DEPLOY将为false，进入else块，执行计划轮询逻辑。
步骤 3：根据轮询类型控制目的地执行
一旦在源过滤器/转换器中识别了轮询类型，就可以将这个信息传递下去，或者直接在此处根据条件控制后续目的地的行为。
例如，如果你想在首次部署轮询时只执行备份目的地，而在计划轮询时不执行恢复目的地，可以在源转换器中根据NEW_DEPLOY的状态来修改消息的元数据或直接操作destinationSet。
// 假设你有一个名为 'RestoreDestination' 的目的地
if ($gc('NEW_DEPLOY') == true) {
// 部署后的首次轮询，可能只执行备份，不执行恢复
// 可以在这里设置一个标志，供后续目的地过滤器使用
channelMap.put('isFirstDeployPoll', true);
} else {
// 计划轮询，可能执行备份，但不执行恢复
channelMap.put('isFirstDeployPoll', false);
// 示例：如果希望在计划轮询时移除特定目的地
// var destinationName = 'RestoreDestination';
// if (destinationSet.containsKey(destinationName)) {
// destinationSet.remove(destinationName);
// }
}然后，在“RestoreDestination”的目的地过滤器中，你可以检查channelMap.get('isFirstDeployPoll')的值来决定是否处理消息。
注意事项与局限性
- “手动轮询”的定义： 这种方法主要区分了“部署后的首次轮询”（通常与手动部署操作相关）与“所有后续的计划轮询”。它不能直接区分用户从Mirth Connect仪表板上点击“Poll”按钮手动触发的轮询（如果通道已经运行）。从Mirth Connect的角度看，这种手动触发的轮询在NEW_DEPLOY标志为false时，会被视为一次性的计划轮询。
- 服务器重启： 如果Mirth Connect服务器重启，所有通道都会重新部署，NEW_DEPLOY标志将再次被设置为true，导致通道的首次轮询被识别为“部署后的首次轮询”。
- 全局变量的范围： globalChannelMap变量仅在该特定通道内部可见和共享。
- 代码位置： 确保将代码放置在正确的脚本位置。部署脚本在通道启动时执行一次，而源过滤器/转换器脚本在每次消息通过源连接器时执行。
总结
通过巧妙地利用Mirth Connect的全局通道变量和通道部署脚本，我们可以有效地识别通道是刚刚部署后进行的首次轮询，还是按预定计划进行的自动轮询。这为实现基于轮询类型的条件逻辑提供了基础，使得Mirth Connect通道的自动化流程更加灵活和可控。然而，对于需要区分“正在运行通道的手动触发轮询”与“计划轮询”的更复杂场景，可能需要考虑其他策略，例如使用独立的通道进行手动触发，或通过外部系统发送带有特定标志的消息来触发。
