在 Mirth 中处理异步 ACK

Question

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

为了能够在 ACK 中收到 AR 或 AE 时重新发送 ORU 消息，我需要将此 ORU 存储在某处，以便稍后在收到 ACK 时访问它（记住它是异步的）。

我正在研究如何实现这一目标。我的想法是这样的：

• 发送 ORU 消息并将其存储在数据库中
• 在另一个通道中等待传入的 ACK
• 对于传入的 ACK，在数据库中查找相关的 ORU，并根据 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 的消息之前，您需要某种方式进行协调。