Обработка асинхронного ACK в Mirth

Question

Я разработал канал в Mirth, который отправляет сообщение ORU. Затем ACK будет асинхронно отправляться обратно на другой канал на определенном порту.

Для того, чтобы отправить сообщение ORU в случае получения AR или AE обратно в ACK, мне нужно сохранить этот ORU где-нибудь, чтобы получить к нему доступ позже, когда принимается ACK (помните, что он асинхронный) ,

Я выясняю, как этого достичь. Моя идея выглядит следующим образом:

• отправить ОРУ сообщение и сохранить его в базе данных
• в другом канале засаде Incomming ACKs
• для Incomming ACK ищет соответствующий Орала в базе данных и в зависимости от того ACK был положительным или нет, удалите ORU или повторно отправьте его повторно

Было бы неплохо, если бы кто-то из вас имел некоторый опыт работы с ним и мог сказать мне, является ли это правильным способом сделать это, а если нет, как. Дело в том, что идея хорошая, как я должен реализовать третий шаг? Я уже пробовал с одним каналом, но мне не удастся повторно отправить ORU.

Answer 1

Я думаю, что ваш подход разумный. Мы склонны уклоняться от жестких удалений и вместо этого отмечаем сообщение как «подтвержденное» с появлением сообщения ACK (или NACK). Это дает вам возможность запрашивать ACK/NACK/NULL и дает вам историю ответов.

Мы отслеживаем наш ORU с помощью sampleId/timestamp и отмечаем messageID. СообщениеID возвращается в ACK/NACK, поэтому его легко совместить.

Возможно, вы не хотите повторно отправлять (автоматически) сообщения NACK, потому что то, что когда-либо вызывало NACK в первую очередь (например, проблему с форматом), вряд ли разрешится с простой отправкой. Вместо этого вы можете захотеть, чтобы NACK вызывал предупреждение (например, письмо) какой-либо группе, которая может выполнить исправление и повторно отправить вручную.

Вам нужно будет решить, можете ли вы спокойно переслать отсутствующие «ACK» и как долго вы должны ждать. Это больше бизнес-решений, чем технических. Например, вы не получили ACK/NACK, но было ли это из-за сетевой икоты, проблемы с Mirth или действительно ли ваше оригинальное сообщение не прошло? Если принимающая система подсчитывает 1 и только 1 сообщение, вам потребуется какой-то способ согласования, прежде чем повторно отправлять те сообщения, которые не получили ACK.