Mirth Connect：区分自动与手动通道轮询以实现条件性目的地执行

新闻中心 NEWS CENTER

您当前位置：首页 > 新闻中心 > 网络学院

Mirth Connect：区分自动与手动通道轮询以实现条件性目的地执行

2025-12-03

浏览次数：次

返回列表

Mirth Connect：区分自动与手动通道轮询以实现条件性目的地执行

本教程详细介绍了如何在mirth connect通道中区分自动（计划性）轮询和手动（部署时）轮询。通过在部署脚本中设置一个全局通道变量，并在源过滤器/转换器中检查该变量，可以有效地识别轮询类型。这使得开发者能够根据轮询来源，灵活地控制目的地（destination）的执行逻辑，从而实现更精细的通道行为管理。

理解通道轮询的场景与挑战

在Mirth Connect中，通道的源连接器（Source Connector）通常配置为周期性地轮询外部资源（如文件系统、数据库等）以获取消息。轮询可以分为两种主要类型：

自动（计划性）轮询：根据Cron表达式或预设间隔自动执行，通常用于夜间备份、定时同步等场景。
手动轮询：
- 部署时轮询：当通道部署或重新部署时，如果勾选了“Poll Once on Start”选项，会立即执行一次轮询。这常被视为一种初始的手动触发。
- 按需轮询：用户通过Mirth Connect仪表板手动点击“Poll Now”按钮触发的轮询。

开发人员有时需要根据轮询的类型来执行不同的业务逻辑。例如，一个通道可能需要在夜间自动备份文件，而在手动触发时执行文件恢复操作。直接从源过滤器或转换器中获取当前轮询是自动还是手动的状态，Mirth Connect并没有提供一个直接的API或内置变量。

利用全局通道变量区分轮询类型

为了解决上述挑战，我们可以利用Mirth Connect的全局通道变量（globalChannelMap）机制，结合通道的部署脚本和源处理脚本来实现轮询类型的区分。核心思路是：在通道部署时设置一个标志，然后在每次轮询时检查并根据该标志判断是否为“部署时轮询”。

步骤一：在部署脚本中初始化标志

当通道部署或重新部署时，Mirth Connect会执行通道的部署脚本（Deploy Script）。我们可以在这里设置一个全局通道变量作为“新部署”的标志。

打开你的Mirth Connect 通道配置。
导航到“Scripts”选项卡。
在“Deploy Script”区域中添加以下代码：
```
// 设置一个全局通道变量，标记通道刚刚部署
globalChannelMap.put('NEW_DEPLOY', true);
return;
```
这段代码的目的是在通道每次部署时，将NEW_DEPLOY这个键的值设置为true并存储在当前通道的全局映射中。这意味着通道在刚刚部署后，NEW_DEPLOY标志将为真。

步骤二：在源过滤器/转换器中检测轮询类型

在源连接器的过滤器或转换器脚本中（例如，在“Source Transformer”或“Source Filter”中），我们可以在每次消息处理前检查NEW_DEPLOY变量的值。

导航到“Source”选项卡。
Remover
几秒钟去除图中不需要的元素
304 查看详情
选择“Transformer”或“Filter”子选项卡。

在相应的脚本区域中添加以下代码：

if ($gc('NEW_DEPLOY') == true) {
    // 记录日志，表明这是一个部署时轮询
    logger.info("NEW_DEPLOY WAS " + $gc('NEW_DEPLOY') + ", 这次轮询发生在部署之后 (Poll On Deploy)");
    // 重置标志，以便后续的轮询被识别为计划性轮询
    globalChannelMap.put('NEW_DEPLOY', false);
    // 在这里可以添加针对“部署时轮询”的特定逻辑
    // 例如，设置一个变量来控制目的地执行
    channelMap.put('pollType', 'DEPLOY_POLL');
} else {
    // 记录日志，表明这是一个计划性轮询
    logger.info("NEW_DEPLOY WAS " + $gc('NEW_DEPLOY') + ", 这次轮询是计划性的");
    // 在这里可以添加针对“计划性轮询”的特定逻辑
    channelMap.put('pollType', 'SCHEDULED_POLL');
}

这段脚本首先检查NEW_DEPLOY变量。如果为true，则表明这是通道部署后的第一次轮询（通常对应“Poll Once on Start”）。脚本会记录日志，然后将NEW_DEPLOY重置为false，确保后续的轮询不会再次被误判为部署时轮询。同时，我们将轮询类型存储在channelMap中，方便后续的目的地使用。

步骤三：根据轮询类型控制目的地执行

在目的地的过滤器或转换器中，你可以通过检查channelMap.get('pollType')的值来决定是否执行该目的地。

例如，如果你有一个用于恢复文件的目的地，你可能只希望在DEPLOY_POLL时执行它：

在目的地过滤器中：

// 只有当轮询类型是部署时轮询时才通过过滤器
if (channelMap.get('pollType') == 'DEPLOY_POLL') {
    return true; // 允许消息通过，执行此目的地
}
return false; // 阻止消息通过，不执行此目的地

或者，你可以在源转换器中动态地移除不需要的目的地：

// 在源转换器中，根据 pollType 移除不需要的目的地
if (channelMap.get('pollType') == 'SCHEDULED_POLL') {
    // 假设 'RestoreDestination' 是恢复文件的目的地名称
    destinationSet.remove('RestoreDestination');
}

注意事项与局限性

“Poll Once on Start”的关联：此方法主要用于区分通道部署后的第一次轮询（通常与“Poll Once on Start”选项相关）和后续的计划性轮询。
手动“Poll Now”的识别：如果用户在通道部署后，通过Mirth Connect仪表板手动点击“Poll Now”按钮触发轮询，此方法将无法将其与计划性轮询区分开来，因为NEW_DEPLOY标志已经被重置为false。如果需要区分所有类型的手动触发，可能需要更复杂的机制（例如，结合外部API调用或更高级的Mirth Connect事件监听）。
通道重部署：每次通道重新部署时，NEW_DEPLOY标志都会被重置为true，因此部署后的第一次轮询将再次被识别为“部署时轮询”。
日志记录：在脚本中使用logger.info()可以有效地在Mirth Connect服务器日志中查看轮询类型，这对于调试和监控非常有帮助。
变量作用域：globalChannelMap变量在通道的生命周期内持续存在，而channelMap变量则针对每条消息的生命周期。根据你的需求选择合适的变量作用域。

总结

通过在Mirth Connect的部署脚本和源处理脚本中巧妙地利用全局通道变量，我们可以有效地识别通道部署后的首次轮询与后续的计划性轮询。这种方法提供了一种灵活的机制，使得开发者能够根据轮询的来源，精确地控制不同目的地的执行行为，从而更好地满足复杂的业务逻辑需求。虽然对于所有类型的“手动”轮询识别存在一定局限性，但对于区分部署时的初始化操作和常规的自动化流程，该方案非常实用且易于实现。

以上就是Mirth Connect：区分自动与手动通道轮询以实现条件性目的地执行的详细内容，更多请关注其它相关文章！

# 这段 # 关键词挖掘排名 # 驻马店网站推广营销公司 # 丽江古城营销推广方案 # 淘宝排名关键词有哪些 # 天河seo优化营销推广 # 台州标题seo优化 # 招商加盟论坛推广营销 # 美术展营销推广案例 # 河北进口网站建设调试 # 推广模式营销怎么写 # 这是一个 # 作用域 # 你可以 # 选项卡 # 有效地 # 我们可以 # 不需要 # 在这里 # 仪表板 # 器中 # red # api调用