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