BizTalk + BTAHL7 MLLP - вернуть оригинальный номер отправителю

Question

В моем сценарии клиент отправляет HL7 через MLLP на мой двухсторонний порт приема BizTalk. BizTalk выполняет вызов веб-службы для внешней службы, получает ответ, переводит его в ACK HL7 и возвращает его клиенту в синхронной транзакции.

Чтобы это произошло, у меня есть оркестровка, которая напрямую связана с окном сообщений, и конфигурация стороны BTAHL7 настроена так, чтобы не направлять ACK на конвейер отправки на портах приема запроса-ответа. По сути, я отключаю генерацию ACK по умолчанию и генерирую собственный ACK из своей оркестровки. Я также добавил дополнительный фильтр в форму получения оркестровок BTAHL7Schemas.ParseError == false, чтобы оркестровка не получала неверных сообщений, если полученные сообщения не соответствуют схеме.

Все отлично работает. В моем тестировании я специально отправляю плохие сообщения HL7. В этом случае я получаю отчет об ошибке приостановки маршрутизации, поскольку подписчики не найдены.

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

Обычно в асинхронной архитектуре я включаю "Route ACK для отправки конвейера через порт приема запроса-ответа" и позволяю BTAHL72X принимать / отправлять конвейеры. Затем клиент получит сообщение об ошибке ACK, содержащее сведения об ошибке.

Итак, мой вопрос: есть ли способ получить исходный ACK для конвейеров приема и вернуть его из моей оркестровки?

Answer 1

Да, то, что ты хочешь, конечно, выполнимо. У меня нет проекта HL7 прямо сейчас, поэтому моя память может быть не точной, но что-то вроде:

1. Снимите флажок "Reoute ACK для отправки конвейера..."
2. Вам потребуется пользовательский конвейерный компонент для продвижения BTS.InterchangeID на выходе дизассемблера.
3. В вашей Оркестрации внедрите Конвой, связанный с BTS.InterchageID.
4. Затем оркестровка получит сообщение HL7 и автоматически сгенерированный ACK.
5. У тебя нормальная обработка.
6. Решите, какой ACK вернуть, ваш или сгенерированный.
7. Верните ACK в порт TwoWay.

*Нестандартное конвейерное решение: *

На вкладке "Подтверждение" в проводнике конфигурации BTAHL7:

1. Установите тип подтверждения для Enhanced
2. Установите MSH15 (Принять тип подтверждения) в NE.
3. Установите MSH16 (Тип подтверждения приложения на ER)
4. Включите Route ACK для отправки конвейера по запросу-ответу,

Похоже, чтобы получить поведение, которое я хочу. Успешные ACK не будут генерироваться конвейером, что позволяет моей оркестровке обрабатывать его, но будут генерироваться ошибки ACK приложения (AR - отклонение приложения) и направляться в конвейер отправки.