Mirth Connect中区分自动与手动轮询以实现条件逻辑

新闻中心 NEWS CENTER

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

Mirth Connect中区分自动与手动轮询以实现条件逻辑

2025-12-03

浏览次数：次

返回列表

Mirth Connect中区分自动与手动轮询以实现条件逻辑

本文详细介绍了在mirth connect中如何区分通道的自动（计划）轮询与部署时的首次轮询（可视为手动触发），从而实现基于轮询类型的条件逻辑。通过在部署脚本中设置一个全局通道变量作为标志，并在源过滤器/转换器中检查并重置该标志，可以有效识别不同轮询事件，进而控制目的地（destination）的执行，解决诸如备份与恢复任务的场景需求。

Mirth Connect通道轮询类型识别与条件执行指南

在Mirth Connect通道开发中，有时需要根据通道的轮询方式（自动计划轮询或手动/部署时轮询）来执行不同的业务逻辑，例如有条件地启用或禁用某些目的地（Destination）。直接访问Mirth Connect的内部轮询设置通常较为复杂且不推荐。本文将介绍一种通过全局通道变量（Global Channel Map Variable）来有效区分轮询类型并实现条件逻辑的实用方法。

场景背景与挑战

假设一个Mirth Connect通道需要实现文件备份和恢复功能。通道应在每晚自动轮询以备份文件，但在手动触发时（例如，通道部署后首次轮询或手动点击“立即轮询”），则可能需要执行文件恢复操作。核心挑战在于，如何在源过滤器或转换器中识别当前轮询是自动计划的还是手动触发的，从而决定是否执行恢复目的地。

直接尝试通过Packages.com.mirth.connect.donkey.model.channel.CronProperty().getExpression()等方法获取轮询设置通常会遇到方法不存在的错误，因为这些内部API可能不直接暴露或需要特定的实例化过程。

解决方案：利用全局通道变量作标志

Mirth Connect提供了一个名为globalChannelMap的机制，允许在通道内部的各个脚本（部署脚本、源过滤器、源转换器、目的地转换器等）之间共享数据。我们可以利用它设置一个标志位，来区分通道部署后的首次轮询与后续的计划轮询。

1. 在通道部署脚本中设置标志

通道的部署脚本（Deploy Script）在通道每次部署时执行。我们可以在这里设置一个标志，指示通道刚刚被部署。

脚本位置： Mirth Connect Dashboard -> Channels -> 选择你的通道 -> Scripts -> Deploy Script

示例代码：

Remover

几秒钟去除图中不需要的元素

304 查看详情 Remover

// 在通道部署时，设置一个全局通道变量'NEW_DEPLOY'为true
globalChannelMap.put('NEW_DEPLOY', true);
logger.info("通道已部署，设置 NEW_DEPLOY 标志为 true。");
return;

解释： 当通道被部署或重新部署时，NEW_DEPLOY变量会被设置为true。这标志着通道进入了一个新的运行周期，通常伴随着“Poll Once on Start”选项的触发，可以被视为一种“手动”或“初始化”轮询。

2. 在源过滤器/转换器中检查并重置标志

在通道的源过滤器或源转换器中，我们可以检查NEW_DEPLOY标志的状态。

脚本位置： Mirth Connect Dashboard -> Channels -> 选择你的通道 -> Source -> Filter 或 Transformer

示例代码：

// 获取全局通道变量'NEW_DEPLOY'的值
var isNewDeploy = $gc('NEW_DEPLOY');

if (isNewDeploy == true) {
    logger.info("检测到 NEW_DEPLOY 标志为 true，当前为部署后的首次轮询。");
    // 重置标志，确保后续的计划轮询不会被误判为首次部署轮询
    globalChannelMap.put('NEW_DEPLOY', false);

    // 执行部署后首次轮询的特定逻辑，例如：
    // 移除备份目的地，只执行恢复目的地
    // destinationSet.removeAllExcept(['RecoveryDestination']); 

} else {
    logger.info("检测到 NEW_DEPLOY 标志为 false，当前为计划轮询。");
    // 执行计划轮询的特定逻辑，例如：
    // 移除恢复目的地，只执行备份目的地
    // destinationSet.removeAllExcept(['BackupDestination']);
}

// 继续处理消息
return true;

解释：

首次轮询： 如果isNewDeploy为true，则表明这是通道部署后的首次轮询。此时，可以执行与“手动”或“初始化”轮询相关的逻辑，例如激活文件恢复目的地，并禁用文件备份目的地。
重置标志： 在执行完首次轮询的逻辑后，务必将NEW_DEPLOY标志重置为false。这是关键一步，它确保了后续的计划轮询不会再次进入“首次部署轮询”的逻辑分支。
计划轮询： 如果isNewDeploy为false，则表明当前是常规的计划轮询。此时，可以执行与“自动”轮询相关的逻辑，例如激活文件备份目的地，并禁用文件恢复目的地。

实际应用与注意事项

条件目的地执行： 在上述示例代码中，注释掉的部分展示了如何利用destinationSet对象来动态控制目的地的执行。destinationSet.removeAllExcept(['DestinationName'])方法可以移除除指定目的地之外的所有目的地。这使得根据轮询类型选择性地执行备份或恢复操作变得非常灵活。
$gc() 函数：$gc() 是Mirth Connect提供的一个快捷函数，用于从globalChannelMap中获取值。例如，$gc('NEW_DEPLOY')等同于globalChannelMap.get('NEW_DEPLOY')。
日志记录： 在示例中加入了logger.info()语句，这有助于在Mirth Connect的服务器日志中跟踪轮询类型，方便调试和监控。
“Poll Now”的局限性： 此方法主要区分“Poll Once on Start”（部署后的首次轮询）和后续的计划轮询。如果通道已经在运行，并且用户手动点击了Mirth Connect界面上的“Poll Now”按钮，此方法将无法将其与常规的计划轮询区分开来，因为NEW_DEPLOY标志只在部署时设置。对于需要区分“Poll Now”和计划轮询的场景，可能需要更复杂的外部触发机制或Mirth Connect未来版本提供的更直接的API。然而，对于大多数“手动触发”指的是部署后初始化操作的场景，此方法已足够有效。
变量命名： 选择清晰、有意义的变量名（如NEW_DEPLOY）可以提高代码的可读性和维护性。

总结

通过在Mirth Connect的部署脚本中巧妙地设置一个全局通道变量，并在源过滤器/转换器中检查并重置该变量，我们可以有效地识别通道是处于部署后的首次轮询状态还是常规的计划轮询状态。这种方法为实现基于轮询类型的复杂条件逻辑提供了强大的支持，尤其适用于需要区分初始化操作与常规自动化任务的场景，如文件备份与恢复。虽然对于所有类型的“手动”轮询（例如，通道运行时手动点击“Poll Now”）可能存在局限性，但它解决了大部分实际应用中区分部署时轮询与计划轮询的需求。

以上就是Mirth Connect中区分自动与手动轮询以实现条件逻辑的详细内容，更多请关注其它相关文章！

# 枣庄seo优化排名价格 # 隆回营销推广招聘信息 # 关键词seo排名匪云速捷上选 # 房地产营销高调性推广语 # 滨州网站建设远洋科技 # 百度营销推广实况在哪里 # seo常用推广方法 # 手机端seo关键词排名 # 泰安品质网站建设费用 # 寻seo推广专员 # 文件备份 # 多条 # 错误信息 # 自定义 # 并在 # 移除 # 这是 # 我们可以 # 器中 # 首次