Возможно ли, что и TA1, и 999 отсутствуют в BizTalk при входящем входящем файле X12 с неправильным форматированием?

Такое встречаю 1 раз.

Обычно, когда мы получаем входящий файл X12. Всегда будет генерироваться 999 (путем настройки в BizTalk), и в случае возникновения ошибки уровня обмена будет создан TA1.

Но сегодня я получил файл X12 с некоторыми ошибками форматирования, всплывающее окно с ошибкой в ​​BizTalk:

 Delimiters are not unique, field and component seperator are the same.
 The sequence number of the suspended message is 1.

Я ожидаю, что будет сгенерирован 999 или TA1 для отклонения входящего файла. но ни один из этих 2 файлов не создан.

Мой вопрос:

  • Какой файл я должен создать для такого рода ошибок? 999 или ТА1?
  • Это ошибка или нормальное поведение BizTalk?
  • Если это нормально, каков наилучший механизм для обнаружения этой ошибки и ответа торговому партнеру.

biztalk edi x12 biztalk-2013
person Zee    schedule 19.04.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

TA1 может подойти, но это кажется серой зоной — возможно, стоит обратиться в службу поддержки Microsoft. В документации указано, что недопустимый ISA должен привести к отрицательному TA1, но коды ошибок для TA1 не указывают этот конкретный сценарий как поддержки (или вообще).

Возможным обходным решением может быть захват такого рода сообщения, создание для него TA1 и перенаправление его обратно на TP. Однако наличие неуникальных разделителей может сделать невозможным определение TP из самого сообщения, даже если вы сможете определить его из контекста (но, возможно, нет, если несколько торговых партнеров используют одни и те же порты/местоположения). Я предполагаю, что именно поэтому BizTalk не справляется с этим должным образом. Честно говоря, если это не происходит довольно часто, вероятно, было бы проще/надежнее справиться с этим в виде исключения с вмешательством человека.

Что касается захвата сообщения, я думаю, вам понадобится собственный компонент конвейера - возможно, даже подкласс EdiDisassembler, чтобы вы могли поймать это конкретное исключение и справиться с ним.

person Dan Field    schedule 20.04.2016