EDI стандарт. Технический обзор

    EDI стандарт (Electronic Data Interchange) — часть старых, устоявшихся систем. Но мы постоянно видим, как EDI представляют, как современный стандарт. Так ли это? Надо ли нам рассматривать EDI в качестве базовой технологии для новых проектов?
    Давайте посмотрим на EDI с технической точки зрения, отбросив все остальное.

    Формат данных в EDI


    EDI использует delimited text формат. Он хорошо работает для плоских структур данных, таких как таблицы. Он не так хорош для представления иерархических структур данных. Вложенные объекты лучше сериализуются с помощью tagged форматов, таких, как XML и JSON.
    Очень странно, но так и не был создан язык описания (document definition) для EDI. Прошло столько лет с момента появления EDI и столько усилий было затрачено на него, но язык описания так и не создан. Язык описания позволяет автоматизировать обработку данных, а именно их генерацию, верификацию, преобразование, сериализацию, десериализацию. Для сравнения, для верификации XML данных мы берем схему данных (XML Schema, xsd) и парсер автоматически проверяет данные на соответствие этой схеме.
    Можно обойтись и без схемы, но тогда желательна разметка документа. XML и JSON документы могут быть десериализованны и без схемы, потому что сами данные содержат тэги (имена) элементов данных. EDI имеет тэги только для сегментов и не имеет тэгов для элементов. Элементы определяются позицией внутри сегмента. Универсальный EDI парсер сможет разобрать документ только на примитивные коллекции, потому что документ не содержит ни имен, ни типов для элементов данных.

    Давайте обратимся к деталям.

    EDI стандарт состоит из двух основных частей:
    • Envelope (пакетный?) формат (смесь стандартов сообщений (messaging))
    • Спецификации (форматы) документов (смесь индустриальных (domain) стандартов)


    Пакетный формат


    EDI определяет пакеты для наборов документов, групп документов и самих документов/транзакций (Interchange, Group and Transaction/Document). Пакеты ограничиваются соответственно ISA/IEA, GS/GE, ST/SE парами сегментов.
    Замечание: Для иллюстрации я использую EDI X12 вариант стандарта, распространенный в Северной Америке. Другой вариант стандарта, EDIFACT, распространен в Европе и принципиально не отличается от X12.
    Здесь представлен пример самых первых сегментов всех трех пакетов: ISA, GS и ST. Пример взят отсюда:
    ISA*00*          *00*          *ZZ*RECEIVERID     *12*SENDERID       *100325*1113*U*00403*000011436*0*T*>~
    GS*FA*RECEIVERID*SENDERID*20100325*1113*24712*X*004030~
    ST*997*1136~

    Что мы видим в первом сегменте?
    Последние три символа сегмента ISA — это разделительные символы: "*>~": ‘~’ — символ разделения сегментов; ‘*’ — символ разделения элементов внутри сегмента; ‘>’ — символ разделения подэлементов внутри элемента. Изменяя эти символы мы по сути изменяем форматы пакетов и документов. В XML и JSON разделительные символы прописаны в стандарте, их нельзя изменить. Изменяемые разделительные символы — это рудименты эпохи, когда Unicode еще не был создан. Но даже в те времена делать разделительные символы изменяемыми было не очень хорошей идеей. Разделительные символы — очень важные символы. Если мы можем использовать любые символы в качестве разделителей, это не только именяет логику разбора пакетов на составляющие части, это сильно усложняет логику разбора текста внутри самих элементов.
    Еще в ISA сегменте мы видим элементы, определяющие форматы времени и дат. Они помогают нам использовать настраиваемые форматы дат и времён внутри документов. Это имело смысл в семидесятых годах, когда нам надо было сохранить несколько байт при кодировке дат и времён. Нужны ли эти элементы теперь, после того как мы побороли проблему «2000-ного года», после того как были созданы специализированные и очень подробные  стандарты представления времени?
    Мы видим в ISA сегменте элементы, определяющие отправителя и адресата. По сути это — адресная (routing) информация. То есть стандарт упаковки объединен со стандартом адресации. Используя EDI, мы должны задавать отправителя и адресата внутри наших данных. В сегменте ISA есть еще и авторизационные элементы. Вся идея размещения этой авторизационной информации внутри самих сообщений когда-то была довольно прогрессивная, но сейчас она выглядит по меньшей мере наивной, а то и опасной. Сейчас мы понимаем, что авторизационная информация — много-много сложнее чем пара значений. То же самое можно сказать и про адресную информацию. EDI стандарт подталкивает нас к использованию этих элементов.
    Еще мы видим элемент запроса подтверждения (acknowledgement request). То есть создатель документа задает стратегию использования подтверждений прямо в документе. Хорошая ли это идея? Мы можем использовать документы в разных сценариях. В некоторых из них подтверждения используются на уровне приложений, в других для повышения надежности используются другие протоколы. Политика надежности определяется не внутри самих данных, потому что надежность — это довольно сложная тема в передаче данных, определяемая многими участниками коммуникации.
    Еще внутри сегментов пакетов мы видим контрольные номера (Control Numbers). Они нужны в сценариях, когда мы получаем набор документов, но часть набора потеряна или искажена по пути, и мы пытаемся восстановить как можно больше данных. Этот сценарий давно уже не используется, так как подобная проблема надежности как правило решается на нижних уровнях коммуникационных протоколов. Мы не встраиваем надежность коммуникаций на уровень приложений, так ведь?
    Другой элемент ISA сегмента, это EDI версия (Standard Identifier). Это похоже на поддержку версионности, знакомую нам по сериализационным стандартам.
    В сегменте GS находится элемент, определяющий тип документа  (Type of Document). К примеру, это заказ или накладная. Ничего очень плохого в этом нет, хотя задавать тип документа проще внутри самого документа.

    Как видим, практически все элементы в пакетных сегментах или бесполезны, или, более того, опасны, если мы будем их использовать в соответствии со стандартом.
    Пожалуйста, не пытайтесь использовать данные из пакетных сегментов для аутентификации и адресации.
    EDI был создан во времена, когда размещение этой информации в пакетах было единственным вариантом. Сейчас мы передаем документы через интернет и используем большой набор стандартов и протоколов для упаковки, адресации, аутентификации, авторизации, надежности, кодирования, сериализации, сегментирования и т.д., и т.п. Специфичная для конкретного протокола информация добавляется и удаляется на всем пути данных, и эта информация независима от самих данных.

    EDI — это стандарт формата данных или протокол?

    EDI пытается быть протоколом, именно поэтому мы видим эти элементы адресации, авторизации и запроса подтверждения. Я не знаю, как эту информацию можно сопоставить с OSI protocol layer model.
    Но все же большая часть EDI стандарта посвящена форматам данных.

    Форматы документов

    Внутри пакетов мы видим сами документы. Но мы не найдем стандарта для универсального, обобщенного документа. Стандарт определяет многочисленные форматы для всевозможных типов документов: для заказов, для накладных, для описей вложения… Здесь вы найдете небольшую часть из громадного списка стандартизованных документов.
    EDI следует известному мифу: «Где-то там есть идеальный формат, который описывает все на свете сценарии. Мы обязательно найдем этот формат. Нам нужно просто добавлять новые сценарии и подстраивать старые.»
    Как результат EDI стандартные документы (спецификации) чрезмерно сложные.
    Возьмем один пример: Нам нужна накладная для небольшого местного книжного магазина. Мы нашли подходящую стандартную спецификацию, EDI 850, заказ на покупку (Purchase Order). На первый взгляд он выглядит чересчур детальным. Мы не будем покупать продукты питания, уголь, зерно, жидкие продукты, опасные продукты, медицинские препараты. Нам не нужны международные адреса. Мы не будем использовать службы срочной доставки. EDI спецификация описывает все эти возможные варианты, но в ней слишком много полей, которые мы никогда не будем использовать. Она чересчур сложна для нашего простого документа.
    Существует много индустриальных (domain) стандартов, которые используются как своеобразные хранилища знаний. Но эти стандарты не используются как стандарты передачи данных. (Посмотрите эту статью, описывающую проблему индустриальных стандартов.)

    Циклы (Loops) внутри документов

    Структура индивидуальных документов довольно проста. Документы составлены из серии сегментов, внутри которых находятся данные документов.
    Но оказывается, что сегменты могут объединяться в группы или в повторяющиеся группы, так называемые циклы (loops). Пикантность в том, что эти циклы абсолютно никак не выделены в документе. О наличии цикла мы можем прочитать в спецификации данного конкретного документа. Сегменты одинакового типа (с одинаковыми тэгами) могут располагаться как независимо, так и внутри циклов. Создать парсер, распознающий циклы (которые, повторяю, никак не отмечаются в документе), это довольно нетривиальная задача.
    В XML и JSON такой проблемы не стоит, иерархические объекты или коллекции объектов любого уровня вложенности очень просто задаются с помощью открывающих и закрывающих тэгов, именованных или неименованных.
    EDI попытался усидеть на двух стульях. С одной стороны, его документный формат похож на формат csv и удобен для представления табличных данных. С другой стороны, он пытался описывать иерархические объекты, и попытка эта окончилась очень неубедительно. Конечно, мы понимаем это сейчас, когда имеем перед глазами JSON. Но давайте вспомним, что EDI был сделан не для передачи табличных данных, а именно для передачи документов, структура которых именно иерархическая.

    Нетехнический взгляд на EDI


    Для полной картины я все же перечислю некоторые из нетехнических особенностей EDI:
    • EDI стандарт не бесплатный. Это выглядит довольно странно по сравнению с другими стандартами.
    • Спецификации EDI стандарта чрезмерно детальны. EDI спецификации настолько сложны, что компании должны нанимать специалистов, знакомых с конкретной спецификацией. Эти специалисты общаются с помощью специальных EDI терминов, это почти EDI язык, который никак не связан с бизнесом. Посмотрите на EDI соглашения (agreements) между компаниями. Эти соглашения полны специфических требований, определяемый EDI стандартом, но далекими от требований бизнеса.
    • EDI стандарт не стабилен. Специальный комитет выпускает модификации EDI стандарта каждые полгода. Каждая из этих версий привносит новые уточнения. Развитие стандарта не следует запросам пользователей, скорее оно просто следует календарному плану. Предположительно это происходит не из-за очень высоких требований к стандарту, а потому что комитету нужно показать результаты своей работы.
    • EDI был создан, чтобы экономить биты и делать документы как можно более компактными. Это требование до сих пор существует, но оно вряд ли используется для передачи документов. Каждый ребенок сейчас владеет телефоном, который перекачивает гигабайты видео. На дворе уже не эпоха мэйнфреймов и телетайпов. И довольно странно читать отчеты, которые совершенно серьезно обсуждают экономию ресурсов из-за перехода с бумажного документооборота на использование EDI.
    • Для экономии памяти EDI использует коды для представления данных где только возможно. В результате документы выглядят зашифрованными, что создает дополнительную проблему обмена кодовыми таблицами.
    • EDI стандарт был создан для передачи наборов (batches) документов из-за того, что коммуникации и компьютеры стоили дорого и работали медленно. С тех пор многое изменилось, коммуникации и компьютеры стали быстрыми и дешевыми. Данные сейчас передаются маленькими сообщениями или потоками, и эти маленькие сообщения являются основой распределенных систем. Наборы документов еще используются, но не из-за медленного оборудования, а потому что это требуют бизнес-процессы.
    • Не существует стандарта на язык описания EDI. Это означает, что мы не можем создать универсальный парсер для обработки EDI документов. Парсеры должны содержать описания тысяч существующих EDI спецификаций с огромным количеством деталей. (К примеру, Microsoft предоставляет около 7 тысяч XML схем для EDI документов как часть BizTalk Server.) Имеющиеся EDI парсеры стоят дорого. Для работы с EDI документами нам скорее всего придется преобразовать EDI документы в формат XML и использовать XML Schema вместе с XML парсером для обработки EDI документов: для проверки, преобразования, сериализации, десериализации, создания. Что и делается в BizTalk Server.
    • Из-за отсутствия стандартного языка описания EDI документы описываются с помощью… многостраничных инструкций.  Разработчики EDI парсеров трактуют эти инструкции по-разному, и из-за этого различные EDI парсеры несовместимы.
    • EDI стандарт создавался во времена, когда разработка программ, протоколов и форматов данных была чрезвычайно дорога и длилась очень долго. Создание стандарта для универсального формата документов было оправдано. Сейчас форматы данных генерируются на лету и наши программы как правило не используют каких-то универсальных стандартов, а создают разные форматы под конкретные случаи. EDI спецификации включают максимально возможное количество деталей, чтобы удовлетворить всех пользователей. Современные программы включают в спецификации передаваемых данных только те данные, которые необходимы. Количество элементов в EDI спецификации, ненужных в вашем конкретном случае всегда будет очень большим.
    • EDI смешивает два типа стандартов: стандарты для коммуникаций и стандарты для форматирования бизнес данных. Современные тенденции прямо противоположны: стандарты должны быть независимы друг от друга (ортогональны), что позволяет смешивать их в любых сочетаниях.


    Как видим, EDI стандарт устарел практически в каждом аспекте, если мы рассматриваем его с технических позиций. Вряд ли сейчас есть рациональные технические причины для его использования. Но, несмотря на это, EDI по-прежнему широко используется.
    В следующей части мы постараемся найти этому причины. Скорее всего они будут не технического характера.
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 31
    • 0
      Для трансляции(json/xml -> edi x12 -> json/xml) использовали bots, но он не универсальный и для каждого вендора приходится писать свой специфический транслятор в виде плагина.
      • 0
        В том-то и дело, что с EDI невозможно сгенерировать нормальный XML, JSON или объектный граф. Вот, к примеру, вручную сделанный граф объектов для одного EDI документа. Я его использовал в тестах сериализаторов для .NET. Очень сложный иерархический граф. В структуре EDI просто нет всей нужной разметки для всей этой иерархии, она вся подразумевается.
        • 0
          Я бы посмотрел исходную спецификацию, в которой описаны сообщения. Может быть даже есть какая-то модель данных для сообщений. И попробовал сгенерить из неё XML-схему и маппинги из EDI-сообщений в XML-сообщения. Или сгенерить код для объектной модели типа вашей.

          Что это за сообщения? Они описаны где-то?
          • 0
            Судя по номеру 835, похоже на Health Care Claim Payment/Advice. Нашёл только спецификацию, модель не нашёл. Остаётся видимо только вручную делать объектную модель. Или брать такие таблички из спецификации

            переводить их в Excel, csv, xml,… формат.

            И запилить генератор, который будет делать из них объектную модель. Чтобы вручную не писать весь этот код, наверное, так было бы проще.
            • 0
              Многие вещи я просто не стал касаться. К примеру, rules, своеобразная попытка зашить правила обработки документа в сам документ. Для них в XML просто нет однозначного эквивалента. С одной стороны, не знаю никого, кто их использует, с другой стороны, наверняка кто-то использует. Им можно только посочувствовать.
            • 0
              У меня нет проблемы сгенерировать XML-схему. Я, наверное, нечетко объяснился, сорри. Я привел это для примера, что подразумеваемые структуры, не выделенные тэгами, невозможно выделить автоматически.
              • 0
                Согласен, не имея спецификацию сообщения, в нём не возможно ничего понять. В отличие от XML-документов, структура которых понятна даже без схемы и спецификации. И в целом с XML конечно проще работать, тут сложно поспорить. А есть же вроде всякие XMI/EDI или ASC X12 Context Inspired Component Architecture? Я с EDI дело особо не имел. В нашей области стандарты в основном уже более или менее синтаксически нейтральные или с уклоном в XML (CCTS, WCO DM, NIEM, ISO 20022 и т.п.).
        • 0
          Вполне можно понять почему он до сих пор используется… Просто на нём основано много стандартов. Большая часть из которых появилась до XML. И просто так всё переделывать из-за какого-то XML, который появился сравнительно недавно и даёт какие-то сугубо технические преимущества, видимо слишком дорого. Хотя на XML конечно потихоньку переходят. Тот же HL7v3, ISO 20022, UN/CEFACT CCTS и т.п.

          Правда, нет гарантии, что лет через 10 не появится ещё какой-нибудь модный стандарт и все не начнут переползать на него. Наверное единственный способ защититься от переделывания всего при появлении новых технологий, это использование модельно-ориентированного подхода, о котором я пишу тут цикл статей :) Вообще, это наверное общий тренд сейчас в этой области. Взять тот же CCTS или ISO 20022 (любой более-менее современный стандарт) — везде предлагается описывать данные в платформо-независимом виде. И есть отдельная спецификация, в которой описано как сгенерить из платформо-независимой модели XML-схемы и т.п. Если появляется новая технология, то не нужно переделывать абсолютно всё, просто делаем новые маппинги из PIM в PSM.

          А почему вам интересна эта тема?
          • 0
            Не совсем так, применение той или иной технологии обычно продиктовано бизнес потребностями компаний.
            Начнем с базовых принципов. Для чего нам EDI.
            EDI всегда использовался как электронный документооборот между компаниями и обеспечивал на бизнес уровне 2 вещи:
            1. Гарантированную доставку данных;
            2. Роль арбитра в спорах между компаниями (если сделки срываются из-за не доставленных либо не вовремя доставленных данных.
            Но по различным причинам «частота» обмена данными в последнее время резко выросла, а плоские структуры больше подходят для неторопливого обмена «большими» порциями данных чем для высокочастотного обмена.
            Именно это я считаю основной причиной перехода EDI провайдеров на XML/Json
            И, имхо, EDIFact это ужасный формат с кучей не понятных своим смыслом полей, добавленных в стандарт по причине того, что несколько крупных компаний их используют.
            • 0
              Полностью с вами согласен.
              1. Гарантированная доставка сейчас обеспечивается массой протоколов совершенно другого уровня, чем EDI. Обеспечивать гарантированную доставку с помощью EDI сейчас — это и наивно, и опасно.
              2. Это пока работает. Хотя на практике эта функция сильно зависит от реализации. К примеру, сгенерировала моя програма ack, послала его обратно отпавителю. А отправитель эти ack или хранит так, что их легко потерять, либо чистит раз в квартал. Дошло дело до разборов, отправитель говорит, что никакого ack нет. А то, что ты ему этот ACK предъявляешь… дык. Ты может его и отправлял, а я вот его не получал. Т.е.вступает в дело ack на ack на… Данная проблема решается в интернете вполне успешно. А EDI только делает вид, что решает эту проблему.
              • 0
                Да, EDI включал в себя очень много всего: протоколы, форматы и т.п. Сейчас появились лучшие протоколы, лучшие форматы. Но EDI этим не ограничивается. В первую очередь — это единые наборы элементов данных, единые структуры сообщений, единые классификаторы. Я по своему опыту знаю какая это титаническая работа. К тому же, они не дураки и давно есть XML-решения: CCTS, CCL, UBL и т.п.
                • 0
                  К примеру, если я буду заменять EDI на любую сериализацию.
                  Что из перечисленного списка мне понадобится?
                  — единые наборы элементов данных и — единые структуры сообщений: вещь бесполезная. Если я использую какой-нибудь старенький SOAP, все эти наборы сгенерятся в виде xsd автоматом. Автоматом же на приемном конце получат эти схемы и сгенерят классы.
                  Те, кто получают данные, подключатся к ?wsdl адресу, автоматом получат эти схемы и сгенерируют классы. Проблема согласования структур решена.
                  — единые классификаторы: скорее всего это реальная потребность. Всем обменивающимся данными надо использовать единые классификаторы. Но, с другой стороны, эти коды не должны быть частью передаваемых сообщений или спецификаций предаваемых сообщений. Они должны быть в виде именно *единых* классификаторов. Т.е. комитет или организация, отвечающая за коды, должна вывешивать их, к примеру, в виде сервисов. Любой пользователь подключается и получает коды он-лайн. Т.е. классификаторы должны кому-то принадлежать. И уж точно не EDI (или подобному) комитету. Коды химич.составов — организациям, лицензирующим эти составы. Коды лекарств — тем, кто лицензирует лекарства (т.е. поддерживает базы кодов). А ЕDI комитет определяет структуру сообщений, а уж никак не коды лекарств.
                  Вы скажете, что по поводу кодов-классификаторов организаций, которые используются в кодах отправилеля и адресата в ISA сегменте? Я скажу, что подобные коды д.б.уничножены и забыты, как страшный сон.
                  • 0
                    Т.е. классификаторы должны кому-то принадлежать. И уж точно не EDI (или подобному) комитету. Коды химич.составов — организациям, лицензирующим эти составы. Коды лекарств — тем, кто лицензирует лекарства (т.е. поддерживает базы кодов).
                    Ну, да, а если эти организации по какой-то причине не сделали нужный классификатор, то напишем им гневное письмо: ну-ка быстро запилили нам классификатор, это ваша обязанность :) Например, 19 или 21 рекомендации (виды транспорта, упаковок).

                    единые наборы элементов данных и — единые структуры сообщений: вещь бесполезная
                    Допустим, вы передаёте сведения о какой-нибудь товарной партии. Как вы назовёте эту сущность «Партия товаров», «Товарная партия» или ещё как-то? А её содержимое: «Единица товарной партии», «Товар», «Товарная позиция», «Сведения о товаре»? Отправителя: «Отправитель», «Грузоотправитель», «Отправитель груза»? Сведения об отправителе вы вложите внутрь сведений о товарной партии или на тот же уровень? Какие сведения об отправителе будете передавать: полное и краткое наименование организации или достаточно только полного. А какая максимальная длина для наименования? 100, 200, 300, 500 символов? А если отправитель — это физическое лицо, то его ФИО вы будете передавать в поле «Полное наименование» или в отдельных полях «Фамилия», «Имя», «Отчество»? А какие из этих полей вы сделаете обязательными? А что если в некоторых странах нет фамилий и т.п.

                    Таких вопросов миллион.

                    Допустим, в вашей организации есть какие-то нормативные документы, в которых описано как всё это должно называться, структурироваться и т.п. Ну, а в другой организации свои нормативные документы, и, вообще, она находится в другой стране с другим законодательством. Вы представляете сколько нужно человековеков, чтобы создать единый реестр элементов данных?
                    • 0
                      @Ares-ekb: прежде всего, спасибо за плодотворную дискуссию!
                      Согласен с вами полностью.
                      Классификаторы играют несколько ролей:
                      * лицензирование. Налоги, лекарства, опасные вещества… Если лицензирующая организация не поддерживает классификаторы в нужном порядке, она, скорее всего, и будет отвечать за коды, невовремя опубликованные, невовремя доведенные до пользователя. Пользователи должны следовать этим кодам.
                      * стандартные размеры, разъемы, допуска. Тут никто обычно не отвечает рублем. Комитеты публикуют коды, стандартные числа. Все, кто хочет им следовать, — следует.
                      * общая терминология. Здесь термины — «непротивление двух сторон». Никого, кроме отправителя и адресата не волнует, как вы там договоритесь насчет общей терминологии, максимальных значений, типов данных и т.п. Здесь как раз wsdl или swagger делают все согласования автоматическими. *Автоматически*. *все* согласования. Как раз в этой области EDI и подобные стандарты пытаются навести порядок, ввести
                      единые наборы элементов данных и — единые структуры сообщений
                      . И именно этот порядок, эти *единые реестры элементов данных* — это прошлый век, рудименты социализма.
                      • 0
                        Допустим, тот же пример с банком и налоговой. Налоговая запилила WSDL, в котором описана служба TransactionAckReceiver, которая может принимать уведомления об оплате с определенной XML-схемой.

                        Банковая ИС смотрит этот WSDL. Она не сможет автоматически понять, что уведомление об оплате нужно отправлять именно службе TransactionAckReceiver, а не какой-то другой. Банку и налоговой нужно предварительно договориться, что эта служба должна называться именно так. Это не происходит автоматически без участия человека.

                        Затем, налоговая в XML-схеме уведомления сделала обязательный элемент «код бюджетной классификации платежа», а ФИО плательщика описала в виде 3-х отдельных элементов: фамилия, имя и отчество. Причем, фамилия — обязательный элемент.

                        Какой-нибудь исландский банк пытается отправить в нашу налоговую уведомление об оплате. У него есть WSDL, XSD. Но это никак не поможет ему заполнить поле «код бюджетной классификации», ну, потому что в их ИС это поле просто не предусмотрено, не откуда взять этот код. И никак не поможет ему заполнить обязательное поле «фамилия», потому что у исландцев нет фамилий.

                        Эти согласования не могут быть сделаны автоматически. Сначала должны договориться чиновники о том, что в принципе такое взаимодействие между банками и налоговой должно быть. На реализацию всего этого должны быть выделены деньги. Потом аналитики, предметники (банковские и налоговики) читают нормативные документы, плотно общаются друг с другом. Пока не договорятся о том должна быть фамилия обязательным элементом или нет. Фиксируют все свои договоренности в виде документов, которые утверждаются чиновниками. И только после этого программисты начинают пилить свои WSDL, XSD и т.п. Причём, набор элементов данных, правила их именования, заполнения и т.п. программисты воспринимают как само собой разумеющееся. Хотя на это-то как-раз и ушла основная часть времени и денег. Реализовать теперь всё это теперь в синтаксисе EDI, XML, JSON или чём-то ещё — это дело техники.

                        Ценность EDI как-раз в том, что там уже пройден весь этот путь для разных видов сообщений. Чиновники, крупный бизнес договорились о том, что сообщения должны быть такие-то. В них должно передаваться то-то. То, что синтаксис EDI не очень, ну, это печально, но не на столько, чтобы тратить деньги на переход на XML. Синтаксис — это уже незначительные технические детали. Которые конечно нужно совершенствовать, и это делается, но медленно, потому что затраты на этот переход очевидны, а существенный положительный эффект не очень очевиден.
                        • 0
                          Проблема с TransactionAckReceiver:

                          Конечно, WSDL не может добавить документацию к набору xsd, поэтому в вашем примере банк где-то должен прочитать, какие операции где использовать. И если схемы генерируются автоматом, то и в комментарии к схемам этого не добавишь. Увы, надо договариваться или вывесить описания на всем известном месте, что, кстати, обычно и делается. Но вот Swagger, тот уже может описания протоколов добавлять, в нем этой проблемы нет.
                          фамилия — обязательный элемент
                          Ну не знаю. optional or not — это все генерируется в схему автоматом. Enum — тоже автоматом.
                          И никак не поможет ему заполнить обязательное поле «фамилия», потому что у исландцев нет фамилий.
                          И как EDI здесь поможет? Это ж типичная проблема, которая затрагивает только вот этот сценарий. И добавлять этот сценарий в стандарт, чтобы для всех будущих поколений эта проблема была уже решена? Нет. Стандарт — это прежде всего набор обобщений. Если стандарт — это набор уточнений, то грош цена этому стандарту. Уточнения должны решаться на нижних уровнях. Пусть предприятия сами договариваются между собою о форматах, если они решили свои детали, которые нигде больше не появляются, добавить в коммуникации.
                          Сначала должны договориться чиновники о том, что в принципе такое взаимодействие между банками и налоговой должно быть.
                          — да. Это типичная «лицензированная» классификация, если так можно ее назвать. Все кому надо, договорились. Потом (или сразу же) кто-то один объявляется главным и хозяином этой классификации/лицензии.
                          Таких классификаций немного, не надо преувеличивать их количество. Большая часть кодов/классификаций никого не интересует. К примеру в EDI, код отправителя, на моей памяти, почти всегда выбирают ZZ ( все остальное). Т.е. никто почти этот код не использует.
                          • 0
                            Банку и налоговой нужно предварительно договориться

                            Отвечу на ваш вопрос немножко с другого конца:
                            Да, им надо договориться. Организационно это может выглядеть очень сложно, просто сложно, просто или очень просто.
                            Технически сейчас это сделать очень просто всегда. Сделать с нуля структуру сообщения сейчас очень просто. Сделать код для обработки сообщения с известной структурой тоже очень просто. Стандарт для, к примеру, платежки никому не нужен, т.к. на этом времени не съэкономишь, а совсем надоборот, потеряешь.
                            В результате всем проще делать оригинальные структуры сообщений под каждый отдельный случай. Стандартные структуры сообщений не помогают. Кто определяет сообщение, тот его и изобретает. И технически делает это просто, быстро, дешево. Подгонять свои данные под какие-то обобщенные стандарты стоит времени и денег, поэтому это никому не нужно.
                            Если EDI, или подобные стандарты используются, то только потому что кто-то из общающихся партнеров настаивает на этом. Чиновникам и бизнесу совершенно неважно в каком стандарте передаются данные, они мыслят в других категориях.
                            Важно ли, чтобы форматы данных на уровне полей были стандартными? К примеру, чтобы ИНН было в нужном формате? Скорее всего. И это тоже технически сейас решается просто и быстро.
                            • 0
                              Сделать XML-схему, WSDL, сгенерить исходный код может школьник с незаконченным средним образованием. Это действительно очень просто.

                              Насчет того, что стандарты никому не нужны не могу согласиться. В конце концов, те же XML или WSDL откуда по-вашему взялись? Крупные компании создавали свои частные форматы и т.п., создавали на основе этих внутренних "стандартов" свои программные решения не совместимые с софтом других компаний. Потом собрались, обобщили свои наработки и утвердили в качестве стандарта. Стандарты везде, их полно и без них вряд ли возможна какая-то работа.

                              Если говорить более узко о стандартах на структуру сообщений. Ну, посмотрите где применяется ISO 20022 или модель данных всемирной таможенной организации. На последней основано энное количество более частных стандартов типа CITES, ePhyto, eTIR. Многие организации уже используют эти стандарты. Попробуйте им объяснить, что зря они их используют, есть пара студентов, которые запилят несколько XML-схем и всем будет счастье.

                              Описание модели eTIR — это 800 страниц текста с описанием сценариев использования, процессов, структур сообщений, согласованные с законодательством разных стран, энное количество раз вычитанные юристами и предметниками, прошедшие сотни согласований. А вы предлагаете просто запилить XML-схему и типа этого достаточно.

                              Для мелких организаций, да, подобные стандарты наверное не нужны. В общем-то и какой-нибудь банк топ 1 — это не очень крупная организация, которая вполне может разрабатывать свои внутренние стандарты. Но если речь идет об отраслях, межгосударственном обмене информацией, о проектах в которых количество разработчиков исчисляется тысячами, то тут только два пути: либо брать существующие стандарты, либо разрабатывать свои. Просто XML-схема не подойдет.

                              Ну, банально, одна подгруппа разработчиков будет описывать процессы на BPMN, а модель данных в виде ER-моделей. Другая группа будет использовать соответственно диаграммы деятельности UML и диаграммы классов. Третья будет описывать процессы словами, а модель данных будет делать сразу в виде XML-схемы и т.д. Все они будут применять разные схемы именования. Например, одни будут называть процедуры с использование глаголов в неопределенной форме, другие будут использовать отглагольные существительные, третьи будут писать как получится, но на английском языке в CamelCase. В части модели данных одни будут использовать слово товар, другие — продукт, третьи — груз для обозначения одной и той же сущности.

                              Для двух разработчиков, да, наверное стандарты не нужны. Но если их больше (сотни или тысячи, причём работают в разных организациях, если не разных странах), то как они обойдутся без стандартов? У одних разработчиков принято моделировать адрес как структуру, содержащую код страны, наименование города, улицы и т.п. У других принято представлять адрес в виде: строка адреса 1, строка адрес 2, строка адреса 3. Как разрешить этот противоречие? Очень просто: 1) собраться разработчикам, аналитикам и решить, что адрес будет содержать такие-то реквизиты 2) оформить это решение в виде документа и 3) утвердить в качестве стандарта.

                              То, что какой-то разработчик описал в XML-схеме адрес так как он захотел ничего не значит. Нужно оформить эту схему в виде документа, согласовать и утвердить.
                • 0
                  Я, как раз, постарался уйти он «модности» и перевести на конкретику.
                  Мой главный пойнт: время таких стандартов ушло. Если вы давите современному программисту разработать систему для интеграции госпиталя, к примеру, то архитектура этой интеграции будет построена на неявной сериализации/десериализации, на поинт-то-поинт интерфейсах, микросервисах. Потребности в чем-то подобном HL7 не возникнет. Зачем мучиться с подгонкой данных под эти безумные HL7 схемы, если можно просто перeдать те данные, которые есть у передающей стороны, и те данные, которые нужны принимающей стороне. Не нужны никакие специально созданные DTO.
                  • 0
                    Основная цель всех этих стандартов — это гармонизация данных. Чтобы какие-нибудь организации в Гондурасе и Австралии одинаково именовали элементы данных, одинаково понимали что за данные передаются или требуется передать. Это ради чего всё это делается. А то, что программист потратит 10 часов вместо 5 часов на реализацию какой-то фичи — это второстепенно и не играет особой роли. Основное время и деньги тут тратятся на совершенно другие вещи.
                    • 0
                      Вот мы и пришли к тому, что из всего EDI стандарта (и подобных) нам нужны только *единые классификаторы*. Согласен, абсолютно и полностью.
                  • 0
                    Еще раз вернусь к вашему комментарию. Все упомянутые вами стандарты именно доменные стандары. Они описывают предметную область, играют роль своеобразных энциклопедий. Использовать схемы этих стандартов для передачи данных — это полное безумие. К сожалению, я вижу подобные попытки снова и снова. К примеру, работал в команде одной всеми извесной компании, которая использовала схемы OAGIS именно для этого. В результате… они хвалились, что у них один из самых больших в мире кластеров BizTalk Server. Ну хорошо. Но чтобы ввести пару доп.полей в передаваемые данные им понадобилось нанимать контракторов и ждать результата 3 месяца. В схемах OAGIS было 10К+ одних элементов, не считая атрибутов, уровень вложенности в иерархии доходил до 10. Чудвищная плата для того чтобы передать в лучшем случае сотню полей. Это — в очень спец.случае. Обычно много меньше.
                    У меня была спец технология только для поиска элементов внутри схем.
                    Это — как пример испльзования не подумав.
                    Кажется, что проще. Вот вам стандарт, вот в нем схема накладной. Блин, этож стандарт, умные люди его создавали, будем эту схему испльзовать.
                    • 0
                      Это всё техника. Например, есть модель данных Всемирной таможенной организации. В ней гигантские информационные пакеты с кучей полей на все случаи в жизни, как вы пишите. Есть, скажем, странные вещи. Но использовать её или нет — это не технический вопрос, а политический. 99% времени и денег уходит на работу аналитиков, а 1% — работа программистов. Не нравится эта модель? Ну, попробуйте сделать свою, попробуйте утвердить её в виде стандарта, попробуйте убедить перейти всех на вашу модель. В итоге вы придёте к тому, что нафиг весь этот геморой, нужен EDI значит будем использовать EDI.
                      • 0
                        Дык, не нужны эти 99% времени.
                        Современная модель уже давно существует.
                        Мы идем на сайт, скажем налогового управления, я смотрю, что мне надо заплатить. Плачу через сайт банка. Транзакция появляется на сайте налогового управления.
                        Где здесь EDI или нечто подобное? Нет никаких стандартных документов в этом документообороте. Есть немного полей, которые заполняются. Не гигантские модели. Налоговому управлению нужны эти поля? Зачем какой-то стандарт? Зачем что-то утверждать? Зачем кого-то убеждать?
                        Обмен только *необходимыми* данными. Вот и вся модель.
                        Посмотрите на то, чем мы реально сейчас пользуемся. Ежедневно мы заполняем кучи запросов, массу запросов. Ни один из этих документооборотов не требует от нас заполнить *стандартный* запрос.
                        • 0
                          А как банк и налоговая договорятся о формате сообщения? Налоговая будет договариваться с каждым банком отдельно? А если банкам нужно передавать сведения о платежах не только в налоговую, но и в ГИБДД или таможню? Банкам придется договариваться с ними тоже о формате уведомления?
                          • 0
                            Банк и налоговая договариваются элементарно. У налоговой есть готовые интерфейсы для банков. Банку надо подключиться и, скорее всего, заключить договор на обслуживание по этим интерфейсам. Налоговая здесь — хозяин интерфейсов.
                            Такая же ситуация с другими гос. службами.
                            Если предприятию надо подключиться к банку, тут уже банк хозяин. Он создает интерфейсы, которым надо следовать.
                            Чаще всего интерфейсы в виде SOAP сервиса, тогда скачиваешь с этого сервиса wsdl+xsd, генерируешь прокси классы на их основе и работай. Иногда интерфейсы в виде библиотек, API. Тебе дадут адрес, с которого ты их перекачаешь, вместе с инструкциями и примерами.
                            Не разу не встречал в подобных ситуациях требования работать по стандартам каким-нибудь.
                            Есть, конечно, совершенно безумные примеры, типа того же HIPAA. Конечно, под президентскую программу нашли самые большие деньги, самых дорогих подрядчиков. Кто же тут устоит от искушения выдоить все деньги, которые у президента есть? Сейчас с Америке все госпитали и клиники пытаются начать жить с этим. Пока получается плохо.
                            • 0
                              Согласен, если взаимодействуют две организации, то им не нужна 3-я организация, которая будет разрабатывать какие-то стандарты и т.п. Но если речь идёт о большом количестве участников, об отраслях, то без стандартов никак. Для примера, вот, XML-схемы ISO 20022. Вы действительно считаете, что этот стандарт — пустая трата денег и 2 банка как-нибудь сами между собой договорятся, сами сделают WSDL+XSD какие им нужны и всё?
                              • 0
                                Еще раз спасибо за интересную дискуссию! :)
                                Ответ на ваш вопрос: Да. (в 75-90% случаев)
                                Говоря о банковский схемах: Участвовал в подобном интеграционном проекте. Архитекторы долго выбирали стандарт. Выбрали. Хороший стандарт, все тонкости и взаимосвязи данных и сценариев учитывает. Одна беда: банки — консервативные организации. Стандары там не приживаются, т.к.каждый банк свою систему делает. Есть несколько универсальных пакетов, но они работают в основном в средних и маленьких банках. Большой банк просто не в силах перейти со своей уникальной системы на что-то другое. Чтобы перейти, ему надо закрыться на несколько лет.
                                В результате схема баз данных банка сильно отличается от схем стандарта.
                                После нескольких попыток с этим бороться решили стандарт использовать как справочник возможных сценариев. Для передачи данных все структуры запросов/ответов сделали сами. Проблем не было. Что надо — включали, чего надо — о том не парились.
                                Отвечая на ваш вопрос, пустая ли это трата денег? Честно говоря, не очень помогают, по описанной причине. Чем сложнее внутренняя система, кот.интегрируешь, тем меньше она подходит под стандарт, тем меньше пользы от стандарта. С другой стороны, для внедрения в маленьких банках эти стандарты чересчур сложные. Тоже не годятся.
                                Как результаты исследования предметной области эти стандарты как-то помогают в реальной жизни. Т.е.работают как справочники сценариев. Не больше и не меньше. В принципе это — полезная функция.
                                Использование этих стандартов для передачи данных, для интеграции систем — большое НЕТ.
                                • 0
                                  PS Почему так сложно использовать схемы стандартов?
                                  Пример из реальной жизни, из того же банковского проекта.
                                  Взяли самую популярную банковскую операцию. Попробовали сделать схему запроса из схемы, кот.имелась в стандарте. Около 5% полей запроса хорошо совпали с полями из стандартной схемы. Около 5% плохо совпали, т.е.мы имели жесткий мэппинг (когда термины так отличаются, что аналисты их просто не понимают в данном контексте). Еще около 5% полей в стандарте не было, даже с жестким мэппингом, их надо было добавлять. Станд.схема конечно имела поля для расширения, еще тот геморрой. Остальные (85%,) полей с стандартн.схеме нам не были нужны (многие удивятся, почему так много полей? Значит вы не имели дело с подобными стандартами. Схемы там просто громадные, в лучшем случае. В худшем — это набор взаимосвязанных схем, из которого песни не выкинешь.). Но не тут-то было. Часть из этих ненужных полей были required. Результат? Без модификации стандартной схемы было не обойтись. Вопрос, какой же тогда это стандарт, если мы, в результате, имеем свой уникальный запрос?
                                  • 0
                                    В общем-то я со многим согласен. Буквально на днях сравнивал два документа по разным стандартам. Пересечение было на 1/4, не хватало примерно 800 элементов, а пара тысяч элементов наоборот была избыточной. С разработкой и внедрением стандартов связано действительно очень много проблем и сложностей. Но тем интересней эта задача!

                                    Лично я гораздо больше занимался самими стандартами, чем их внедрением (невозможно заниматься всем). К последнему относился как к сугубо технической задаче. Мне конечно и раньше были знакомы все эти проблемы 1) гигантских суперструктур, с кучей лишних полей 2) чрезмерная сложность некоторых стандартов 3) сложность настройки под конкретные процессы. Но сейчас они проявились совершенно отчетливо. Об этом не принято что ли говорить, обычно говорят о том сколько денег сэкономит внедрение стандарта и на сколько он упростит жизнь. Спасибо за статью и обсуждение.
                                    • 0
                                      Для разработчика:
                                      Напоследок еще раз акцентирую следующую мысль:
                                      Для связи систем, их интеграции, для передачи данных между системами почти всегда можно обойтись небольшим кол-вом данных.

                                      Если приходится передавать большие структуры, то это скорее всего признак smelly code. Обязательно задайте вопрос: надо ли каждый раз передавать эти данные? Скорее всего большую часть данных можно загрузить в самом начале, а потом передавать только маленькие порции. Если надо азделите обмен на два этапа: «первоначальную загрузку» и «текущий обмен».

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.