Введение
Управляющая система (УС) – программа (система), под управлением которой работает программа СуперМаг Мобайл.
Данный документ адресован техническим специалистам (программистам, бизнес-аналитикам) и предназначен для разработки кода в УС для интеграции с программой СуперМаг Мобайл. Помимо данного документа, для интеграции используются результаты предпроектного исследования и XSD-схемы передаваемых объектов.
Во избежание терминологической путаницы, в дальнейшем под СуперМаг Мобайл понимается полнофункциональная система, которая используется, прежде всего, для поддержки бизнес-процессов ТСД, и где в инфраструктуре программного обеспечения торгового предприятия в качестве бэк-офиса используется 1С или другая бэк-офисная система.
Под стандартной интеграцией подразумевается такой обмен между СуперМаг Мобайл и 1С, при котором преобразование информации из представления СуперМаг Мобайл в представление 1С и наоборот выполняется штатными инструментами 1С. В тех случаях, когда этого механизма недостаточно, необходимо привлечение сотрудников сопровождения из нашей компании для дополнительных действий по настройке программ СуперМаг Мобайл.
Для обмена данными с 1С используется почтовый модуль с XML-фильтром.
Стандартный протокол обмена выглядит следующим образом. Каждый объект данных СуперМаг Мобайл описывается XSD-файлом. Стандартный набор таких файлов можно получить утилитой Создание схемы данных для XML-фильтра административного модуля:
Результатом работы утилиты являются XSD-файлы с описанием структуры XML-файлов:
Название файлов соответствует типам объектов СуперМаг Мобайл, например, WI – приходная накладная.
Посмотреть структуру объектов можно с помощью программы Редактор XML-схем из стандартной поставки СуперМаг Мобайл, которая позволяет описать схему почтового объекта в терминах понятных системе:
Если описанный таким образом объект принимается в первый раз, он будет принят в соответствии со схемой. Отсутствующие в схеме поля объекта после помещения его в базу данных будут либо пустыми, либо примут значение по умолчанию. Поля, которые в схеме присутствуют, но отсутствуют в XML-объекте, будут иметь значение в соответствии со схемой (NULL или DEFAULT). Если объект приходит во второй раз (то есть, он уже есть в БД), то поля, отсутствующие в схеме, но присутствующие в базе данных, не изменят своего значения. Поля, описанные в схеме, но отсутствующие в XML-объекте, будут трактоваться как пустое значение и будут обновлены в базе данных.
Опционально реализован вариант приема почтового объекта с произвольным содержанием, при котором все поля, отсутствующие в почтовом объекте и имеющиеся в стандартной схеме объекта, считаются именно отсутствующими, и их значения при обновлении объекта в базе данных не изменяются. Для того чтобы включить режим произвольного состава XML-объекта, надо в настройках почтового модуля отметить следующий флажок:
Этот режим работы XML-протокола имеет следующие ограничения:
1) В XML-объекте должны быть заполнены обязательные поля: как правило, это ключевые поля, которые нужны для идентификации объекта.
В одном XML-файле объекты одного типа должны иметь одну и ту же структуру. Или иначе: два объекта одного типа с разным набором полей должны передаваться в разных файлах. Такое ограничение связано с тем, что при приеме XML-файла фильтр почтового модуля фактически воссоздает схему объекта по содержанию файла и в дальнейшем использует эту схему при обработке именно этого файла. Такое же требование одинаковости структуры предъявляется к компонентам сложного объекта. То есть, его части должны иметь одинаковую структуру (например, в спецификации документа все строки должны иметь одинаковый набор полей). Опция позволяет получать обновления объектов в тех случаях, когда сторонняя система не имеет возможности передавать полный набор данных об объекте при его изменении.
Как правило, данных, которые предусмотрены приведенными выше схемами, достаточно, чтобы в 1С можно было принять XML-файлы через настраиваемые интерфейсы 1С.
Для формирования XML-файлов и передачи их в 1С, необходимо настроить почтовый модуль, то есть описать в нем каталоги обмена с 1С:
Затем нужно описать правила рассылки, то есть указать, что отсылать и при каком событии:
На этом стандартная интеграция завершена.
Примечание. Перечень данных, которые передаются из 1С в СуперМаг Мобайл, и из СуперМаг Мобайл в 1С (например, классификатор, товары, информация о заказах и т.д.), определяется перечнем бизнес-процессов ТСД. Правила рассылки настраиваются, исходя из такого перечня. Для тех клиентов, которые не приемлют файловый обмен и настаивают на использовании WEB-сервисов, можно предлагать сервер обмена данными, который имеет аналогичный функционал, но не имеет опыта многолетней эксплуатации.
Симметричный и несимметричный обмен при использовании XML-фильтра
При описании XSD-схемы почтового объекта в качестве полей объекта можно использовать функции, с помощью которых в поле добавляется значение, отсутствующее в исходном объекте, например, название артикула в строке спецификации документа.
Использование функций в описании объекта приводит к тому, что такое описание не может использоваться как для отсылки, так и для приема объекта в равной степени.
В редакторе присутствует понятие назначения файла схемы описания почтового объекта:
- для симметричного обмена, для принятия данных, то есть для импорта,
- и для отсылки данных, то есть для экспорта.
Симметричный обмен – это такой обмен, при котором схема почтового объекта одинакова как при его отсылке, так и при его приеме. При несимметричном обмене структура одного и того же объекта при отсылке и при приеме отличается.
В программе Редактор XML-схем на экране описания схемы объекта указаны элементы для выбора назначения схемы: Симметричный обмен/Импорт из XML/Экспорт в XML:
Тип или назначение схемы прописывается в заголовке XSD-файла, что позволяет помещать файлы разных типов в один каталог и корректно использовать их как при приеме, так и при отсылке данных.
Сохранено ограничение, согласно которому одному типу почтового объекта может соответствовать только один файл описания схемы объекта при обмене по одному направлению. Это означает, что при несимметричном обмене какими-либо объектами, объект может только отсылаться или только приниматься, то есть нельзя описать для одного и того же объекта разные схемы для приема и отсылки. Например: при обмене с поставщиком контрагенту можно отсылать заказы с дополнительными данными, такими как добавление артикулов контрагента в спецификацию документа. От контрагента при этом можно получать накладные поставщика, которые не содержат номер документа торговой системы. При этом нельзя одновременно получать заказ от поставщика или отсылать накладную поставщика тому же контрагенту по тому же направлению обмена.
Файлы описания схемы для симметричного обмена могут содержать только стандартные поля почтового объекта и простые поля, то есть такие поля, значения которых при приеме игнорируются, а при отсылке заполняются значением по умолчанию.