在歡樂

Question

處理異步ACK我開發在歡樂發送一個ORU消息的信道。然後ACK將異步發送回特定端口上的不同通道。

爲了能夠在ACK中接收到AR或AE時重新發送ORU消息，我需要將此ORU存儲在某個地方以便稍後在接收到ACK時訪問它（記住它是異步的） 。

我搞清楚如何實現這一目標。我的想法是這樣的：

• 發送ORU消息，並將其存儲在數據庫中的其他通道等待
• 對進來的ACK的
• 一個進來的ACK查找相關ORU在數據庫中，並根據若ACK是否爲正數，刪除ORU或重新發送

如果你的某個人有一些經驗，並且可以告訴我這是否是一種正確的方法，如果不是，怎麼樣。 這個想法很好，我應該如何實施第三步？我已經嘗試過使用單個通道，但無法重新發送ORU。

Answer 1

我覺得你的做法是合理的。我們傾向於避免硬刪除，而是將消息標記爲ACK（或NACK）消息到達時的「已確認」。這使您能夠查詢ACK/NACK/NULL併爲您提供響應的歷史記錄。

我們保留通過sampleId /時間戳我們ORU的軌道，並記下MESSAGEID的。 messageID返回ACK/NACK，因此很容易匹配。

你可能不希望重新發送（自動）NACK'ed消息的原因是什麼，曾經引起了NACK在第一的位置（如格式問題）不太可能用一個簡單的重發來解決。相反，您可能需要一個NACK來觸發警報（如電子郵件）給某個可以進行修復和手動重新發送的組。

你必須決定你是否可以安全地重發丟失「的ACK」多久你應該等待。這些是比技術更多的商業決策。例如，您沒有收到ACK/NACK，但是由於網絡呃逆，Mirth的問題，還是您的原始消息實際上沒有通過？如果接收系統僅依靠1條消息並且只有1條消息，那麼在重新發送那些沒有收到ACK的消息之前，需要一些協調方法。