Создание единого глобального электронного рынка

2001 г

Создание единого глобального электронного рынка - проект ebXML

© А.Календарев.
Оригинал статьи находится на сайте, посвященном проблеме использования электронных документов - 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">
<!-BGM : 	Beginning of Message -->
<!ELEMENT 	MessageId (#PCDATA) >
<!ATTLIST 	MessageId
    UN-EDIFACT:Segment      CDATA   #FIXED      "BGM"
    UN-EDIFACT:Attributes   CDATA   #FIXED      "1001 MessageTypeCode
                                                1060 RevisionNo
                                                1225 MessageFunction
                                                4343 ResponseType"
    MessageTypeCode         CDATA   #FIXED      "CustomsDeclaration"
    RevisionNo              CDATA   #IMPLIED
    MessageFunction         (%Confirmation;     "Original"
    ResponseType            (%Response;)        "Accepted"
    Constraints             CDATA #FIXED        "an..35" >
____________________________________________________________________________

Подходя комплексно к моделированию всего сообщения, используются как информация из базовых сегментов, таких как 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">
<!- section B 4 Customs -->
<!ELEMENT    Customs               (CustomsIdentification,
                                    CustomsDetails) >
<!ELEMENT    CustomsIdentification (CustomsID                    ; код таможни
                                    CustomsRegion?,            ; регион деятельности таможни
                                    CustomsType?,              ; тип таможни
                                    CustomsPostName,           ; наименование тамж. Поста
                                    Address?)>               ; адрес поста
<!ELEMENT    CustomsID              (#PCDATA)>
<!ELEMENT    CustomsRegion          (#PCDATA)>
<!ELEMENT    CustomsIype            (#PCDATA)>               ; "destination", "departure","border"
<!ELEMENT    CustomsPostName        (#PCDATA)>
<!ELEMENT    CustomsDetalies      (DataTimeRegistration,      ; дата и время оформления
                                  TypeExamination?,           ; вид досмотра
                                  SealExamination?,           ; номер печати после досмотра
                                  InspectorName,              ; ФИО инспектора
                                  SealNumber,                 ; номер личной печати
                                  TextDetalies?) >            ; примечание
<!ELEMENT    DataTimeRegistration (Date,                      ; дата оформления
                                  Time?)                      ; время оформления
<!ELEMENT    TypeExamination      (#PCDATA)>
<!ELEMENT    SealExamination      (#PCDATA)>
<!ELEMENT    InspectorName        (#PCDATA)>
<!ELEMENT    SealNumber           (#PCDATA)>
<!ELEMENT    TextDetalies         (#PCDATA) >
<!ELEMENT    Address              (Province?,                 ; регион
                                   City,                       ; город
                                   Street?,                    ; улица
                                   HomeNumber?,                ; номер дома
                                   OfficeNumber?,              ; номер офиса
                                   Zip?)>                      ; почтовый индекс
<!ELEMENT      Date               (#PCDATA) >
<!ELEMENT      Time               (#PCDATA) >
<!ELEMENT      Province           (#PCDATA) >
<!ELEMENT      City               (#PCDATA) >
<!ELEMENT      Street             (#PCDATA) >
<!ELEMENT      HomeNumber         (#PCDATA) >
<!ELEMENT      OfficeNumber       (#PCDATA) >
<!ELEMENT      Zip                (#PCDATA) >

Заключение

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

По официальным данным CEFACT финансируется для работы над проектом ebXML до середины 2002 года. К этому моменту должны быть разработаны все спецификации и поданы предложения в группу стандартизации (ISO) при ООН.

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

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

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