|
2000 г
Построение XML/EDI систем
А.Календарев
Введение в XML/EDI
Исторически так сложилось, что основная масса заключенных сделок оформлялась на бумаге. Условия сделки письменно излагались и договаривающие стороны под условиями ставили свои подписи. В конце XVII века были уже сформированы основные требования к составлению разных видов документов, такие как купчая, дарственная, наследство Наследование— приобретение имущества, оставшегося после смерти другого лица (наследодателя). Имущество, получаемое при наследовании, называют наследством, наследственным имуществом, наследственной массой. Наследство умершего переходит к другим лицам в порядке универсального правопреемства, то есть в неизменном виде как единое целое и в один и тот же момент. и т.д.
СегодняСегодня — наречие, указывающее (кроме телевизионных рекламных анонсов) на «текущий» 24-часовой отрезок времени (с 00 до 24 часов по местному времени)., в сфере бизнеса создается и обрабатывается внушительный объем разнообразной бумажной документДокумент (от лат.documentum— «образец, свидетельство, доказательство») — материальный объект, содержащий информацию в зафиксированном виде и специально предназначенный для её передачи во времени и пространстве .ации. Она включает в себя заказы на приобретение, счета, каталогиКаталог сайтов Интернета, или каталог Интернет-ресурсов, или просто Интернет-каталог (англ.web directory),— структурированный набор ссылок на сайты с кратким их описанием. Сайты внутри каталога разбиваются по темам, а внутри тем могут быть ранжированы или по индексу цитирования (как в каталогах Яндекса или Google), или по дате добавления, или по алфавиту, или по другому параметру. Это один из старейших сервисов Интернета. Подавляющее большинство рейтингов посещаемости ресурсов имеют классификатор сайтов, но ранжирование всегда основано на посещаемости сайтов. В зависимости от широты тематики ссылок каталоги могут быть общими и специализированными (тематическими)., отчеты, платежные поручения и т.д. Бурное развитие телекоммуникаций в конце 80-х годов XX века открыло ворота для электронной торговли и Электронного обмена данными (Electronic Data InterchangeInterchange— система для создания интернет-магазинов, разработанная Interchange Development Group. Под управлением одной системы могут одновременно работать несколько интернет-магазинов (каталогов). Interchange представляет собой свободное программное обеспечение и распространяется бесплатно под лицензией GNU GPL. или EDI)
Идея систем EDI заключается в стандартизации документов и представлении их в виде, удобном для компьютерной обработки. В этом заинтересованы все участники внешнеэкономической деятельности, в том числе и контролирующие органы (таможняТаможня— государственный орган, обеспечивающий порядок перемещения через таможенную границу товаров и транспортных средств, вещей и иных предметов, применение таможенных режимов и взимание таможенных платежей, производящий таможенный контроль и таможенное оформление., налоговаяИнспекция федеральной налоговой службы (ИФНС)— территориальный орган федерального органа исполнительной власти межрайонного, городского (районного) уровня, подотчетный Федеральной налоговой службе Российской Федерации, осуществляющий контроль за соблюдением законодательства о налогах и сборах, а также правильностью исчисления, полнотой и своевременностью внесения налоговых платежей, сборов, а в случаях, установленных законом— и иных платежей в соответствующий бюджет. служба).
Коренное отличие систем EDI от систем электронного документооборота состоит в том, что EDI системы - это межведомственные системы обмена (подачи) электронными документами, использующие строго стандартизированные правила составления электронных документов. А системаСистема (от др.-греч. — «сочетание»)— множество взаимосвязанных элементов, обособленное от среды и взаимодействующее с ней, как целое. электронного документооборота - это системы, как правило, разрабатываемые в рамках одной корпорацииКорпорация (от новолат. corporatio— объединение)— юридическое лицо, которое, будучи объединением физических лиц, при этом независимо от них (то есть самоуправляемо). В широком смысле под корпорацией можно понимать всякое объединение с экономическими целями деятельности. или предприятия, обмен в которых осуществляется по средствам распределенных СУБД (RMDB).
БурноеБауыржан-Мамыш-Улы — село, административный центр Жуалынского района Жамбылской области Казахстана. развитиеРазвитие— необратимый закономерный процесс, направленный на изменение материальных и идеальных объектов. Изменение материи и сознания, их универсальное свойство, всеобщий принцип объяснения истории природы, общества и познания. InternetИнтернет (произносится [интэрнэт]; англ.Internet)— всемирная система объединённых компьютерных сетей, построенная на использовании протокола IP и маршрутизации пакетов данных. Интернет образует глобальное информационное пространство, служит физической основой для Всемирной паутины и множества других систем (протоколов) передачи данных. Часто упоминается как «Всемирная сеть» и «Глобальная сеть». В обиходе иногда говорят «Инет».-технологий за последнее пятилетие вовлекло в международную электронную паутину миллионы«Миллионы» — кинофильм. Экранизация произведения, автор которого — Ренцо Барбьери. Не рекомендуется просмотр детям и подросткам моложе 16 лет. новых пользователей. Требования к цифровому обмену возросли, и уже существующие EDI системы перестали удовлетворять многие группы пользователей.
Современные приложения требуют более гибкий протоколПротокол (от др.-греч. protos— «первый» и kolla— «клей»)— первый лист, приклеенный к свитку. На нем фиксировались титульная информация (например, дата написания, имя писателя) и краткое основное содержание свитка. представления данных и механизмыМеханизм (греч. mechan— машина)— это совокупность совершающих требуемые движения тел (обычно— деталей машин), подвижно связанных и соприкасающихся между собой. Механизмы служат для передачи и преобразования движения., позволяющие определять структуру документа и описывать содержащие в нем элементы. Данным требованием удовлетворяет язык расширенной разметки - XML ("Extensible Markup Language"), спецификация которого была утверждена международной организацией я W3C в начале февраля 1998 г.
Сегодня создаются новые языки, в том числе и для ведения электронной коммерции, созданныеДанные (калька от лат.data) — это представление фактов и идей в формализованном виде, пригодном для передачи и обработки в некотором информационном процессе. на основе XML. В настоящееНастоящее— часть линии времени, состоящая из событий, которые происходят в настоящий момент, то есть определенная область пространства-времени. время разработана спецификацияСпецификация— (позднелат.specificatio, от лат. species - род, вид, разновидность и facio - делаю) инженерный термин, обозначающий набор требований и параметров, которым удовлетворяет некоторая сущность. К примеру, мост через реку удовлетворяет таким параметрам, как максимальный общий вес нагрузки, максимальная нагрузка на ось, максимальная скорость ветра ит.д. OTP - Открытого торгового протокола (OnlineОнлайн (англ.online, от англ.on line— «на линии», «на связи», «в сети», «в эфире»)— «находящийся в состоянии подключения». Первоначально использовалось только в отношении коммуникационного оборудования для указания на режим связи, типичным значением могло быть «не вешая трубку», то есть за один телефонный звонок, в режиме реального времени. Trading Protocol), являющейся спецификацией деловых транзакций на основе XML. КомпанияКомпания: (фр.compagnie — 1) общество, группа; 2) фирма, рота, экипаж корабля, театральная труппа)ми CheckFree, Intuil и MicrosoftMicrosoft (Microsoft Corporation, читается «майкрософт», NASDAQ: MSFT)— одна из крупнейших транснациональных компаний по производству программного обеспечения для различного рода вычислительной техники— персональных компьютеров, игровых приставок, КПК, мобильных телефонов и прочего, разработчик наиболее широко распространённой на данный момент в мире программной платформы— семейства операционных систем Windows. разработан язык OFX, позволяющий на основе XML безопасно проводить в WEB финансовые транзакцииТранзакция (англ.transaction)— в информатике, группа последовательных операций, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще и тогда она не должна произвести никакого эффекта. Транзакции обрабатываются транзакционными системами, в процессе работы которых создаётся история транзакций. - Open Financial eXchange.
Основная идея создания XML/EDI систем заключается в дополнительном привлечение в электронную торговлю мелких и средних клиентов. Существующие сегодняСегодня — наречие, указывающее (кроме телевизионных рекламных анонсов) на «текущий» 24-часовой отрезок времени (с 00 до 24 часов по местному времени). EDI системы довольно дорогиДорога— путь сообщения для передвижения людей и транспорта, составная часть дорожной инфраструктуры. (от 10 до 100 тыс. дол. США) и многим мелким конечным пользователем, в связи с этим, недоступны.
Более подробную информацию о структуре систем XML/EDI и стандарте UN/EDIFACT можно найти в статье "ПонятиеПонятие— отображённое в мышлении единство существенных свойств, связей и отношений предметов или явлений; мысль или система мыслей, выделяющая и обобщающая предметы некоторого класса по определённым общим и в совокупности специфических для них признаков. XML/EDI" (http://www.S-Networks.ru/internet/articles/xmledi.shtml)
Одноступенчатое формирование XML-документа
РазвитиеРазвитие— необратимый закономерный процесс, направленный на изменение материальных и идеальных объектов. Изменение материи и сознания, их универсальное свойство, всеобщий принцип объяснения истории природы, общества и познания. новых тенденций объединения технологий XML и EDI обеспечивает динамичный процесс формирования электронных документов и взаимодействия между информационными системами. Тенденция объединения XML и EDI является наиболее перспективным направлениям в использование электронных документов.
Рис. 1
На рис.1 представлена схема вариантов обмена Электронными документами для разных (мелких и крупных) компаний. Крупные компанииЮридическое лицо— созданная и зарегистрированная в установленном законом порядке организация, которая имеет в собственности, хозяйственном ведении или оперативном управлении обособленное имущество и отвечает по своим обязательствам этим имуществом, может от своего имени приобретать и осуществлять имущественные и личные неимущественные права, нести обязанности, быть истцом и ответчиком в суде. Юридические лица должны иметь самостоятельный баланс или смету. продолжают использовать уже имеющие EDI-системыСистема (от др.-греч. — «сочетание»)— множество взаимосвязанных элементов, обособленное от среды и взаимодействующее с ней, как целое. через VAN сеть (сеть с добавленной стоимостью, т.е. предоставление за плату добавочных услуг). Провайдеры предоставляют такую услугу, как подготовка и обмен EDI-сообщениями по средствам корпоративных сетей. Более мелкие компании, используя технологию XML/EDI осуществляют обмен через Internet.
Один из самых простых вариантов обмена используя XML/EDI технологию - это подготовка XML-докуамента на стороне клиента и отправка на XML-сервер компании, где документ проверяется и преобразуется в стандартное EDI - сообщениеСообщение— наименьший элемент языка, имеющий идею или смысл, пригодный для общения. В информатике— форма представления информации, имеющая признаки начала и конца, предназначенная для передачи через среду связи. Также форма предоставления информации, совокупность знаков или первичных сигналов, содержащих информацию. В объектно-ориентированном программировании — средство взаимодействия объектов, где передача сообщения объекту — процесс вызова метода этого объекта с содержимым сообщения (необходимыми параметрами) или без такового (параметры по умолчанию) при условии, что он готов его принять (вызываемый метод является открытым). и будет передан по IntranetИнтранет (англ.Intranet, также употребляется термин интрасеть)— в отличие от сети Интернет, это внутренняя частная сеть организации. Как правило, Интранет— это Интернет в миниатюре, который построен на использовании протокола IP для обмена и совместного использования некоторой части информации внутри этой организации. Это могут быть списки сотрудников, списки телефонов партнёров и заказчиков. Чаще всего под этим термином имеют в виду только видимую часть Интранет— внутренний веб-сайт организации. Основанный на базовых протоколах HTTP и HTTPS и организованный по принципу клиент-сервер, интранет-сайт доступен с любого компьютера через браузер. Таким образом, Интранет— это «частный» Интернет, ограниченный виртуальным пространством отдельно взятой организации. Intranet допускает использование публичных каналов связи, входящих в Internet, (VPN), но при этом обеспечивается защита передаваемых данных и меры по пресечению проникновения извне на корпоративные узлы. на EDI-сервер компании.
Рис. 2
На рис.2 представлена схема формирования XML документа на клиентской стороне. В ходе начала обмена, клиент принимает от XML сервера шаблонШаблон в технике— пластина (лекало, трафарет ит.п.) с вырезами, по контуру которых изготовляются чертежи или изделия либо инструмент для измерения размеров. (формально назовем XML шаблон). Текст простого шаблона на примере XML документа "инвойсИнвойс (англ.invoice) — в международной коммерческой практике документ, предоставляемый продавцом покупателю и содержащий перечень товаров, их количество и цену, по которой они будут поставлены покупателю, формальные особенности товара (цвет, вес и т. д.), условия поставки и сведения об отправителе и получателе. Выписка инвойса свидетельствует о том, что (кроме случаев, когда поставка осуществляется по предоплате) у покупателя появляется обязанность оплаты товара в соответствии с указанными условиями." может иметь следующий вид:
<?xml version="1.0">
<!DOCTYPE InvoiceForm >
<?xml-stylesheet type="text/xsl" server-config="Config.xml"
href=#>
Элемент <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
|
Особой задачей для семантической проверки и разбора XML документа и формирования EDIFACT сообщения является разработка Таблицы определения данных - DTD. При разработке DTD, учитывая иерархическую структуру EDIFACT сообщения, разрабатывается объектная модель документа - DOM. На рис 3 представлена иерархическая схема сообщения INVOICE.
В рассматриваемом 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-систему, где и происходит обработка сообщения.
Двухступенчатое преобразование 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">
<!-- содержание сегмента 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 |
Возвращаясь к нашему примеру, кодировка в 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>;, имеющие значение параметра 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.
Автор будет очень благодарен за отзывы об актуальности темы, общем содержании, виде и стиле изложения, а также всем остальным комментариям, которые помогут в дальнейшем улучшить качество написания сборника статей и выпуску книги освещающую тему использования электронных документов. Также автору будет интересно узнать пожелания читателей об освещении смежных тем, связанных с использованием электронных документов и электронной коммерции. Свои комментарии и пожелания просьба направлять на akalend@mail.ru Автор постарается ответить на вопросы, связанной с изложенным материалом или осветить их в будущем.
| 
