On-Line Библиотека www.XServer.ru - учебники, книги, статьи, документация, нормативная литература.
       Главная         В избранное         Контакты        Карта сайта   
    Навигация XServer.ru








 

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

А.Календарев

      Введение


Сегодня, в сфере бизнеса создается и обрабатывается внушительный объем разнообразной бумажной документации. Она включает в себя разные заказы на приобретение, счета, инвойсы, каталоги, отчеты, платежные поручения и т.д. Внедрение транспортных протоколов в конце 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. изображена трехступенчатая схема реализации модели сообщения.

Схема Преобразования EDI в XML

Рис 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

пример Class CustomsDeclaration

Секции и подсекции в БМ могут быть разделены на категории по:

  • простым секциям, т.е секция которая не категоризируется по списку ролей и списку значений;
  • списку ролей - т.е секции содержат данные, являющимися именами ролей;
  • списку значений - т.е секции содержат данные термов специальных кодов значений.

Ниже приведен пример создания корневой секции сообщения 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 Автор постарается ответить на вопросы, связанные с изложенным материалом или осветить их в будущем.



  • Литература по XML