Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Для трансляции(json/xml -> edi x12 -> json/xml) использовали bots, но он не универсальный и для каждого вендора приходится писать свой специфический транслятор в виде плагина.
В том-то и дело, что с EDI невозможно сгенерировать нормальный XML, JSON или объектный граф. Вот, к примеру, вручную сделанный граф объектов для одного EDI документа. Я его использовал в тестах сериализаторов для .NET. Очень сложный иерархический граф. В структуре EDI просто нет всей нужной разметки для всей этой иерархии, она вся подразумевается.
Я бы посмотрел исходную спецификацию, в которой описаны сообщения. Может быть даже есть какая-то модель данных для сообщений. И попробовал сгенерить из неё XML-схему и маппинги из EDI-сообщений в XML-сообщения. Или сгенерить код для объектной модели типа вашей.
Что это за сообщения? Они описаны где-то?
Что это за сообщения? Они описаны где-то?
Судя по номеру 835, похоже на Health Care Claim Payment/Advice. Нашёл только спецификацию, модель не нашёл. Остаётся видимо только вручную делать объектную модель. Или брать такие таблички из спецификации
переводить их в Excel, csv, xml,… формат.
И запилить генератор, который будет делать из них объектную модель. Чтобы вручную не писать весь этот код, наверное, так было бы проще.
переводить их в Excel, csv, xml,… формат.
И запилить генератор, который будет делать из них объектную модель. Чтобы вручную не писать весь этот код, наверное, так было бы проще.
Многие вещи я просто не стал касаться. К примеру, rules, своеобразная попытка зашить правила обработки документа в сам документ. Для них в XML просто нет однозначного эквивалента. С одной стороны, не знаю никого, кто их использует, с другой стороны, наверняка кто-то использует. Им можно только посочувствовать.
У меня нет проблемы сгенерировать XML-схему. Я, наверное, нечетко объяснился, сорри. Я привел это для примера, что подразумеваемые структуры, не выделенные тэгами, невозможно выделить автоматически.
Согласен, не имея спецификацию сообщения, в нём не возможно ничего понять. В отличие от XML-документов, структура которых понятна даже без схемы и спецификации. И в целом с XML конечно проще работать, тут сложно поспорить. А есть же вроде всякие XMI/EDI или ASC X12 Context Inspired Component Architecture? Я с EDI дело особо не имел. В нашей области стандарты в основном уже более или менее синтаксически нейтральные или с уклоном в XML (CCTS, WCO DM, NIEM, ISO 20022 и т.п.).
Вполне можно понять почему он до сих пор используется… Просто на нём основано много стандартов. Большая часть из которых появилась до XML. И просто так всё переделывать из-за какого-то XML, который появился сравнительно недавно и даёт какие-то сугубо технические преимущества, видимо слишком дорого. Хотя на XML конечно потихоньку переходят. Тот же HL7v3, ISO 20022, UN/CEFACT CCTS и т.п.
Правда, нет гарантии, что лет через 10 не появится ещё какой-нибудь модный стандарт и все не начнут переползать на него. Наверное единственный способ защититься от переделывания всего при появлении новых технологий, это использование модельно-ориентированного подхода, о котором я пишу тут цикл статей :) Вообще, это наверное общий тренд сейчас в этой области. Взять тот же CCTS или ISO 20022 (любой более-менее современный стандарт) — везде предлагается описывать данные в платформо-независимом виде. И есть отдельная спецификация, в которой описано как сгенерить из платформо-независимой модели XML-схемы и т.п. Если появляется новая технология, то не нужно переделывать абсолютно всё, просто делаем новые маппинги из PIM в PSM.
А почему вам интересна эта тема?
Правда, нет гарантии, что лет через 10 не появится ещё какой-нибудь модный стандарт и все не начнут переползать на него. Наверное единственный способ защититься от переделывания всего при появлении новых технологий, это использование модельно-ориентированного подхода, о котором я пишу тут цикл статей :) Вообще, это наверное общий тренд сейчас в этой области. Взять тот же CCTS или ISO 20022 (любой более-менее современный стандарт) — везде предлагается описывать данные в платформо-независимом виде. И есть отдельная спецификация, в которой описано как сгенерить из платформо-независимой модели XML-схемы и т.п. Если появляется новая технология, то не нужно переделывать абсолютно всё, просто делаем новые маппинги из PIM в PSM.
А почему вам интересна эта тема?
Не совсем так, применение той или иной технологии обычно продиктовано бизнес потребностями компаний.
Начнем с базовых принципов. Для чего нам EDI.
EDI всегда использовался как электронный документооборот между компаниями и обеспечивал на бизнес уровне 2 вещи:
1. Гарантированную доставку данных;
2. Роль арбитра в спорах между компаниями (если сделки срываются из-за не доставленных либо не вовремя доставленных данных.
Но по различным причинам «частота» обмена данными в последнее время резко выросла, а плоские структуры больше подходят для неторопливого обмена «большими» порциями данных чем для высокочастотного обмена.
Именно это я считаю основной причиной перехода EDI провайдеров на XML/Json
И, имхо, EDIFact это ужасный формат с кучей не понятных своим смыслом полей, добавленных в стандарт по причине того, что несколько крупных компаний их используют.
Начнем с базовых принципов. Для чего нам EDI.
EDI всегда использовался как электронный документооборот между компаниями и обеспечивал на бизнес уровне 2 вещи:
1. Гарантированную доставку данных;
2. Роль арбитра в спорах между компаниями (если сделки срываются из-за не доставленных либо не вовремя доставленных данных.
Но по различным причинам «частота» обмена данными в последнее время резко выросла, а плоские структуры больше подходят для неторопливого обмена «большими» порциями данных чем для высокочастотного обмена.
Именно это я считаю основной причиной перехода EDI провайдеров на XML/Json
И, имхо, EDIFact это ужасный формат с кучей не понятных своим смыслом полей, добавленных в стандарт по причине того, что несколько крупных компаний их используют.
Полностью с вами согласен.
1. Гарантированная доставка сейчас обеспечивается массой протоколов совершенно другого уровня, чем EDI. Обеспечивать гарантированную доставку с помощью EDI сейчас — это и наивно, и опасно.
2. Это пока работает. Хотя на практике эта функция сильно зависит от реализации. К примеру, сгенерировала моя програма ack, послала его обратно отпавителю. А отправитель эти ack или хранит так, что их легко потерять, либо чистит раз в квартал. Дошло дело до разборов, отправитель говорит, что никакого ack нет. А то, что ты ему этот ACK предъявляешь… дык. Ты может его и отправлял, а я вот его не получал. Т.е.вступает в дело ack на ack на… Данная проблема решается в интернете вполне успешно. А EDI только делает вид, что решает эту проблему.
1. Гарантированная доставка сейчас обеспечивается массой протоколов совершенно другого уровня, чем EDI. Обеспечивать гарантированную доставку с помощью EDI сейчас — это и наивно, и опасно.
2. Это пока работает. Хотя на практике эта функция сильно зависит от реализации. К примеру, сгенерировала моя програма ack, послала его обратно отпавителю. А отправитель эти ack или хранит так, что их легко потерять, либо чистит раз в квартал. Дошло дело до разборов, отправитель говорит, что никакого ack нет. А то, что ты ему этот ACK предъявляешь… дык. Ты может его и отправлял, а я вот его не получал. Т.е.вступает в дело ack на ack на… Данная проблема решается в интернете вполне успешно. А EDI только делает вид, что решает эту проблему.
Да, EDI включал в себя очень много всего: протоколы, форматы и т.п. Сейчас появились лучшие протоколы, лучшие форматы. Но EDI этим не ограничивается. В первую очередь — это единые наборы элементов данных, единые структуры сообщений, единые классификаторы. Я по своему опыту знаю какая это титаническая работа. К тому же, они не дураки и давно есть XML-решения: CCTS, CCL, UBL и т.п.
К примеру, если я буду заменять EDI на любую сериализацию.
Что из перечисленного списка мне понадобится?
— единые наборы элементов данных и — единые структуры сообщений: вещь бесполезная. Если я использую какой-нибудь старенький SOAP, все эти наборы сгенерятся в виде xsd автоматом. Автоматом же на приемном конце получат эти схемы и сгенерят классы.
Те, кто получают данные, подключатся к ?wsdl адресу, автоматом получат эти схемы и сгенерируют классы. Проблема согласования структур решена.
— единые классификаторы: скорее всего это реальная потребность. Всем обменивающимся данными надо использовать единые классификаторы. Но, с другой стороны, эти коды не должны быть частью передаваемых сообщений или спецификаций предаваемых сообщений. Они должны быть в виде именно *единых* классификаторов. Т.е. комитет или организация, отвечающая за коды, должна вывешивать их, к примеру, в виде сервисов. Любой пользователь подключается и получает коды он-лайн. Т.е. классификаторы должны кому-то принадлежать. И уж точно не EDI (или подобному) комитету. Коды химич.составов — организациям, лицензирующим эти составы. Коды лекарств — тем, кто лицензирует лекарства (т.е. поддерживает базы кодов). А ЕDI комитет определяет структуру сообщений, а уж никак не коды лекарств.
Вы скажете, что по поводу кодов-классификаторов организаций, которые используются в кодах отправилеля и адресата в ISA сегменте? Я скажу, что подобные коды д.б.уничножены и забыты, как страшный сон.
Что из перечисленного списка мне понадобится?
— единые наборы элементов данных и — единые структуры сообщений: вещь бесполезная. Если я использую какой-нибудь старенький SOAP, все эти наборы сгенерятся в виде xsd автоматом. Автоматом же на приемном конце получат эти схемы и сгенерят классы.
Те, кто получают данные, подключатся к ?wsdl адресу, автоматом получат эти схемы и сгенерируют классы. Проблема согласования структур решена.
— единые классификаторы: скорее всего это реальная потребность. Всем обменивающимся данными надо использовать единые классификаторы. Но, с другой стороны, эти коды не должны быть частью передаваемых сообщений или спецификаций предаваемых сообщений. Они должны быть в виде именно *единых* классификаторов. Т.е. комитет или организация, отвечающая за коды, должна вывешивать их, к примеру, в виде сервисов. Любой пользователь подключается и получает коды он-лайн. Т.е. классификаторы должны кому-то принадлежать. И уж точно не EDI (или подобному) комитету. Коды химич.составов — организациям, лицензирующим эти составы. Коды лекарств — тем, кто лицензирует лекарства (т.е. поддерживает базы кодов). А ЕDI комитет определяет структуру сообщений, а уж никак не коды лекарств.
Вы скажете, что по поводу кодов-классификаторов организаций, которые используются в кодах отправилеля и адресата в ISA сегменте? Я скажу, что подобные коды д.б.уничножены и забыты, как страшный сон.
Т.е. классификаторы должны кому-то принадлежать. И уж точно не EDI (или подобному) комитету. Коды химич.составов — организациям, лицензирующим эти составы. Коды лекарств — тем, кто лицензирует лекарства (т.е. поддерживает базы кодов).Ну, да, а если эти организации по какой-то причине не сделали нужный классификатор, то напишем им гневное письмо: ну-ка быстро запилили нам классификатор, это ваша обязанность :) Например, 19 или 21 рекомендации (виды транспорта, упаковок).
единые наборы элементов данных и — единые структуры сообщений: вещь бесполезнаяДопустим, вы передаёте сведения о какой-нибудь товарной партии. Как вы назовёте эту сущность «Партия товаров», «Товарная партия» или ещё как-то? А её содержимое: «Единица товарной партии», «Товар», «Товарная позиция», «Сведения о товаре»? Отправителя: «Отправитель», «Грузоотправитель», «Отправитель груза»? Сведения об отправителе вы вложите внутрь сведений о товарной партии или на тот же уровень? Какие сведения об отправителе будете передавать: полное и краткое наименование организации или достаточно только полного. А какая максимальная длина для наименования? 100, 200, 300, 500 символов? А если отправитель — это физическое лицо, то его ФИО вы будете передавать в поле «Полное наименование» или в отдельных полях «Фамилия», «Имя», «Отчество»? А какие из этих полей вы сделаете обязательными? А что если в некоторых странах нет фамилий и т.п.
Таких вопросов миллион.
Допустим, в вашей организации есть какие-то нормативные документы, в которых описано как всё это должно называться, структурироваться и т.п. Ну, а в другой организации свои нормативные документы, и, вообще, она находится в другой стране с другим законодательством. Вы представляете сколько нужно человековеков, чтобы создать единый реестр элементов данных?
@Ares-ekb: прежде всего, спасибо за плодотворную дискуссию!
Согласен с вами полностью.
Классификаторы играют несколько ролей:
* лицензирование. Налоги, лекарства, опасные вещества… Если лицензирующая организация не поддерживает классификаторы в нужном порядке, она, скорее всего, и будет отвечать за коды, невовремя опубликованные, невовремя доведенные до пользователя. Пользователи должны следовать этим кодам.
* стандартные размеры, разъемы, допуска. Тут никто обычно не отвечает рублем. Комитеты публикуют коды, стандартные числа. Все, кто хочет им следовать, — следует.
* общая терминология. Здесь термины — «непротивление двух сторон». Никого, кроме отправителя и адресата не волнует, как вы там договоритесь насчет общей терминологии, максимальных значений, типов данных и т.п. Здесь как раз wsdl или swagger делают все согласования автоматическими. *Автоматически*. *все* согласования. Как раз в этой области EDI и подобные стандарты пытаются навести порядок, ввести
Согласен с вами полностью.
Классификаторы играют несколько ролей:
* лицензирование. Налоги, лекарства, опасные вещества… Если лицензирующая организация не поддерживает классификаторы в нужном порядке, она, скорее всего, и будет отвечать за коды, невовремя опубликованные, невовремя доведенные до пользователя. Пользователи должны следовать этим кодам.
* стандартные размеры, разъемы, допуска. Тут никто обычно не отвечает рублем. Комитеты публикуют коды, стандартные числа. Все, кто хочет им следовать, — следует.
* общая терминология. Здесь термины — «непротивление двух сторон». Никого, кроме отправителя и адресата не волнует, как вы там договоритесь насчет общей терминологии, максимальных значений, типов данных и т.п. Здесь как раз wsdl или swagger делают все согласования автоматическими. *Автоматически*. *все* согласования. Как раз в этой области EDI и подобные стандарты пытаются навести порядок, ввести
единые наборы элементов данных и — единые структуры сообщений. И именно этот порядок, эти *единые реестры элементов данных* — это прошлый век, рудименты социализма.
Допустим, тот же пример с банком и налоговой. Налоговая запилила WSDL, в котором описана служба TransactionAckReceiver, которая может принимать уведомления об оплате с определенной XML-схемой.
Банковая ИС смотрит этот WSDL. Она не сможет автоматически понять, что уведомление об оплате нужно отправлять именно службе TransactionAckReceiver, а не какой-то другой. Банку и налоговой нужно предварительно договориться, что эта служба должна называться именно так. Это не происходит автоматически без участия человека.
Затем, налоговая в XML-схеме уведомления сделала обязательный элемент «код бюджетной классификации платежа», а ФИО плательщика описала в виде 3-х отдельных элементов: фамилия, имя и отчество. Причем, фамилия — обязательный элемент.
Какой-нибудь исландский банк пытается отправить в нашу налоговую уведомление об оплате. У него есть WSDL, XSD. Но это никак не поможет ему заполнить поле «код бюджетной классификации», ну, потому что в их ИС это поле просто не предусмотрено, не откуда взять этот код. И никак не поможет ему заполнить обязательное поле «фамилия», потому что у исландцев нет фамилий.
Эти согласования не могут быть сделаны автоматически. Сначала должны договориться чиновники о том, что в принципе такое взаимодействие между банками и налоговой должно быть. На реализацию всего этого должны быть выделены деньги. Потом аналитики, предметники (банковские и налоговики) читают нормативные документы, плотно общаются друг с другом. Пока не договорятся о том должна быть фамилия обязательным элементом или нет. Фиксируют все свои договоренности в виде документов, которые утверждаются чиновниками. И только после этого программисты начинают пилить свои WSDL, XSD и т.п. Причём, набор элементов данных, правила их именования, заполнения и т.п. программисты воспринимают как само собой разумеющееся. Хотя на это-то как-раз и ушла основная часть времени и денег. Реализовать теперь всё это теперь в синтаксисе EDI, XML, JSON или чём-то ещё — это дело техники.
Ценность EDI как-раз в том, что там уже пройден весь этот путь для разных видов сообщений. Чиновники, крупный бизнес договорились о том, что сообщения должны быть такие-то. В них должно передаваться то-то. То, что синтаксис EDI не очень, ну, это печально, но не на столько, чтобы тратить деньги на переход на XML. Синтаксис — это уже незначительные технические детали. Которые конечно нужно совершенствовать, и это делается, но медленно, потому что затраты на этот переход очевидны, а существенный положительный эффект не очень очевиден.
Банковая ИС смотрит этот WSDL. Она не сможет автоматически понять, что уведомление об оплате нужно отправлять именно службе TransactionAckReceiver, а не какой-то другой. Банку и налоговой нужно предварительно договориться, что эта служба должна называться именно так. Это не происходит автоматически без участия человека.
Затем, налоговая в XML-схеме уведомления сделала обязательный элемент «код бюджетной классификации платежа», а ФИО плательщика описала в виде 3-х отдельных элементов: фамилия, имя и отчество. Причем, фамилия — обязательный элемент.
Какой-нибудь исландский банк пытается отправить в нашу налоговую уведомление об оплате. У него есть WSDL, XSD. Но это никак не поможет ему заполнить поле «код бюджетной классификации», ну, потому что в их ИС это поле просто не предусмотрено, не откуда взять этот код. И никак не поможет ему заполнить обязательное поле «фамилия», потому что у исландцев нет фамилий.
Эти согласования не могут быть сделаны автоматически. Сначала должны договориться чиновники о том, что в принципе такое взаимодействие между банками и налоговой должно быть. На реализацию всего этого должны быть выделены деньги. Потом аналитики, предметники (банковские и налоговики) читают нормативные документы, плотно общаются друг с другом. Пока не договорятся о том должна быть фамилия обязательным элементом или нет. Фиксируют все свои договоренности в виде документов, которые утверждаются чиновниками. И только после этого программисты начинают пилить свои WSDL, XSD и т.п. Причём, набор элементов данных, правила их именования, заполнения и т.п. программисты воспринимают как само собой разумеющееся. Хотя на это-то как-раз и ушла основная часть времени и денег. Реализовать теперь всё это теперь в синтаксисе EDI, XML, JSON или чём-то ещё — это дело техники.
Ценность EDI как-раз в том, что там уже пройден весь этот путь для разных видов сообщений. Чиновники, крупный бизнес договорились о том, что сообщения должны быть такие-то. В них должно передаваться то-то. То, что синтаксис EDI не очень, ну, это печально, но не на столько, чтобы тратить деньги на переход на XML. Синтаксис — это уже незначительные технические детали. Которые конечно нужно совершенствовать, и это делается, но медленно, потому что затраты на этот переход очевидны, а существенный положительный эффект не очень очевиден.
Проблема с TransactionAckReceiver:
Конечно, WSDL не может добавить документацию к набору xsd, поэтому в вашем примере банк где-то должен прочитать, какие операции где использовать. И если схемы генерируются автоматом, то и в комментарии к схемам этого не добавишь. Увы, надо договариваться или вывесить описания на всем известном месте, что, кстати, обычно и делается. Но вот Swagger, тот уже может описания протоколов добавлять, в нем этой проблемы нет.
фамилия — обязательный элементНу не знаю. optional or not — это все генерируется в схему автоматом. Enum — тоже автоматом.
И никак не поможет ему заполнить обязательное поле «фамилия», потому что у исландцев нет фамилий.И как EDI здесь поможет? Это ж типичная проблема, которая затрагивает только вот этот сценарий. И добавлять этот сценарий в стандарт, чтобы для всех будущих поколений эта проблема была уже решена? Нет. Стандарт — это прежде всего набор обобщений. Если стандарт — это набор уточнений, то грош цена этому стандарту. Уточнения должны решаться на нижних уровнях. Пусть предприятия сами договариваются между собою о форматах, если они решили свои детали, которые нигде больше не появляются, добавить в коммуникации.
Сначала должны договориться чиновники о том, что в принципе такое взаимодействие между банками и налоговой должно быть.— да. Это типичная «лицензированная» классификация, если так можно ее назвать. Все кому надо, договорились. Потом (или сразу же) кто-то один объявляется главным и хозяином этой классификации/лицензии.
Таких классификаций немного, не надо преувеличивать их количество. Большая часть кодов/классификаций никого не интересует. К примеру в EDI, код отправителя, на моей памяти, почти всегда выбирают ZZ ( все остальное). Т.е. никто почти этот код не использует.
Банку и налоговой нужно предварительно договориться
Отвечу на ваш вопрос немножко с другого конца:
Да, им надо договориться. Организационно это может выглядеть очень сложно, просто сложно, просто или очень просто.
Технически сейчас это сделать очень просто всегда. Сделать с нуля структуру сообщения сейчас очень просто. Сделать код для обработки сообщения с известной структурой тоже очень просто. Стандарт для, к примеру, платежки никому не нужен, т.к. на этом времени не съэкономишь, а совсем надоборот, потеряешь.
В результате всем проще делать оригинальные структуры сообщений под каждый отдельный случай. Стандартные структуры сообщений не помогают. Кто определяет сообщение, тот его и изобретает. И технически делает это просто, быстро, дешево. Подгонять свои данные под какие-то обобщенные стандарты стоит времени и денег, поэтому это никому не нужно.
Если EDI, или подобные стандарты используются, то только потому что кто-то из общающихся партнеров настаивает на этом. Чиновникам и бизнесу совершенно неважно в каком стандарте передаются данные, они мыслят в других категориях.
Важно ли, чтобы форматы данных на уровне полей были стандартными? К примеру, чтобы ИНН было в нужном формате? Скорее всего. И это тоже технически сейас решается просто и быстро.
Сделать 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-схеме адрес так как он захотел ничего не значит. Нужно оформить эту схему в виде документа, согласовать и утвердить.
Насчет того, что стандарты никому не нужны не могу согласиться. В конце концов, те же 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-схеме адрес так как он захотел ничего не значит. Нужно оформить эту схему в виде документа, согласовать и утвердить.
Я, как раз, постарался уйти он «модности» и перевести на конкретику.
Мой главный пойнт: время таких стандартов ушло. Если вы давите современному программисту разработать систему для интеграции госпиталя, к примеру, то архитектура этой интеграции будет построена на неявной сериализации/десериализации, на поинт-то-поинт интерфейсах, микросервисах. Потребности в чем-то подобном HL7 не возникнет. Зачем мучиться с подгонкой данных под эти безумные HL7 схемы, если можно просто перeдать те данные, которые есть у передающей стороны, и те данные, которые нужны принимающей стороне. Не нужны никакие специально созданные DTO.
Мой главный пойнт: время таких стандартов ушло. Если вы давите современному программисту разработать систему для интеграции госпиталя, к примеру, то архитектура этой интеграции будет построена на неявной сериализации/десериализации, на поинт-то-поинт интерфейсах, микросервисах. Потребности в чем-то подобном HL7 не возникнет. Зачем мучиться с подгонкой данных под эти безумные HL7 схемы, если можно просто перeдать те данные, которые есть у передающей стороны, и те данные, которые нужны принимающей стороне. Не нужны никакие специально созданные DTO.
Основная цель всех этих стандартов — это гармонизация данных. Чтобы какие-нибудь организации в Гондурасе и Австралии одинаково именовали элементы данных, одинаково понимали что за данные передаются или требуется передать. Это ради чего всё это делается. А то, что программист потратит 10 часов вместо 5 часов на реализацию какой-то фичи — это второстепенно и не играет особой роли. Основное время и деньги тут тратятся на совершенно другие вещи.
Еще раз вернусь к вашему комментарию. Все упомянутые вами стандарты именно доменные стандары. Они описывают предметную область, играют роль своеобразных энциклопедий. Использовать схемы этих стандартов для передачи данных — это полное безумие. К сожалению, я вижу подобные попытки снова и снова. К примеру, работал в команде одной всеми извесной компании, которая использовала схемы OAGIS именно для этого. В результате… они хвалились, что у них один из самых больших в мире кластеров BizTalk Server. Ну хорошо. Но чтобы ввести пару доп.полей в передаваемые данные им понадобилось нанимать контракторов и ждать результата 3 месяца. В схемах OAGIS было 10К+ одних элементов, не считая атрибутов, уровень вложенности в иерархии доходил до 10. Чудвищная плата для того чтобы передать в лучшем случае сотню полей. Это — в очень спец.случае. Обычно много меньше.
У меня была спец технология только для поиска элементов внутри схем.
Это — как пример испльзования не подумав.
Кажется, что проще. Вот вам стандарт, вот в нем схема накладной. Блин, этож стандарт, умные люди его создавали, будем эту схему испльзовать.
У меня была спец технология только для поиска элементов внутри схем.
Это — как пример испльзования не подумав.
Кажется, что проще. Вот вам стандарт, вот в нем схема накладной. Блин, этож стандарт, умные люди его создавали, будем эту схему испльзовать.
Это всё техника. Например, есть модель данных Всемирной таможенной организации. В ней гигантские информационные пакеты с кучей полей на все случаи в жизни, как вы пишите. Есть, скажем, странные вещи. Но использовать её или нет — это не технический вопрос, а политический. 99% времени и денег уходит на работу аналитиков, а 1% — работа программистов. Не нравится эта модель? Ну, попробуйте сделать свою, попробуйте утвердить её в виде стандарта, попробуйте убедить перейти всех на вашу модель. В итоге вы придёте к тому, что нафиг весь этот геморой, нужен EDI значит будем использовать EDI.
Дык, не нужны эти 99% времени.
Современная модель уже давно существует.
Мы идем на сайт, скажем налогового управления, я смотрю, что мне надо заплатить. Плачу через сайт банка. Транзакция появляется на сайте налогового управления.
Где здесь EDI или нечто подобное? Нет никаких стандартных документов в этом документообороте. Есть немного полей, которые заполняются. Не гигантские модели. Налоговому управлению нужны эти поля? Зачем какой-то стандарт? Зачем что-то утверждать? Зачем кого-то убеждать?
Обмен только *необходимыми* данными. Вот и вся модель.
Посмотрите на то, чем мы реально сейчас пользуемся. Ежедневно мы заполняем кучи запросов, массу запросов. Ни один из этих документооборотов не требует от нас заполнить *стандартный* запрос.
Современная модель уже давно существует.
Мы идем на сайт, скажем налогового управления, я смотрю, что мне надо заплатить. Плачу через сайт банка. Транзакция появляется на сайте налогового управления.
Где здесь EDI или нечто подобное? Нет никаких стандартных документов в этом документообороте. Есть немного полей, которые заполняются. Не гигантские модели. Налоговому управлению нужны эти поля? Зачем какой-то стандарт? Зачем что-то утверждать? Зачем кого-то убеждать?
Обмен только *необходимыми* данными. Вот и вся модель.
Посмотрите на то, чем мы реально сейчас пользуемся. Ежедневно мы заполняем кучи запросов, массу запросов. Ни один из этих документооборотов не требует от нас заполнить *стандартный* запрос.
А как банк и налоговая договорятся о формате сообщения? Налоговая будет договариваться с каждым банком отдельно? А если банкам нужно передавать сведения о платежах не только в налоговую, но и в ГИБДД или таможню? Банкам придется договариваться с ними тоже о формате уведомления?
Банк и налоговая договариваются элементарно. У налоговой есть готовые интерфейсы для банков. Банку надо подключиться и, скорее всего, заключить договор на обслуживание по этим интерфейсам. Налоговая здесь — хозяин интерфейсов.
Такая же ситуация с другими гос. службами.
Если предприятию надо подключиться к банку, тут уже банк хозяин. Он создает интерфейсы, которым надо следовать.
Чаще всего интерфейсы в виде SOAP сервиса, тогда скачиваешь с этого сервиса wsdl+xsd, генерируешь прокси классы на их основе и работай. Иногда интерфейсы в виде библиотек, API. Тебе дадут адрес, с которого ты их перекачаешь, вместе с инструкциями и примерами.
Не разу не встречал в подобных ситуациях требования работать по стандартам каким-нибудь.
Есть, конечно, совершенно безумные примеры, типа того же HIPAA. Конечно, под президентскую программу нашли самые большие деньги, самых дорогих подрядчиков. Кто же тут устоит от искушения выдоить все деньги, которые у президента есть? Сейчас с Америке все госпитали и клиники пытаются начать жить с этим. Пока получается плохо.
Такая же ситуация с другими гос. службами.
Если предприятию надо подключиться к банку, тут уже банк хозяин. Он создает интерфейсы, которым надо следовать.
Чаще всего интерфейсы в виде SOAP сервиса, тогда скачиваешь с этого сервиса wsdl+xsd, генерируешь прокси классы на их основе и работай. Иногда интерфейсы в виде библиотек, API. Тебе дадут адрес, с которого ты их перекачаешь, вместе с инструкциями и примерами.
Не разу не встречал в подобных ситуациях требования работать по стандартам каким-нибудь.
Есть, конечно, совершенно безумные примеры, типа того же HIPAA. Конечно, под президентскую программу нашли самые большие деньги, самых дорогих подрядчиков. Кто же тут устоит от искушения выдоить все деньги, которые у президента есть? Сейчас с Америке все госпитали и клиники пытаются начать жить с этим. Пока получается плохо.
Согласен, если взаимодействуют две организации, то им не нужна 3-я организация, которая будет разрабатывать какие-то стандарты и т.п. Но если речь идёт о большом количестве участников, об отраслях, то без стандартов никак. Для примера, вот, XML-схемы ISO 20022. Вы действительно считаете, что этот стандарт — пустая трата денег и 2 банка как-нибудь сами между собой договорятся, сами сделают WSDL+XSD какие им нужны и всё?
Еще раз спасибо за интересную дискуссию! :)
Ответ на ваш вопрос: Да. (в 75-90% случаев)
Говоря о банковский схемах: Участвовал в подобном интеграционном проекте. Архитекторы долго выбирали стандарт. Выбрали. Хороший стандарт, все тонкости и взаимосвязи данных и сценариев учитывает. Одна беда: банки — консервативные организации. Стандары там не приживаются, т.к.каждый банк свою систему делает. Есть несколько универсальных пакетов, но они работают в основном в средних и маленьких банках. Большой банк просто не в силах перейти со своей уникальной системы на что-то другое. Чтобы перейти, ему надо закрыться на несколько лет.
В результате схема баз данных банка сильно отличается от схем стандарта.
После нескольких попыток с этим бороться решили стандарт использовать как справочник возможных сценариев. Для передачи данных все структуры запросов/ответов сделали сами. Проблем не было. Что надо — включали, чего надо — о том не парились.
Отвечая на ваш вопрос, пустая ли это трата денег? Честно говоря, не очень помогают, по описанной причине. Чем сложнее внутренняя система, кот.интегрируешь, тем меньше она подходит под стандарт, тем меньше пользы от стандарта. С другой стороны, для внедрения в маленьких банках эти стандарты чересчур сложные. Тоже не годятся.
Как результаты исследования предметной области эти стандарты как-то помогают в реальной жизни. Т.е.работают как справочники сценариев. Не больше и не меньше. В принципе это — полезная функция.
Использование этих стандартов для передачи данных, для интеграции систем — большое НЕТ.
Ответ на ваш вопрос: Да. (в 75-90% случаев)
Говоря о банковский схемах: Участвовал в подобном интеграционном проекте. Архитекторы долго выбирали стандарт. Выбрали. Хороший стандарт, все тонкости и взаимосвязи данных и сценариев учитывает. Одна беда: банки — консервативные организации. Стандары там не приживаются, т.к.каждый банк свою систему делает. Есть несколько универсальных пакетов, но они работают в основном в средних и маленьких банках. Большой банк просто не в силах перейти со своей уникальной системы на что-то другое. Чтобы перейти, ему надо закрыться на несколько лет.
В результате схема баз данных банка сильно отличается от схем стандарта.
После нескольких попыток с этим бороться решили стандарт использовать как справочник возможных сценариев. Для передачи данных все структуры запросов/ответов сделали сами. Проблем не было. Что надо — включали, чего надо — о том не парились.
Отвечая на ваш вопрос, пустая ли это трата денег? Честно говоря, не очень помогают, по описанной причине. Чем сложнее внутренняя система, кот.интегрируешь, тем меньше она подходит под стандарт, тем меньше пользы от стандарта. С другой стороны, для внедрения в маленьких банках эти стандарты чересчур сложные. Тоже не годятся.
Как результаты исследования предметной области эти стандарты как-то помогают в реальной жизни. Т.е.работают как справочники сценариев. Не больше и не меньше. В принципе это — полезная функция.
Использование этих стандартов для передачи данных, для интеграции систем — большое НЕТ.
PS Почему так сложно использовать схемы стандартов?
Пример из реальной жизни, из того же банковского проекта.
Взяли самую популярную банковскую операцию. Попробовали сделать схему запроса из схемы, кот.имелась в стандарте. Около 5% полей запроса хорошо совпали с полями из стандартной схемы. Около 5% плохо совпали, т.е.мы имели жесткий мэппинг (когда термины так отличаются, что аналисты их просто не понимают в данном контексте). Еще около 5% полей в стандарте не было, даже с жестким мэппингом, их надо было добавлять. Станд.схема конечно имела поля для расширения, еще тот геморрой. Остальные (85%,) полей с стандартн.схеме нам не были нужны (многие удивятся, почему так много полей? Значит вы не имели дело с подобными стандартами. Схемы там просто громадные, в лучшем случае. В худшем — это набор взаимосвязанных схем, из которого песни не выкинешь.). Но не тут-то было. Часть из этих ненужных полей были required. Результат? Без модификации стандартной схемы было не обойтись. Вопрос, какой же тогда это стандарт, если мы, в результате, имеем свой уникальный запрос?
Пример из реальной жизни, из того же банковского проекта.
Взяли самую популярную банковскую операцию. Попробовали сделать схему запроса из схемы, кот.имелась в стандарте. Около 5% полей запроса хорошо совпали с полями из стандартной схемы. Около 5% плохо совпали, т.е.мы имели жесткий мэппинг (когда термины так отличаются, что аналисты их просто не понимают в данном контексте). Еще около 5% полей в стандарте не было, даже с жестким мэппингом, их надо было добавлять. Станд.схема конечно имела поля для расширения, еще тот геморрой. Остальные (85%,) полей с стандартн.схеме нам не были нужны (многие удивятся, почему так много полей? Значит вы не имели дело с подобными стандартами. Схемы там просто громадные, в лучшем случае. В худшем — это набор взаимосвязанных схем, из которого песни не выкинешь.). Но не тут-то было. Часть из этих ненужных полей были required. Результат? Без модификации стандартной схемы было не обойтись. Вопрос, какой же тогда это стандарт, если мы, в результате, имеем свой уникальный запрос?
В общем-то я со многим согласен. Буквально на днях сравнивал два документа по разным стандартам. Пересечение было на 1/4, не хватало примерно 800 элементов, а пара тысяч элементов наоборот была избыточной. С разработкой и внедрением стандартов связано действительно очень много проблем и сложностей. Но тем интересней эта задача!
Лично я гораздо больше занимался самими стандартами, чем их внедрением (невозможно заниматься всем). К последнему относился как к сугубо технической задаче. Мне конечно и раньше были знакомы все эти проблемы 1) гигантских суперструктур, с кучей лишних полей 2) чрезмерная сложность некоторых стандартов 3) сложность настройки под конкретные процессы. Но сейчас они проявились совершенно отчетливо. Об этом не принято что ли говорить, обычно говорят о том сколько денег сэкономит внедрение стандарта и на сколько он упростит жизнь. Спасибо за статью и обсуждение.
Лично я гораздо больше занимался самими стандартами, чем их внедрением (невозможно заниматься всем). К последнему относился как к сугубо технической задаче. Мне конечно и раньше были знакомы все эти проблемы 1) гигантских суперструктур, с кучей лишних полей 2) чрезмерная сложность некоторых стандартов 3) сложность настройки под конкретные процессы. Но сейчас они проявились совершенно отчетливо. Об этом не принято что ли говорить, обычно говорят о том сколько денег сэкономит внедрение стандарта и на сколько он упростит жизнь. Спасибо за статью и обсуждение.
Для разработчика:
Напоследок еще раз акцентирую следующую мысль:
Если приходится передавать большие структуры, то это скорее всего признак smelly code. Обязательно задайте вопрос: надо ли каждый раз передавать эти данные? Скорее всего большую часть данных можно загрузить в самом начале, а потом передавать только маленькие порции. Если надо азделите обмен на два этапа: «первоначальную загрузку» и «текущий обмен».
Напоследок еще раз акцентирую следующую мысль:
Для связи систем, их интеграции, для передачи данных между системами почти всегда можно обойтись небольшим кол-вом данных.
Если приходится передавать большие структуры, то это скорее всего признак smelly code. Обязательно задайте вопрос: надо ли каждый раз передавать эти данные? Скорее всего большую часть данных можно загрузить в самом начале, а потом передавать только маленькие порции. Если надо азделите обмен на два этапа: «первоначальную загрузку» и «текущий обмен».
Сейчас есть документооборот на флешках «ответственным сотрудником банка». И еще множество вариантов доставки документов «не интернетом». Все это работает до сих пор и EDI это умеет и стандартизует роутинг и авторизацию. Вероятно потому, что все не ограничивается интернетом единым он существует до сих пор… если забыть о легаси и переделке и стоимости этого всего.
Метод доставки сообщения ("ручной", интернетом,..) мало влияет не формат сообщения. Но если у вас действительно используются используются поля EDI сообщений для роуминга и авторизации, то это будет первый случай в моей практике :) Не рассказывайте только это знакомым хакерам, хотя вряд ли они будут это хакать. Слишком просто и примитивно все это взломать. Все равно, что у младеньца леденец отобрать.
Мы это конечно не пользуем, но оно могет и думаю где-то пользуют.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
EDI стандарт. Технический обзор