Практические вопросы при реализации EDI-проектов являются не менее интересными темами для анализа, чем новости компаний о выпуске очередного обновления или события в области законодательства.
Сегодня предлагаем рассмотреть вопрос пользовательских предпочтений при выборе формата для обмена данными.
Собственно говоря, тема этой статьи возникла в тот момент, когда один из EDI-клиентов, реализуя интеграцию со своей ERP-системой, обратился с вопросом, должен ли он прислать схему карты трансляции (преобразования сообщения или мэппинга, от английского map), составленную при помощи JSON или XML? Что само по себе прозвучало довольно необычно, т.к. в большинстве случаев для этих целей используется XML, а не JSON.
XML (Extensible Markup Language) – расширяемый не зависящий от платформы язык разметки, который определяет набор правил для представления иерархических данных и унификации передаваемой информации формате, читаемом человеком и машиной. Язык описан в спецификации W3C XML 1.0 и ряде других спецификацией, с ней связанных.
JSON (JavaScript Object Notation) — открытый формат стандарта, который использует человеко-читаемый текст для передачи объектов данных, состоящих из пары «атрибут-значение». Применяется, в основном, для передачи данных между сервером и веб-приложением, как альтернатива XML.
Так почему же стоит вопрос выбора языка разметки? Множество постов в сети описывают преимущества JSON над XML. Некоторые называют JSON «обезжиренной» версией XML из-за меньшего грамматического набора (т.е. не такой многословной). JSON также более точно соответствует структурам данных, используемых в современных языках программирования.
Как XML, так и JSON, используются при реализации Ajax подхода. Ajax описывает способность веб-страницы запрашивать новые данные после того, как она уже загружена в веб-браузер, обычно в ответ на действия пользователя на отображаемой веб-странице. Новые данные, как часть модели Ajax, обычно отражаются в пользовательском интерфейсе динамически, в момент получения этих данных от сервера. Примером реализации подхода может служить набор пользователем в строке поиска запроса, который отправляется клиентской частью программы на сервер, а в ответ из базы данных поступает список возможных вариантов. Список может быть отображен в виде ниспадающего меню под строкой поиска. Пользователь может остановить набор и выбрать непосредственно интересующую его строку. На начальных этапах в решениях Ajax в качестве формата обмена данными в основном использовался XML. Сейчас многие разработчики Ajax для обмена обновленными данными между клиентом и сервером используют JSON, т.к. он более быстрый и эффективный.
Многие ERP-системы, к примеру Oracle, в настоящий момент для интеграции используют XML для импорта и экспорта объединяемых данных. Внесение изменений для использования JSON потребует больших временных затрат и значительных усилий со стороны вендоров.
Среди известных нам российских EDI ЭДО -операторов JSON наиболее активно используют в своих интерфейсах относительно «молодые»игроки этого рынка, в частности, компания ИКС-АРТ. По отзывам клиентов использование JSON позволяет им проще и быстрее своими силами реализовывать интеграцию с учетными системами, практически не привлекая специалистов самого EDI-оператора.
Таким образом, получается, что несмотря на высокую популярность JSON (мало от кого можно услышать, что ему нравится XML), XML на практике используется чаще, чем JSON. В то же время, для того, чтобы оставаться «на плаву», следует знать оба языка, т.к. многие разработчики используют JSON для создания API-интерфейсов и модулей обмена данными.