Спецификация xml для электронного обмена данными
Изобретение относится к средствам для электронного обмена данными (ЭОД). Техническим результатом является повышение эффективности обработки ЭОД-транзакций. В способе для преобразования транзакций электронного обмена данными принимают в пакете совокупность данных ЭОД. Пакет данных ЭОД включает в себя множество документов ЭОД, и каждый из множества документов ЭОД содержит, по меньшей мере, одну ЭОД-транзакцию, соответствующую некоторому типу транзакции. Идентифицируют ЭОД-транзакции, идентифицируют множество экземпляров идентифицированных ЭОД-транзакций, идентифицируют повторяющиеся структурные элементы ЭОД-транзакций. Из документов ЭОД в пакете данных ЭОД генерируют объединенный документ ЭОД. Объединенный документ ЭОД включает в себя идентифицированные ЭОД-транзакции, организованные согласно типу транзакции. 3 н. и 16 з.п. ф-лы, 27 ил., 4 табл.
Уровень техники
Для облегчения обработки транзакций организации часто передают данные о деловых операциях в строгом формате по обычным сетям связи. Например, одним из способов, при помощи которых организации с выгодой для себя используют получающие все большее распространение автоматизированные вычислительные системы, является электронный обмен данными (ЭОД).
В ЭОД деловая информация форматируется согласно одному или нескольким известным и утвержденным стандартам, таким как ANSI X12 или EDIFACT. Например, данные ЭОД, представляющие различные транзакции, передаются в виде пакета разграниченных документов, и каждый из разграниченных документов кодируется в соответствии со строгими правилами форматирования, обеспечивающими, чтобы приложение-получатель, принимающее документы, могло успешно выполнить синтаксический анализ и потребление информации для дальнейшей обработки.
При проведении синтаксического анализа и обработке сообщений ЭОД существующие системы передают данные ЭОД и в процессе обмена включают правила или схемы форматирования в каждый разграниченный документ. Например, данные ЭОД, представляющие транзакцию заказа на поставку, включают в себя схему для транзакции заказа на поставку. Таким образом, каждый документ ЭОД, содержащий транзакцию, включает в себя как данные ЭОД, так и конкретную схему для транзакции. Хотя такая компоновка или конфигурация облегчает синтаксический анализ данных ЭОД, она является статической и делает большим каждый транзакционный документ с точки зрения размера документа. Кроме того, включенная в него схема не является совместно используемой. Иными словами, если имеются транзакционные документы A и B с заказами на поставку, каждый транзакционный документ с заказом на поставку должен включать в себя схему заказа на поставку, даже если в каждом документе используется одинаковая схема. Кроме того, плата за ЭОД-транзакции взимается, в частности, в зависимости от числа строк в документе и требуется определенная пропускная способность для передачи данных ЭОД. Поскольку организации передают ежедневно миллионы транзакций при помощи ЭОД, такие большие документы ЭОД-транзакций, в которых дублируется информация о схеме, приводят к излишним расходам из-за наличия избыточной информации о схеме.
После приема документов ЭОД-транзакций приложение-получатель обычно хранит документы ЭОД-транзакций в области памяти. Затем приложение-получатель передает подтверждение приема источнику с указанием, что транзакции приняты. Затем сохраненные ЭОД-транзакции проверяются приложениями, которые проверяют, соответствуют ли ЭОД-данные, содержащиеся в документах транзакции, правилам форматирования схем для этих типов транзакций. Во время этой проверки источнику (например, торговцу или заказчику) необходимо подождать подтверждения проверки правильности, указывающей, что данные транзакции соответствуют формату. Если установлено, что одна или более транзакций сформатированы неправильно, для обработки необходимо повторно передать заменяющие документы ЭОД-транзакций. Эта задержка на ожидание проверки подлинности еще более снижает эффективность обработки ЭОД-транзакций.
Сущность изобретения
Варианты осуществления настоящего изобретения преодолевают недостатки существующих систем при обработке ЭОД-транзакций посредством преобразования файлов ЭОД-транзакций в ЭОД-документ с вложенными структурами или поддокументами, определяющими различные типы ЭОД-транзакций. Кроме того, аспекты изобретения позволяют ЭОД-документу давать ссылку на схему посредством обеспечения доступности экземпляров схем во время обработки ЭОД-транзакций. Варианты осуществления изобретения предпочтительно автоматически распознают схемы, связанные с типами транзакций, и обрабатывают ЭОД-транзакции по мере приема ЭОД-транзакций. Согласно другим вариантам осуществления изобретения правильность ЭОД-транзакций проверяется по мере приема ЭОД-транзакций.
В еще одном варианте осуществления изобретения задается единая метасхема, представляющая множество схем. Единая метасхема предоставляется конечным пользователям для модификации свойств схем.
Настоящее описание краткой сущности приведено для ознакомления с некоторыми идеями в упрощенном виде, которые будут описаны далее в подробном описании. Настоящее описание краткой сущности не предназначено для выявления основных или существенных характерных особенностей заявленного изобретения и не предназначено для использования в качестве вспомогательного средства для определения объема заявленного изобретения.
Другие характерные особенности будут отчасти очевидны и отчасти указаны ниже.
Краткое описание чертежей
Фиг.1 - блок-схема, иллюстрирующая реализацию обработки ЭОД-транзакций.
Фиг.2A-2C - диаграммы, иллюстрирующие структуру транзакционных данных, использующих электронный обмен данными (ЭОД) согласно варианту осуществления изобретения.
Фиг.3 - пример блок-схемы, иллюстрирующей систему для преобразования ЭОД-транзакций согласно варианту осуществления изобретения.
Фиг.4A и 4B - блок-схемы последовательности действий, иллюстрирующие преобразование ЭОД-транзакций согласно варианту осуществления изобретения.
Фиг.5A - блок-схема, иллюстрирующая вложение ЭОД-транзакции согласно варианту осуществления изобретения.
Фиг.5B и 5C - блок-схемы, иллюстрирующие преобразование ЭОД-транзакций в последовательный вид согласно варианту осуществления изобретения.
Фиг.6A и 6B - "снимки экрана", иллюстрирующие преобразованные ЭОД-транзакции, включенные в объединенный документ ЭОД в формате документа расширяемого языка разметки (XML) согласно варианту осуществления изобретения.
Фиг.7A-7D - "снимки экрана", иллюстрирующие автоматически идентифицирующие схемы ЭОД согласно варианту осуществления изобретения.
Фиг.8A - блок-схема последовательности действий, иллюстрирующая подтверждение правильности ЭОД-транзакций согласно варианту осуществления изобретения.
Фиг.8B - диаграмма, иллюстрирующая обнаружение ошибок в ЭОД-транзакциях согласно варианту осуществления изобретения.
Фиг.9A и 9B - диаграммы, иллюстрирующие структуры подтверждения проверки правильности ЭОД согласно варианту осуществления изобретения.
Фиг.10 - "снимок экрана", иллюстрирующий единую метасхему для модификации множества схем ЭОД согласно варианту осуществления изобретения.
Фиг.10A - блок-схема последовательности действий, иллюстрирующая способ модификации множества ЭОД-схем с использованием единой метасхемы согласно варианту осуществления изобретения.
Фиг.11A и 11B - блок-схема, иллюстрирующая пример машиночитаемого носителя, на котором могут храниться аспекты изобретения.
Фиг.12 - блок-схема, иллюстрирующая один пример подходящей среды вычислительной системы, в которой может быть реализовано изобретение.
В Приложении A полностью описывается схема XML, приведенная на фиг.10A.
В Приложении B приведен пример единой метасхемы в формате XML, представляющий схему заказа на покупку.
На всех чертежах соответствующие обозначения позиций указывают на соответствующие детали.
Подробное описание
На фиг.1 приведена блок-схема, иллюстрирующая обработку ЭОД-транзакций. Вначале, как показано на фиг.1, источник (например, деловой партнер) 102 передает сообщение ЭОД 106, которое может включать в себя счет-фактуру 202, получателю (например, компании-заказчику) 104 через обычную сеть 108 связи.
Источник 102 передает сообщение ЭОД 106, включающее в себя схемы и данные ЭОД-транзакций, получателю 104 по общей сети 108 связи. В одном примере сообщение ЭОД 106 включает в себя множество данных ЭОД-транзакций в пакете для экономии затрат на передачу или пропускную способность. В другом примере обычная сеть связи 108 может быть частной, специализированной сетью, такой как интрасеть, или общедоступной сетью, такой как Интернет. В другом примере обычная сеть 108 связи включает в себя один или несколько протоколов, таких как FTP, HTTP, Kermit, Xmodem, с задержкой кадров, EDIINT, 3780 Bisync® или аналогичные, для облегчения передачи сообщений ЭОД между партнерами.
Источник 102 инициирует передачу сообщения ЭОД 106 посредством открытия сеанса соединения (например, сеанса безопасного соединения через сокет) с получателем 104 через обычную сеть 108 связи. После открытия сеанса соединения источник 102 передает сообщение ЭОД 106 получателю 104. Набор систем 110 трансляторов ЭОД, имеющийся у получателя 104, принимает сообщение ЭОД 106, и системы 110 трансляторов ЭОД передают подтверждение 112 приема источнику 102 через обычную сеть 108 связи, указывающее, что сообщение ЭОД было получено. Обычно подтверждение приема передается или возвращается источнику 102 до того, как источник 102 закроет сеанс связи.
После получения сообщения ЭОД 106 данные ЭОД, связанные с ЭОД-транзакцией, подвергаются синтаксическому анализу и обрабатываются системами 110 трансляторов ЭОД. Как известно специалистам в данной области техники, синтаксический анализ и декодирование ЭОД-транзакции включает в себя один или несколько этапов идентификации различных стандартов ЭОД, спецификаций схем и т.п. При этом системы 110 трансляторов ЭОД передают данные ЭОД, подвергшиеся синтаксическому анализу или декодированию, нижележащему приложению 114 для обработки данных ЭОД, подвергшихся синтаксическому анализу или декодированию. Например, нижележащее приложение 114 может быть бухгалтерским приложением для обработки счетов-фактур или программным обеспечением для обработки данных о заказах на поставку. Таким образом, нижележащее приложение 114 может проверить, соответствуют ли принятые данные ЭОД после синтаксического анализа или декодирования правилам форматирования, задаваемым схемами. Если принятые данные ЭОД соответствуют правилам схем, нижележащее приложение 114 передает подтверждение 116 правильности источнику 102. Если же принятые данные ЭОД включают в себя ошибки или являются неправильными, нижележащее приложение 114 может передать источнику уведомление об ошибке с указанием ошибки в принятых данных ЭОД.
Подтверждение 116 правильности обычно передается источнику 102 через некоторое время после передачи подтверждения приема. В других вариантах осуществления данные ЭОД, подвергшиеся синтаксическому анализу, хранятся в базе данных или хранилище данных (не показано) в ожидании проверки правильности. Таким образом, источнику 102 часто требуется ждать подтверждения 116 правильности, чтобы быть уверенным, что данные ЭОД могут быть надлежащим образом обработаны получателем.
На фиг.2A-2C приведены диаграммы, иллюстрирующие структуры транзакционных данных, использующие электронный обмен данными (ЭОД), согласно варианту осуществления изобретения. На фиг.2A приведен пример представления документа 202 ЭОД-транзакции счета фактуры с использованием формата ANSI X12. В этом примере счет-фактура 202 включает в себя ряд сегментов или разделов (об общем представлении о структуре 218 ЭОД-обмена X12 см. фиг.2C), таких как секция функциональной группы 204, которая может содержать дополнительную информацию о счете-фактуре 202. Например, специалистам в данной области техники известно, что в сфере цепочек поставок информация и значения в функциональной группе 204 идентичны информации и значениям в секции обмена данными (например, в заголовке управления обменом данными), как показано на фиг.2C. В другом примере информация или значения в функциональной группе 204 включают в себя значения или идентификаторы для идентификации коммерческого или структурного подразделения более крупного предприятия.
Счет-фактура 202 также включает в себя заголовочную часть 206, которая содержит такую информацию, как информация о компании-заказчике. В данном примере заголовочная часть 206 включает в себя название компании-заказчика "Компания ABC" и адрес "0887 Шестая улица, Сент-Луис, штат Миссури 63101." В одном варианте осуществления заголовочная часть 206 включает в себя информацию о том, где принимать подтверждения правильности, см. описание, связанное с фиг.8, 9A и 9B. Счет-фактура 202 также включает в себя раздел (секцию) 208 таблицы отдельных позиций, содержащий один или несколько сегментов 212 данных, которые организованы в цикл 210. Например, цикл 210 включает в себя группу сегментов семантически связанных данных, и для специалистов в данной области техники эти сегменты могут быть либо ограниченными, либо неограниченными согласно ANSI X12.6.
Не выходя за рамки объема изобретения, в документ ЭОД-транзакции в соответствии с форматом ANSI X12 или EDIFACT можно включить дополнительные типы и разделы сегментов и соответствующую информацию. Например, на фиг.2B приведены одна или более типов транзакций, включенных в одно сообщение ЭОД 106, которое подлежит обработке получателем 104. Документы ЭОД-транзакций счета-фактуры 214 и заказа 216 на поставку включаются в сообщение ЭОД 106, поскольку счет-фактура 214 и заказ 216 на поставку относятся к одном заказчику - "Компании ABC". В обмен данными в виде сообщения ЭОД 106 могут быть включены дополнительные группы связанных транзакционных документов. В одном варианте осуществления документы ЭОД для одного получателя или заказчика могут направляться в пакете.
Должно быть также понятно, что каждый тип ЭОД-транзакции должен соответствовать схеме, связанной с данным типом транзакции. Например, схема транзакции счета-фактуры может требовать, в частности, некоторых ограничений на максимальную или минимальную длину символов для названия торговца или покупателя. Транзакция заказа на поставку может требовать максимального числа цифр после запятой. В другом примере схема для различных типов транзакций может указывать, что некоторые графы являются обязательными, а другие - необязательными.
Существующие варианты реализации включают схемы транзакций в документы ЭОД-транзакций при передаче ЭОД-транзакций заказчику, такому как получатель 104. Хотя эти варианты реализации облегчают декодирование ЭОД-транзакций, они требуют от разработчиков схем значительных временных затрат на разработку и конфигурирование схем перед передачей ЭОД-транзакций деловым партнерам. Кроме того, для переконструирования схемы требуется внести последующие модификации в схемы вследствие изменения деловых соглашений между партнерами.
Таким образом, варианты осуществления настоящего изобретения преодолевают недостатки существующих вариантов реализации посредством преобразования сообщения ЭОД в объединенный документ ЭОД с вложенными структурами или поддокументами, организующими одну или несколько ЭОД-транзакций согласно типам транзакций. ЭОД-документ также включает в себя надсхему для представления множества схем, связанных с типами транзакций. В другом варианте осуществления множество схем преобразуются картой отображения схем во время выполнения для обработки во время выполнения в адресате (получателе) 104.
Блок-схема, приведенная на фиг.3, иллюстрирует систему 302 для преобразования ЭОД-транзакций согласно варианту осуществления изобретения. Система 302 включает в себя источник 304, который может быть торговым предприятием, совершающим деловые операции с получателем 306 или заказчиком. Например, источником 304 может быть торговое предприятие, такое как розничный магазин бытовой электроники, продающий большое количество товаров корпоративному заказчику, приобретающему вычислительное оборудование. В другом примере источником может быть организация здравоохранения, такая как больница или аптека, которая передает данные ЭОД страховой компании или расчетной палате для подачи заявок или с целью выполнения положений, предусмотренных Законом по обеспечению доступности и подотчетности в медицинском страховании (HIPAA).
В одном варианте осуществления источник 304 и получатель 306 включают в себя одно или несколько вычислительных устройств, таких как компьютер 130 на фиг.12, для отправки документов ЭОД в пакете. Вначале источник 304 передает сообщение 310 ЭОД, содержащее множество документов ЭОД. Каждый из документов ЭОД содержит по меньшей мере одну ЭОД-транзакцию, соответствующую некоторому типу транзакции (например, счету-фактуре, заказу на поставку, счету к оплате и т.п.)
Если обратиться также к фиг.4A, то на ней изображена блок-схема последовательности действий по преобразованию ЭОД-транзакции согласно варианту осуществления изобретения. После того как источник 304 открывает сеанс связи в сети 308 связи для установления связи с получателем 306, источник 304 передает сообщение 310 ЭОД ЭОД-механизму 312 получателя 306. В одном варианте осуществления ЭОД-механизм 312 включает в себя одно или несколько вычислительных устройств (например, компьютер 130), выполняющих машиноисполняемые команды, программы или функции. На этапе 402 ЭОД-механизм 312 принимает сообщение 310 ЭОД, содержащее множество документов ЭОД. На этапе 404 ЭОД-механизм 312 идентифицирует ЭОД-транзакции, включенные в множество документов ЭОД. При помощи вышеприведенного примера ANSI X12 ЭОД-механизм 312 декодирует и осуществляет синтаксический анализ счета-фактуры X12 посредством идентификации различных заголовков данных и сегментов данных (например, ISA, GS и т.п.), приведенных на фиг.2C, для обнаружения данных ЭОД в транзакции. В другом варианте осуществления ЭОД-механизм 312 идентифицирует также различные схемы, включенные в множество документов ЭОД, для определения конкретных правил форматирования для данных типов транзакций.
На этапе 406 ЭОД-механизм 312 создает объединенный документ 314 ЭОД из множества документов ЭОД в пакете. В одном примере на этапе 410 ЭОД-механизм 312 создает объединенный документ 314 ЭОД в виде документа XML с тегами разметки структуры XML. Например, в отличие от существующих вариантов реализации, когда каждая транзакция организуется в виде одного документа, варианты осуществления изобретения организуют ЭОД-транзакции во множестве документов ЭОД в виде одного документа XML, который не только определяет отдельные наборы транзакций, но также предназначен для определения обменов данными посредством охвата всех аспектов данных ЭОД, в том числе сегментов, циклов, полей, разделителей и т. д. В одном примере, приведенном на фиг.6A, пример объединенного документа XML включает в себя одну или несколько ЭОД-транзакций, таких как "заказ на поставку".
В еще одном варианте осуществления изобретения объединенный документ 314 ЭОД содержит надсхему, представляющую множество схем, на которые ссылаются ЭОД-транзакции. Например, надсхема включается в набор ЭОД-транзакций и встраивается или вшивается внутрь функциональных групп или охватывающих сегментов каждых ЭОД-транзакций, так что конечному пользователю не требуется создавать конкретную схему для каждого набора транзакций, которые предполагается включить в сообщение 310 ЭОД. В качестве примера на фиг.6B приведен "снимок экрана" с изображением надсхемы в формате XML в объединенном документе 314 ЭОД согласно варианту осуществления изобретения. При такой модели обмен объединенным документом 314 ЭОД в меньшей степени требует включения в себя одной или более схем, соответствующих типу транзакции в документах ЭОД. Варианты осуществления изобретения также сокращают время на разработку и конструирование схемы перед передачей.
В другом варианте осуществления на этапе 412, приведенном на фиг.4B, ЭОД-механизм 312 преобразует объединенный документ ЭОД при помощи карты отображения схем во время выполнения или схемы полезной информации. На этапе 414 ЭОД-механизм 312 создает поддокументы или вложенные структуры для ЭОД-транзакций в объединенном документе 314 ЭОД (для более подробного описания см. таблицы 1 и 2). В альтернативном варианте осуществления объединенный документ 314 ЭОД преобразуется посредством схемы полезной информации (например, карты отображения схем во время выполнения) и может также быть структурно преобразован на этапе 416. Альтернативно, на этапе 418 объединенный документ 314 ЭОД может быть передан нижележащему приложению 316 на обработку без структурной информации. На этапе 420 объединенный документ 314 ЭОД с поддокументами или вложенной структурой также передается нижележащему приложению 316 на обработку.
Должно быть понятно, что, не отступая от объема изобретения, можно использовать другие форматы, отличные от XML, для объединенного документа 314 ЭОД с тегами разметки, определяющими и организующими ЭОД-транзакции в идентифицируемых структурах.
В другом варианте осуществления машиночитаемый носитель 1102 (на фиг.11A), на котором могут храниться описанные выше аспекты изобретения. Например, интерфейсный компонент 1104, идентифицирующий компонент 1106 и преобразующий компонент 1108 могут содержаться в ЭОД-механизме 312, выполняющем одну или несколько рассмотренных выше операций.
Должно быть также понятно, что способ, приведенный на фиг.4A, может выполняться источником 304, так что источник 304 сокращает объем обмена данными до передачи. Таким образом, вложенная структура и поддокументы объединенного документа 314 ЭОД сокращают число строк, что может также сократить стоимость передачи данных ЭОД, когда плата взимается за число строк.
Например, в таблице 1 приведены три ЭОД-транзакции во вложенной структуре в объединенном документе ЭОД и три соответствующих первоначальных документа ЭОД, каждый из которых включает в себя одну из трех транзакций ЭОД.
| Таблица 1 | |
| Три ЭОД-транзакции во вложенной структуре (левый столбец) и в трех документах ЭОД (правый столбец) | |
| ЭОД-транзации во вложенной структуре | Развернутые ЭОД-транзации для последующей обработки |
| BeginOfTransaction#1 POHeaderSegment POLine1 POSchedule1.1 POSchedule1.2 POLine1Totals POLine2 POSchedule2.1 POLine2Totals POTotals EndOfTransaction#1 |
BeginOfTransaction#1a POHeaderSegment POLine1 POSchedule1.1 POLine1Totals POTotals EndOfTransaction#1a BeginOfTransaction#1b POHeaderSegment POLine1 POSchedule1.1 POLine1Totals POTotals EndOfTransaction#1b BeginOfTransaction#1c POHeaderSegment POLine1 POSchedule1.1 POLine1Totals POTotals EndOfTransaction#1c |
Предположим, что в процессе работы лицу, финансирующему услуги здравоохранения, например работодателю A, необходимо послать сообщение ЭОД, такое как документ HIPAA 834, плательщику, такому как организация здравоохранения B. Схема такого обмена требует, чтобы Работодатель A представил сведения о пособиях, предоставленных получателям услуг здравоохранения (например, сотрудникам или их иждивенцам). Поэтому Работодатель A обычно включает подробные сведения о реквизитах финансирующего лица и плательщика. Эти подробные сведения о реквизитах финансирующего лица и плательщика являются общими для всех получателей пособий и повторяются для каждого сотрудника или иждивенца, который получает пособие, финансируемое Работодателем A. Вместо того чтобы повторять одинаковые сведения о финансирующем лице и плательщике для тысяч сотрудников и иждивенцев, как делается в существующих реализациях ЭОД, варианты осуществления изобретения создают вложенную структуру, так что каждый элемент можно создать вместе с копией сведений о реквизитах спонсора и плательщика посредством циклообразной логики в одном документе ЭОД.
На фиг.5 приведена блок-схема, иллюстрирующая вложение ЭОД-транзакции согласно варианту осуществления изобретения. Например, на этапе 502 сообщение ЭОД (например, сообщение 310 ЭОД) принимается от источника (например, от источника 304) получателем (например, получателем 306). На этапе 504 создается объединенный документ ЭОД с ЭОД-транзакциями, включенными во вложенную структуру или в виде поддокументов. В одном примере охватывающие/управляющие сегменты (например, сегменты ISA/GS/GE/IEA в формате ANSI X12) удаляются, и транзакционный набор подвергается синтаксическому разбору приемным конвейером для генерации множества поддокументов XML в расчете на каждый транзакционный набор. В одном варианте осуществления множество поддокументов XML хранится в хранилище сообщений. На этапе 506 приемный конвейер у получателя осуществляет проверку правильности поступившего обмена и генерирует соответствующее подтверждение правильности (что подробно рассмотрено на фиг.8, 9A и 9B). В одном варианте осуществления приемный конвейер также обновляет контрольную сумму и итоговые данные экономической деятельности.
Как описано выше, объединенный документ 314 ЭОД может быть обработан нижележащим приложением 316. В этом случае объединенный документ ЭОД отправляется в порт отправки, и на этапе 508 порт отправки передает ЭОД-транзакции в поддокументах ЭОД. В одном варианте осуществления конвейер отправки, связанный с портом отправки, преобразует поддокументы XML в последовательную форму и отправляет "n" обменов данными с числом сегментов, обновляемых конвейером отправки.
В одном варианте осуществления при приеме обмена ЭОД он подвергается проверке на правильность. Если при проверке на правильность ошибок не обнаружено, каждый транзакционный набор преобразуется в формат XML в соответствии со своей схемой. Таким образом, обмен ЭОД может содержать документы с заказами на поставки и счетами-фактурами. Заказы на поставки преобразуются в XML, который согласуется со схемой заказа на поставку. Аналогично, счет-фактура преобразуется в счет-фактуру XML.
На фиг.5B приведен пример заказа на поставку из обмена ЭОД в формате XML. Когда документ заказа на поставку обрабатывается отправляющей стороной на фиг.5 A, он преобразуется в формат 514 ЭОД после обработки охватывающих сегментов. На фиг.5C приведен пример документа, создаваемого портом отправки из формата XML на фиг.5B. В одном варианте осуществления формат 514 ЭОД включает в себя два охватывающих сегмента (например, строки, которые начинаются с ISA и GS). Аналогично, формат 514 ЭОД включает в себя два охватывающих сегмента, GE и IEA, в конце документа. Как показано на чертеже, данные, включенные между сегментами ST и SE, представляют собой данные первоначального транзакционного набора.
В вышеприведенном примере, проиллюстрированном фиг.5B и 5C, значение SE0l (см. стрелку 512) равно "14" и вычисляется динамически портом отправки. При преобразовании документа ЭОД в последовательную форму отправляющая сторона отправки ЭОД-механизма (например, ЭОД-механизма 312) отслеживает число сегментов, имеющихся в транзакционном наборе. На основе этого значения определяется значение SE01.
Когда источник 304 создает объединенный документ 314 ЭОД для включения в него ЭОД-транзакций из множества ЭОД-документов, варианты осуществления изобретения включают в себя организацию включенных ЭОД-транзакций во вложенную структуру. В другом примере варианты осуществления изобретения дают возможность получателю 306, который принимает от источника объединенный документ 314 ЭОД, восстановить множество документов ЭОД из объединенного документа 314 ЭОД с целью обратной совместимости или обеспечения возможности использования нижележащего приложения 316, которое может обрабатывать только такие документы ЭОД, которые содержат одну транзакцию на документ. Альтернативные варианты осуществления изобретения позволяют отслеживать или коррелировать объединенный документ ЭОД с ЭОД-транзакциями во вложенных структурах с первоначальным множеством документов ЭОД.
Например, в таблице 2 приведено преобразование ЭОД-транзакций из объединенного документа 314 ЭОД в множество документов ЭОД.
| Таблица 2 | ||||
| Преобразование объединенного документа ЭОД | ||||
| A0 | A1 | A2 | A3 | A4 |
| Схема (мин. происходит и макс. происходит) | Первоначальный экземпляр | Расщепление №1 | Расщепление №2 | Расщепление №3 |
| ST(1,0) AA(1,1) BB loop (1,n)-sub doc break = yes BB1(1,1) BB2(0,1) CC(1,n) DD(0,n) SE |
ST AA BB1*1 BB2*1 BB1*2 BB1*3 BB2*3 CC CC DD SE |
ST AA BB1*1 BB2*1 CC CC DD SE |
ST AA BB1*2 CC CC DD SE |
ST AA BB1*3 BB2*3 CC CC DD SE |
В примере, приведенном в таблице 2, обработка ЭОД-транзакций во вложенной структуре начинается с идентификации заданной SubDocumentCreationBreakPoint (например, метки "\", которая описывает, где внутри материнского документа начинается дочерний документ) для генерации множества поддокументов.
Согласно таблице 2 объединенный документ ЭОД, приведенный в столбце A1, может быть расщеплен на три транзакции в соответствии с разбиением на поддокументы, определенным в цикле BB схемы: BB1*1-BB2*1, BB1*2 и BB1*3-BB2*3. В столбце A2 транзакционный набор BB1*1-BB2*1 (обозначенный полужирным шрифтом) организуется или выделяется в отдельный документ, в столбце A3 транзакция BB1*2 организуется во второй документ (обозначенный подчеркнутым шрифтом). Аналогично транзакционный набор BB1*3-BB2*3 организуется в третий документ ЭОД (обозначенный курсивным шрифтом), который затем подлежит обработке нижележащим приложением 316.
Преобразуя ЭОД-транзакции, включенные в множество документов ЭОД, в объединенный документ 314 ЭОД, варианты осуществления изобретения позволяют получателю 306 или источнику 304 эффективно идентифицировать множество схем, включенных в каждый документ ЭОД в процессе преобразования. Кроме того, по меньшей мере один аспект изобретения позволяет получателю 306 после преобразования объединенного документа ЭОД сгенерировать подтверждение правильности, которое должно вернуться источнику 304 в течение времени, когда сеанс связи еще открыт. Иными словами, аспекты изобретения обеспечивают получателю 306 возможность автоматически идентифицировать множество схем и проверять правильность ЭОД-транзакций во время получения ЭОД-транзакций.
На фиг.7A-7D изображен ряд "снимков экрана", иллюстрирующих автоматическую идентификацию схем ЭОД согласно варианту осуществления изобретения. На фиг.7A изображена типичная схема ANSI X12 заказа на покупку. Схема идентифицируется посредством связанного с ним DocType. DocType представляет собой сочетание пунктов конфигурации, таких как область имен, и имени корневого узла. Как показано на фиг.7A, левый столбец 702 "снимка экрана" показывает иерархическую структуру схемы. В данном примере в левом столбце 702 приведена структура схемы. Средний столбец 704 показывает XML-код схемы. В правом столбце 706 показаны свойства или целевое пространство имен, включенных в схему.
В одном варианте осуществления DocType имеет следующий формат: "DocType = TargetNamespace '#' RootNodeName" в формате X12, который более подробно описан ниже. Должно быть понятно, что, хотя на фиг.7A описана схема X12, в рамках объема изобретения можно использовать и другие форматы схем, например схемы EDIFACT.
Корневой узел DocType имеет в X12 один из следующих форматов: "X12_{Version}_{TsId}". В данном примере значение пункта конфигурации "root node" равно "X12_00401_850", как показано рамкой 708. Иными словами, "00401" является версией документа, и это - динамическая информация, которая определяет конфигурацию или экземпляр обработки во время выполнения. Аналогично, "850" - это TsId, что представляет собой идентификационные данные (ID) транзакции для схемы, которая подвергается обработке и определяется по входному экземпляру. В данном примере транзакция с ID "850" представляет заказ на поставку, как показано в рамке 710. Кроме того, целевая область имен указана в рамке 712 в правом столбце 706.
В другом примере для декодирования или идентификации схем в формате EDIFACT схемы EDIFACT в настоящее время имеют следующий формат: "Efact_{Version}_{Tsid}". Иными словами, у всех схем EDIFACT имя корневого узла начинается с "Efact," а определения для Version и Tsid те же, что и для формата X12.
Если воспользоваться фиг.3 в качестве примера, то, когда получатель 306 принимает документ ЭОД от источника 304, ЭОД-транзакции могут включать в документ ID транзакции "850". Однако информация о версии или информация о целевой области имен определяется во время выполнения, и значения этих пунктов конфигурации могут конфигурироваться на различных уровнях. Поэтому после применения правил в соответствии со стандартами ЭОД (например, X12 или EDIFACT) для декодирования ЭОД-транзакции в соответствии с соответствующими типами транзакций (например, заказом на поставку, счетом-фактурой и т.п.) ЭОД-механизм 312 идентифицирует пункты конфигурации в декодированных ЭОД-транзакциях. В одном варианте осуществления ЭОД-механизм 312 идентифицирует пункты конфигурации из одного или нескольких уровней конфигурации, таких как партнерский уровень и уровень отправляющего приложения, глобальный уровень, конвейерный уровень или стандартный уровень.
Например, на фиг.7B приведен "снимок экрана" с изображением пунктов конфигурации в конфигурации на уровне сторон. В данном примере ID 850 транзакции для вышеуказанного партнера, приведенной на фиг.7A, сконфигурирован для использования целевой области имен и информации о версии, приведенных выше. Для всех других типов документов используются стандартные значения, поскольку указан флаг или параметр "стандартный" (default), как показано в рамке 714. В другом примере другой торговый партнер может установить другие конкретные пункты конфигурации при конфигурации на уровне сторон на основе деловых соглашений, установленных между деловыми торговыми партнерами. Вместо статического определения значения пунктов конфигурации варианты осуществления изобретения при автоматической идентификации схем идентифицируют значения пунктов конфигурации посредством определения конкретных значений, которые установлены торговыми партнерами из одного или нескольких уровней конфигурации.
В одном варианте осуществления значения пунктов конфигурации при конфигурации на уровне сторон могут быть сконфигурированы равными значениям, отличным от тех, что приведены в DocType на фиг.7A, вследствие конкретного сочетания Id отправителя и Id транзакции. Например, в X12 каждый Id отправителя может представлять некоторый отдел на предприятии. Поэтому ID отправителя на одном предприятии может означать отдел "товаров аппаратного обеспечения", тогда как другой ID отправителя может означать отдел "товаров программного обеспечения" на том же предприятии. Таким образом, варианты осуществления изобретения распознают эти различные конфигурации и идентифицируют схемы соответствующим образом. В результате, один и тот же заказ на поставку от одного предприятия может подвергаться идентификационному процессу по различным схемам, так чтобы генерировались соответствующие и различные данные ЭОД в XML, например, в объединенном документе 314 ЭОД в соответствии со значениями пунктов конфигурации.
Должно быть также понятно, что конкретным деловым партнером могут быть сконфигурированы или установлены один или несколько дополнительных пунктов конфигурации без отклонения от объема изобретения. Например, один партнер может установить минимальный объем конфигурации, тогда как другой партнер может подробно задать пункты конфигурации при конфигурации на уровне сторон.
На фиг.7C приведен "снимок экрана", иллюстрирующий схему EDIFACT с ее конфигурацией на уровне сторон. В этом примере в отличие от схем X12 целевая область имен может быть сконфигурирована на основе конкретного сочетания ID приложения отправителя (необязательно) (такого как UNG2.1 в 716 и UNG2.2 в 718), версии 720 (UNG8) и ID транзакционного набора 722. Иными словами, можно иметь множество конфигураций для документа ЭОД со счетом-фактурой, каждая из которых имеет уникальный ID приложения. В данном примере во время выполнения будет использоваться целевая область имен, соответствующая конкретному приложению. В ситуации, когда никакой ID приложения отправителя не сконфигурирован, значение ID приложения отправителя может сопоставляться с любым значением из имеющихся записей (например, регистрационных файлов), которые содержат тот же самый ID транзакции. В случае обнаружения множества соответствий используется стандартная целевая область имен, чтобы обеспечить использование подходящего стандартного значения в случае, когда имеется неоднозначность.
На фиг.7D приведен снимок экрана, иллюстрирующий конфигурацию глобального уровня для схемы X12. В данном примере в случае, когда пункты конфигурации, такие как целевая область имен или версия, не заданы торговыми партнерами, используются значения пунктов конфигурации в конфигурации глобального уровня. В данном примере рамка 724 указывает, что значения для версии и целевой области имен не сконфигурированы. Поэтому значения пунктов конфигурации не меняются во время выполнения.
В ситуации, когда некоторые из пропущенных на глобальном уровне пунктов конфигурации не сконфигурированы, используются значения для пунктов конфигурации на конвейерном уровне или уровне выполнения. Таким образом, если на глобальном уровне не сконфигурирована целевая область имен, используются значения из конфигурации на конвейерном уровне. В одном варианте осуществления значения в конфигурации на конвейерном уровне могут быть установлены пользователем.
В другом варианте осуществления на фиг.11B приведен машиночитаемый носитель 1110, на котором могут храниться аспекты изобретения. Например, интерфейсный компонент 1112 принимает от источника ЭОД в пакете, причем каждый документ ЭОД содержит по меньшей мере одну ЭОД-транзакцию, соответствующую некоторому типу транзакции. Транзакционный компонент 1114 декодирует ЭОД-транзакции согласно соответствующим типам транзакции посредством применения правил согласно стандартам ЭОД (например, X12 или EDIFACT). Конфигурационный компонент 1116 идентифицирует значения в одном или нескольких пунктах конфигурации для каждой ЭОД-транзакции в декодированных ЭОД-транзакциях. Схемный компонент 1118 определяет одну или несколько схем на основе значений пунктов конфигурации.
В альтернативном варианте осуществления значения пунктов конфигурации, описанные в предыдущих разделах, могут быть модифицированы во время выполнения. Так, значения для типов транзакций, целевой области имен, версии могут быть модифицированы после того, как ЭОД-механизм 312 обработает документы ЭОД (то есть автоматически идентифицирует схемы). В таком варианте осуществления изменения будут отражаться на последующих документах, которые еще предстоит обработать. Такая динамическая реализация изобретения позволяет пользователям на получающей стороне 306 конфигурировать значения во время выполнения, а не во время разработки/конфигурирования схемы перед отправкой документов ЭОД источником 304.
В процессе работы автоматическая идентификация схем дает возможность ЭОД-партнерам ускорить обработку документов ЭОД. В отличие от существующей реализации, когда принимающее соединение и отправляющее соединение необходимо конфигурировать для каждого партнера или для каждого типа документа, ЭОД-механизм 312 обеспечивает автоматическую идентификацию схем, так чтобы значения пунктов конфигурации идентифицировались и определялись во время выполнения, что дает деловым ЭОД-партнерам гибкость при обработке данных ЭОД.
Если вернуться к тому, что по меньшей мере один аспект изобретения включает в себя генерирование подтверждения правильности после приема данных ЭОД, то на фиг.8A приведена блок-схема последовательности действий, иллюстрирующая это свойство. На этапе 802 передается сообщение ЭОД (например, сообщение 310 ЭОД) из источника (например, из источника 304) получателю (например, получателю 306). На этапе 804 сообщение ЭОД, которое содержит ЭОД-транзакции, принимается получателем. Затем на этапе 806 определяется, является ли передача сообщения ЭОД правильной, путем определения, действительно ли сообщение ЭОД предназначено надлежащему получателю. Если определяется, что передача сообщения ЭОД является неправильной, обработка сообщения ЭОД приостанавливается и на этапе 808 генерируется подтверждение неудачного обмена. Если определяется, что обмен сообщения ЭОД является правильным, то затем на этапе 810 определяется, не содержат ли группы ЭОД-транзакций ошибки.
Если группы содержат ошибки, обработка групп ЭОД-транзакций приостанавливается, и на этапе 812 генерируется подтверждение функционального сбоя. Например, спецификация ЭОД может определять число ошибок, которые можно обнаружить в уровнях группы и транзакционного набора. В таблице 3 приведен перечень распространенных ошибок, которые могут возникать при обменах данными ЭОД X12.
| Таблица 3 | |
| Ошибки в функциональных группах - ошибки, относящиеся к сегменту GS/GE | |
| Код | Описание - из перечня кодов AK905 |
| 1 | Функциональная группа не поддерживается |
| 2 | Версия функциональной группы не поддерживается |
| 3 | Отсутствует трейлер функциональной группы |
| 4 | Контрольный номер группы в заголовке и трейлере функциональной группы не согласуются |
| 5 | Число включенных транзакционных наборов не совпадает с фактически подсчитанным |
Например, ЭОД-механизм 312 определяет ошибку, такую как ошибка с кодом 4 "Контрольный номер группы в заголовке и трейлере функциональной группы не согласуются", посредством идентификации шестого значения строки/сегмента GS в сообщение ЭОД. На фиг.8B шестое значение строки GS 532 имеет значение "9" (показано в рамке 528). При проверке правильности ЭОД-транзакции варианты осуществления изобретения определяют, имеется ли то же самое значение во втором значении строки GE 534. Как показано на фиг.8B, второе значение линии GE 534 равно "10" (показано в рамке 530). При таком несоответствии определяется наличие ошибки сообщения ЭОД.
В другом примере ошибка с кодом 5 "Число включенных наборов транзакций не совпадает с фактически подсчитанным" определяется посредством идентификации транзакционных наборов между сегментами GS-GE. Как показано на фиг.8B, имеется один сегмент GS-GE, тогда как значение первой строки GE равно "02", указывая на два транзакционных набора. Таким образом, эта функциональная группа содержит ошибку.
Однако, если определено, что в группах нет ошибок, то затем на этапе 814 определяется правильность каждой ЭОД-транзакции посредством оценки правил форматирования в соответствии с форматом X12 или EDIFACT и правил в соответствии со схемами, включенными в ЭОД-транзакции. Если определено, что ЭОД-транзакция является неправильной, обработка ЭОД-транзакций приостанавливается, и на этапе 816 генерируется подтверждение функционального сбоя.
Например, в таблице 4 содержится перечень распространенных транзакционных ошибок.
| Таблица 4 | |
| Ошибки транзакционного набора - ошибки, связанные с данными внутри ST и SE | |
| Код | Описание - из перечня кодов AK502 |
| 1 | Транзакционный набор не поддерживается |
| 2 | Отсутствует трейлер транзакционного набора |
| 3 | Контрольное число транзакционного набора в заголовке и трейлере не совпадает |
| 4 | Число включенных сегментов не соответствует фактически подсчитанным |
| 5 | Один или несколько сегментов содержат ошибку |
| 6 | Отсутствующий или неверный идентификатор транзакционного набора |
| 7 | Отсутствующее или неверное контрольное число транзакционного набора |
Если воспользоваться в качестве примера фиг.8B, ЭОД-механизм (например, ЭОД-механизм 312) идентифицирует ошибку с кодом 4 "Число включенных сегментов не соответствует фактически подсчитанным" посредством оценки числа сегментов (строк) между ST и SE. В данном примере это число равно "12", тогда как первое значение в строке SE равно 14. Таким образом, в этом транзакционном наборе имеется ошибка, и такой код ошибки может быть включен в подтверждение функционального сбоя.
В одном варианте осуществления ЭОД-механизм (например, ЭОД-механизм 312) может иметь ссылки или обладать знанием об условиях различных ошибок или правилах ЭОД-транзакций. При обработке документа ЭОД ЭОД-механизм 312 обеспечивает, чтобы не нарушалось ни одно из правил форматирования ЭОД. При любом нарушении ЭОД-механизм 312 направляет соответствующее сообщение в виде обмена данными или подтверждений на функциональном уровне.
Альтернативно, если ЭОД-транзакции являются правильными, ЭОД-механизм 312 на стороне получателя переходит на этапе 818 к обработке ЭОД-транзакций. На этапе 9 генерируется подтверждение правильности, указывающее, что ЭОД-транзакции являются правильными. В одном варианте осуществления ЭОД-механизм 312 может осуществить объединение и сгенерировать объединенное подтверждение правильности, когда сообщения ЭОД, группы ЭОД и (или) ЭОД-транзакции приняты и проверены на правильность. В другом варианте осуществления ЭОД-механизм генерирует объединенное подтверждение правильности по существу одновременно с приемом сообщения ЭОД, группы ЭОД и (или) ЭОД-транзакций.
На этапе 824 сгенерированное подтверждение правильности возвращается источнику, принимающему на этапе 826 подтверждение правильности. В одном варианте осуществления источник открывает сеанс соединения для передачи сообщения ЭОД и принимает подтверждение правильности до закрытия этого же сеанса соединения. Таким образом, в процессе проверки правильности документа не требуется никакого обращения к базе данных или хранилищу данных, а также считывания/запись на диск, поскольку процесс проверки правильности осуществляется во время выполнения или во время приема ЭОД-транзакции, что показано стрелкой 318 на фиг.3. В еще одном варианте осуществления процесс проверки правильности может быть распространен на подключение обработчиков во время выполнения.
В альтернативном варианте осуществления различные типы подтверждения правильности могут генерироваться и передаваться в различные места (информацию о таких местах можно найти в заголовочной части 106) после приема сообщения ЭОД/ЭОД-транзакции. Таким образом, варианты осуществления настоящего изобретения генерируют и передают подтверждение правильности в один или несколько этапов (например, после проверки одного аспекта обмена данными) или в один этап в виде объединенного подтверждения. В еще одном варианте осуществления эти подтверждения могут быть сконфигурированы для доставки в том же или новом сеансе соединения различным получателям, как показано стрелкой 320 на фиг.3.
Например, предположим, что схемы или правила форматирования определяют, что подтверждение правильности для заказа на поставку сконфигурировано для отправки в отдел обслуживания клиентов предприятия, тогда как подтверждение правильности счета-фактуры сконфигурировано для передачи в отдел финансового учета того же предприятия. Аспекты изобретения обеспечивают передачу соответствующих подтверждений надлежащему получателю посредством открытия новых сеансов соединения. На фиг.9A приведено подтверждение правильности для ЭОД-транзакций в формате X12, тогда как на фиг.9B приведено подтверждение правильности для ЭОД-транзакций в формате EDIFACT.
Другим вариантом осуществления, приведенным на фиг.11C, является машиночитаемый носитель 1120, на котором могут храниться аспекты изобретения. Например, интерфейсный компонент 1122, подтверждающий компонент 1124 и проверяющий компонент 1126 могут быть встроены и представлять собой единое целое с ЭОД-механизмом для выполнения одного или нескольких этапов, описанных на фиг.8A.
Дополнительные аспекты изобретения обеспечивают модификацию схем ЭОД, не требуя от конечных пользователей квалификации разработчика схемы ЭОД. Например, предположим, в рамках предприятия создается новый отдел, но отсутствует индивидуализированная схема или правило ЭОД, принятые для нового отдела. Чтобы не нужно было просить разработчика схем ЭОД разработать специальную схему ЭОД для нового отдела, варианты осуществления изобретения определяют метасхему, которая представляет все схемы, так чтобы конечные пользователи имели возможность изменить свойства схем.
На фиг.10A приведен "снимок экрана", иллюстрирующий единую метасхему для модификации множества схем ЭОД согласно варианту осуществления изобретения. В окне 1002 конечному пользователю представлена структура единой метасхемы. Как только конечный пользователь выделяет какое-либо свойство (показанное пунктирной рамкой вокруг "MaxOccurs"), в окне 1004 будет выделен соответствующий раздел с кодом свойства, что позволяет конечному пользователю изменять значения свойств. В одном варианте осуществления конечный пользователь снабжен пользовательским интерфейсом (ПИ), полностью воплощающим аспект изобретения, приведенный на фиг.10A.
На фиг.10B приведена блок-схема последовательности действий, иллюстрирующая способ модификации множества схем ЭОД при помощи единой метасхемы согласно варианту осуществления изобретения. На этапе 1006 идентифицируется единая структура, представляющая множество схем ЭОД, посредством декодирования данных во множестве схем ЭОД. В одном примере единая структура, такая как структура 1128 данных на фиг.11D, представляет множество схем ЭОД посредством вмещения в себя одного или нескольких из следующих данных:
1. Каждая схема ЭОД состоит из корневого элемента, который имеет имя;
2. Корневой элемент состоит из повторяющихся блоков данных, которые могут быть либо циклами, либо сегментами;
3. Каждый цикл имеет следующую структуру
a. Name - имя цикла
b. Block - совокупность элементов данных
c. MinOccurs - минимальное число вхождений
d. MaxOccurs - максимальное число вхождений
4. Каждый сегмент имеет различные свойства
a. Name - имя сегмента
b. TagId - TagId сегмента
c. MinOccurs - минимальное число вхождений
d. MaxOccurs - максимальное число вхождений
e. Перечень элементов данных
5. Каждый элемент данных состоит из совокупности (коллекции) элементов, каждый из которых может быть либо составным элементом или простым элементом
6. Каждый простой элемент имеет различные свойства
a. Name - имя элемента
b. MinOccurs - минимальное число вхождений
c. MaxOccurs - максимальное число вхождений
d. MinLength - минимальная длина данных
e. MaxLength - максимальная длина данных
f. DataType - тип данных, допустимые значения A, AN, ID, R, N, Date, Time - по одному для каждого типа данных ЭОД
g. AllowedValues - набор допустимых значений, применимых только в случае, когда элемент относится к типу ID.
Например, структура 1128 данных включает в себя первое поле 1130 данных, включающее в себя корневые данные, связанные с корневым элементом каждой из множества схем ЭОД. Эта структура данных также включает в себя одно или несколько вторых полей 1132 данных, содержащих данные, представляющие один или несколько блоков данных каждой из множества схем ЭОД. Данные в одном или нескольких вторых полях данных определяются как функция от корневых данных в первом поле 1130 данных.
На этапе 1008 определяются свойства, которые будут включены в единую структуру. Эти свойства определяют (задают) характеристики множества схем ЭОД. Например, корневой элемент со значением свойства "заказ на поставку" показывает, что характеристика единой структуры соответствует схеме заказа на покупку, такой как приведена на фиг.7A. Когда единая структура имеет значения свойства, на этапе 1010 для пользователя задается единая метасхема в виде функции от заданных характеристик и единой структуры. Заданная метасхема соответствует множеству схем ЭОД. На этапе 1012 определенные свойства в заданной метасхеме предоставляются конечному пользователю, так чтобы конечный пользователь мог модифицировать характеристики каждой из множества схем ЭОД, как показано на фиг.10A.
Приложение B содержит пример единой метасхемы в формате XML, представляющий схему заказа на поставку со следующей структурой:
1. Сегмент PurchaseOrderDetail;
2. Цикл, состоящий из сегмента LineItem и ShippingAddress;
3. Сегмент Notes.
На фиг.12 приведен один пример вычислительного устройства общего назначения в виде компьютера 130. В одном варианте осуществления компьютер, такой как компьютер 130, пригоден для использования в других чертежах, приведенных и описанных в настоящем документе. Компьютер 130 имеет один или несколько процессоров или обрабатывающих устройств 132 и системную память 134. В приведенном варианте осуществления различные компоненты системы, в том числе системную память 134, связывает с процессором 132 системная шина 136. Шина 136 представляет один или несколько любых из нескольких типов шинных структур, в том числе шину памяти и контроллер памяти, периферийную шину, ускоренный графический порт и процессорную или локальную шину, использующих любую из множества шинных архитектур. В качестве неограничивающего примера такие архитектуры включают шину промышленной стандартной архитектуры (ISA), шину микроканальной архитектуры (MCA), шину улучшенной ISA (EISA), локальную шину видеоэлектронных стандартов и шину взаимодействия периферийных компонентов (PCI), известную также под названием шины расширения.
Компьютер 130 обычно имеет по меньшей мере некоторый вид машиночитаемых носителей. Машиночитаемые носители, которые включают в себя энергозависимые и энергонезависимые носители, съемные и несъемные носители, могут быть любым доступным носителем, к которому может обращаться компьютер 130. В качестве неограничивающего примера машиночитаемые носители содержат компьютерные носители для хранения данных и среды передачи данных. Компьютерные носители для хранения данных включают в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные при помощи любого способа или технологии для хранения информации, таких как машиночитаемые команды, структуры данных, программные модули или другие данные. Например, компьютерные носители для хранения данных включают в себя ОЗУ, ПЗУ, электрически стираемое ПЗУ, флэш-память или другую технологию получения памяти, CD-ROM, цифровые универсальные диски (DVD) или другое запоминающее устройство на оптических дисках, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитном диске или другие магнитные запоминающие устройства либо любые другие носители, к которым может обращаться компьютер 130. Среды передачи данных обычно содержат машиночитаемые команды, структуры данных или другие данные в модулированном сигнале данных, таком как несущая волна или другой механизм переноса, и включают в себя любые среды передачи информации. Специалистам в данной области техники известен модулированный сигнал данных, у которого одна или несколько характеристик устанавливаются или изменяются таким образом, чтобы кодировать информацию в сигнале. Проводные среды, такие как проводная сеть или прямое проводное соединение, и беспроводные среды, такие как акустическая, инфракрасная или другие беспроводные среды, служат примерами среды передачи данных. Сочетания любого из вышеперечисленного также подпадают под определение машиночитаемых носителей.
Системная память 134 включает в себя компьютерные носители для хранения данных в виде съемной и (или) несъемной, энергозависимой и (или) энергонезависимой памяти. В приведенном варианте осуществления системная память 134 включает в себя постоянное запоминающее устройство (ПЗУ) 138 и оперативное запоминающее устройство (ОЗУ) 140. Базовая система 142 ввода-вывода (BIOS), содержащая основные программы, которые помогают передавать информацию между элементами компьютера 130, например, во время начальной загрузки, обычно хранится в ПЗУ 138. ОЗУ 140 обычно содержит данные и (или) программы, к которым процессорное устройство 132 имеет мгновенный доступ и (или) которые оно в настоящее время обрабатывает. В качестве неограничивающего примера на фиг.12 приведена операционная система 144, прикладные программы 146, другие программные модули 148 и программные данные 150.
Компьютер 130 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители для хранения данных. Например, на фиг.12 приведен накопитель 154 на жестком диске, который считывает данные или записывает данные на несъемные, энергонезависимые магнитные носители. На фиг.12 приведен также накопитель 156 магнитных дисков, который считывает и записывает данные на съемный энергонезависимый магнитный диск 158, и накопитель 160 для оптических дисков, который считывает и записывает данные на съемный энергонезависимый оптический диск 162, такой как CD-ROM или другие оптические носители. Другие съемные/несъемные энергозависимые/энергонезависимые компьютерные носители для хранения данных, которые могут использоваться в примерной операционной среде, включают в себя, в частности, кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, цифровые видеокассеты, твердотельное ОЗУ, твердотельное ПЗУ и т.п. Накопитель 154 на жестком диске, привод 156 магнитных дисков и привод 160 оптических дисков обычно соединены с системной шиной 136 интерфейсом энергонезависимых запоминающих устройств, таким как интерфейс 166.
Рассмотренные выше и приведенные на фиг.12 приводы и другие устройства хранения больших объемом данных и связанные с ними компьютерные носители для хранения данных обеспечивают хранение машиночитаемых команд, структур данных, программных модулей и других данных для компьютера 130. На фиг.12, например, приведен накопитель 154 на жестком диске, на котором хранится операционная система 170, прикладные программы 172, другие программные модули 174 и программные данные 176. Заметим, что эти компоненты могут быть теми же самыми или отличаться от операционной системы 144, прикладных программ 146, других программных модулей 148 и программных данных 150. Операционная система 170, прикладные программы 172, другие программные модули 174 и программные данные 176 обозначены здесь другими позициями, чтобы отразить тот факт, что это, как минимум, другие копии.
Пользователь может вводить в компьютер 130 команды и информацию при помощи устройств ввода или устройств выбора пользовательского интерфейса, таких как клавиатура 180 и координатно-указательное устройство 182 (например, мышь, шаровой указатель, стило или сенсорная панель). Другие устройства ввода (не показаны) могут включать микрофон, джойстик, игровую панель, спутниковую антенну, сканер и т.п. Эти и другие устройства ввода соединены с процессорным устройством 132 через интерфейс 184 пользовательского ввода, который связан с системной шиной 136, но может быть соединен при помощи других интерфейсных и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 188 или устройство отображения иного типа соединены с системной шиной 136 через интерфейс, такой как видеоинтерфейс 190. Помимо монитора 188 компьютеры также содержат другие периферийные устройства вывода (не показаны), такие как принтер и динамики, которые могут быть соединены через периферийный выходной интерфейс (не показан).
Компьютер 130 может работать в сетевой среде с использованием логических соединений с одним или несколькими удаленными компьютерами, такими как удаленный компьютер 194. Удаленный компьютер 194 может быть персональным компьютером, сервером, маршрутизатором, сетевым ПК, равноправным устройством или другим известным сетевым узлом и обычно содержит множество или все элементы, описанные выше в отношении компьютера 130. Логические соединения, изображенные на фиг.12, включают в себя локальную сеть (LAN) 196 и глобальную сеть (WAN) 198, но могут также включать в себя другие сети. LAN 136 и (или) WAN 138 могут быть проводной сетью, беспроводной сетью, их сочетанием и т. д. Такие сетевые среды распространены в организациях, в корпоративных компьютерных сетях, в интрасетях и в глобальных компьютерных сетях (например, в Интернете).
В случае использования в локальной сетевой среде компьютер 130 соединен с LAN 196 через сетевой интерфейс или адаптер 186. В случае использования в глобальной сетевой среде компьютер 130 обычно содержит модем 178 или другое средство для установления связи через WAN 198, такую как Интернет. Модем 178, который может быть встроенным или внешним, соединен с системной шиной 136 через интерфейс 184 пользовательского ввода или посредством иного подходящего механизма. В сетевой среде программные модули, изображенные относящимися к компьютеру 130 или к его частям, могут храниться в удаленном запоминающем устройстве (не показано). В качестве неограничивающего примера на фиг.12 приведены удаленные прикладные программы 192, находящиеся в запоминающем устройстве. Показанные сетевые соединения приведены в качестве примера, но могут использоваться и другие средства установления линии связи между компьютерами.
В целом, процессоры данных компьютера 130 запрограммированы посредством команд, хранящихся в различное время в различных машиночитаемых носителях для хранения. Программы и операционные системы, как правило, распространяются, например, на гибких дисках или на CD-ROM. С этих дисков их устанавливают и загружают во вторичную память компьютера. При выполнении они загружаются, по меньшей мере частично, в первичную электронную память компьютера. Описанные в настоящем документе аспекты изобретения включают в себя эти и другие различные типы машиночитаемых носителей для хранения данных, когда такие носители содержат команды и программы для реализации описанных ниже этапов совместно с микропроцессором или иным процессором данных. Кроме того, аспекты изобретения включают в себя сам компьютер, когда он запрограммирован в соответствии с описанными здесь способами и методиками.
Для наглядности программы и другие выполняемые программные компоненты, такие как операционная система, изображены в виде отдельных блоков. Ясно, однако, что такие программы и компоненты располагаются в различное время в различных компонентах компьютера для хранения данных и выполняются процессором(ами) данных компьютера.
Хотя варианты осуществления изобретения описаны при помощи среды вычислительной системы, включающей компьютер 130, они могут быть реализованы при помощи многих других сред и конфигураций вычислительных систем общего и специального назначения. Предполагается, что среда вычислительной системы не накладывает никаких ограничений на объем использования или функциональные возможности любого аспекта изобретения. Кроме того, среду вычислительной системы не следует толковать таким образом, что она обладает какой-либо зависимостью или предъявляются требования в отношении какого-либо компонента или сочетания компонентов, приведенных в примерной операционной среде.
Примеры известных вычислительных систем, сред и (или) конфигураций, которые могут быть пригодными для использования с аспектами изобретения, включают, в частности, персональные компьютеры, компьютеры-серверы, карманные или портативные устройства, многопроцессорные системы, системы на основе микропроцессоров, телевизионные приставки, программируемые потребителем бытовые электронные приборы, мобильные телефоны, сетевые ПК, миникомпьютеры, большие компьютеры, распределенные вычислительные среды, которые включают в себя любые из вышеперечисленных систем и устройств, и т.п.
Варианты осуществления изобретения могут быть описаны в общем контексте машиноисполняемых команд, таких как программные модули, выполняемые одним или несколькими компьютерами или другими устройствами. В целом программные модули включают в себя, в частности, программы, объекты, компоненты и структуры данных, которые выполняют определенные задачи и реализуют определенные абстрактные типы данных. Аспекты изобретения могут также использоваться в распределенных вычислительных средах, в которых задачи выполняются удаленными процессорными устройствами, которые связаны сетью связи. В распределенной вычислительной среде программные модули могут быть расположены как на локальном, так и на удаленном компьютерном носителе для хранения данных, в том числе на запоминающих устройствах.
Интерфейс может быть сильносвязанной синхронной реализацией, такой как платформа Java 2, редакция для предприятий (J2EE), экземпляры объектной модели программных компонентов (COM) или распределенной COM (DCOM). Или же в дополнение к этому интерфейс может быть слабосвязанной асинхронной реализацией, такой как WEB-служба (например, при помощи простого протокола доступа к объектам). В целом интерфейс включает в себя любое сочетание следующих характеристик: сильносвязанный, слабосвязанный, синхронный и асинхронный. Кроме того, интерфейс может согласовываться со стандартным протоколом, специализированным протоколом или с любым сочетанием стандартных и специализированных протоколов.
Все описанные здесь интерфейсы могут быть частью единого интерфейса или могут быть реализованы в виде отдельных интерфейсов или в виде любого их сочетания. Для обеспечения функциональных возможностей интерфейсы могут быть реализованы локальными или удаленными. Кроме того, интерфейсы могут включать в себя дополнительные функциональные возможности или обладать меньшими функциональными возможностями по сравнению с теми, что приведены и описаны в настоящем документе.
В процессе работы компьютер 130 выполняет машиноисполняемые команды, такие как приведенные на чертежах для реализации аспектов изобретения.
Порядок выполнения операций в вариантах осуществления изобретения, приведенных и описанных в настоящем документе, не является существенным, если не оговорено иное. Иными словами, операции могут выполняться в любой последовательности, если не оговорено иное, и варианты осуществления изобретения могут содержать дополнительные операции или меньше операций по сравнению с тем, что были раскрыты в настоящем документе. Например, в рамках аспектов изобретения возможно выполнение определенной операции до, одновременно или после другой операции.
Варианты осуществления изобретения могут быть реализованы при помощи машиноисполняемых команд. Машиноисполняемые команды могут быть организованы в один или несколько машиноисполняемых компонентов или модулей. Аспекты изобретения могут быть реализованы при помощи любого количества и любой организации таких компонентов или модулей. Например, аспекты изобретения не ограничиваются конкретными машиноисполняемыми командами или конкретными компонентами и модулями, приведенными на чертежах и описанными в настоящем документе. Другие варианты осуществления изобретения могут включать в себя иные машиноисполняемые команды или компоненты, обладающие большими или меньшими функциональными возможностями по сравнению с теми, что приведены и описаны в настоящем документе.
При упоминании элементов аспектов изобретения или их вариантов осуществления единственное число означает, что имеется один или несколько элементов. Термины, "содержащий", "включающий в себя" и "имеющий" имеют неограничивающий характер и означают, что могут быть дополнительные элементы, отличные от перечисленных элементов.
Поскольку в вышеупомянутые конструкции, продукты и способы могут быть внесены различные изменения без отступления от объема аспектов изобретения, подразумевается, что весь материал, содержащийся в вышеприведенном описании и изображенный на прилагаемых чертежах, должен восприниматься как иллюстративный и не имеющий ограничивающего смысла.
1. Способ, реализуемый, по меньшей мере, частично вычислительным устройством, для преобразования транзакций электронного обмена данными (ЭОД), указанный способ содержит этапы, на которых:
принимают данные ЭОД в пакете, причем указанный пакет данных ЭОД включает в себя множество документов ЭОД, каждый из которых содержит по меньшей мере одну ЭОД-транзакцию, соответствующую некоторому типу транзакции;
идентифицируют ЭОД-транзакции, содержащиеся в документах ЭОД, посредством декодирования принятых данных ЭОД согласно стандартам ЭОД, при этом каждая из идентифицированных ЭОД-транзакций имеет ассоциированные с ней значения транзакций;
идентифицируют множество экземпляров идентифицированных ЭОД-транзакций, принадлежащих одному и тому же типу транзакции,
идентифицируют повторяющиеся структурные элементы ЭОД-транзакции в идентифицированном множестве экземпляров ЭОД-транзакций в документах ЭОД, принадлежащих одному и тому же типу транзакции, и
уменьшают количество строк множества экземпляров идентифицированных ЭОД-транзакций, принадлежащих одному и тому же типу транзакции, так, что остается только один экземпляр идентифицированных повторяющихся структурных элементов ЭОД-транзакции, и значения транзакций, ассоциированные с множеством экземпляров идентифицированных ЭОВ-транзакций, заключены во вложенную структуру одного экземпляра повторяющихся структурных элементов ЭОД-транзакции, причем упомянутая вложенная структура значений транзакции в одном экземпляре повторяющихся структурных элементов ЭОД-транзакции представляет ту же информацию, что и повторяющиеся ЭОД-транзакции из множества экземпляров идентифированных ЭОД-транзакций, и
генерируют объединенный документ ЭОД из множества документов ЭОД в пакете, причем указанный объединенный документ ЭОД содержит данные ЭОД идентифицированных ЭОД-транзакций, организованных согласно типу транзакции, и включает в себя упомянутую вложенную структуру с упомянутым одним экземпляром идентифицированных повторяющихся структурных элементов ЭОД-транзакции, так что циклообразная логика может быть использована для создания их копий во время обработки.
2. Способ по п.1, в котором объединенный документ ЭОД является документом на расширяемом языке разметки (XML).
3. Способ по п.2, дополнительно содержащий этап, на котором организуют ЭОД-транзакции, включенные в объединенный документ ЭОД, посредством тегов XML, при этом теги XML указывают типы транзакций для ЭОД-транзакций.
4. Способ по п.1, в котором объединенный документ ЭОД содержит надсхему, причем указанная надсхема представляет множество схем, на которые ссылаются ЭОД-транзакции.
5. Способ по п.4, дополнительно содержащий этап, на котором определяют карту отображения схем во время выполнения для преобразования множества схем для обработки во время выполнения.
6. Способ по п.1, дополнительно содержащий этап, в котором организуют ЭОД-транзакции с вложенной структурой в объединенном документе ЭОД в виде поддокументов согласно одному или нескольким фрагментам информации, содержащимся в ЭОД-транзакциях, и в котором ЭОД-транзакции в поддокументах коррелируют с ЭОД-транзакциями во множестве документов ЭОД.
7. Система для преобразования транзакции электронного обмена данными (ЭОД) между передающим источником и принимающим устройством, указанная система содержит:
передающий источник для передачи данных ЭОД в пакете, причем указанный пакет данных ЭОД включает в себя множество документов ЭОД, каждый из которых содержит, по меньшей мере, одну ЭОД-транзакцию, соответствующую некоторому типу транзакции, при этом по меньшей мере одна ЭОД-транзакция имеет ассоциированные с ней значения транзакции;
интерфейс для приема данных ЭОД в пакете;
процессор для выполнения машиноисполняемых команд для:
идентификации множества экземпляров идентифицированных ЭОД-транзакций, принадлежащих одному и тому же типу транзакции,
идентификации повторяющихся структурных элементов ЭОД-транзакции в идентифицированном множестве экземпляров ЭОД-транзакций в документах ЭОД, принадлежащих одному и тому же типу транзакции, и
уменьшения количества строк множества экземпляров идентифицированных ЭОД-транзакций, принадлежащих одному и тому же типу транзакции, так, что остается только один экземпляр идентифицированных повторяющихся структурных элементов ЭОД-транзакции, и значения транзакции, ассоциированные с множеством экземпляров идентифицированных ЭОД-транзакций, заключены во вложенную структуру одного экземпляра повторяющихся структурных элементов ЭОД-транзакции, причем упомянутая вложенная структура значений транзакции в одном экземпляре повторяющихся структурных элементов ЭОД-транзакции представляет ту же информацию, что и повторяющиеся ЭОД-транзакции из множества экземпляров идентифицированных ЭОД-транзакций,
идентификации ЭОД-транзакций, содержащихся во множестве документов ЭОД, посредством декодирования принятых данных ЭОД согласно стандартам ЭОД; и
определения объединенного документа ЭОД из множества документов ЭОД в пакете данных ЭОД, причем упомянутый объединенный документ ЭОД включает в себя идентифицированные ЭОД-транзакции, организованные согласно типу транзакции, и включает в себя один экземпляр идентифицированных повторяющихся структурных элементов ЭОД-транзакции, так что циклообразная логика может быть использована для создания их копий во время обработки.
8. Система по п.7, в которой объединенный документ ЭОД является документом на расширяемом языке разметки (XML).
9. Система по п.8, в которой процессор дополнительно выполнен с возможностью организации ЭОД-транзакций, содержащихся в объединенном документе ЭОД, посредством тегов XML, причем теги XML указывают типы транзакций для ЭОД-транзакций.
10. Система по п.7, в которой объединенный документ ЭОД содержит надсхему, причем указанная надсхема представляет множество схем, на который ссылаются ЭОД-транзакции.
11. Система по п.10, в которой интерфейс дополнительно принимает карту отображения схем во время выполнения для преобразования множества схем для обработки процессором.
12. Система по п.11, в которой процессор выполнен с возможностью применения карты отображения схем во время выполнения для согласования множества схем во время выполнения.
13. Система по п.7, в которой процессор дополнительно выполнен с возможностью организации ЭОД-транзакций и одного экземпляра идентифицированных повторяющихся элементов в объединенном документе ЭОД в виде поддокументов согласно одному или нескольким фрагментам информации, содержащимся в ЭОД-транзакциях, и в которой ЭОД-транзакции в поддокументах коррелируют с ЭОД-транзакциями во множестве документов ЭОД.
14. Машиночитаемый носитель, содержащий машиноисполняемые компоненты, для преобразования транзакций электронного обмена данным (ЭОД), причем указанные машиноисполняемые компоненты содержат:
интерфейсный компонент для приема данных ЭОД в пакете от передающего источника и передачи данных ЭОД получателю, при этом указанный пакет данных ЭОД включает в себя множество документов ЭОД, каждый из которых содержит по меньшей мере одну ЭОД-транзакцию, соответствующую некоторому типу транзакции;
компонент идентификации для идентификации ЭОД-транзакций, содержащихся во множестве документов ЭОД, посредством декодирования принятых данных ЭОД согласно стандартам ЭОД, при этом каждая из идентифицированных ЭОД-транзакций имеет ассоциированные с ней значения транзакции, и упомянутый компонент идентификации дополнительно идентифицирует множество экземпляров идентифицированных ЭОД-транзакций, принадлежащих одному и тому же типу транзакции; при этом компонент идентификации идентифицирует повторяющиеся структурные элементы ЭОД-транзакции в идентифицированном множестве экземпляров ЭОД-транзакций в документах ЭОД, принадлежащих одному и тому же типу транзакции, причем компонент идентификации также уменьшает количество строк множества экземпляров идентифицированных ЭОД-транзакций, принадлежащих одному и тому же типу транзакции так, что остается только один экземпляр идентифицированных повторяющихся структурных элементов ЭОД-транзакции, и значения транзакции, ассоциированные с множеством экземпляров идентифицированных ЭОД-транзакций, заключены во вложенную структуру одного экземпляра повторяющихся структурных элементов ЭОД-транзакции, причем упомянутая вложенная структура значений транзакции в упомянутом одном экземпляре повторяющихся структурных элементов ЭОД-транзакции представляет ту же информацию, что и повторяющиеся ЭОД-транзакции из множества экземпляров идентифицированных ЭОД-транзакций,
компонент преобразования для определения объединенного документа ЭОД из множества документов ЭОД в пакете данных ЭОД, причем указанный объединенный документ ЭОД включает в себя идентифицированные ЭОД-транзакции, организованные согласно типу транзакции, и включает в себя упомянутую вложенную структуру с упомянутым одним экземпляром идентифицированных повторяющихся структурных элементов ЭОД-транзакции, так что циклообразная логика может быть использована для создания их копий во время обработки.
15. Машиночитаемый носитель по п.14, в которых объединенный документ ЭОД является документом на расширяемом языке разметки (XML).
16. Машиночитаемый носитель по п.15, дополнительно содержащий документный компонент для организации ЭОД-транзакций, содержащихся в объединенном документе ЭОД, посредством тегов XML, причем теги XML указывают типы транзакций для ЭОД-транзакций.
17. Машиночитаемый носитель по п.16, в котором документный компонент дополнительно организует ЭОД-транзакции с вложенной структурой в объединенном документе ЭОД в виде поддокументов согласно одному или нескольким фрагментам информации, содержащихся в ЭОД-транзакциях, и в которых ЭОД-транзакции в поддокументах коррелируют с ЭОД-транзакциями во множестве документов ЭОД.
18. Машиночитаемый носитель по п.14, в которых объединенный документ ЭОД содержит надсхему, причем указанная надсхема представляет множество схем, на которые ссылаются ЭОД-транзакции.
19. Машиночитаемый носитель по п.14, в котором интерфейсный компонент дополнительно принимает карту отображения схем во время выполнения для преобразования множества схем для выполнения процессором во время выполнения.
