Формат EnterpriseData

Для облегчения интеграции с программными продуктами фирмы «1С» разработан формат обмена данными EnterpriseData. Формат основан на XML и является бизнес-ориентированным — описанные в нем структуры данных соответствуют бизнес-сущностям (документам и элементам справочников), представленным в программах «1С», например: акт выполненных работ, приходный кассовый ордер, контрагент, договор и т. п. Это делает формат интуитивно понятным и легким в использовании.

Формат EnterpriseData предназначен для обмена данными внутри компании (в том числе между разнородными и территориально удаленными информационными системами) и призван покрыть все сферы деятельности предприятия — финансы, производство, закупки и продажи, складские операции и т. п.

Описание формата

Версия 1.0.1 формата включает в себя описание 94 типов бизнес-сущностей из различных областей бизнеса. Формат является расширяемым — фирма «1С» будет добавлять в него описание новых бизнес-сущностей и расширять существующие сущности новыми полями. Поддержка формата в продуктах фирмы «1С» обеспечивает совместимость снизу вверх — все программы сторонних производителей, обменивающихся данными в формате EnterpriseData с продуктами «1С», при выходе новых версий формата корректно продолжат работу.

Формат предназначен для обмена информацией между любыми информационными системами: он не зависит от особенностей собственного программного обеспечения или структур информационных баз, которые участвуют в обмене и не содержит в себе явных ограничений использования.

Обмен данными с программами «1С»

Предварительная настройка на стороне «1С»

В случае обмена через веб-сервис стороннее приложение будет инициировать сеанс обмена данными путем вызова соответствующих веб-методов приложения «1С». В остальных случаях инициатором сеанса обмена будет приложение «1С».

Формат файлов обмена

Приложения «1С» ведут учет отправленных и полученных сообщений синхронизации и ожидают того же от сторонних приложений. Для чего это делается — изложено ниже.

Механизм квитирования

Приложения «1С» в ходе синхронизации передают только информацию об изменениях, произошедших с бизнес-сущностями со времени последней синхронизации (чтобы минимизировать объем передаваемой информации). При первой синхронизации приложение «1С» выгрузит все бизнес-сущности в формате EnterpriseData в XML-файл (поскольку все они являются «новыми» для внешнего приложения). Следующий шаг за сторонним приложением –оно должно обработать информацию из XML-файла и при следующем сеансе синхронизации поместить в секцию информацию, что сообщение от «1С» за определенным номером успешно принято (поместить в поле ReceivedNo номер полученного от «1С» сообщения). Сообщение-квитанция является для приложения «1С» сигналом, что все бизнес-сущности успешно обработаны внешним приложением и информацию о них передавать больше не нужно. Помимо квитанции XML-файл от стороннего приложения также может содержать данные для синхронизации (в секции ).

После получения сообщения-квитанции приложение «1С» помечает все изменения, переданные в предыдущем сообщении, как успешно синхронизированные. Лишь несинхронизированные изменения в бизнес-сущностях (создание новых, изменение и удаление существующих) будут отправлены во внешнее приложение при следующем сеансе синхронизации.

При передаче данных от внешнего приложения в приложение «1С» картина меняется на обратную. Приложение должно заполнить секцию соответствующим образом, а в секцию поместить бизнес-данные для синхронизации в формате EnterpriseData.

Приложение «1С» после обработки файла сформирует XML-файл, который будет содержать сообщение-квитанцию и новые данные для синхронизации со стороны «1С» (если такие есть со времени последнего сеанса синхронизации).

Обмен через веб-сервис

При использовании веб-сервиса инициатором сеанса обмена выступает стороннее приложение. Для получения данных от приложения «1С» ему нужно вызвать веб-метод GetData, передав в качестве параметров метода уникальный код приложения, введенный на этапе настройки. В ответ «1С» вернет файл, содержащий данные о бизнес-сущностях в формате EnterpriseData[1]. Формат файла описан выше.

Чтобы передать данные в «1С», приложение должно вызвать веб-метод PutData, передав как параметры уникальный код приложения и заархивированный файл в описанном выше формате.

Обмен через другие каналы

В случае обмена данными через каталог/FTP каталог или электронную почту инициатором обмена будет выступать приложение «1С». Оно будет помещать в соответствующий канал (каталог или почтовый ящик) файл описанного выше формата и ожидать от стороннего приложения в этом же канале ответных файлов. В случае обмена каталог/FTP каталог имя файла должно быть составлено специальным образом, чтобы приложение «1С» смогло его обработать. В случае обмена по электронной почте тема письма должна быть составлена по определенному правилу, а заархивированный файл с данными должен быть приложен к письму.

