Одноступенчатое формирование XML-документа
Развитие новых тенденций объединения технологий XML и EDI обеспечивает динамичный процесс формирования электронных документов и взаимодействия между информационными системами. Тенденция объединения XML и EDI является наиболее перспективным направлениям в использование электронных документов.
Рис. 1
На рис.1 представлена схема вариантов обмена Электронными документами для разных (мелких и крупных) компаний. Крупные компании продолжают использовать уже имеющие EDI-системы через VAN сеть (сеть с добавленной стоимостью, т.е. предоставление за плату добавочных услуг). Провайдеры предоставляют такую услугу, как подготовка и обмен EDI-сообщениями по средствам корпоративных сетей. Более мелкие компании, используя технологию XML/EDI осуществляют обмен через Internet.
Один из самых простых вариантов обмена используя XML/EDI технологию - это подготовка XML-докуамента на стороне клиента и отправка на XML-сервер компании, где документ проверяется и преобразуется в стандартное EDI - сообщение и будет передан по Intranet на EDI-сервер компании.
Рис. 2
На рис.2 представлена схема формирования 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.
Рис. 3
Упрощенный вид генерируемой HTML формы представлен на рис. 3. После инициации события OnClick кнопки "Передача" (SUBMIT) происходит генерация следующего XML документа:
<?xml version="1.0"> <!DOCTYPE Invoice> <Transaction id="768765324"> <InvoiceNum>12345<InvoiceNum> <!-- номер инвойса --> <DataSend>20000105</DataSend> <!-- YYYYMMDD 5/01/2000 -->
<Consignor> <ConsignorName>OY Valio</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 сервером, который генерирует следующее EDI - сообщение:
|
UNH+768765324+INVOIC:D:96A:UN:EAN002' BGM+380+12345+9+NA' DTM+3:20000105:102' NAD+SE+++OY Valio++Helsinki++Box 789+Fi' NAD+By+++АО Северная столица ++Saint-Peterburg+Невский 176 + +RU' |
Заголовок Сообщения Номер транзакции 768765324 Номер инвойса 12345 Дата выдачи 5.01.2000 Поставщик Valio Адр: Helsinki Box 789 FI Получатель "АО Северная столица" Адр: С-Петербург Пр. Невский 176 Россия |
|
LIN+1' IMD+F+011+:::Сыр' MEA+AAI' QTY+92:200' PRI+INV:300' CUX+2:USD' |
Первая позиция Наим. Сыр Ед.изм- кг Кол-во 200 кг Цена 300 за кг Валюта - USD |
|
LIN+2' IMD+F+011+:::Масло' MEA+AAU' QTY+92:150' PRI+INV:500' CUX+2:USD' |
Вторая позиция Наим. Масло Ед.изм- упак Кол-во 150 упак Цена за упак - 500 Валюта - USD |
|
LIN+3' IMD+F+011+:::Варенье' MEA+AAU' QTY+92:100' PRI+INV:180' CUX+2:USD' |
Третья позиция Наим. Варенье Ед.изм- упак Кол-во 100 упак Цена 180 за упак Валюта - USD |
|
UNS+S' CNT+4:3' UNT+26+12345' |
Контрольная секция Общее кол-во позиций- 3 Кол-во сегментов - 26 и Номер сообщения - 12345 |
В рассматриваемом EDIFACT сообщении INVOICE можно выделить сегменты и сопоставить их с объектами ELEMENT объектной модели. В левой части таблицы представлены DOM элементы, а в правой соответствующие им сегменты или части сегментов. Значок # указывает, что в данном месте должно находится значение из соответствующего элемента DOM.
| Корневой элемент Name= "Transaction" Attr "id = #" |
Сегмент UNH UNH +#+INVOIC:D:96A:UN:EAN002' |
| Элементы: Name ="InvoiceNum" Value = # |
Сегмент BGM BGM+380+#+9+NA' |
| Name ="Consignor " | Сегмент NAD NAD+SE+++#01++#02' |
|
Дочерние элементы "Consignor " Name = "ConsignorName" Value = #01 Name ="Addsress" Value = #02 | |
| Name ="Consignee " Дочерние элементы "Consignee " Name ="ConsigneeName " Value = #01 Name ="Addsress" Value = #02 | NAD+BY+++#01++#02' |
|
Name ="Addsress" Дочерние элементы "Addsress" Name ="City " Value = #01 Name ="Street" Value = #02 Name ="Zip" Value= #03 Name ="Country" Value= #04 | Часть Сегмента NAD #01+#02+#03+#04 |
|
Name ="Goods" Дочерние элементы "Goods" Name ="Item " |
Идентификатор группы сегментов: LIN-IMD-QTY-MEA-PTI-CUX |
| Name ="Item" Attr "id = #" Дочерние элементы "Item" Name ="Name" Name ="Qulity" Name ="TypeEQU" Name ="Price " Name ="TypeCur" |
Сегмент LIN LIN+#' |
| Name ="Name" Value = # | Сегмент IMD IMD+F+011+:::#' |
| Name ="Qulity" Value = # | Сегмент QTY QTY+92:#' |
| Name ="TypeEQU " Value= # | Сегмент MEA MEA+#' |
| Name ="Price" Value= # | Сегмент PRI PRI+INV:#' |
| Name ="TypeCur" Value= # | Сегмент CUX CUX+2:#' |
Интерпретация содержания сегмента осуществляется следующим образом: значение тага <InvoiceNum> из текста нашего XML документа ( <InvoiceNum>12345<InvoiceNum> ) будет преобразовано в BGM+380+12345+9+NA', что соответствует записи в левой части таблицы объкта Element ( Name ="InvoiceNum" Value = # ) и BGM+380+#+9+NA' в правой. Если какой либо сегмент содержит информацию из нескольких родственных (Sublin) тагов, то указывается номер вхождения:
Пример: Сегмент NAD содержит информацию из элемента "ConsigneeName" - вхождение #01 и элемента "Addsress" - вхождение #02:
Соответственно информация из элемента "Addsress" извлекается из дочерних элементов ( "City ", "Street" и "Country"), которые имеют свою часть вхождения в сегмент NAD:
При генерации 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-систему, где и происходит обработка сообщения.
