Введение в XML/EDI

Исторически так сложилось, что основная масса заключенных сделок оформлялась на бумаге. Условия сделки письменно излагались и договаривающие стороны под условиями ставили свои подписи. В конце 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-документа:
  1. Одноступенчатое формирование XML-документа
  2. Двухступенчатое преобразование XML-документа

Одноступенчатое формирование XML-документа

Развитие новых тенденций объединения технологий XML и EDI обеспечивает динамичный процесс формирования электронных документов и взаимодействия между информационными системами. Тенденция объединения XML и EDI является наиболее перспективным направлениям в использование электронных документов.

Рис. 2 Примерная схема обмена документами.

На рис.2 представлена схема вариантов обмена Электронными документами для разных (мелких и крупных) компаний. Крупные компании продолжают использовать уже имеющие EDI-системы через VAN сеть (сеть с добавленной стоимостью, т.е. предоставление за плату добавочных услуг). Провайдеры предоставляют такую услугу, как подготовка и обмен EDI-сообщениями по средствам корпоративных сетей. Более мелкие компании, используя технологию XML/EDI осуществляют обмен через Internet.

Один из самых простых вариантов обмена используя XML/EDI технологию - это подготовка XML-докуамента на стороне клиента и отправка на XML-сервер компании, где документ проверяется и преобразуется в стандартное EDI - сообщение и будет передан по Intranet на EDI-сервер компании.

Рис. 3 Схема формирования XML документа на клиентской стороне.

На рис.3 представлена схема формирования 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.

Рис. 4 Пример генерируемой HTML-формы.

Упрощенный вид генерируемой HTML формы представлен на рис. 4. После инициации события 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. На рис 5 представлена иерархическая схема сообщения INVOICE.

В рассматриваемом EDIFACT сообщении INVOICE можно выделить сегменты и сопоставить их с объектами ELEMENT объектной модели. В левой части таблицы представлены DOM элементы, а в правой соответствующие им сегменты или части сегментов. Значок # указывает, что в данном месте должно находится значение из соответствующего элемента DOM.

Рис. 5 Иерархическая схема сообщения 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:

Рис. 6 Иллюстрация к сегменту NAD.

Соответственно информация из элемента "Addsress" извлекается из дочерних элементов ( "City ", "Street" и "Country"), которые имеют свою часть вхождения в сегмент NAD:

Рис. 7 Дочерние элементы "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-документа

В предыдущем разделе рассказывалось об одном из способов организации состава клиентской части XML/EDI. Основным недостатком построения клиентской части по схеме одноступенчатого преобразования является "мануальностью" системы, т.е. система является не автоматической: Пользователь из Компании 1 (см. рис 5) должен взять из информационной системы своей компании информацию и в ручную заполнить форму Браузера, которая формирует XML документ (На рис. 5 для наглядности изображено два разных компьютера, один из которых является частью Intranet компании, и другой, который посредством WEB browser формирует XML документ).

Рис. 8 Топология внутреннего взаимодействия в компании.

Компания 2, где расположена серверная часть, осуществляет автоматическую обработку XML-документа, без непосредственного участия человека. Было бы целесообразно, организовать обмен электронными документами таким же образом и на отправляемой стороне, т.е. чтоб человек мог только контролировать передачу документов, не осуществляя каких-либо ручных операций по заполнению HTML-форм.

Так на рис. 8, изображена топология внутреннего взаимодействия в Компании 3, где оператор со своего рабочего места вносит необходимые данные в информационную систему своей компании, которая автоматически, при определенных условиях, формирует XML-документ и отправляет его адресату.

Такая организация передачи электронных документов возможна разными способами: использование встроенных в HTML файл объектов ActiveX или написание специальных Java программ, которые реализовывали бы серверные обмены.

Другой из возможных вариантов построения системы XML/EDI - является использование двухступенчатого формирования электронного документа. На рис. 9 представлена схема двухступенчатого преобразования XML документа в EDI-сообщение.

Рис. 9 Схема двухступенчатого преобразования 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>

Навигация :
К Предыдущей Странице В Оглавление. На Следующую Страницу

Hosted by uCoz