Построение систем электронного документооборота на базе технологий XML-EDI.

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

Исторически так сложилось, что основная масса заключенных сделок оформлялась на бумаге. Условия сделки письменно излагались и договаривающие стороны под условиями ставили свои подписи. В конце XVII века были уже сформированы основные требования к составлению разных видов документов, такие как купчая, дарственная, наследство и т.д.

Американской фирмой IMC (International Marketing Company) были проведены исследования по изучению бумажных потоков подготовки и оформления документов участников международной торговли. В результате исследования оказалось, что в общей сложности все участники внешнеэкономической деятельности в рамках одной поставки (партии товаров) оформляют 40 документов-оригиналов и 360 копий.

Можно выделить следующие типы взаимодействия информационных систем:

Произвольное взаимодействие между двумя отдельными компьютерами, например по модему. Обязательное участие оператора на принимающей и передающей стороне. Возможен обмен в произвольном, но заранее оговоренном формате;
Интерактивное удаленное взаимодействие компьютера с информационной системой, например по протоколу http. Оператор на передающей стороне. Как правило используется определенная форма HTML документа. Принимаемые документы обрабатываются автоматически;
Контролируемая потоковая обработка, например прием по e-mail, файл содержащий HTML форму, запуск которой инициирует процесс обработки документа или прием оператором по e-mail электронных документов в оговоренном формате и далее запуск запуск программы обработки. Требует обязательный контроль оператора на принимаемой стороне;
Полностью автоматизированный процесс приема и обработки электронных документов в оговоренном формате. Участие операторов не требуется.

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

EDI-Prefics - информация (статическая часть текста сегмента) предшествующая вхождению переменной;
EDI-Suffics - статическая часть текста сегмента после вхождения переменной.

Так для тага <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>

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