В предыдущей статье мы рассмотрели вопрос о том, как спроектировать обмен с множеством поставщиков, используя единый подход. Повествование будет логически вытекать из предыдущей статьи, поэтому если вы ее пропустили - рекомендую ознакомиться.
Сейчас мы перейдем от теории к делу, от идеальных поставщиков к реальным.
Начнем с того, как лучше устроить файл выгрузки (для идеального 51-го поставщика):
- Во-первых это должен быть XML (почему - станет ясно позднее).
- Во-вторых он должен содержать максимальное количество данных, которые вы только можете выгрузить с этим заказом. Т.е. на этом этапе нам не важно, требуется ли указывать ставку НДС для поставщика, которому в конечном итоге предназначен заказ - мы должны выгружать все что может потребоваться.
- В-третьих конвертируемые значения должны быть сконвертированы. Т.е. уже на стадии формирования XML для идеального 51-го поставщика, например, идентификаторы товаров должны быть подставлены от того поставщика, которому предназначен заказ. Это не должно вызвать каких-то затруднений, поскольку каждый из поставщиков имеет свою номенклатуру поставщика, а поставщик известен.
Таким образом, у нас должен получиться файл, содержащий все данные, нужные поставщику чтобы принять заказ, но в немного невалидном виде )
Так как же это работает
Думаю все кому интересно уже догадались что тот XML, который у нас получился, мы будем преобразовывать хитрым способом, чтобы из одного формата получить 50.
Для этого мы будем использовать двухступенчатое преобразование:
- XSLT
- Форматный конвертер
Сначала нам нужно создать саму структуру данных. Для этого лучше всего подходит XML, поскольку в нашем распоряжении имеется мощный язык преобразования XML-документов (eXtensible Stylesheet Language Transformations), позволяющий преобразовать XML документ из одного вида в другой. И (!) этот язык поддерживается платформой 1С:Предприятие. Объект платформы ПреобразованиеXSL позволяет приводить ваш XML к другому виду, используя язык XSLT.
Язык не сложный, освоить на базовом уровне (а базового уровня для нашей задачи хватит с головой) его можно за пару-тройку дней.
Далее, созданную структуру, возможно, потребуется преобразовать в формат, отличный от XML. Форматный конвертер, который, к сожалению, платформа не поставляет в готовом виде, придется писать самостоятельно. В этом смысле наиболее сложным представляется преобразование XML <-> JSON, пример такого преобразования я выкладывал. Бывает еще преобразование XML в параметры GET запроса, т.е. в строку вида ?item=12345&qty=4&price=19.50, но это уже совсем просто. В результате этого шага должен появиться текст обмена, валидный для конкретного поставщика.
После получения валидного текста для обмена - его остается только отправить. Этой задачей занимается функциональность, которую я условно называю универсальный дозвонщик. Она умеет по настройкам вызвать SOAP или REST сервис и передавать туда результат работы конвертера. Дозвонщик должен предусматривать очень разные сценарии развития событий: он должен быть готов отправить данные как параметры и как тело запроса, POST и GET методами, с basic и не очень авторизацией и т.п.
Теоретически, к дозвонщику можно прикрутить хоть чтение/запись в эксель, конкретные "коннекторы" выбирайте под свои потребности.
В принципе, функции получения данных в формате идеального 51-го поставщика, XSL трансформации, форматного конвертера и дозвонщика можно вынести в отдельную ИБ, что у меня и сделано. Я называю эту штуку Конвертер интерфейсов.
Код всей этой ИБ умещается в 300 строк. Основные настройки (тексты XSLT, настройки преобразований и вызовов) хранятся как элементы справочников. При подключении к ней, эта ИБ делает следующее:
- ERP формирует заказ и отправляет его в формате 51-го поставщика Конвертору интерфейсов
- Конвертер получает тест XML в формате 51-го поставщика и дообогащает его
- определяет какому поставщику нужно отправить запрос (условно, по коду интерфейса), — на лету выполняет XSL трансформацию и форматную конвертацию
- тут же отправляет преобразованный запрос дальше поставщику
- получает ответ поставщика
- из тела ответа в обратном порядке выполняет форматную конвертацию, дообогащение, далее XSL трансформацию в формат ответа идеального поставщика
- возвращает в ERP ответ идеального поставщика
Все это происходит «на лету», т.е. синхронно, т.е. ERP думает что обменивается со всеми поставщиками в одном, удобном ей формате, даже не замечая что происходит что-то неладное. Такой подход, естественно, применим только для случаев передачи относительно небольших пакетов данных. Если у вас ходят прайс-листы по 1 Гб — стоит подумать как ко всей этой истории прикрутить асинхрон.
Фишка с дообогащением
Почти в каждом обмене есть такие значения, которые просто хардкодятся. Частично это может быть следствием чересчур богатой функциональности поставщика, например, параметр «процент на который может быть увеличена цена товара без дополнительного согласования», частично это просто какие-то значения типа «для вас это всегда 4000». Что 4000? Почему 4000? Просто 4000 и все. Чтобы не хранить в ERP такие «мертвые» значения, в Конвертере есть возможность дообогатить данные ERP каким-то еще XML'ем. Т.е. это просто произвольный XML, который хранится в БД Конвертера интерфейсов.
Для каждого интерфейса (поставщика) такой XML свой. Дообогащение происходит по принципу простой склейки с обёрткой в общий тег, например:
<body>
<ERPData>
...данные из ERP...
</ERPData>
<AdditionalData>
...статичные данные Конвертера...
</AdditionalData>
</body>
И далее, такой обогащенный XML поступает на вход XSLT движка, где доступны как данные, отправленный ERP, так и наши статичные данные.
Что мы имеет в результате?
Мы ведь не за просто так весь этот огород городить начали, а потому что хотели сократить время на подключение поставщика. Вот что из себя представляет подключение нового поставщика:
- Изучение документации к API
- Создание соответствующего поставщика в ERP и его настройка (порядка 10 галочек).
- Описание преобразования текста обмена на языке XSLT
- Описание форматной конвертации (если требуется)
- Настройка параметров исходящего подключения (еще 10 галочек).
На практике, все эти действия занимают до 3-х часов. Понятно, что бывают случаи когда поставщик выдумает что-то «эдакое», но в 95% случаев можно уложиться в 2-3 часа. (в этом предложении я ошибся и написал «подставщик» вместо «поставщик». Совпадение?..)
Естественно, есть еще масса деталей и нюансов, рассказать о которых в рамках обзорной статьи не представляется возможным, однако цель статьи: показать один из возможных подходов к проектированию архитектуры мультиформатного обмена, я считаю достигнутой.
