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

Рис. 5
Компания 2, где расположена серверная часть, осуществляет автоматическую обработку XML-документа, без непосредственного участия человека. Было бы целесообразно, организовать обмен электронными документами таким же образом и на отправляемой стороне, т.е. чтоб человек мог только контролировать передачу документов, не осуществляя каких-либо ручных операций по заполнению HTML-форм.
Так на рис. 5, изображена топология внутреннего взаимодействия в Компании 3, где оператор со своего рабочего места вносит необходимые данные в информационную систему своей компании, которая автоматически, при определенных условиях, формирует XML-документ и отправляет его адресату.
Такая организация передачи электронных документов возможна разными способами: использование встроенных в HTML файл объектов ActiveX или написание специальных Java программ, которые реализовывали бы серверные обмены.
Другой из возможных вариантов построения системы XML/EDI - является использование двухступенчатого формирования электронного документа. На рис. 6 представлена схема двухступенчатого преобразования XML документа в EDI-сообщение.

Рис.6
На первом этапе, осуществляется преобразование XML-источника, используя XSL-преобразование стандартным XSL-анализатором, в формат метаданных XEDI.. По своей сути, формат метаданных XEDI - является своего рода новым языком, описанного языком разметки.
Второй этап заключается в прямом преобразовании метаданных XEDI транслятором XML/EDI непосредственно в EDI-сообщение. Аналогичный процесс, но уже в обратном порядке, происходит при конвертации EDI-сообщения в XML-документ.
Преимущество идеи двухступенчатого преобразования в том, что метаданные XEDI описывают любые виды EDI-сообщений в соответствии с XEDI синтаксисом. Одноступенчатое преобразование применяется в основном в системах, использующих один тип сообщения.
Ниже будут изложены предложения XML-EDI Group, заложенные в преобразование метаданных.
Сообщение UN/EDIFACT можно разобрать на следующие самостоятельные единицы, вложенные друг в друга:
- Сообщение
- Группа сегментов
- Сегмент
- Группа Элементов данных
- Элемент данных или Квалификатор
Каждой самостоятельной единице будет соответствовать свой элемент XML (элемент метаданных XEDI). Можно выделить следующее соответствие EDI-XML:
Сообщение | <Message Name=имя сообщения> |
Группа сегментов | <SegmentGroup> |
Сегмент | <Segment Name=имя сегмента> |
Группа Элементов данных | <ElementGroup > |
Элемент данных Квалификатор | <DataElement id=код данных> |
<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. Например, в соответствии со справочником EDSD, сегмент NAD (имя и адрес) имеет следующие описание:
№ группы | Код справочника | Описание данных | Усл/обяз | формат |
010 | 3035 | КВАЛИФИКАТОР УЧАСТНИКА | M | an..3 |
020 | C082 | ОСОБЕННОСТИ ИДЕНТИФИКАЦИИ УЧАСТНИКОВ | C | |
3039 | Идентификация участников | M | an..35 | |
1131 | Квалификатор контролирующего органа | C | an..3 | |
3055 | Код контролирующего органа | C | an..3 | |
030 | C058 | НАЗВАНИЕ И АДРЕС | С | |
3124 | Строка имени (названия) и адреса | M | an..35 | |
3124 | Строка имени (названия) и адреса | C | an..35 | |
040 | C080 | НАЗВАНИЕ УЧАСТНИКА | С | |
3036 | Название участника | M | an..35 | |
3036 | Название участника | C | an..35 | |
3045 | Код названия участника | C | an..3 | |
050 | С059 | УЛИЦА | C | |
3042 | Улица и номер п.я. | C | an..35 | |
3042 | Улица и номер п.я. | C | an..35 | |
060 | 3164 | НАЗВАНИЕ ГОРОДА | C | an..35 |
070 | 3229 | ИДЕНТИФИКАЦИЯ РЕГИОНА | C | an..9 |
080 | 3251 | ИДЕНТИФИКАЦИЯ ПОЧТОВОГО КОДА | C | an..9 |
090 | 3207 | КОД СТРАНЫ | C | an..3 |
<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=строка запроса /> осуществляет подстановку результата.
Синтаксис строки запроса схож с обычным способом определения пути к ресурсу- список узлов дерева, разделенных символом /.
Для выделения всех дочерних элементов - используется символ "*", для выделения элемента, расположенного просто "ниже" по дереву(на любом уровне вложенности) символ - "//". Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.
Примеры простых шаблонов:
" Transaction/" | возвращает дочерние элементы для элемента Transaction |
"Consignor//" | список всех элементов, вложенных в Consignor |
"SegmentName[@Id]" | список элементов SegmentName, в котором определен атрибут Id |
"SegmentName [@Id=2]" | поиск всех тагов, которые имеют значение атрибута id равное 2 |
<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>
В заключение хочется отметить, что предлагаемый способ формирования XEDI метаданных находится на стадии утверждения. В настоящее время в XML-EDI Group находится на рассмотрении предложения по комбинированному формированию метаданных, при котором используется конверсия не только стандарта UN/EDIFACT, но и не менее популярного в США и Германии стандарта формирования электронных документов ANSI X12.
Автор будет очень благодарен за отзывы об актуальности темы, общем содержании, виде и стиле изложения, а также всем остальным комментариям, которые помогут в дальнейшем улучшить качество написания сборника статей и выпуску книги освещающую тему использования электронных документов. Также автору будет интересно узнать пожелания читателей об освещении смежных тем, связанных с использованием электронных документов и электронной коммерции. Свои комментарии и пожелания просьба направлять на Автор постарается ответить на вопросы, связанной с изложенным материалом или осветить их в будущем.