Двухступенчатое преобразование 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=код данных>

Каждый элемент XML имеет определенный набор параметров, которые содержат информацию. Возвращаясь к нашему примеру, Все содержание EDI-сообщения INVOICE будет обрамлено следующими тагами:

<Message Name="INVOICE">

..... сегменты и группы сегментов, составляющие сообщение ...

</Message>

Значение атрибута Name для тага <Message> представляет имя EDI-сообщения. Для упрощения синтаксического анализа и сохранения наглядности документа вводится таг <SegmentGroup>, который обрамляет повторяющиеся группы сегментов:

<Message Name="INVOICE"> <Segment Name="UNH">  </Segment>

<Segment Name="BGM">  </Segment> 

<SegmentGroup>  <Segment Name="LIN">  </Segment> <Segment Name="IMD">  </Segment>  </SegmentGroup>  </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

Возвращаясь к нашему примеру, кодировка в 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=строка запроса /> осуществляет подстановку результата.

Синтаксис строки запроса схож с обычным способом определения пути к ресурсу- список узлов дерева, разделенных символом /.

Для выделения всех дочерних элементов - используется символ "*", для выделения элемента, расположенного просто "ниже" по дереву(на любом уровне вложенности) символ - "//". Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.

Примеры простых шаблонов:

" 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&gt;, имеющие значение параметра 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.

Автор будет очень благодарен за отзывы об актуальности темы, общем содержании, виде и стиле изложения, а также всем остальным комментариям, которые помогут в дальнейшем улучшить качество написания сборника статей и выпуску книги освещающую тему использования электронных документов. Также автору будет интересно узнать пожелания читателей об освещении смежных тем, связанных с использованием электронных документов и электронной коммерции. Свои комментарии и пожелания просьба направлять на Автор постарается ответить на вопросы, связанной с изложенным материалом или осветить их в будущем.