Заключение

Набор сценариев интеграции с использованием формата EnterpriseData широк. Это и обмен данными в пределах одной организации, например, передача данных в «1С: Бухгалтерию» из других приложений для ведения целостного учета, или обмен данными между центральным офисом и удаленными складами. Подходит формат и для обмена данными между разными организациями.

В планах «1С» — дальнейшее развитие формата EnterpriseData и его поддержка во все большем количестве приложений, разрабатываемых фирмой.

Ресурсы

[1] В реальности ситуация чуть сложнее. Поскольку размер передаваемой через веб-сервисы информации ограничен, приложению нужно будет получать от «1С» файл в виде архива, разделенного на части. В случае передачи файла от стороннего приложения в приложение «1С» приложению нужно будет заархивировать файл с данными и передать архив по частям, используя методы веб-сервиса.

Источник

Формат EnterpriseData

Введение

Данная статья описывает технологию интеграции с прикладными решениями на платформе «1С:Предприятие» с использованием формата EnterpriseData. Статья разделена на две логических части:

Вкратце эти 2 пункта описаны ниже, а в самой статье – подробно.

Что такое формат EnterpriseData

Это формат, позволяющий описать объект информационной базы (контрагента, накладную и т.п.) или сообщить о факте удаления этого объекта. Ожидается, что конфигурация, получившая файл в формате EnterpriseData, отреагирует соответствующим образом – создаст у себя новые объекты и удалит те, которые в файле помечены как удаленные.

Как обмениваться данными в формате EnterpriseData

Помимо информации об объектах, файл в формате EnterpriseData содержит заголовок (секцию ) со служебной информацией. По этой информации конфигурация сможет понять, от какого внешнего приложения получена информация и какую информацию нужно отправить приложению в ответ (данные о тех объектах, которые были обновлены в информационной базе со времени последней синхронизации с данным сторонним приложением).

Таким образом, обмен данными в формате EnterpriseData с конфигурацией — это обмен файлами. В ответ на полученный от внешнего приложения файл конфигурация обработает его и создаст файл-ответ. Обмен файлами может происходить:

Примечание. Для двустороннего обмена данными между сторонним приложением и конфигурацией на стороне информационной базы должен быть сделан ряд настроек – стороннее приложение должно быть зарегистрировано в информационной базе, для него должен быть определен канал обмена (через файловый или FTP-каталог) и т.п. Но для случаев простой интеграции, когда достаточно только передавать информацию от стороннего приложения в информационную базу и обратной передачи данных из информационной базы в стороннее приложение не требуется (например, интеграция онлайн-магазина, передающего информацию о продажах в «1С:Бухгалтерию»), есть упрощенный вариант работы через веб-сервис, не требующий настроек на стороне информационной базы.

О формате EnterpriseData

Формат ED включают в себя описание бизнес-сущностей из различных областей хозяйственно-экономической деятельности предприятия, и является расширяемым. В дальнейших версиях формата ED, фирма «1С» будет добавлять в него описание новых сущностей и расширять существующие новыми полями. Номера версий формата ED состоят из X.Y.Z, где X.Y. – это Major версия, Z – это Minor версия.

Major версия изменяется:

X — в случае глобальной реструктуризации объектов формата ED;

Y — в случаях добавления новых или незначительной реструктуризации существующих объектов формата ED. Примером таких изменений может быть: добавление новых объектов формата ED; добавление свойств, требующих обязательное заполнение; изменение ключевых свойств объектов формата ED.

Minor версия изменяется:

В случае исправления ошибок и прочих незначительных изменениях, при которых сохраняется логика конвертации данных, разработанная для предыдущих minor версий формата ED. Примером таких изменений может быть исправление ошибки, изменения свойств объектов формата ED, добавление свойств, использование которых при конвертации данных не является обязательным.

Изменение Minor версии не приводит к потери совместимости с предыдущими minor весиями. Major версии не имеют обратной совместимости.

Внимание! Гарантированный срок поддержки актуальной версии составит 1 год с момента выхода новой версии формата ED. Поддержка версии формата ED в составе конфигураций, использующих библиотеку стандартных подсистем (далее «БСП»), не может быть прекращена раньше гарантированного срока. Решение о фактическом прекращении поддержки версии формата ED принимается исходя из анализа ее использования при обмене между существующими прикладными решениями. Например, версия формата ED 1.4 будет гарантированно поддерживаться еще 1 год после выпуска версии 1.5.

Объекты

