© А.Календарев.
Оригинал статьи находится на сайте, посвященном проблеме использования электронных документов - 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 работает в следующих направлениях, которые выделены как самостоятельные проекты:
На рис.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 и пр., так и учитывается их семантика и месторасположение.
При создании Бизнес модели используются следующие принципы:
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 (необязательное). Секция может быть перенесена, при соблюдении следующих условий:
Перенос между секциями мог бы осуществляться в виде иерархических уровней, или дочерняя секция переносилась бы с ее родительской секцией.
Правило 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) атрибутов
Допустимые значения используют определение одного или более допустимых значений кодов атрибутов. Например:
Эти значения всегда используются при создании 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 Автор постарается ответить на вопросы, связанные с изложенным материалом или осветить их в будущем.