Створення єдиного глобального електронного ринку – проект ebXML, HTML, XML, DHTML, Інтернет-технології, статті

www.edocs.al.ru, А.Календарев

Введення

Сьогодні, у сфері бізнесу створюється й обробляється значний обсяг різноманітної паперової документації. Вона включає в себе різні замовлення на придбання, рахунки, інвойси, каталоги, звіти, платіжні доручення і т.д. Впровадження транспортних протоколів у кінці 80-х років XX століття привело до стрімкого розвитку телекомунікацій і дало можливість відкриття воріт для електронної торгівлі та Електронного обміну даними (Electronic Data Interchange або EDI) Ідея систем EDI полягає в стандартизації документів та подання їх у вигляді, зручному для комп’ютерної обробки.

До середини 1980-х років в розробці стандарту EDI взяла участь Європейська економічна комісія ООН (UN / ECE) в особі Робочої групи N4 по спрощенню процедур міжнародної торгівлі (the working Party for the Facilitation of International Trade Procedures – WP.4). І в 1987 році синтаксичні правила нової мови були затверджені у вигляді міжнародного стандарту ISO 9735, відомого під абревіатурою UN/EDIFACT.

Акронім UN / EDIFACT розшифровується як “Правила ООН еелектронного обміну документами для гос. управління торгівлі та транспорту ” (United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport).

Електронний обмін документами (EDI – Electronic Data Interchange) накладає три основні вимоги:

Необхідно зауважити, що відмінність систем EDI від систем електронного документообігу полягає в тому, що EDI системи – це міжвідомчі системи обміну (подання) електронними документами, що використовують строго стандартизовані правила складання електронних документів. Під системою електронного документообігу розуміється системи, як правило, розробляються в рамках однієї корпорації або підприємства, обмін в яких здійснюється за коштами розподілених СУБД (RMDB).

Бурхливий розвиток Internet-технологій за останнє п’ятиріччя втягнуло в міжнародну електронну павутину мільйони нових користувачів. З’явилися нові протоколи обміну, змінилися вимоги і вже раніше впроваджені EDI системи перестали задовольняти багато груп користувачів. В даний час організацією CEFACT (the United Nations Centre for the Facilitation of Procedures and Practices for Administration, Commerce and Transport – Центр по спрощенню процедур і практики в управлінні, торгівлі та на транспорті) при ООН реалізується проект ebXML – “Створення єдиного глобального електронного ринку”, який підтримується Організацією просування стандартів структурованої інформації (the Organization for the Advancement of Structured Information Standards) – OASIS. Акронім ebXML – XML for electronic bisiness тобто XML для електронного бізнесу. Концепція проекту При розробці проекту ebXML використовувалися такі основні принципи: просте, єдине і повсюдне використання ebXML в електронному бізнесі; використання специфікацій XML в максимально можливих межах; забезпечення відкритими стандартами електронної торгівлі: B2B (business to business) і НД (business to Customer); об’єднання структури та змісту компонентів розходяться XML ініціатив в єдиний XML бізнес стандарт; Мінімізація витрат при обміні додаток-додаток; забезпечення багатомовними підтримки; врахування національних і міжнародних правил торгівлі; врахування традіціональних принципів EDI на основі стандарту UN / EDIFACT. Робоча група створення глобального електронного ринку – ebXML працює в наступних напрямках, які виділені як самостійні проекти: Розробка загальної методології та основних компонентів; Розробка специфікацій технічної архітектури; Розробка специфікацій для Репосіторіев (Центр електронного бізнесу) Розробка специфікацій пакетів і маршрутизації; Моделювання бізнес процесів і створення служби повідомлень; На рис.1 представлено взаємодію основних компонентів ebXML при здійсненні бізнес-транзакцій. Рис 1.   Якась Компанія Х (Interprise Systems) веде електронний обмін з іншого Компанією Y через Центр електронного бізнесу – Репосіторій (Repository). Електронний бізнес здійснюється шляхом обміну між компаніями електронними бізнес-документами. Правила обміну при проведенні бізнес операцій контролюються спеціальною службою повідомлень, які будуються у відповідності з методологією бізнес процесів. У якості незалежного арбітра використовуються Центр електронного бізнесу, який є серцем інфраструктури і являє Репосіторій (сховище) та Регістр. За допомогою Реєстру визначається ставлення учасників обміну до бізнес об’єктів і метаданих. Регістр повинен мати сумісний механізм запитів до індексу Репосітарія допомогою API. В Репосіторіі зберігаються спільно використовувані в Інтернеті загальнодоступні словники, метадані про учасників інформаційного обміну та сценарії обміну. На рис.2 представлений один з варіантів обміну Електронними документами для компаній X і Y. Рис 2. Моделювання Елементів даних для Бізнес об’єктів. Основою введення електронного бізнесу є обмін електронними повідомленнями, на підставі яких здійснюються прийняття рішення щодо проведення операцій при торгових угодах. В якості базової структури повідомлення використовується досвід при створенні повідомлень стандарту UN / EDIFACT. В результаті моделювання необхідно отримати опису структури повідомлення у вигляді структури XML / DTD або XML-схеми. На рис 3. зображена триступенева схема реалізації моделі повідомлення. Рис 3. Крок 1 – Ручне перетворення в Бізнес модель (БМ) на основі використання Посібника з розробки повідомлень EDIFACT. При цьому перетворенні мається на увазі перенесення синтаксису елементів EDIFACT всіх специфікацій і виділення функціональної специфікації на зміст інформації і її структури. Крок 2 – Перетворення БМ в UML Модель повідомлень. Перетворення підтримується програмним комплексом моделювання UML, використовуються такий апарат як клас діаграм, клас списку атрибутів і т.д. Крок 3 – Створення відповідності Бізнес моделі XML / DTD та XML-схеми. Дане перетворення здійснюється спеціально розробленим програмним забезпеченням. Крок 4 – (Необов’язковий) Можливість запам’ятати образ UML Моделі повідомлення і створення домену транспортної моделі для використання накопиченого досвіду при розробці інших типів повідомлення. Точне відображення EDIFACT структури включає імена сегментів, складових та окремих елементів даних. Повідомлення UN / EDIFACT можна розібрати на наступні самостійні одиниці, вкладені одна в одну: Повідомлення Сегмент Елемент даних Клаліфікатор Здійснення ручного переносу (крок 1) структури сегмента повідомлення в терміни опису XML / DTD вимагає хорошого розуміння структури повідомлення і знання стандарту UN / EDIFACT. Нижче наведено приклад перетворення в DTD початкового сегмента повідомлення – BGM. Структура сегмента BGM відповідно до специфікації:
# Гр.ел. # Спр опис елемента даних зобов / необ формат
данн M / C даних
____________________________________________________________________________
010 C002 DOCUMENT/MESSAGE NAME C
1001 Document/message name, coded C an..3
1131 Code list qualifier C an..3
3055 Code list responsible agency, coded C an..3
1000 Document/message name C an..35
020 C106 DOCUMENT/MESSAGE IDENTIFICATION C
1004 Document/message number C an..35
1056 Version C an..9
1060 Revision number C an..6
030 1225 MESSAGE FUNCTION, CODED C an..3
040 4343 RESPONSE TYPE, CODED C an..3
____________________________________________________________________________ Таблиця 1 Перетворюючи сегмент повідомлення BGM, опускаючи невикористовувані клаліфікатори, ми отримаємо наступний вигляд DTD:

