Цель данного обозрения - дать общее понятие о системах обмена электронными документами, перспективы их развития и интеграции с новыми технологиями. Также показать практическую возможность использования систем XML/EDI в такой новой отрасли, как электронная коммерция.
Сегодня, в сфере бизнеса создается и обрабатывается внушительный объем разнообразной бумажной документации. Она включает в себя заказы на приобретение, счета, каталоги, отчеты, платежные поручения и т.д.
Американской фирмой IMC (International Marketing Company) были проведены исследования по изучению бумажных потоков подготовки и оформления документов участников международной торговли. В результате исследования оказалось, что в общей сложности все участники внешнеэкономической деятельности в рамках одной поставки (партии товаров) оформляют 40 документов-оригиналов и 360 копий.
Можно выделить следующие типы взаимодействия информационных систем:
Здесь подробее будет сакцентированно внимание на создание и основные принципы организации последнего типа взаимодействия, называемого "Электронным обменом данными" - (Electronic Data Interchange или EDI).
В чем же состоит преимущество систем EDI? Сегодня, большая часть данных, содержащихся в коммерческих документах, генерируется их существующих компьютерных прикладных программ. Типовая схема оформления торговых сделок предполагает следующие действия:
По данным исследования IMC внедрение EDI-систем позволяет снизить расходы, связанные с составлением документов до 7-10% от общей стоимости сделки. Мировая практика электронной коммерции, основанной на системах-EDI осуществляется уже более 30 лет и представляет собой определенный стандарт выполнения торговых операций и представление структурированных деловых документов.
Коренное отличие систем EDI от систем электронного документооборота состоит в том, что EDI системы - это межведомственные системы обмена электронныими документами, использующие строго стандартизированные правила составления электронных документов. А система электронного документооборота - это системы, как правило, разрабатываемые в рамках одной кропорации или предприятия, обмен в которых осуществляется по средствам распределенных СУБД типа ORACLE или INFORMIX.
Существует много разных определений EDI, но мы приведем наиболее подходящее для наших целей: "передача между информационными системами электронным способом структурированных сообщений в согласованном стандарте".
При помощи технологии EDI данные из корпоративных компьютерных систем переводятся на понятный всем стандарт и передаются по надежным телекоммуникационным каналам, как правило, по корпаротивной сети передачи данных.
В настоящее время в системах EDI широко используются около двенадцати стандартов, но наибольшую популярность прибрели два стандарта: UN/EDIFACT и ANSI X-12. Так например, в США оклоло 500 тыс. пользователей EDI обмена в формате UN/EDIFACT, и такое же количество пользователей формата ANSI X-12.
Для упорядочивания разностандартных EDI систем, в 1996 году Экономическим и Социальным советом ООН была выпущена Рекомендация №25 по использованию стандарта EDIFACT, в которой рекомендовано модернизировать существующие EDI-системы в системы, ориентированные на использование UN/EDIFACT, а вновь создоваемые системы изначально строить на основе использования UN/EDIFACT.
Акроним UN/EDIFACT расшифровывается как "Правила ООН эелектронного обмена документами для гос. управления торговли и транспорта" (United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport).
В настоящее время из-за отсутствия законодательного регулирования процессов электронного обмена документами полномасштабное развитие систем EDI в нашей стране затруднено. Но лавинообразное развитие в мире систем электронной коммерции раскачивает официальные органы и жизнь заставлляет использовать параллельно с бумажными документами и их электронный образ.
В качестве примера можно привести использование стандарта UN/EDIFACT в международных банковских системах обмена информацией SWIFT. Следующие примеры использования электронных документов в стандарте UN/EDIFACT: EDI-система контроля сопровождения груза из стран ЕС до терминала назначения в таможенных органах Российской Федерации.
Государственный таможенный комитет (ГТК РФ) реализует проект взаимодействия с информационной системой МПС (Министерства путей сообщения), где для обмена электронными документами используется стандарт UN/EDIFACT. В ГТК разрабатывается проект обмена электронными документами с информационными системами крупных портов мира стран Балтийского моря с таможней в морском порту Санкт Петербург и портов Тихого океана США (Сиетл и Сан-Франциско) с таможней в морском порта Находка и Владивосток.
В МПС реализован проект взаимодействие EDI-систем Октябрьской железной дороги и Финляндских государственных железных дорог (VR cargo).
При разработке стандартов электронного документооборота была проведена работа по исследованию использования всех данных "бумажных" документов, используемых во внешнеэкономической деятельности. Как выяснилось, большинство документов содержат повторяющиеся данные, и даже целые группы данных.
Например, название и адрес фирмы отправителя встречается как в счете-фактуре, транспортно-сопроводительных документах - CMR, так и в таможенной декларации.
Было предложено выделить наиболее повторяющиеся группы данных, и в них выделить соответствующие поля данных. В последствии оказалось, что данные так часто повторяются, что для их заполнения было разработано более 200 специальных кодировочных таблиц - называемых справочники данных.
Часть справочников (такие как трехзначные коды стран мира, коды валют) использовались до появления стандартов UN/EDIFACT. Эти справочники были пересмотрены и скорректированы с точки зрения использования их в новых стандартах.
В основу стандарта UN/EDIFACT положены следующие принципиальные идеи:
Группа сегментов кроме типовых сегментов данных может содержать другие группы сегментов.
Сегменты в группе сообщений могут повторяться некоторое количество раз. Также незаполненные (пустые) сегменты могут опускаться.
Стандартом предусмотрено около 200 различных типов сегментов, из которых составляется сообщение.
На рис. 1 Представлен фрагмент структуры сообщения, на котором видно, как объеденены в группу SG. 8 сегменты TDT-LOC и MEA-EQN которые в свою очередь объединены в группу SG.9 В группе, порядок следования сегментов строго упорядочен, но они могут повторяться, например:
TDT- LOC
MEA-EQN
MEA-EQN
TDT- LOC
MEA-EQN
Первый раз, в группе SG.9 сегменты MEA-EQN повторяются два раза, второй раз - один. В группе SG.8 - сегменты TDT- LOC повторяются - два раза.
Сегменты данных состоят из элементов данных, которые могут быть простыми (аналогом является поле данных) и составными (обычно 2-3 поля данных).
На конец 1999 года разработано более 170 стандартных сообщений. Стандартом предусмотрено, что каждое сообщение имеет уникальный 6-значный код из заглавных букв, а каждый сегмент данных имеет 3-значныный код из заглавных букв.
По правилам UN/EDIFACT не предусмотрено использование символов перевода строки и возврата каретки, но для наглядности на каждой строчке расположен отдельный сегмент. Ниже, для примера, показано разобранное на сегменты сообщение ORDERS в стандарте UN/EDIFACT.
| UNH+000002+ORDERS:D:96A:UN:EAN008' | Заголовок Сообщения |
| BGM+220+B00002+9' | Номер заказа |
| DTM+137:19940202:102' | дата отправки сообщения |
| NAD+BY+++Stadt- und Universitaetsbibliothek | Имя и адрес покупателя |
| :Frankfurt+Bockenheimer Landstr. 134-13 8+Frankfurt++60325' RFF+API:DE1141110388' | Идентификатор покупателя |
| NAD+SU+++DREIER' | Наименование поставщика |
| CUX+2:DEM:9' | Валюта оплаты |
| LIN+1' | Позиция заказа 1 |
| PIA+5+3772815359:IB' | Идентификатор ISBN заказа |
| IMD+F+050+:::Die "Jahrbuecher fuer wissensc haftl:iche Kritik"' IMD+F+060+:::Hegels Berliner Gegenakademie' IMD+F+065+:::Hrsg. von Christoph Jamme' IMD+F+110+:::Stuttgart-Bad Cannstadt' IMD+F+120+:::Frommann-Holzboog' IMD+F+170+:::1994' IMD+F+190+:::Spekulation und Erfahrung' IMD+F+191+:::Abt. 2' IMD+F+192+:::Untersuchungen' IMD+F+194+:::Bd. 27' IMD+F+220+:::Gewebe' | Подробности описания товара |
| QTY+21:1' | кол-во копий заказа |
| PRI+AAE:295:CA' | Цена заказа в Нем. марках |
| UNS+S' | Разделительный сегмент |
| CNT+2:1' | Общее кол-во позиций - 1 |
| UNT+25+000002' | Общее кол-во сегментов = 25 |
Сегменты, составляющие сообщение, начинаются с трехбуквенного имени, например UNA, UNH, BGM, DTM и т.д. Оканчивается сегмент символом окончания сегмента - в данном примере апострофом.
Ниже приведены названия некоторых сегментов:
| BGM | BEGINNING OF MESSAGE | НАЧАЛО СООБЩЕНИЯ |
| CUX | CURRENCIES | ВАЛЮТА |
| DTM | DATE/TIME/PERIOD | ДАТА/ВРЕМЯ/ПЕРИОД |
| IDM | ITEM DESCRIPTION | ОПИСАНИЕ ПУНКТА |
Каждый сегмент состоит из элементов данных. В отличие от имени сегмента, имя элементов данных не указывается в сообщении. Элементы данных разделены разделителями которым является символ "плюс". Так, например сегмент NAD+BY+++Stadtund Universitaets bibliothek:Frankfurt+Bockenheimer.Landstr.134 -138+Frankfurt++ 60325'
Состоит из следующих элементов данных:
| Первый элемент | BY |
| Четвертый элемент | Stadt-und Universitaetsbibliothek:Frankfurt |
| Пятый элемент | Bockenheimer.Landstr.134-138 |
| Шестой элемент | Frankfurt |
| Восьмой элемент | 60325 |
Каждый из элементов данных занимает свое определенное место в сегменте. Если какой-либо из элементов данных не требуется, то для его пропуска повторяют разделитель элементов данных (см. в примере - между первым и четвертым элементом расположено три разделителя). Назначение того или иного элемента данных определяется справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT.
Элементы данных могут быть простыми и составными, состоящими из компонентов. Для составных элементов данных предусмотрен еще один разделитель - в данном случае "двоеточие". Четвертый элементы данных в вышеприведенном примере, являются составными, части которого разделены символом ":" Последовательность элементов данных в сегменте регламентируется справочником элементов данных и строго определена.
Бурное развитие Интернет технологий вовлекло в международную паутину миллионы пользователей. Требования к электронному обмену возросли, и уже существующий протокол HTML многие группы пользователей перестал удовлетворять.
В начале февраля 1998 г международная организация W3C утвердила спецификацию "Extensible Markup Language(XML) 1.0". Уже сегодня появляются новые языки, созданные на основе XML. Возникают многочисленные Web-сервера, использующие и технологию XML для организации хранящейся на них информации.
Современные приложения требуют не только более гибкий протокол представления данных, но и механизм, позволяющий определить структуру документа и описывать содержащие в нем элементы.
Язык XML предназначен для создания новых языков разметки. С его помощью можно описать целый класс объектов данных, называемых XML - документами, ориентированными на конкретную предметную область. XML позволяет определить допустимый набор тэгов, их атрибуты и внутреннюю структуру документа. Тэги (подобно тэгам в HTML) представляют специальные инструкции, предназначенные для формирования в документах определенной структуры и четких отношений между различными элементами этой структуры.
Можно выделить следующий круг задач, связанных с созданием и обработкой структурированной информации, для решения которых может использоваться XML:
Тэги языка кодируются и выделяются относительно основного содержимого документа и служат в качестве инструкций для программы, производящей действия над содержимым документа на стороне клиента.
Исторически сложилось таким образом, что в системах для обозначения этих команд использовались символы "<" и ">", внутри которых помещались названия инструкций и их параметры. Сейчас такой способ обозначения тэгов является стандартным.
Например, для создания элемента Ivanov в имене заказчика используется тэг <CustumerName>. В программе это выглядит следующим образом:
<CustumerName> Ivanov </CustumerName>
Определения тэгов может легко расширяться. Так для указания более полных реквизитов заказчика можно определить тег <Custumer>, в который включено не только имя, телефон заказчика, но и адрес компании.
<Custumer> <CustumerName> Ivanov </CustumerName> <phone>312-12-13<phone> <Company>Bussines Trade Consulti</Company> </Custumer>
Можно создать массив заказчиков, определив тег <Custumers>:
<Custumers> <Custumer> <CustumerName> Ivanov </CustumerName> <phone>312-12-13<phone> <Company>Bussines Trade Consulti</Company> </Custumer> <Custumer> <CustumerName> Petrov </CustumerName> <phone>315-15-16<phone> <Company> Trade Forest Company</Company> </Custumer> <Custumer> ...... </Custumer> </Custumers>
Из приведенного примера видно, что XML - документы подлежат четкой структуризации и имеют четкую иерархическую структуру следования элементов. Элементы имеют своих родителей - корневые элементы и наследников - дочерние элементы.
Документ XML состоит из элементов. Элемент - это структурная единица XML- документа. Заключая данные об имени заказчика в тэги <CustumerName> </CustumerName>, XML-процессор определит как элемент. Содержимым элемента CustumerName является значение. В нашем примере имеется два значения (Ivanov и Petrov) элемента CustumerName.
Контроль за правильностью использования порядка использования элементов осуществляется при помощи специального набора правил, называемых DTD (Document Type Definition)- описаниями, которые используются программой клиента при анализе документа.
Производя в последствии поиск в XML документе, программа клиента будет опираться на информацию, заложенную в его структуру - используя элементы документа, определенные в DTD.
В общем случае XML- документы должны удовлетворять следующим синктатическим правилам:
В случае, если элемент не содержит данных, т.е. является пустым, то начальный и конечные тэги такого элемента можно объединить в один. При этом не обязательно ставить косую черту перед закрывающей угловой скобкой (например, в вышеприведеном примере отсутствие факса в компании пару тэгов <fax></fax> можно заменить на <fax/>;)
При необходимости, каждому элементу можно задать параметры, уточняющие его характеристики. При этом используются атрибуты эдлемента. Атрибут - это пара "название" = "значение", которую необходимо задавать при определении элемента в начальном тэге. Пример:
<container Type="20f">123456</container > двадцати футофый контейнер <container Type ="30f ">654321</container> тридцати футофый контейнер
Просмотр XML документов осуществляется специальной программой анализатором. На сегодняшний день разработано около десятка подобных анализаторов. В своем новом браузере Internet Explorer 5 фирма Microsoft уже предусмотрела анализ XML документов.
Анализ документа в Internet Explorer 5 осуществляется тремя вариантами: просмотр аналогично HTML документу, форматирование документа с использованием специальных стилевых таблиц - XSL и анализ с помощью сценариев, написанных на Java Script ил VBScript.
Поиск нужного элемента или поддерева осуществляется при помощи XQL запроса. XQL является частью XML и переволится как язык запросов для XML (XML Query Language). Идет дисскусия об утверждении языка запросов в качестве общепринятого стандарта, который может заменить SQL.
Синтаксис языка запросов очень гибок и позволяет осуществлять поиск элемента как по названию, значению атрибутов, содержанию, так и учитывать вложенность и положение в дереве элементов. При помощи запросов мы можем выделять из общего дерева необходимые нам элементы и применять к ним необходимые инструкции. Запрос возможно применять как к самому XML документу, так и к ссылкам URL.
Язык запросов напоминает обычный способ определения пути к ресурсу- список узлов дерева, разделенных символом "/". Для указания на текущий элемент используется символ "." , на родительский - "..", для выделения всех дочерних элементов - символ "*", для выделения элемента, расположенного просто "ниже" по дереву(не важно на каком уровне вложенности) - "//". Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.
Примеры простых XQL шаблонов:
| "/Customer " | корневой элемент |
| "Customers/" | возвращает дочерние элементы для элемента Customers |
| "Customers //" | список всех элементов, вложенных в Customers |
| "container[@Type]" | список элементов container, в котором определен атрибут Type |
| "container[@Type =20f]" | поиск всех двадцатифутовых контейнеров, т.е. элементов container, в котором значение атрибута Type равно "20f" |
| "Customers[address]" | список элементов Customers, которые содержат хотя бы один элемент address, выражение в квадратных скобках может быть составным. |
Как мы видим, XML документ в отличие от EDIFACT сообщения позволяет более наглядно представить объектную модель данных. Использование языка описания XML запросов - XQL позволяет адекватно формализовать любой из существующих "бизнес" запросов (оформленных в виде стандартных документов) для информационных систем.
Разбор XML документов в отличие от EDI-систем возможен стандартными анализаторами, что значительно удешевляет разработку новых информационных систем. Использование встроенных транспортных протоколов делает эти системы полностью совместимыми с существующими программными средствами и WEB технологиями.
Комбинация XML и EDI предполагает для XML/EDI разработку предложений основных методов описания и кодирования EDI сообщений посредством XML обработки. Формы, обрабатывающие XML документы должны быть согласованы, чтобы осуществлять взаимодействие с существующими XML/EDI системами. Для этого они должны иметь возможность генерировать EDIFACT сообщения, осуществлять их анализ и отображение.
XML/EDI предлагает пользователям, использующих текущие стандарты пути решения возможных проблем и может быть интегрировано в существующие EDI системы путем:
XML/EDI представляет нечто больше, чем прямой перенос XML документов в системы EDI. В рамках построения XML/EDI представляется слияние пяти технологий (XML, EDI, Templates, Agents и Repository), которые существенно расширят существующие возможности информационной системы. Каждый из этих компонент добавляет свои специфические возможности.
Использование технологий XML/EDI реализует следующие цели:
На рис. 2 представлены составные части технологий XML/EDI:
Рис. 2 Составные части XML/EDI технологий
Более подробно про каждую из составных частей:
XML. В основе обмена документами лежат транспортные протоколы, используемые в Интернет. С помощью заранее определенных тэгов определяется объектная модель данных, которая в последствии заполняется данными и передается в качестве электронного документа. Существующее идентификаторы сегментов EDI заменяются тэгами XML, или часть данных из EDI сегмента добавляются в тэги в качестве параметров.
EDI. Разработанные в EDI системах стандарты способны представлять данные в простом формате. Эти данные однозначно интерпретируются на принимающей и передающей стороне. XML/EDI позволит обеспечить 100 % совместимостью с существующими EDI системами, используя при этом обмен EDIFACT сообщениями. Разработка протоколов XML/EDI позволяет использовать уже существующие EDI системы, что не потребует новых капиталовложений для разработки глобальных систем.
Templates (Шаблоны) - это набор определенных правил, которые осуществляют управление процессом, как на клиентской, так и на серверной стороне. С помощью шаблонов можно выразить в XML все особенности процесса, который должен быть выполнен. Шаблон могжет быть загружен как с удаленного источника, откуда пришел XML документ, так и быть его составной частью. Шаблоны используют Document Type Definitions (DTD's), по которым определяется объектная модель данных. Удаленное использование (DTD's) позволит всем клиентским приложениям однозначно определить используемую модель данных.
Agents (Агенты) интерпретируют шаблоны, чтобы интерактивно выполнить необходимые транзакции и взаимодействовать с пользователем. Агенты могут быть реализованы как аплеты Java или внедренные объекты ActiveX. Разбор структуры XML может осуществляться Агентом прямо на компьютере клиента и использовать при этом необходимые для пользователя данные и их представление. Первоначально агенты будут управляться Шаблонами и предоставлять пользователю некоторые дополнительные возможности. Предполагается, что позже будут разработаны соответствующие протоколы для Агентов.
Repository (хранилище) - совместно используемые в Интернете общедоступные словари - которые уже используются в традиционных EDI системах. Данные словари позволяют пользователям найти значение и область определения EDI элементов. Совместно используемые общие словари обеспечивают автоматические поисковые таблицы более гибким механизмом поиска. Данный компонент обеспечит семантическую основу для EDI транзакций.
Можно выделить следующие основные принципы построения XML/EDI:
Определенные XML/EDI компоненты сформированы на основе существующих протоколов передачи и обработки кодированных в XML данных.
Рис 3. Уровни Интерфейсов XML/EDI
На рисунке представлены следующие интерфейсы уровней XML/EDI:
Сегодня уже доступны синтаксические XML анализаторы, программы просмотра XML-документов (браузеры), программы разметки страниц и библиотеки программ. Предполагается использование специальных XML/EDI компонент встаивать в существующие программные продукты. Это позволит значительно ускорить создание новых приложений, реализующих XML/EDI.
Первичные компоненты XML/EDI представляют общей язык описания и синтаксические правила и включают:
На рис. 4 представлены возможные варианты подключения отдельных компонентов XML/EDI. На данной схеме выделены в отдельные компоненты: удаленный пользователь, бизнес приложения, существующие EDI-системы, публичные директории и специальные словари и базы данных.
Рис 4 Связи в XML/EDI
Конечный пользователь посредством WEB-браузера может взаимодействовать с любыми компонентами системы, используя XML-представления и XQL запросы.
Исторически так сложилось, что основная масса заключенных сделок оформлялась на бумаге. Условия сделки письменно излагались и договаривающие стороны под условиями ставили свои подписи. В конце XVII века были уже сформированы основные требования к составлению разных видов документов, такие как купчая, дарственная, наследство и т.д.
Американской фирмой IMC (International Marketing Company) были проведены исследования по изучению бумажных потоков подготовки и оформления документов участников международной торговли. В результате исследования оказалось, что в общей сложности все участники внешнеэкономической деятельности в рамках одной поставки (партии товаров) оформляют 40 документов-оригиналов и 360 копий.
Можно выделить следующие типы взаимодействия информационных систем:
Сегодня, в сфере бизнеса создается и обрабатывается внушительный объем разнообразной бумажной документации. Она включает в себя заказы на приобретение, счета, каталоги, отчеты, платежные поручения и т.д. Бурное развитие телекоммуникаций в конце 80-х годов XX века открыло ворота для электронной торговли и Электронного обмена данными (Electronic Data Interchange или EDI)
Идея систем EDI заключается в стандартизации документов и представлении их в виде, удобном для компьютерной обработки. В этом заинтересованы все участники внешнеэкономической деятельности, в том числе и контролирующие органы (таможня, налоговая служба).
Коренное отличие систем EDI от систем электронного документооборота состоит в том, что EDI системы - это межведомственные системы обмена (подачи) электронными документами, использующие строго стандартизированные правила составления электронных документов. А система электронного документооборота - это системы, как правило, разрабатываемые в рамках одной корпорации или предприятия, обмен в которых осуществляется по средствам распределенных СУБД (RMDB).
Бурное развитие Internet-технологий за последнее пятилетие вовлекло в международную электронную паутину миллионы новых пользователей. Требования к цифровому обмену возросли, и уже существующие EDI системы перестали удовлетворять многие группы пользователей.
<Современные приложения требуют более гибкий протокол представления данных и механизмы, позволяющие определять структуру документа и описывать содержащие в нем элементы. Данным требованием удовлетворяет язык расширенной разметки - XML ("Extensible Markup Language").
Сегодня создаются новые языки, в том числе и для ведения электронной коммерции, созданные на основе XML. В настоящее время разработана спецификация OTP - Открытого торгового протокола (Online Trading Protocol), являющейся спецификацией деловых транзакций на основе XML. Компаниями CheckFree, Intuil и Microsoft разработан язык OFX, позволяющий на основе XML безопасно проводить в WEB финансовые транзакции - Open Financial eXchange.
Основная идея создания XML/EDI систем заключается в дополнительном привлечение в электронную торговлю мелких и средних клиентов. Существующие сегодня EDI системы довольно дороги (от 10 до 100 тыс. дол. США) и многим мелким конечным пользователем, в связи с этим, недоступны.
Возможны два принципиальных способа формирования XML-документа:Развитие новых тенденций объединения технологий XML и EDI обеспечивает динамичный процесс формирования электронных документов и взаимодействия между информационными системами. Тенденция объединения XML и EDI является наиболее перспективным направлениям в использование электронных документов.
Рис. 5 Примерная схема обмена документами.
На рис. 5 представлена схема вариантов обмена Электронными документами для разных (мелких и крупных) компаний. Крупные компании продолжают использовать уже имеющие EDI-системы через VAN сеть (сеть с добавленной стоимостью, т.е. предоставление за плату добавочных услуг). Провайдеры предоставляют такую услугу, как подготовка и обмен EDI-сообщениями по средствам корпоративных сетей. Более мелкие компании, используя технологию XML/EDI осуществляют обмен через Internet.
Один из самых простых вариантов обмена используя XML/EDI технологию - это подготовка XML-докуамента на стороне клиента и отправка на XML-сервер компании, где документ проверяется и преобразуется в стандартное EDI - сообщение и будет передан по Intranet на EDI-сервер компании.
Рис. 6 Схема формирования XML документа на клиентской стороне.
На рис. 6 представлена схема формирования XML документа на клиентской стороне. В ходе начала обмена, клиент принимает от XML сервера шаблон (формально назовем XML шаблон). Текст простого шаблона на примере XML документа "инвойс" может иметь следующий вид:
<?xml version="1.0">
<!DOCTYPE InvoiceForm >
<?xml-stylesheet type="text/xsl" server-config="Config.xml"
href=" InvoiceForm.xsl" ?>
<Transaction id="768765324">
<ItemQuantity>3</ItemQuantity>
</Transaction>
Элемент <Transaction> включает атрибут id, указывающий номер транзакции имеющий значение "768765324". Элемент <ItemQuantity> описывает количество "пунктов" инвойса, т.е. количество наименований перевозимого товара. Далее, используя язык описания стилей XSL, генерируется HTML форма, которая заполняется данными об отправителе и получателе груза, а также о самом грузе. Внешнее представление сгенерированной формы принципиального значения не имеет и может быть разработано получателем документа самостоятельно. Также, возможно использование заранее подготовленной HTML формы с параметром id тага Transaction.
Рис. 8 Пример генерируемой HTML-формы.
Упрощенный вид генерируемой HTML формы представлен на рис. 8. После инициации события OnClick кнопки "Передача" (SUBMIT)
происходит генерация следующего XML документа:
<?xml version="1.0">
<!DOCTYPE Invoice>
<Transaction id="768765324">
<InvoiceNum>12345<InvoiceNum> <!--номер инвойса -->
<DataSend>20000105</DataSend> <!-- YYYYMMDD 5/01/2000 -->
<Consignor>
<ConsignorName>OYValio</ConsignorName> <!-- Отправитель -->
<Address> <!-- Адрес -->
<City>Helsinki</City>
<Street/>
<Zip>Box 789</Zip>
<Country>FI</Country>
</Address>
</Consignor>
<Consignee> <!-- Получатель -->
<ConsigneeName>АО Северная столица</ConsigneeName>
<Address>
<City>Санкт-Петербург</City>
<Street>Невский 176</Street>
<Zip>194376</Zip>
<Country>RU</Country>
</Address>
</Consignor>
<Goods> <!-- Описание товаров -->
<Item id=1> <!-- Первая позиция -->
<Name>Сыр</Name> <!-- Наименование товара -->
<Qulity>200</Qulity> <!-- кол-во -->
<TypeEQU>AAI</TypeEQU> <!-- тип измерения AAI - по весу -->
<Price>300</Price> <!-- Цена за ед. -->
<Currently>FIM</Currently> <!-- тип используемой валюты -->
</Item>
<Item id=2> <!-- Вторая позиция -->
<Name>Масло</Name>
<Qulity>150</Qulity>
<TypeEQU>AAU</TypeEQU> <!-- тип измерения AAU - упаковки-->
<Price>500</ Price>
<Currently>FIM</Currently>
</Item>
<Item id=2> <!-- Третья позиция -->
<Name>Варенье</Name>
<Qulity>100</Qulity>
<TypeEQU>AAU</TypeEQU>
<Price>180</ Price>
<Currently>FIM</Currently>
</Item>
</Goods>
</Transaction>
Особой задачей для семантической проверки и разбора XML документа и формирования EDIFACT сообщения является разработка Таблицы определения данных - DTD. При разработке DTD, учитывая иерархическую структуру EDIFACT сообщения, разрабатывается объектная модель документа - DOM. На рис 9 представлена иерархическая схема сообщения INVOICE.
В рассматриваемом EDIFACT сообщении INVOICE можно выделить сегменты и сопоставить их с объектами ELEMENT объектной модели. В левой части таблицы представлены DOM элементы, а в правой соответствующие им сегменты или части сегментов. Значок # указывает, что в данном месте должно находится значение из соответствующего элемента DOM.
Рис. 9 Иерархическая схема сообщения INVOICE.
Интерпретация содержания сегмента осуществляется следующим образом: значение тага <InvoiceNum> из текста нашего XML документа ( <InvoiceNum>12345<InvoiceNum> ) будет преобразовано в BGM+380+12345+9+NA', что соответствует записи в левой части таблицы объкта Element ( Name ="InvoiceNum" Value = # ) и BGM+380+#+9+NA' в правой. Если какой либо сегмент содержит информацию из нескольких родственных (Sublin) тагов, то указывается номер вхождения:
Пример: Сегмент NAD содержит информацию из элемента "ConsigneeName" - вхождение #01 и элемента "Addsress" - вхождение #02:
Рис. 10 Иллюстрация к сегменту NAD.
Соответственно информация из элемента "Addsress" извлекается из дочерних элементов ( "City ", "Street" и "Country"), которые имеют свою часть вхождения в сегмент NAD:
Рис. 11 Дочерние элементы "Addsress"
При генерации EDI-сообщения, необходимая информация извлекается из значений атрибутов, которые описываются как константы элементов DTD. Каждый элемент, информация из которого имеет вхождение в сегмент сообщения, имеет атрибуты:
Так для тага <InvoiceNum> атрибутом является:
EDI-Prefics - "BGM+380+"
EDI-Suffics - "+9+NA' ".
Для тегов, которые используют информацию при вводе из поля данных, используются атрибуты Title и Size.
Ниже представлена часть таблицы определения данных, которая иллюстрирует основы построения DTD для XML/EDI.
<!DOCTYPE Invoice [
<!ENTITY InvoiceNum (#PCDATA) >
<!ATTLIST InvoiceNum
EDI-Prefics CDATA #FIXED "BGM+380+"
EDI-Suffics CDATA #FIXED "+9+NA'"
Title CDATA"INVOICE"
Size NUMBER #FIXED "8" >
<!ENTITY Consignor (ConsignorName, Address) >
<!ATTLIST Consignor
EDI-Prefics CDATA #FIXED "NAD+SE+++"
EDI-Suffics CDATA "#FIXED "'"
Title CDATA #FIXED ""
Size NUMBER #FIXED "30" >
<!ENTITY ConsignorName (#PCDATA) >
<!ATTLIST ConsignorName
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA "#FIXED "++"
Title CDATA #FIXED ""Отправитель"
Size NUMBER #FIXED "30" >
<!ENTITY Consignee (ConsigneeName, Address) >
<!ATTLIST Consignee
EDI-Prefics CDATA #FIXED "NAD+BY+++"
EDI-Suffics CDATA "#FIXED "'"
Title CDATA #FIXED ""
Size NUMBER #FIXED "0" >
<!ENTITY ConsigneeName (#PCDATA) >
<!ATTLIST ConsigneeName
EDI-Prefics CDATA #FIXED "Отправитель "
EDI-Suffics CDATA #FIXED "++"
Title CDATA #FIXED "Получатель"
Size NUMBER #FIXED "30" >
<!ENTITY Address (Street?,City,ZIP?,Country) >
<!ATTLIST Address
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED "'"
Title CDATA #FIXED "Адрес"
Size NUMBER #FIXED "30" >
<!ENTITY Street (#PCDATA) >
<!ATTLIST Street
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED "+'"
Title CDATA #FIXED "Улица"
Size NUMBER #FIXED "30" >
<!ENTITY City (#PCDATA) >
<!ATTLIST City
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED "+'"
Title CDATA #FIXED "Город"
Size NUMBER #FIXED "30" >
<!ENTITY Zip (#PCDATA) >
<!ATTLIST Zip
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED "+'"
Title CDATA #FIXED "Индекс"
Size NUMBER #FIXED "6" >
<!ENTITY Country (#PCDATA) >
<!ATTLIST Country
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED ""
Title CDATA #FIXED "Страна"
Size NUMBER #FIXED "3" >
]>
EDI-сообщение специальным модулем генерируется на серверной стороне извлекая динамическую информацию из XML документа и статическую из DTD. Далее сгенерированное сообщение передается в EDI-систему, где и происходит обработка сообщения.
В предыдущем разделе рассказывалось об одном из способов организации состава клиентской части XML/EDI. Основным недостатком построения клиентской части по схеме одноступенчатого преобразования является "мануальностью" системы, т.е. система является не автоматической: Пользователь из Компании 1 (см. рис 9) должен взять из информационной системы своей компании информацию и в ручную заполнить форму Браузера, которая формирует XML документ (На рис. 9 для наглядности изображено два разных компьютера, один из которых является частью Intranet компании, и другой, который посредством WEB browser формирует XML документ).
Рис. 12 Топология внутреннего взаимодействия в компании.
Компания 2, где расположена серверная часть, осуществляет автоматическую обработку XML-документа, без непосредственного участия человека. Было бы целесообразно, организовать обмен электронными документами таким же образом и на отправляемой стороне, т.е. чтоб человек мог только контролировать передачу документов, не осуществляя каких-либо ручных операций по заполнению HTML-форм.
Так на рис. 12, изображена топология внутреннего взаимодействия в Компании 3, где оператор со своего рабочего места вносит необходимые данные в информационную систему своей компании, которая автоматически, при определенных условиях, формирует XML-документ и отправляет его адресату.
Такая организация передачи электронных документов возможна разными способами: использование встроенных в HTML файл объектов ActiveX или написание специальных Java программ, которые реализовывали бы серверные обмены.
Другой из возможных вариантов построения системы XML/EDI - является использование двухступенчатого формирования электронного документа. На рис. 13 представлена схема двухступенчатого преобразования XML документа в EDI-сообщение.
Рис. 13 Схема двухступенчатого преобразования XML документа в EDI-сообщение.
На первом этапе, осуществляется преобразование XML-источника, используя XSL-преобразование стандартным XSL-анализатором, в формат метаданных XEDI.. По своей сути, формат метаданных XEDI - является своего рода новым языком, описанного языком разметки.
Второй этап заключается в прямом преобразовании метаданных XEDI транслятором XML/EDI непосредственно в EDI-сообщение. Аналогичный процесс, но уже в обратном порядке, происходит при конвертации EDI-сообщения в XML-документ.
Преимущество идеи двухступенчатого преобразования в том, что метаданные XEDI описывают любые виды EDI-сообщений в соответствии с XEDI синтаксисом. Одноступенчатое преобразование применяется в основном в системах, использующих один тип сообщения.
Ниже будут изложены предложения XML-EDI Group, заложенные в преобразование метаданных.
Сообщение UN/EDIFACT можно разобрать на следующие самостоятельные единицы, вложенные друг в друга:
Каждой самостоятельной единице будет соответствовать свой элемент XML (элемент
метаданных XEDI).
Каждый элемент XML имеет определенный набор параметров, которые содержат информацию. Возвращаясь к нашему примеру, Все содержание EDI-сообщения INVOICE будет обрамлено следующими тагами:
<Message Name="INVOICE"> ..... сегменты и группы сегментов, составляющие сообщение ... </Message>
Значение атрибута Name для тага <Message> представляет имя EDI-сообщения. Для упрощения синтаксического анализа и сохранения наглядности документа вводится таг <SegmentGroup>, который обрамляет повторяющиеся группы сегментов:
<Message Name="INVOICE">
<Segment Name="UNH">
<!-- содержание сегмента UNH -->
</Segment>
<Segment Name="BGM">
<!-- содержание сегмента BGM -->
</Segment>
<!-- ....... информация о сегментах DTM,NAD-->
<SegmentGroup>
<!-- ...... обрамляет группу сегментов (LIN, IMD,MEA,QTY,PRI,CUX) -->
<Segment Name="LIN">
<!-- ...... содержание сегмента LIN -->
</Segment>
<Segment Name="IMD">
<!--...... содержание сегмента IMD -->
</Segment>
<!--..... информация об остальных сегментах группы LIN (MEA,QTY,PRI,CUX) -->
</SegmentGroup>
<!--.... контрольная секция, сегменты UNS,CNT,UNT -->
</Message>
Каждый сегмент содержит группу элементов данных, в соответствии со справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT.
Возвращаясь к нашему примеру, кодировка в UN/EDIFACT NAD+SE+++OY Valio++ Helsinki++Box 789+Fi' будет преобразована в:
<Segment Name="NAD">
<DataElement id=10 dic=3035> SE </DataElement>
<DataElement id=40> OY Valio </DataElement>
<DataElement id=60> Y=Helsinki </DataElement>
<DataElement id=80> Box 789 </DataElement>
<DataElement id=90 dic=3207> FI </DataElement>
</Segment>
Атрибутом тага <DataElement> id - является номер группы в справочнике элементов данных, а атрибут dic - номер справочника, по которому определяется квалификатор.
Элементы данных могут быть простыми и составными, состоящими из компонентов. Составные элементы данных объединяются тагами <ElementGroup>. Например, сегмент цена: PRI+INV:180' содержит составной элемент данных, включающий квалификатор INV (цена по инвойсу) и значение цены - 180:
<Segment Name="PRI">
<ElementGroup id=10>
<DataElement id=1 dic=5125> INV </DataElement>
<DataElement id=2 dic=5118> 180 </DataElement>
</ElementGroup>
</Segment>
В данном примере таг <ElementGroup> имеет аттрибут id, который имеет значение положения составного элемента по справочнику EDCD. Значения id тага <DataElement> представляет относительное месторасположение в справочнике сегментов.
Преобразование XML документа в метаданные осуществляется посредством обработки XQL-запросов анализатором XSL. Ниже представлен текст запроса для преобразования EDIFACT элемента PRI (таг <Price> ) в XEDI метаданные:
<xsl:template>
xsl:for-each select="//Price">
<Segment Name="PRI">
<ElementGroup id=10>
<DataElement id=1 dic=5125> INV </DataElement>
<DataElement id=2 dic=5118>
<xsl:value-of select="//Price"/>
</DataElement>
</ElementGroup>
</Segment>
</xsl:for-each>
</xsl:template>
Таг <xsl:template> определяет область действия шаблона XSL фильтра, а таг <xsl:for-each> определяет область шаблона, на которую распространяется данный запрос. Параметр select определяет область действия запроса в соответствии с синтаксисом запроса. Таг <xsl:value-of select=строка запроса /> осуществляет подcтановку результата.
Синтаксис строки запроса схож с обычным способом определения пути к ресурсу- список узлов дерева, разделенных символом /. Для выделения всех дочерних элементов - используется символ "*", для выделения элемента, расположенного просто "ниже" по дереву(на любом уровне вложенности) символ - "file://". Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.
Примеры простых шаблонов:
| " Transaction/" | возвращает дочерние элементы для элемента Transaction |
| "Consignor//" | список всех элементов, вложенных в Consignor |
| "SegmentName[@Id]" | список элементов SegmentName, в котором определен атрибут Id |
| "SegmentName [@Id=2]" | поиск всех тагов, которые имеют значение атрибута id равное 2 |
При формировании ответа на сообщение обратное преобразование из метаданных в XML-документ, осуществляется с помощью следующего шаблона:
<xsl:template>
xsl:for-each select="//Segment/">
<Price>
<xsl:value-of select=" Segment[@Name="PRI"]/DataElement[@Id="2"]"/>
</Price>
</xsl:for-each>
</xsl:template>
Данный запрос интерпретируется как: выбрать все значения из тагов <DataElement>;, имеющие значение параметра Id="2", и которые имеют вхождение в таги <Segment> со значением параметра Name="PRI".
Выполнение более сложных запросов, например, при формировании метаданных для сегмента NAD осуществляется, учитывая уровни вложенности:
<xsl:template>
xsl:for-each select="//Consignor">
<Segment Name="NAD">
<DataElement id=10 dic=3035> SE </DataElement>
<DataElement id=40>
<xsl:value-of select="//Consignor/ConsignorName"/>
</DataElement>
<DataElement id=50>
<xsl:value-of select="//Consignor/Address/Street"/>
</DataElement>
<DataElement id=60>
<xsl:value-of select="//Consignor/Address/City"/>
</DataElement>
<DataElement id=80>
<xsl:value-of select="//Consignor/Address/Zip"/>
</DataElement>
<DataElement id=90 dic=3207>
<xsl:value-of select="//Consignor/Address/Country"/>
</DataElement>
</Segment>
</xsl:for-each>
</xsl:template>
Хотелось бы отметить о возможности более интересующегося читателя подчерпнуть более подробную информацию на следующих серверах:
| http://www.Unece.org/trade/facil/tf-rec_h.htm | - рекомендации Торговой Палаты |
| http://www.Edigroup.com | - EDI группа |
| http://www.Mindspring.com | - консультативная EDI группа |
| http://www.Computerworld.com/xml | - Обзор публикаций по EDI |
| http://www.r3.ch | - рабочая группа по защите UN/EDIFACT (SJWG) |
| http://www.toto.com/lteren/edi.html | - EDI стандарты |
| http://www.spokane.net/edi/standard.html | - EDI стандарты |
| http://www.eema.org/ | - ассоциация пользователь электронными сообщениями |
| http://www.citforum.ru/internet/xml | - введение в XML, статьи по XML |
| http://www.W3.org/tr/1998/rec-xml | - рекомендации группы W3 по использованию XML |
| http://www.Oasis-open.org/cover/xml.html | - руководство по XML |
| http://www.Xml.com | - публичный сервер пользователей XML |
| http://www.Xmls.com | - публичный сервер пользователей XML |
| http://www.xmledi.net | - сервер группы XML/EDI |
| http://www.microsoft.com/xml | - разработки Microsoft в области применения XML |
| http://www.geocites.com/WallStreet/Floor/5815/guide.htm | - Руководство по применению XML в системах EDI |
| http://www.Cenorm.be/isss/workshop/ec/Projects.html | -Европейский XML/EDI пилотный проект |
| http://www.Tedim.com | - пилотные прокты Программы TEDIM |
| http://www.Techweb.com/netbiz/ | - электронный бизнес |
| http://www.Itaa.org/ipecmmrl.htm | - электронная коммерция |
| http://www.Ms.com | - бизнес через WEB |
|
|
 |
