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 як і раніше широко використовується.

У наступній частині ми постараємося знайти цьому причини. Швидше за все вони будуть не технічного характеру.