____________________________________________________________________________
<?xml version=”1.0″>

____________________________________________________________________________
  Підходячи комплексно до моделювання всього повідомлення, використовуються як інформація з базових сегментів, таких як NAD, RFF, DOC тощо, так і враховується їх семантика і місце розташування. При створенні Бізнес моделі використовуються наступні принципи: Бізнес модель розділена на наступні секції: реквізити повідомлення, сторони, митні відмітки, упаковка, товари, документи, коди; основні сегментні групи або сегменти кореневого рівня повинні відповідати секції БМ. терміни даних БМ можуть породжуватися з інших елементів даних EDIFACT або із значення кодів для певних елементів даних; підсекції бізнес моделі повинні бути засновані відповідно до потребами, розуміння бізнес операцій. Це не обов’язкові запропоновані структури складових елементів даних або групи сегментів; Використання терміну даних в БМ на рівні кодів даних сслилается на свю “концепцію коду” імена БМ повинні бути специфіковані достатнім для розуміння; в БМ використовувати смислову семантику, так наприклад таг, що описує перевозяться товари може іменуватися GoodItems дублювання імен неприпустимо. Перетворення Бізнес Модель в Модель повідомлень UML Модель повідомлень специфікована як тип повідомлення і складається з: класів повідомлень, атрибутів і відповідностей (асоціацій). Ці терми формально визначені в UML і представляють клас повідомлень, який є підклас формального класу UML. Ці терми використовують різні форми звичайного UML класу, тому що повідомлення може складатися з атрибутів форм одного або більше класів. Правило 1. Класи повідомлень повинні бути структурно ієрархічно взаємопов’язані. Кореневий клас завжди повинен бути визначений. Створюючи кореневої клас переважно йому дати ім’я БМ повідомлення, наприклад при моделюванні EDIFACT повідомлення CusDec (митна декларація), Класу переважно дати ім’я CustomDeclaration. Нижче зображено формальний UML клас – CustomDeclaration Секції та підсекції у БМ можуть бути розділені на категорії по: простим секціях, Тобто секція яка не категоризируются за списком ролей і списку значень; списку ролей – Т.е секції містять дані, які є іменами ролей; списку значень – Т.е секції містять дані термів спеціальних кодів значень. Нижче наведено приклад створення кореневої секції повідомлення CusDec. У таблиці прийняті такі скорочення: O = Optional / Необов’язковий DE = елемент даних довідника UN / EDIFACT R = Requred / Обов’язковий CL = значення зі списку кодів довідника D = Dependent / Залежний   Секція А – Message Information (інформація про повідомлення) Найменування терма, посилання на Елемент даних O/R/D Значення клаліфікатора, примітка Елемент даних клаліфікатор А 1 ідентифікація документа       A1-1 Document type coded R “914″ = Customs declaration CL 1001 – 335 A1-2 Document issue date R   CL 2005 – 137 A1-3 Customs procedure R 1 – export, 2 -import CL 8323 A1-4 Customs Declaration number R   CL 3035 – CM A1-5 Carrier booking number D Primary key, if not CU CL 1153 – BN A1-6 Invoice reference number D   CL 1101- 935 A1-7 Consignor reference number D Primary key, If not BN CL 1153 – CU A1-8 Reference to previous message D   CL 1153 – ACW A1-9 Message sender O For return purposes CL 3035 – MS A1-10 Message receiver O For on-distribution CL 3035 – MR A2 функції повідомлення     DE 1225 A2-1 Original D   CL 1225 – 9 A2-2 Replace D   CL 1225 – 5 A2-3 Cancellation D   CL 1225 – 1 A3 ідентифікація Edifact       A3-1 Message type O Fixed “CUSDEC” DE 0065 A3-2 Message type version O Fixed “ D” DE 0052 A3-3 Message type release O Fixed “98A” DE 0054 A3-4 Controlling agency O Fixed “UN” DE 0051 A3-5 MIG identity O Fixed “SE0023” DE 0057 A3-6 Message reference number O   DE 0062 Таблиця 2 Аналогічним чином будуються інші секції БМ. Правило 2. Створити клас повідомлень для кожної необов’язковою секції. Ім’я класу повідомлень повинно бути еквівалентно імені секції. Секція категорій списку ролей буде формуватися не з класу повідомлень, але ім’я ролі буде пізніше використовуватися при створенні відповідностей (асоціацій). Секція категорій списку значень повинна формуватися не з класу повідомлень, але пізніше вона буде використовуватися для створення атрибутів. При моделюванні простіше вибрати клас, якщо клас повідомлень буде мати один атрибут. Правило 3 (необов’язкове). Секція може бути перенесена, при дотриманні наступних умов: максимальна к-ть відповідностей = 1 (не повторюваних), і існує тільки одна батьківська асоціація. Перенесення між секціями міг би здійснюватися у вигляді ієрархічних рівнів, або дочірня секція переносилася б з її батьківського секцією. Правило 4. Створення єдиної асоціації (відповідності). Єдине відповідність створюється з повідомлення батьківського класу до дочірнього класу повідомлення при відсутності множинної посилальної. “Відповідність” в повідомлення має тільки один напрям – від батьківського класу до дочірнього. Можливо подання множинних відповідностей. Множинні відповідності записуються як Min..Max Наприклад по одній митної декларації можливо провести від одного до … (десяти) контейнерів. У цьому разі відповідності представиться як 0 .. 9. Множинність повинна описуватися в кінці дочірньої секції. Правило 5. Створення множинного відповідності. Множинні відповідності створюються для класу повідомлень, що включають підсекції категорії списку ролей. Кожне множинне відповідність дає своє ім’я ролі. Ім’я ролі визначається як ім’я терма даних в підсекції категорії списку ролей. Кожне ім’я ролі буде замінено дочірнім ім’ям класу, згенерованих в XML / DTD або схеми XML. Використання нотації UML “+” показує, що ім’я ролі має атрибут “public”. На малюнку нижче зображено альтернативне зображення UML моделі. Дана техніка моделювання може бути використана в основний моделі при моделюванні ролей. Однак вона не може бути використана при моделюванні самого повідомлення, т.к. спадкування збільшує комплексний рівень генерації описів тагов XML. Дані термів в секції можуть бути категорізірованни як: необов’язковий терм даних, ім’я ролі і значення коду (см таблицю 2). Возращаясь наприклад в таблиці 2 значення терма (Терм кодів) A1-3 (Customs procedure ) в довіднику кодів 8323 має значення 1- export і 2- import, значення CU для ролі A1-7 (Consignor reference number ) за довідником кодів 1153, а значення для даних A1-2 (Document issue date ) є датою прийняття документа (наприклад 12/12/2000). Правило 5. Створення атрибутів для термів даних і кодів значень. Атрибут створюється для кожного необов’язкового терма даних і розташовується в класі повідомлення, відповідного атрибуту секції. Секція, що складається з кодів значень, повинна бути перетворена в один атрибут, який завжди має значення відповідне списку кодів. Нижче наведено приклад для секції A3 “Ідентифікація EDIFACT повідомлення ” Коли атрибути створені, кількість властивостей може бути визначено на інформації з БМ. : тип даних; множинність; допустимі значення; бізнес правила; коментарі стандартні посилання. Тип даних використовується в створенні XML схеми і може мати допустимі значення відповідні визначення схеми XML. Множинність – використовується в створенні XML / DTD або схеми XML. Допускаються наступні два значення: 0 .. 1 – для необов’язкових (optional) атрибутів 1 .. 1 – для обов’язкових (Mandatory) атрибутів Допустимі значення використовують визначення одного або більше допустимих значень кодів атрибутів. Наприклад: Митний режим TypeDeclaration – 1 “export” , 2 “import” Вид перевезення EquipmentType- CN – контейнер, PL – палети; Ці значення завжди використовуються при створенні XML / DTD або схеми XML. Бізнес правила можуть бути визначені для більш складних залежностей в БМ. Хоча бізнес правила не використовуються при створенні XML / DTD або XML схеми. Коментарі про термі даних в БМ можуть бути скопійовані як коментарі атрибутів. Они будуть використані для документування. Стандартні посилання представляють унікальний ідентифікатор какточеку визначення стандартного атрибута тобто номер тега елемента даних UN / EDIFACT. Вони можуть бути використані для документування, а також і при створенні XML / DTD і схеми XML як альтернативних атрибут імені. Нижче на рис. 4 приведена Діаграма класів UML бізнес моделі повідомлення CusDec: Рис. 4 При автоматичної генерації з БМ в XML / DTD або XML схема використовується формальний алгоритм перетворення. Правила перетворення UML моделі в XML / DTD або схемі XML осуществляюстя у відповідності наступними правилами: Модель повідомлення XML/DTD XML Sсhema Ім’я класу кореневого повідомлення Ім’я кореневого елемента Ім’я типу кореневого елемента Ім’я ролі Ім’я елемента Ім’я типу елемента Множинне відповідність ?, *, +, (empty) Відповідність min та max Ім’я атрибута Ім’я елемента Ім’я типу елемента Тип даних атрибута – Тип даних або макс. довжина Атрибут множинності ?, (empty) Відповідність min та max Значення атрибутів допустимий список значень Допустимий список значень   При створенні XML / DTD або схеми XML БМ специфікується послідовно по секціях, починаючи з кореневої, і далі з підсекції і термів даних і повинні бути збережені в моделі повідомлення. Відповідності і атрибути повинні бути змодельовані в деякій послідовності. Це можливо тільки для атрибутів, виключаючи відповідності. Нижче наведено приклад XML / DTD, отриманий в результаті моделювання секції повідомлення Customs.
