在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條消息，那么在重新發送未收到ACK的消息之前，您將需要某種方式進行協調。