Формат описывает представление объектов (документов или элементов справочников) в виде XML-файлов. Версия 1.0.1 содержит описание 94-х объектов из различных областей (финансы, производство, закупки и продажи, складские операции). Названия типов, как правило, хорошо понятны и не нуждаются в дополнительных объяснениях: например, «Документ.АктВыполненныхРабот» или «Справочник.Контрагенты». Как можно заметить, описание типов документов начинается с префикса «Документ.», элемента справочника – с префикса «Справочник.».

Каждый сложный тип (complexType) который наследует тип Object (содержит в описании инструкцию ), является описанием самостоятельного объекта. Каждый объект содержит в себе составной элемент под названием «КлючевыеСвойства»; в этом элементе хранятся свойства, по которым объект может быть идентифицирован в системе. Например, для контрагента это НаименованиеПолное, ИНН и КПП. Почти все объекты (кроме документов остатков) имеют среди ключевых свойств свойство «Ссылка»; это Global Unique Identifier (GUID), записанный в виде строки в формате , где Gx — значение соответствующего байта структуры в шестнадцатеричном представлении. Поле «Ссылка» однозначно идентифицирует объект в системе (является ее первичным ключом).

Формат также содержит описание типов вспомогательных объектов, большинство из них описывает:

Пример описания объекта

Рассмотрим формат EnterpriseData на примере сущности «Документ.АктВыполненныхРабот».

Первое поле документа – это «Ключевые свойства» типа «КлючевыеСвойстваАктВыполненныхРабот»:

Первое поле «Ссылка» в типе «КлючевыеСвойстваАктВыполненныхРабот» — это элемент типа «ДокументСсылка.АктВыполненныхРабот», являющийся расширением типа «Ref»:

Тип «Ref» описан в файле ExchangeMessage.xsd и формально является строкой, но, как было сказано выше, конфигурация ожидает в этом поле GUID в строковом представлении:

Далее в документе «Документ.АктВыполненныхРабот» следуют поля, ссылающиеся на ответственного и валюту (оба – ссылки на соответствующие объекты в системе), сумма (тип «ТипСумма», цифровой) и т.д.

Элемент Услуги имеет тип «Документ.АктВыполненныхРабот.Услуги» – это коллекция строк типа «Документ.АктВыполненныхРабот.Услуги.Строка»:

Тип «Документ.АктВыполненныхРабот.Услуги.Строка» описывает строку, соответствующую конкретной услуге:

Как можно заметить, некоторые типы в качестве последнего элемента содержат строчку

Эта строка позволяет нам добавлять в элементы произвольное количество (maxOccurs=»unbounded) дополнительных полей любого типа (xs:any), не нарушая XSD-схему. Это та самая ситуация, когда мы расширяем объекты новыми полями, повышая при этом минорную версию формата. В этом случае программа, которая уже умеет работать с новыми полями, сможет их обработать соответствующим образом; если же программа написана для работы с более старыми минорными версиями формата – она пропустит «незнакомые» поля, не обработав их.

Поля (элементы) сущности, у которых отсутствует атрибут minOccurs=»0″, являются обязательными к заполнению (согласно стандарту XSD).

Как с помощью формата EnterpriseData обмениваться данными с конфигурациями

При обмене с использованием планов обмена конфигурации в ходе синхронизации передают только информацию об изменениях, произошедших со времени последней синхронизации (чтобы минимизировать объем передаваемой информации). При первой синхронизации конфигурация выгрузит все объекты в формате EnterpriseData в XML-файл (поскольку все они являются «новыми» для стороннего приложения).

Следующий шаг за сторонним приложением – оно должно обработать информацию из XML-файла и при следующем сеансе синхронизации поместить в секцию информацию, что сообщение от конфигурации за определенным номером успешно принято (поместить в поле ReceivedNo номер полученного от конфигурации сообщения). Сообщение-квитанция является для конфигурации сигналом, что все объекты успешно обработаны внешним приложением и информацию о них передавать больше не нужно. Помимо квитанции XML-файл от стороннего приложения также может содержать данные для синхронизации (в секции ).

После получения сообщения-квитанции конфигурация помечает все изменения, переданные в предыдущем сообщении, как успешно синхронизированные. Лишь несинхронизированные изменения в объектах (создание новых, изменение и удаление существующих) будут отправлены во внешнее приложение при следующем сеансе синхронизации.

При передаче данных от внешнего приложения в конфигурацию картина меняется на обратную. Приложение должно заполнить секцию соответствующим образом, а в секцию поместить объекты для синхронизации в формате EnterpriseData.

