在Mirth中处理异步ACK

Question

我在Mirth中开发了一个发送ORU消息的频道。然后，ACK将异步发送回特定端口上的其他通道。

为了能够在ACK中收到AR或AE的情况下重新发送ORU消息，我需要将该ORU存储在某个地方，以便在接收到ACK后再访问它（记住它是异步的）。

我正在弄清楚如何实现这一目标。我的想法是这样的：

• 发送ORU消息并将其存储在数据库中
• 在另一个频道中等待接收ACK
• 对于在数据库中查找相关ORU的incomming ACK，并根据ACK是否为正，删除ORU或重新发送

如果你们中的某个人有这方面的经验会很好，并且可以告诉我这是否是一种正确的方法，如果没有，如何。 案例的想法很好，我该如何实施第三步？我已尝试使用单一频道但我无法重新发送ORU。

Answer 1

我认为你的方法是合理的。我们倾向于回避硬删除，而是在ACK（或NACK）消息到达时将消息标记为“已确认”。这使您能够查询ACK / NACK / NULL并为您提供响应历史记录。

我们通过sampleId / timestamp跟踪我们的ORU，并记下messageID。 messageID返回ACK / NACK，因此很容易匹配。

您可能不想重新发送（自动）NACK消息，因为首先导致NACK的事情（如格式问题）不太可能通过简单的重新发送来解决。相反，您可能希望NACK触发警报（如电子邮件）给可以进行修复并手动重新发送的某个组。

您必须决定是否可以安全地重新发送丢失的“ACK”以及您应该等待多长时间。这些是商业决策而不是技术决策。例如，你没有收到ACK / NACK，但那是因为网络打嗝，Mirth的问题，还是你的原始信息实际上没有通过？如果接收系统正在依赖1和只有1条消息，那么在重新发送那些没有收到ACK的消息之前，你需要一些方法来协调。