<?xml version=”1.0″>

; Адресу поста

; “destination”, “departure”,”border”

; Примітка

; Поштовий індекс

Висновок Хочеться відзначити, що в даній статті описана невелика частина проекту ebXML, що стосується теми моделювання повідомлення. Що відносно матеріалу, то планується продовжити дану тему, описавши систему управління повідомленнями. Більш детальна інформація про проект, включаючи основні вимоги до розробкиe і проекти специфікацій можна знайти на сайті www.ebxml.org.

За офіційними даними CEFACT фінансується для роботи над проектом ebXML до середини 2002 року. До цього моменту повинні бути розроблені всі специфікації і подані пропозиції до групи стандартизації (ISO) при ООН.

В даний час у робочій EDI-групою в обчислювального центру митних органів (ГНІВЦ ГТК) ведеться проект з прийому електронних документів в стандарті UN / EDIFACT (додатково разом з паперовими документами) в якості транзитних митних декларацій (Документа контролю доставки), а також досліджується можливість обміну XML повідомленнями, тому що у багатьох учасників ЗЕД не є власною EDI-системи. В цьому напрямку розробок проект ebXML є некіем орієнтиром для організації обміну.

Автор буде дуже вдячний за відгуки про актуальність теми, загальному змісті, як і стилі викладу, а також всім іншим коментарів, які допоможуть у подальшому покращити якість написання збірника статей та випуску книги висвітлює тему використання електронних документів.

Також автору буде цікаво дізнатися побажання читачів про висвітлення суміжних тем, пов’язаних з використанням електронних документів та електронної комерції. Свої коментарі та побажання прохання направляти на akalend@mail.ru Автор постарається відповісти на питання, пов’язані з викладеним матеріалом або висвітлити їх у майбутньому.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*