Конфигурация после обработки файла сформирует XML-файл, который будет содержать сообщение-квитанцию и новые данные для синхронизации со стороны конфигурации (если такие есть со времени последнего сеанса синхронизации).

Учет номеров отправленных и полученных сообщений

Для успешной работы механизма квитирования важно, чтобы стороннее приложение вело учет номеров сообщений, полученных от конфигурации и отправленных в конфигурацию (так же, как делает это сама конфигурация).

В информационной базе есть служебная таблица, в которую заносится информация о настроенных планах обмена. Интересующая нас ее часть содержит четыре поля:

Запись о настроенном обмене с приложением ZZ; ни одного обмена данными еще не было, поэтому в колонках номеров сообщений нули:

Предположим, что обмен данными между конфигурацией и приложением ZZ уже идет некоторое время и конфигурация отослала N сообщений приложению ZZ и получила от него последнее сообщение с номером M:

Получение подтверждения (квитанции) от приложения ZZ

http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.0.beta
2015-02-05T08:01:52

СинхронизацияДанныхЧерезУниверсальныйФормат
УП
ZZ
M+1
N + 1

1.0.beta
1.0

Этим сообщением приложение ZZ подтверждает, что данные из сообщения от конфигурации с номером N+1 получены и обработаны. Конфигурация обновляет таблицу:

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

Если у приложения ZZ есть данные для синхронизации с информационной базой, оно может поместить их в секцию того же сообщения (а может и отправить отдельным сообщением, не забыв при этом увеличить номер сообщения MessageNo).

Полная картина обмена

Предположим для простоты, что в приложении ZZ для хранения информации об обмене данными с конфигурацией используется таблица той же структуры, что и в конфигурации.

Обратите внимание, что в приложении ZZ в таблице с информацией об обмене данными с конфигурацией в полях MessageNo и ReceivedNo лежат цифры, зеркально отображенные из аналогичной таблицы конфигурации: приложение ZZ получило от конфигурации M сообщений и отправило в конфигурацию N сообщений.

После отправки сообщения из конфигурации в приложение ZZ в информационной базе увеличивается счетчик отправленных в приложение ZZ сообщений.

Приложение ZZ посылает сообщение номер M+1 о подтверждении получения сообщения от конфигурации с номером N+1

Приложение ZZ посылает сообщение номер M+1 о подтверждении получения сообщения от конфигурации с номером N+1

Приложение ZZ после обработки данных, полученных от конфигурации:

Конфигурация, получив квитанцию от приложения ZZ, делает следующее:

Источник

Обмен данными с прикладными решениями на платформе «1С:Предприятие» в формате EnterpriseData

Внимание! Данный функционал доступен в «Библиотеке стандартных подсистем», начиная с версии 2.3.1.62.

Введение

Данная статья описывает технологию интеграции с прикладными решениями на платформе «1С:Предприятие» с использованием формата EnterpriseData. Статья разделена на две логических части:

Вкратце эти 2 пункта описаны ниже, а в самой статье – подробно.

Что такое формат EnterpriseData

Это формат, позволяющий описать объект информационной базы (контрагента, накладную и т.п.) или сообщить о факте удаления этого объекта. Ожидается, что конфигурация, получившая файл в формате EnterpriseData, отреагирует соответствующим образом – создаст у себя новые объекты и удалит те, которые в файле помечены как удаленные.

Как обмениваться данными в формате EnterpriseData

Помимо информации об объектах, файл в формате EnterpriseData содержит заголовок (секцию ) со служебной информацией. По этой информации конфигурация сможет понять, от какого внешнего приложения получена информация и какую информацию нужно отправить приложению в ответ (данные о тех объектах, которые были обновлены в информационной базе со времени последней синхронизации с данным сторонним приложением).

О формате EnterpriseData

Major версия изменяется:

Minor версия изменяется:

Изменение Minor версии не приводит к потери совместимости с предыдущими minor весиями. Major версии не имеют обратной совместимости.

Объекты

Формат описывает представление объектов (документов или элементов справочников) в виде XML-файлов. Версия 1.0.1 содержит описание 94-х объектов из различных областей (финансы, производство, закупки и продажи, складские операции). Названия типов, как правило, хорошо понятны и не нуждаются в дополнительных объяснениях: например, «Документ.АктВыполненныхРабот» или «Справочник.Контрагенты». Как можно заметить, описание типов документов начинается с префикса «Документ.», элемента справочника – с префикса «Справочник.».

