Жила была хранимая процедура. Работала во благо клиента. Он её берёг, не запускал понапрасну, только раз в месяц. Она это ценила и исправно создавала XML файлы, которые успешно перерабатывались механизмом Epicor Service Connect и после этого служили пищей для создания проводок Главной книги.
И вдруг что-то сломалось. Прям-таки сказка-страшилка. Почему всё так случилось? В общем, извечные русские вопросы: «Кто виноват?» и «Что делать?»
Показательным для меня является сообщение моего коллеги о том, что событие в трассировке сообщений Epicor Service Connect не возникает, т.е. файл создаётся в нужной папке и тут же исчезает (в результате обработки механизмом входного канала), но никаких следов активности нет. Ну, на счёт следов, я не совсем согласен, сообщение, скорее всего попадает в папку ошибочных входящих сообщений, но это свидетельствует о том, что что-то нехорошее происходит в структуре XML файла. Вообще, проверить, нарушена или нет структура XML файла очень просто. Достаточно просто дважды кликнуть на нём. Обычно при этом вызывается Internet Explorer. Файл, если он корректный, выглядит примерно так:
А присланный мне файл выглядел вот так:
Сразу понятно, что с ним что-то не так. Скорее всего дело в данных, которые подставляются Хранимой Процедурой. Можно попытаться открыть этот файл какой-то другой программой, например, Microsoft Edge:
Открываем с помощью блокнота, находим строку номер 3674 и видим следующее:
<dta:TransTxt>PO:2700001524-000070-Şirniyyat boşqabı (17 sm) (B&B PLATE) (410.00*31/365)</dta:TransTxt>
Ну, теперь всё ясно. Знак «&» — это зарезервированный символ, его нужно заменить на «&». Это сразу ответ на оба вопроса: Кто виноват? Ну, видимо я — не предусмотрел, что пользователь вобьёт в поле описания спецсимвол. А что делать? — заменять. Причем не только «&» на «&», но и " (двойные кавычки) на «"»
