Обмен данными через EnterpriseData — механизм сравнительно новый, появился около 4 лет назад. Тем не менее уже практически все обмены между типовыми конфигурациями используют именно его. Статьи на эту тему уже естественно есть, например вот очень хорошая статья Максима Сухова. Однако, на мой взгляд, требуется более расширенное описание как теоретической, так и практической части новой технологии и самого процесса. По этому, я хочу предложить Вашему вниманию цикл статей.
Остальные статьи из цикла:
EnterpriseData – часть 2. Процесс выгрузки данных
Часть 3. Процесс загрузки данных, Идентификация объектов
Сокращения, которые будут присутствовать в статье:
- ED – универсальный формат обмена (EnterpriseData)
- КД 2.0 – конвертация данных 2.x
- КД 3.0 – конвертация данных 3.0
Содержание
- Что такое универсальный формат?
- Преимущества обмена через универсальный формат
- Недостатки обмена через универсальный формат
- Обход выборки и подбор правил конвертации
- Конвертация объекта и всех его свойств
- XDTO сериализация данных и выгрузка в XML
Первая статья будет вводной, в основном теоретической. Ее задача — донести в общем, в чем заключается новая технология, фундамент, так сказать, без которого дальнейшее постижение будет затруднительно.
Сразу замечу, не все специалисты принимают обмен через ED «на ура». Существует довольно много скептиков, и их возражения весьма оправданы. В общем, ED вызывает много дискуссий между сторонниками и противниками. Я же постараюсь быть объективным, рассказать как есть, плюсы и минусы.
Одно можно сказать точно, нравиться нам это или нет, всем придется рано или поздно разбираться с новой технологией обмена, так как компания 1С явно дает понять, что будущее именно за ED.
Сейчас кто-то наверно набросится на меня, и скажет: «Да нет же, обмен с использованием правил КД 2.0 будет существовать и дальше!»
И… Будет прав.
Да, обмен по правилам КД 2.0 будет сосуществовать параллельно, для решения различных специфических задач, для поддержки обменов с конфигурациями предыдущих версий, и там, где применение обмена через ED не является рациональным по тем или иным причинам.
Ну что же, давайте перейдем, к сути вопроса. В чем же основные отличия обмена через ED от старого, проверенного годами, универсального обмена данными в формате XML, по правилам КД 2.0?
Фундаментальных отличия, на мой взгляд два:
- Обмен происходит не между двумя конфигурациями, как мы все привыкли, а между конфигурациями и универсальным форматом.
- Для реализации обмена данными применяется технология XDTO.
Что такое универсальный формат?
Говоря понятным языком, универсальный формат – это четко заданная структура данных, которые могут быть выгружены в файл обмена. Другими словами, это описание типов бизнес — объектов, которыми нам требуется обмениваться с другими системами. Описание формата разработано компанией 1С для реализации обменов между своими типовыми решениями, и выполнено оно в текстовом виде, а точнее, в виде XML схемы. В дереве конфигурации описание формата содержится в ветке «XDTO пакеты». XDTO пакеты, по своей сути и являются схемами XML, правда с некоторыми оговорками.
По скольку, бизнес не стоит на месте, описание универсального формата постоянно изменяется и дополняется компанией 1С. Соответственно, формат имеет версию, которая состоит из трех цифр. Первые две цифры являются значимыми и меняются при значительной реструктуризации описания формата. При их изменении, совместимости с предыдущими версиями не предусмотрено. Последняя цифра версии формата меняется в случае не значительных доработок: исправления ошибок или добавления свойств, использование которых не является обязательным. Такие изменения не приводят к потере совместимости с предыдущими версиями.
Пример наименования формата: EnterpriseData_1_6_2
1 и 6 – это значимые цифры версии формата.
Компания 1С в своих типовых продуктах гарантирует срок поддержки версии формата не менее 1 года с момента ее выхода. По факту этот срок обычно больше, но, все равно, эту особенность необходимо учитывать при реализации собственного механизма обмена данными. Сроки поддержки актуальных версий формата можно посмотреть по этой ссылке.
Вернемся к обмену данными. Как говорилось выше, обмен происходит между базами данных и ED:
Если быть точнее:
- При выгрузке происходит преобразование объектов базы-источника к типам, описанным в формате.
- При загрузке происходит обратная операция – преобразование данных в формате ED к типам объектов базы–приемника.
Сразу же можно выделить основные преимущества и недостатки нового подхода к обмену данными.
Преимущества обмена через универсальный формат
- Нам не требуется знать НИЧЕГО о структуре данных принимающий стороны для формирования файла с данными. В общем случае, это может быть даже не 1С, а любая другая система, поддерживающая структуру универсального формата.
- Корректировку алгоритма выгрузки или загрузки данных необходимо делать только в случае прекращения поддержки используемой версии формата у второго участника обмена.
- Не требуется включать правила конвертации объектов в файл с данными.
- Новый подход ведет к стандартизации бизнес – объектов, используемых для реализации учетной системы.
Недостатки обмена через универсальный формат
- Процесс обмена разбит на два не связанных друг с другом этапа: выгрузка данных и загрузка данных. Для каждого этапа необходимо создавать отдельные правила конвертации.
- Структура универсального формата накладывает ограничение на состав передаваемых данных. Это может вызывать большие трудности при попытке настроить передачу не стандартных данных. Наверно это самый значительный недостаток новой технологии.
- Конфигурация, участвующая в обмене данными должна иметь соответствующий функционал для поддержки механизмов обмена. Данный функционал предоставляется отдельной подсистемой БСП.
- Ограниченный срок поддержки версий формата.
И так, мы рассмотрели, что такое универсальный формат – сердце новой технологии обмена. Дальше, поговорим о средствах его реализации:
Примечание: В некоторых источниках я даже встречал названия обмена данными через универсальный формат – обмен XDTO.
Вообще, что такое XDTO и его реализация в 1С лучше всего описано в серии статей Андрея Овсянкина.
Как было написано выше, XDTO пакеты необходимы для хранения описания формата. Собственно, без их использования нельзя будет называть обмен — обменом через ED.
Не вдаваясь в подробности, «XDTO пакеты» это преобразованные схемы XML, они являются описанием типов бизнес – объектов, используемых при обмене данными. Преобразованные потому, что не все способы представления данных в XML могут быть представлены напрямую в XDTO.
Например, представление данных в виде текста между тегами «<Message>Текст сообщения</ Message>», нельзя представить в виде объектной модели XDTO, и она будет сымитирована. При загрузке в XDTO пакет будет добавлено дополнительное свойство, имитирующее текст сообщения. Подробнее об этом во второй статье Андрея Овсянкина тут.
Информация из пакетов XDTO используются объектами фабрики XDTO для типизации данных и их быстрого преобразования в XML и обратно.
Для XDTO пакета обязательно указывается пространство имен (принято использовать произвольный url адрес), которое является уникальным идентификатором каждого конкретного пакета. Пример описание XDTO пакета:
«Фабрика XDTO» – это объект платформы 1С. Также «Фабрика XDTO» — это глобальная переменная системы с типом «Фабрика XDTO», к которой можно обращаться для создания новых объектов фабрики. Объекты фабрики XDTO, это привычные нам объекты, обладающие свойствами, доступными через точку. Свойства эти описаны в пакете XDTO, на основании которого каждый такой объект создан.
Однако, важно понимать, что объекты фабрики XDTO не имеют абсолютно ни какой связи с объектами ИБ, не смотря на внешнюю схожесть. Фабрика XDTO имеет представление только об XML типах, описанных в пакетах XDTO.
Пример:
ТипОбъектаТовар = ФабрикаXDTO.Тип(“http://my_url_adres/”, “Товар”);
Товар = ФабрикаXDTO.Создать(ТипОбъектаТовар );
«http://my_url_adres/» — это пространство имен XDTO пакета, в котором существует описание для объекта «Товар». Далее, можно заполнять свойства объекта «Товар», как обычного объекта системы.
Удобством использования фабрики XDTO является то, что ее объекты очень легко преобразуются в XML для последующей выгрузки в файл обмена.
Пример:
XMLДокумент = Новый ЗаписьXML;
ФабрикаXDTO.Записать(XMLДокумент , Товар);
Примечание: Механизмы, реализованные в БСП не требуют от разработчика непосредственной работы с объектами фабрики XDTO. Но, для понимания общей картины происходящего, я думаю, будет не лишним иметь об этом представление.
Ну что же, давайте рассмотрим основной функционал БСП, реализующий механизмы обмена данными.
Компоненты, предоставляемые БСП
Под термином «компоненты», я подразумеваю набор объектов, которые необходимы для реализации механизмов обмена данными через ED. Строго говоря, можно выполнять обмен данными и не используя их. Но тогда, все процедуры по преобразованию данных, выполнению обработчиков, работе с фабрикой XDTO, регистрации объектов к выгрузке — придется реализовывать самостоятельно.
Подсистема БСП предлагает следующие объекты для реализации механизмов обмена:
- План обмена – необходим для формирования списка объектов к выгрузке. Принципиальным отличием от обмена по правилам КД 2.0 является то, что при обмене через ED нет необходимости создавать отдельный план обмена для каждого типа конфигураций – корреспондентов. Планов обмена необходимо ровно столько, сколько используется различных версий формата. Также, в модуле менеджера плана обмена указываются некоторые необходимые настройки: версия формата, ограничения для выгрузки данных, значения «по умолчанию».
- Обработка «Конвертация объектов XDTO» — точка входя. Обработка, с помощью которой выполняются настройки обменов, выгружаются и загружаются данные.
- Общий модуль «ОбменДаннымиXDTOСервер» — модуль, в котором реализованы основные процессы выгрузки и загрузки данным.
- Общий модуль «ОбменДаннымиПредопределяемый» — модуль, в котором можно переопределить стандартное поведение системы. Например, добавить дополнительный план обмена или переопределить менеджер обмена данными.
- Общий модуль «ОбменДаннымиСобытия» — модуль, в котором реализованы алгоритмы регистрации объектов к выгрузке.
- Подписки на события – регистрация объектов к выгрузке при их добавлении, изменении, удалении.
- Общие команды – команды для выполнения настройки обменов данными и их непосредственного выполнения.
Так же как и в старой технологии, в новой необходимы правила конвертации. Только, правила теперь находятся в общем модуля каждой конфигурации, которая участвует в процессе обмена. Общий модуль имеет стандартное наименование «МенеджерОбменаЧерезУниверсальныйФормат». Название, в принципе, может быть любым.
Хранение правил внутри конфигурации имеет как преимущества, так и недостатки. Например, достаточно удобно выполнять отладку механизмов выгрузки и загрузки. Также, не значительные доработки можно выполнить непосредственно, корректировкой модуля менеджера обмена, без использования КД 3.0. Пример такой доработки можно посмотреть в отдельной статье.
Недостатком такого подхода можно считать необходимость обновлять конфигурацию базы данных каждый раз, когда требуется выполнить модификацию правил конвертации. Существует, правда, возможность использования правил из модуля внешней обработки, но тогда будут потеряны и преимущества.
Для создания и корректировки правил конвертации применяется отдельная конфигурация – КД 3.0. В данной конфигурации можно настроить соответствия между объектами информационных баз и объектами используемой версии формата. Также, можно написать программный код для обработки ряда событий. Например, можно переопределить или указать дополнительные данные перед их преобразованием в XDTO объекты в процессе выгрузки. Выполнить какие-либо действия с данными перед их записью в объекты ИБ в процессе загрузки. Более подробно все основные события выгрузки и загрузки данных, будут рассмотрены в следующих статьях.
Рассмотрим, каким образом происходит выгрузка данных.
Обход выборки и подбор правил конвертации объектов
В первую очередь анализируется состав объектов плана обмена. Все зарегистрированные к выгрузке объекты помещаются в выборку и поочередно обходятся.
Для каждого найденного объекта подбираются и начинают выполняться правила обработки данных, которые определены в общем модуле «МенеджерОбменаЧерезУниверсальныйФормат». Основное назначение правил обработки данных – это подбор правила конвертации для каждого объекта. В общем случае, правил конвертации может быть несколько для одного типа объектов.
Конвертация объекта и всех его свойств в набор вложенных структур
Выполняются выбранные правила конвертации объекта, которые состоят из правил конвертации отдельных свойств объекта и его предопределенных данных. На этом этапе формируется структура данных. Как было описано выше, есть возможность вмешаться в этот процесс и выполнить дополнительные действия с данными. Итогом процесса конвертации являются подготовленные структуры с описанием передаваемых данных. Это еще не объекты фабрики XDTO, это просто вложенные друг в друга структуры, с конечными данными простых типов (число, строка, дата).
Сериализация данных и выгрузка в XML
На самом деле, существует два вида сериализации: сериализация XDTO и сериализация XML. Первый механизм преобразует объекты информационной базы в объекты XDTO. Второй преобразует объекты XDTO в XML.
В нашем случае, данные уже преобразованы в набор вложенных структур со значениями простых типов. Тем не менее, сериализация XDTO все равно необходима, так как фабрика XDTO имеет представление исключительно только об XML – типах.
На данном этапе происходит создание объектов фабрики XDTO. На основании данных подготовленных структур происходит заполнение этих объектов. Выполняется приведение типов в соответствие с описанием в XDTO пакете формата. Также, выполняется проверка соответствия подготовленных структур и описания формата: проверка типов, наличие всех обязательных свойств и прочее. В случае выявления ошибок, выполнение выгрузки данных прерывается.
Если все данные успешно перенесены в объекты фабрики XDTO, выполняется преобразование данных в XML и выгрузка в файл обмена.
На этом общее описание процесса выгрузки можно завершить. Более детально оно рассмотрено в этой статье.
Процесс загрузки данных, в общем, аналогичен процессу выгрузки, только все происходит в обратном порядке:
- Выполняется чтение данных из файла обмена
- Выполняется создание объектов фабрики XDTO на основании данных XML и типов в описании формата.
- Каждый объект преобразуются в набор вложенных структур, для удобного доступа к свойствам из обработчиков.
- Выполняется поиск правила обработки данных и его выполнение.
- Обходятся все доступные для объекта правила конвертации.
- Происходит конвертация объекта и его свойств из набора вложенных структур в данные ИБ. На данном этапе можно получить какие-либо дополнительные данные из преобразованного объекта XDTO и записать их в дополнительные свойства формируемого объекта ИБ, для последующей обработки.
- Происходит поиск загруженного объекта в ИБ – приёмнике. По умолчанию поиск происходит по внутреннему уникальному идентификатору. Это поведение можно изменить, я расскажу об этом более подробно в следующих статьях.
- Выполняются дополнительные действия с перед записью найденного или нового объекта.
- Выполняются дополнительные действия после загрузки всех данных.
Наверно, на этом я закончу вводную статью, так как, она и так получилась достаточно объемной, неожиданно для меня. Надеюсь, что общее представление о новом формате обмена данными у Вас сформировалось, в следующих статьях я планирую более детальное рассмотрение отдельных аспектов. Обязательно буду приводить примеры.
Ставьте плюсик, если моё начинание кажется Вам полезным J.
В следующих статьях я планирую более подробно рассмотреть следующие темы:
- Процесс выгрузки данных, обработчики выгрузки.
- Процесс загрузки данных, поиск объектов в ИБ, обработчики загрузки.
- Структура XDTO пакета – как его читать, дополнять, загружать и выгружать.
- Импорт подсистем БСП для реализации обмена данными в собственных ИБ
- Работа с КД 3.0
Другие мои статьи из серии «Новый подход к обмену данными»
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Поправьте заголовок, ну не серьёзно же…
так там и картинки надо тогда менять
(1) Э… Не намного лучше стало…
Да, новый формат корпоративной даты это сильно.
Уважаемый автор!
Буду весьма признателен за исправление во всём тексте и картинках/слайдах всяких разных вариаций на тему написания ED на единственно верный вариант — EnterpriseData.
(4) ВходнойПрайс тоже норм)
Предпринимательское свидание 😉
Уже больше года использую обмен на КД 3.0 с внешней системой. Из явных минусов — сложность. Нужно описывать объекты в пакете XDTO по заданным правилам, их типы + сама по себе конфигурация КД 3.0 довольно сырая: окна обработчиков — обычные текстовые поля, в которых нет даже подсветки синтаксиса. Проще реализовать свой обмен через типовой механизм обмена v8msg
(8) зато вы пишете выгрузкузагрузку один раз для объекта и больше не паритесь, лишь поддерживаете изменения. когда в парке систем больше 10, и например, из 5 из них вы загружаете заказы, а в 8 — выгружаете реализации, вы сразу ощутите преимущества КД 3.0
(9) Это только в теории, к сожалению. На практике с чем только но приходится сталкиваться и править в этих «Универсальных» обменах, которые в типовых весьма безобразны. Обмениваем мы например УТ с УТ, обе базы типовые. В источнике Заказ Клиента имеет допреквизит «Поставщик» с типом СправочникСсылка.Партнеры (старндартный функционал, позволяет). В «Старой» конвертации никаких проблем, тем более у нас тут идентичные конфигурации. Положили в допреквизит -получили оттуда же. В «ED» у нас такой сущности как Партнер не имеется, правил выгрузки под нее нет, и даже механизмов, которые позволяют положить в «Строку» тип реквизита и его GUID а потом разобрать на приёмнике — тоже нет «из коробки». Худо-бедно нормально работает в типовом направлении УТ в Бух, например, но стоит только развернуть обмены в «обратную» сторону — сразу море сюрпризов
(9) если объект в конфигурации поменялся для КД 3.0 ты должен
А) внести изменения в пакет XDTO
Б) внести измнения в ПКО в КД3.0
В) перенести код модуля обработно в конфигурацию
В своем обмене на v8msg просто вносишь изменения в код модуля загрузки и все. Выгрузка делается системой автоматически со всеми реквизитами объекта. Править ничего не надо
+ очень важно. Для обмена, основанного на ФабрикахXDTO, имеет значение порядок тэгов в файле XML! В своем обмене порядок в XML файле может быть произвольный
(12)
вы забыли помножить количество действий на n-обменов. в примере выше получится минимум 5 действий, а в КД 3.0 так и останется 3. еще раз я не утверждаю что КД 2.0 плох, а 3.0 — идеален. вы же должны знать на, что способен тот или иной инструмент и что из этого следует. всё равно что сравнить пилу и бензопилу 🙂
насчет порядка — всё наоборот. в КД 2.0 он был важен, в 3.0 — нет
(13) это если конфигурации идентичные, то 3 действия. А если обмен БП <-> ERP, где документы не соотвествуют друг другу по структуре и реквизитам, то ПКО придется править все-равно для обеих конфигураций. + учитывайте, что для КД3.0 нужно править ПКО на выгрузку, а для обмена на v8msg — нет
Формат называется EnterpriseData. Исправьте заголовок, потому что потенциальные читатели, которые будут искать на инфостарте информацию — не смогут найти Вашу статью.
(15) Спасибо, Андрей.
Все поправил
На счет ошибки в названии всем спасибо!
Все исправил.
И за стеб тоже спасибо 🙂
Ибо, нефиг такие ошибки делать.
К сожалению, грамотность не мой конек.
(1)Исправил
(5)Исправил
Приветствую всех, надеюсь как и автор, что белых пятен, заблуждений и недопониманий в использовании формата EnterpriseData будет всё меньше. 😉
(12)
То же самое могу сказать про КД 3.0. В правила добавил универсальную процедуру, которая умеет выгружать все реквизиты объекта, в том числе и ссылочные, на другой стороне аналогичная процедура собирает данные и заполняет реквизиты. Если в конфигурацию добавили реквизит, правила не нужно дорабатывать, он подхватится автоматически.
— не нужно вводить людей в заблуждение. Это делать не обязательно.
Для выгрузки ссылочного объекта, который не поддерживается форматом ED тоже нашлось решение, не требующее менять пакет XDTO.
— для этого придумали расширения.
Никогда не задумывался о порядке тегов при использовании КД 3.0, если пользоваться БСП.
(14) не требуется синхронно менять правила КД 3.0.
Например УПП уже давно кардинально не меняется. Сделал один раз правила в КД3 и всё. Вне зависимости от появления новых документов в ERP, БП или УТ, правила в УПП не нужно дорабатывать.
(11) Увы и ах. Многообразие использования в наших типовых конфигурациях дополнительных реквизитов и сведений в самых разных вариантах таково, что мы отчаялись решить все возможные возникающие коллизии в «Универсальном обмене» постоянными допилами, а сделали отдельные обмены только допреквизитов на кд 2 для этих целей
(12) А что порекомендуете почитать по v8msg ? Где можно посмотреть работающие примеры обмена?
(21) я писал про ERP, а не про УПП. ERP сейчас очень динамично развивающаяся конфигурация
(20) это вы не вводите людей в заблуждение. Смысл КД3.0 как раз в практическом отсутствии кодинга: создал нужные объекты или доработал существующие в XDTO EnterpriseData, выгрузил получившуюся схему XSD в КД3.0. В КД3.0 мышкой нащелкал ПКО и ПОД и готово. Но по факту приходится все-равно писать сложные обработчики выгрузки и загрузки в ПКО и смысл весь как таковой в КД3.0 теряется. Работа с ним более трудоёмка чем обычный кодинг в своей процедуре загрузки XML формата v8msg
Спасибо за статью, ждем продолжения.
Если я поняла правильно, отладка правил обмена во второй конвертации так хорошо прижилась, что решили модуль отладчика правил превратить в глобальный модуль (чтоб наверняка отладить с перехватом и просмотром в любом месте). А насчет структуры куда выгружать могли хоть в ПВХ предопределенные, хоть в справочник, хоть в перечисления сделать. Решили почему бы не XDTO с пространством имен. Это круче.
Автору респект.
(23) почитайте, например,
(25) Если заниматься доработкой XDTO, то пропадает основной плюс. Слово универсальный формат можно вычеркнуть. Правда появляется другой плюс — снимаются все ограничения и появляется возможность как в КД 2 создавать правила для любых нетиповых баз.
Для вводной статьи по ED пугать людей обязательностью доработки XDTO не стоит. 😉 Это не обязательная процедура, а возможность.
Сложность — понятие относительное. Специалист должен уметь всё. Применять технологии к месту, а не что-то одно, что он умеет. Для типовых конфигураций в настоящее время стандарт — универсальный формат.
(22) Обмен доп реквизитами сделал на КД3. Осталось дополнить возможность обмена типами значений, не поддерживаемых форматом.
Печально, что в типовых правилах это не работает и недостаточно объектов формата, например для переноса наборов доп реквизитов и сведений.
И большой минус в функционале расширений — нельзя расширить состав плана обмена, нельзя подменить XDTO пакет. Если этот вопрос решить в будущих версиях, расширением можно будет решить все вопросы обмена.
(20)
Это которые слетают и перескакивают на стандартный модуль обмена, если в коде расширения ошибка :)?
(29) даже для типовых конфигураций, описанных объектов в пакете EnterpriseData, может быть недостаточно, если используются конфигурации для бюджетных учреждений и тд
На счёт сложности. На EnterpriseData есть, написанное мной, рабочее решение: экспорт/импорт справочников и документов в стороннюю ERP систему. Примерный поток несколько тысяч объектов в день и обмен v8msg. Второй вариант мне показался предпочтительнее
(31) в идеальном мире от 1С, где живет в тч и Enterprise Data, ничего не слетает )))
(31)
Расширения — механизм новый, есть конечно недочеты.
Но его уже очень многие успешно используют.
Так что Ваши опасения напрасны.
(31) Замечал такой момент. Давно была идея — установить второе простое расширение, которое не позволяет запускать типовые правила и генерирует ошибку. Это уже технические вопросы, которые можно решить. Для особо ответственных случаев можно просто снять модуль с правилами с поддержки и вставить свой.
(29)Согласен, основной плюс обмена через ED, как раз стандартизация. Это, правда, и основной минус. Но здесь уж, с какой стороны смотреть.
(32) У каждой задачи есть решение.
Но как в статье отмечено, 1С продвигает ED. И рано или поздно типовой функционал будет работать в основных вариантах обменов и для большинства конечных пользователей этого будет достаточно. Мелкие недочеты исправят программисты.
Полностью менять типовой обмен на свой очень хороший будут единицы.
Меньше всего требуют доработок правила для БП 3.0. Видимо на обмен с БП 3.0 все типовые правила на КД3 заточены.
Самые нерабочие, по моему — правила ED для УНФ.
Требуют доработок все ERP КА УТ, розница, если настраивать обмен между собой и используются виды номенклатуры, доп реквизиты, характеристики..
(37) КД3.0 ещё не стал стандартом и, думаю, не станет им. Слишком неудобная она — требует много лишних манипуляций и нюансов в использовании. История похожая на EDT — задумка хорошая, но пользоваться невозможно
(5) Почему ED — это неверное сокращение?
Смотрим статью ИТС
И видим повсеместное использование «Формат ED», «формата ED».
(38) От технологичных решений не уйти, это вопрос времени. КД 3. неудобна, но это не означает, что технология ED неправильная. Если усовершенствовать КД 3, он сможет сам конструировать сложные обработки, вставлять правила в конфигурацию, тестировать обмен.
EDT аналогично — баги уберут, инструменты появятся, удобство повысится.
Возможность копаться на низшем уровне и переставлять биты информации останется, но такой ручной труд «сделать всё самому» не сможет составить конкуренцию готовым решениям.
Например, можно написать своё решение управления данными на MS Assess 2000-х годов, создать таблицы, связи, индексы, написать функционал взаимодействия с пользователем, программировать каждое действие. Или перейти на 1С и написать тоже самое. Мне приходилось этим заниматься, специально сравнивал затраты времени, чтобы обосновать переход на 1С 8.0. Разница оказалась в 8 раз в пользу 1С.
С каждым годом объёмы информации и сложность обработки будут расти, чтобы не утонуть, придётся использовать комбайны типа EDT, стандартизировать обмены как в ED и т.п.
(40) в эпоху развития REST и JSON мы говорим о «технологичных» решениях, основанных на XML и файлообмене. Ну как-то дальше даже читать не хочется. Для меня лично, касаемо интерфейсов, которые сейчас есть у 1С, более перспективным и технологичным видится интерфейс oData
(41) Для ED не требуется обмен именно файлами. И это уже реализовано в типовых 1С. Открываем обработку «Выгрузка загрузка EnterpriseData» и видим возможность обмена текстом в виде XML. Можно в той же 1С настроить web сервисы и обмениваться в реальном времени текстом. Например, станок с ЧПУ изготавливает деталь и отправляет данные в универсальном формате в файл или в сервис, не важно. Главное он не задумывается по поводу совместимости, т.к. формат универсальный. Сегодня на том конце УПП, завтра ERP.
До появления ED синхронизация с 1С осуществлялась напрямую через com, прямыми запросами к СУБД и т.п.
Других универсальных технологичных способов обмена с типовыми базами 1С, которые поддерживаются типовыми базами пока нет. Если появится, можно будет обсуждать.
(39) Проблема была не в ED, а в вариациях написания EnterpriseData — EnterpriCeData, EnterpriseDatE и т.п.
(42) web сервисы — это уже тоже вчерашний день. «Универсальность» весьма сомнительна и требует допилки напильником. Но если нравится — пользуйтесь на здоровье. Для себя за год+ использования я не нашёл особых плюсов в обмене на XSD схеме по сравнению с обычным XML
(34) Мои опасения — это недавняя боль от бардака в статьях ДДС, которые использовались в доработанном обмене по ED в расширении, для переноса того, что переносить в ED не планировали.
Расширения же тоже можно использовать по разному. Вариант один — точечно править процедуры с использованием &Вместо — подобный вариант отличный в плане контроля действа, но неудобен в разработке и поддержке. Вариант два — подменять в расширении общий модуль
Показать
Этот вариант удобен в разработке и поддержке но «Одно неловкое движение- и ты отец» — при ошибке в расширении есть шанс что всё пойдет по стандартной схеме
Пакет XDTO можно загрузить в макет двоичными данными, mxl-xml или текстом? А модуль менеджера обмена данными вставить в обработку?
(46) Да, можно. Все обмены на УПП, КА 1.1, УТ 10.3 и т.п. так сделал.
(46)Пакет XDTO можно выгрузить в виде xsd-схемы и вставить в макет. Модуль менеджера можно вставить в модуль внешней обработки.
(45) простое решение вынести этот функционал в отдельное расширение.
Вопрос к знающим людям , есть задача организовать автоматический односторонний обмен 32-х баз ЗиУП с одной базой ЗиУП КОРП по расписанию. С помощью КД 2.0 я сделал правила и слил все данные из разных баз в одну КОРП тут проблем нет, все ясно и понятно. Префиксацию документов и некоторых справочников организовал непосредственно в самих правилах. Но это разовый обмен. Сейчас думаю на счет автоматического обмена и смотрю в сторону КД 3.0 и есть вопросы на сколько трудозатратно это все дело надо переносить все документы и справочники по ссылкам из хтих документов а так же их движения и некоторые регис тры сведений . Посмотрел формат ED 1.5 и 1.6 там нет большинства описаний документов из ЗиУП. С КД 2.0 тоже много заморочек не хочется после каждого обновления шерстить правила в поисках изменений + конфигурацию делать не типовой и писать правила регистрации для каждого объекта .
(50) Можно сделать.
Из-за ограниченного описания видов документов и справочников в ED можно поступить 2-мя способами.
1. Выбрать справочник и документ формата для переноса любого справочника и документа.Например, СтатьиДДС и КорректировкаДолга.
Написать процедуры, которые упаковывают все реквизиты и табличные части в данные формата и распаковывают их обратно.
В правилах перед началом конвертации процедура проверяет наличие ПКО и самостоятельно заполняет для ПОД используемые ПКО, чтобы не заморачиваться ручным написанием кода для ПОД загрузки.
2. Заняться доработкой формата ED Например сделать формат 1.61 — за основу берем 1.6 и дорабатываем. Новый формат вставляем в расширение, модуль с новыми правилами туда же. Подобные расширения с идентичным форматом нужно вставить во все базы, участвующие в обмене.
Ещё не забыть загрузить в КД3 конфигурацию с регистрами накопления и расчета.
1-й вариант у меня получился. Написал обработку, создание правил для нового документа или справочника занимает меньше секунды 😉
2.- вариант очень затратный по объёмам. Правильно продумать состав документов и справочников. В процессе доработки и отладки нужно часто менять формат, соответственно одновременно обновлять все базы, участвующие в обмене.
(51) Тогда по 1 варианту получается что для каждого документа писать свои правила по упаковки данных в формат ?
(52) В каждом документе вызов универсальной процедуры. Все ПКО таких документов выглядят идентично за исключением имени и ссылки на документ конфигурации. Процедура по метаданным разбирает состав реквизитов и табличных частей.
По трудозатратам сложно сказать про этот вариант, т.к. всё делалось в течение нескольких лет 😉 Используется множество процедур. От выгрузки одного реквизита по имени эволюционировало в выгрузку документа со всеми реквизитами и табличными частями.
Недостаток первого варианта — конфигурации должны быть примерно идентичными. Если они отливаются обмен не поломается, просто данные по отличающимся реквизитам никуда не запишутся.
Плюс 2-го варианта — это правильное использование универсального формата обмена, обмен возможен между сильно отличающимися конфигурациями.
Если начинать с нуля, может быть и 2-й вариант будет быстрее. Когда начинал с 1-м вариантом, расширение не поддерживало XDTO пакеты.
Минус 2-го варианта в недостатках конфигурации КД3 — там нет как в КД2 автоматического заполнения ПКС. Всё руками. Это тоже пришлось автоматизировать.
(53) Спасибо. Скорее всего придется все таки КД 2.0 юзать, так как по срокам очень ограничен , Как по мне , КД 3.0 не такой уж и универсальный формат как его позиционируют (((.
(54) формат, то как раз универсальный, задумка хорошая и правильная.
Инструменты для подготовки правил обмена с использованием КД3 ещё сырые. Если их довести до того, что умеет КД2, будет проще.
(55) Согласен , инструментария не хватает ,Да и инфы не так много , все рассматривают типовые примеры УТ-БП , В общем и целом понятно , но как доходит до дела… сразу куча вопросов. Еще раз спасибо за ответы
(53)Мне больше импанирует первый вариант, без доработки формата. Хотя конечно есть тоже нюансы. Наверно разработчикам имеет смысл создать специальные объекты формата для удобного переноса произвольных данных. Как раз для таких случаев. Ну и функционал КД 3.0 слабоват конечно. Хотя лучше, чем пару лет назад.
(54)Я бы на Вашем месте все-таки ED использовал, если смотреть в будущее.
КД 3.0 развивается достаточно быстро. Если на данный момент КД 2.0 и удобнее, через год ситуация может поменяться.
(58) Проблема в том , что я сильно ограничен по времени, до конца января уже должен быть рабочий обмен ,
Я то думал что для всех документов будет соответствие с ED , а тут такой облом , а так надо разбираться как все сворачивать в другой формат и как разворачивать потом , боюсь застрять на середине. Если как говорит , Максим у него на доработки КД 3.0 ушло несколько лет , то я за полмесяца явно не разберусь.
(51)
И спустя еще несколько лет мы получим ситуацию как с правами доступа (вместо набора прав — кирпичики, объединяемые в профиль, сохраняемый в пользовательском режиме).
Разбиваем EnterpriseData на подсистемы или даже отдельные объекты, для каждого пишем отдельный собственный формат. Унификация сохранится, в случае несинхронного обновления корреспондентов (как у нас часто бывает) можно будет отключить нерабочие участки в режиме предприятия.
(60) Интересная идея. Думал ранее над таким вариантом. Проблема в том, что на момент инициализации какой версии формата какой отдать модуль правил, мы не знаем для какого узла будут использованы эти модули. Теоретически можно перед началом обмена заново устанавливать менеджер обмена.
Ещё возникала аналогичная мысль — основной обмен через ED, вспомогательный на другом плане обмена с использованием правил на КД2.
(58)
Как выгрузить много табличных частей в одну табличную часть думаю не сложно для программиста и это к КД3 не относится. Простые типы переносим как есть, ссылочные как строка уид, даже тип данных можно не указывать, главное имя реквизита и табличной части указать.
Задержка может возникнуть с КД3 если нет опыта. И для обмена ЗУП 3 — ЗУП 3 нужно создать правила для примерно 60 документов не считая справочников. Умножаем на 3 (2 ПКО и 1 ПОД), получаем гору ручного труда.
Почему нельзя прописать в свойствах формата модуль правил обмена? В подписках на событие определяется модуль, а тут некуда его определить?
(62) вроде бы штатно для плана обмена модуль, а не для каждого узла свой модуль.
А жаль. Для узла модуль было бы удобнее, возникает такое чувство — либо разработчики работают на 2х мониторах(На одном висит ЕД, на другом модуль) либо один отдел или разработчик пишет(отвечает за разработку) ЕД с оглядкой на не-1с-потребителей, а потом под него другой подстраивает конвертацию втискивая их в типовые и особо не задумываясь. Скорее всего 2й вариант, но для этого его надо редактировать во внешнем редакторе, а загружать в 1с готовое. И я не понимаю, зачем некий протокол обмена с каким-либо (даже очень важным) не 1с-ным получателем жестко встраивать в каркас обмена между 1с-ными конфигурациями.
Но фактически такой вариант будет означать встраивание конвертации 3 в конфигурацию (модуль на плане обмена вместо обработчиков до и после начала обмена, модуль на часть XDTO вместо обработчиков перед началом выгрузки, после загрузки).
В конвертации данных 2 я пока тоже только осваиваюсь, не понимаю, как отключить регистрацию чего-то в штатных в правилах регистрации объектов.
(64)
Для обмена данными через формат EnterpriseData у конфигураций, использующих «Библиотеку стандартных подсистем», есть два веб-сервиса:
EnterpriseDataUpload – упрощенный вариант для загрузки данных в информационную базу из сторонних приложений. Не требует специальных настроек на стороне конфигурации (кроме развертывания собственно веб-сервиса); однонаправленный обмен данными – ТОЛЬКО импорт данных в информационную базу.
EnterpriseDataExchange – для двустороннего обмена данными между конфигурацией и сторонним приложением. Для работы с ним необходима настройка обмена данными на стороне конфигурации.
Теоретически можно обмениваться не только с 1С.
С одной стороны это недостаток — общий модуль правил на все узлы, с другой стороны если всем дать функционал на каждый узел свои правила, то после обновления конфигурации пользователи массово забудут обновить правила и так же будут ругать новый формат обмена.
Поэтому если программист, обслуживающий обмен смог настроить для каждого узла свои правила, то он и сможет его поддерживать в рабочем состоянии.
Т.е. так, как сделано сейчас в типовых наверное логично.
Скорее речь идет о продвинутом пользователе, который должен либо настроить обмен как есть, либо получить(купить) обновления если обмен не работает. Типовые конфигурации расходятся в направлениях — в одном нужен программист, в других нет. ED это шаг в сторону когда программисты не нужны, и они ничего не должны настраивать, не так ли?
ИМХО, конфигурации уровня КА2 и ЕРП должны иметь возможность настроек. А к примеру в БП или УНФ это будет только мешать. Но подход один.
(66) ED это правильный шаг. Не нужно заботится о синхронном обновлении конфигурации. Это значительно облегчает жизнь простым пользователям.
Все типовые обмены в целом нормально работают. Основное назначение — обмен между разнородными базами.
В ERP и КА последних версий появились настройки для каждого узла обмена — отбор по разделам учета.
Проблемы возникают при попытке через ED обменяться однотипными базами. КА 2 — КА 2, ЗУП — ЗУП. Для КД2 наоборот — создать правила для обмена однотипными базами легко.
Последние версии ED обмениваются информацией какие виды объектов они умеют отправлять и принимать. Для универсального обмена это полезно. Не нужно отправлять лишнее.
КД 2 предусматривает возможность миграции движений (т.е. перенос данных как есть, независимо от наличия исправлений в последующих периодах и последовательности проведения), КД 3 такой возможности не имеет. При настройке обмена в КД 2 с проведением в базе получателе — лучше сразу делать КД 3.
В любом случае типовая конфигурация получается отражением бизнес процесса разработки конфигурации. Если при таком количестве общих модулей и возможности добавлять методы преобразования в форматы к объектам хоть в модули объектов, хоть в модули менеджера, модуль ED один и к нему построено нечто похожее на вымученную 2ю конвертацию, то таковы особенности разделения труда самих разработчиков в фирме 1с. Есть отдел интеграции, они пока поддерживают кд2 и судя по всему слабо взаимодействуют с самими разработчиками.
(62)Штатно да, для плана обмена. Но можно очень просто прописать отдельные для узлов.
Для этого можно использовать реквизит узла «ПутьКМенеджеруОбмена» и совсем немного доработать процедуру «ДоступныеВерсииФорматаОбмена» из модуля менеджера плана обмена.
(66)Если бы теже ошибки при синхронизации и обмене были человечные а не то что сейчас можно было бы и согласится. Не каждый консультант по 1с сразу поймет что там говорится, какое свойство и почему ЕД решил не выгружать. Особенно забавно когда он два часа выгружает выгружает тысяч 20 объектов, спотыкается на каком то одном и все на смарку. При загрузке таже ситуация.
Про правила регистрации тоже хотел бы почитать.
(67)окей гугл не проходит обмен после обновления )