Каждый сложный тип (complexType) который наследует тип Object (содержит в описании инструкцию ), является описанием самостоятельного объекта. Каждый объект содержит в себе составной элемент под названием «КлючевыеСвойства»; в этом элементе хранятся свойства, по которым объект может быть идентифицирован в системе. Например, для контрагента это НаименованиеПолное, ИНН и КПП. Почти все объекты (кроме документов остатков) имеют среди ключевых свойств свойство «Ссылка»; это Global Unique Identifier (GUID), записанный в виде строки в формате , где Gx — значение соответствующего байта структуры в шестнадцатеричном представлении. Поле «Ссылка» однозначно идентифицирует объект в системе (является ее первичным ключом).

Формат также содержит описание типов вспомогательных объектов, большинство из них описывает:

Пример описания объекта

Рассмотрим формат EnterpriseData на примере сущности «Документ.АктВыполненныхРабот».

Первое поле документа – это «Ключевые свойства» типа «КлючевыеСвойстваАктВыполненныхРабот»:

Тип «Ref» описан в файле ExchangeMessage.xsd и формально является строкой, но, как было сказано выше, конфигурация ожидает в этом поле GUID в строковом представлении:

Далее в документе «Документ.АктВыполненныхРабот» следуют поля, ссылающиеся на ответственного и валюту (оба – ссылки на соответствующие объекты в системе), сумма (тип «ТипСумма», цифровой) и т.д.

Элемент Услуги имеет тип «Документ.АктВыполненныхРабот.Услуги» – это коллекция строк типа «Документ.АктВыполненныхРабот.Услуги.Строка»:

Тип «Документ.АктВыполненныхРабот.Услуги.Строка» описывает строку, соответствующую конкретной услуге:

Как можно заметить, некоторые типы в качестве последнего элемента содержат строчку

Эта строка позволяет нам добавлять в элементы произвольное количество (maxOccurs=» unbounded ) дополнительных полей любого типа (xs:any), не нарушая XSD-схему. Это та самая ситуация, когда мы расширяем объекты новыми полями, повышая при этом минорную версию формата. В этом случае программа, которая уже умеет работать с новыми полями, сможет их обработать соответствующим образом; если же программа написана для работы с более старыми минорными версиями формата – она пропустит «незнакомые» поля, не обработав их.

Поля (элементы) сущности, у которых отсутствует атрибут minOccurs=»0″, являются обязательными к заполнению (согласно стандарту XSD).

Как с помощью формата EnterpriseData обмениваться данными с конфигурациями

При обмене с использованием планов обмена конфигурации в ходе синхронизации передают только информацию об изменениях, произошедших со времени последней синхронизации (чтобы минимизировать объем передаваемой информации). При первой синхронизации конфигурация выгрузит все объекты в формате EnterpriseData в XML-файл (поскольку все они являются «новыми» для стороннего приложения).

Следующий шаг за сторонним приложением – оно должно обработать информацию из XML-файла и при следующем сеансе синхронизации поместить в секцию информацию, что сообщение от конфигурации за определенным номером успешно принято (поместить в поле ReceivedNo номер полученного от конфигурации сообщения). Сообщение-квитанция является для конфигурации сигналом, что все объекты успешно обработаны внешним приложением и информацию о них передавать больше не нужно. Помимо квитанции XML-файл от стороннего приложения также может содержать данные для синхронизации (в секции ).

После получения сообщения-квитанции конфигурация помечает все изменения, переданные в предыдущем сообщении, как успешно синхронизированные. Лишь несинхронизированные изменения в объектах (создание новых, изменение и удаление существующих) будут отправлены во внешнее приложение при следующем сеансе синхронизации.

При передаче данных от внешнего приложения в конфигурацию картина меняется на обратную. Приложение должно заполнить секцию соответствующим образом, а в секцию поместить объекты для синхронизации в формате EnterpriseData.

Конфигурация после обработки файла сформирует XML-файл, который будет содержать сообщение-квитанцию и новые данные для синхронизации со стороны конфигурации (если такие есть со времени последнего сеанса синхронизации).

Учет номеров отправленных и полученных сообщений

Для успешной работы механизма квитирования важно, чтобы стороннее приложение вело учет номеров сообщений, полученных от конфигурации и отправленных в конфигурацию (так же, как делает это сама конфигурация).

В информационной базе есть служебная таблица, в которую заносится информация о настроенных планах обмена. Интересующая нас ее часть содержит четыре поля:

Запись о настроенном обмене с приложением ZZ; ни одного обмена данными еще не было, поэтому в колонках номеров сообщений нули:

Источник