Планы обмена 1С

Публикация № 899200 Дата создания: 10.09.18 08:28

Разработка - Системная интеграция - Интеграция

В статье - мастер-классе Дмитрий Жичкин рассказывает, для чего нужны планы обмена 1С и какие задачи они решают. Он подробно описывает физическую структуру планов обмена и механизмов регистрации изменений, рассматривает основные проблемы, возникающие при выгрузке изменений и предлагает методы их решения.

Содержание:

 

  1. Основные техники регистрации изменений.
    1. Отметка модификации в таблице данных (change timestamp).
    2. Отслеживание изменений с данными (change data capture).
    3. Отслеживание изменений без данных (change tracking + планы обмена).
  2. Планы обмена.
    1. Физическая структура.
      1. Таблица плана обмена.
      2. Таблицы регистрации изменений.
      3. Индексы таблиц регистрации изменений.
    2. Операции с анализом SQL кода.
      1. Регистрация изменений.
      2. Просмотр изменений.
      3. Выгрузка изменений.
      4. Удаление изменений.
      5. Загрузка изменений.
  3. Проблемы блокировки.
    1. Основные конкуренты: регистратор, экспортёр, терминатор, импортёр.
    2. Выгрузка изменений.
    3. Удаление изменений.
    4. Загрузка изменений с одновременной регистрацией на заинтересованные узлы обмена.
  4. Управление регистрацией изменений.
    1. Планы обмена: состояние записи об изменении.
    2. Альтернатива планам обмена: версионирование изменений (общепринятый классический подход).
  5. Проблемы сохранения целостности данных.
    1. Невозможность целостного чтения данных связанных объектов метаданных.
    2. Порционная выгрузка данных, как метод оптимизации.
  6. Репликация транзакций, как решение проблемы целостности данных.
    1. Регистр сведений для регистрации изменений с версионированием.
    2. Получение и сохранение идентификатора транзакции (sys.dm_tran_current_transaction).
  7. Проблема сохранения целостности данных при транспортировке сообщений обмена.
    1. Негарантированная доставка (квитирование).
    2. Гарантированная доставка.
 
Обновление от 18.12.2020

Добавлена новая статья "Анализ блокировок СУБД: таблица изменений плана обмена 1С":

В статье рассматривается практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

 

Основные техники регистрации изменений

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

В мире существуют разные методики регистрации изменений:

  • Одна из них – это когда в основную таблицу добавляется отметка модификации в таблице данных (change timestamp) – какое-то поле с отметкой версии. Обычно это «метка времени» timestamp. При каждом изменении записи в это поле пишется текущий номер версии или отметка времени. Таким образом, мы можем всегда получить те записи, которые были изменены после интересующего нас момента времени. Однако этот механизм имеет один недостаток - если мы удаляем запись, то теряем информацию о её изменении (удалении). Примером использования этого механизма на момент подготовки данного материала является сервис «Мой склад». Он использует его для интеграции с внешними системами.
  • Хорошим примером отслеживания изменений с данными (change data capture) является Microsoft SQL-сервер. Он имеет подсистему, которая регистрирует изменения, считывая их из журнала транзакций. В данном случае каждое изменение регистрируется в отдельной таблице регистрации изменений, сохраняя полностью значения всех полей старой версии записи. Таким образом можно не только получить актуальную версию, старые версии, но и отследить историю всех изменений в прошлом.
  • Ну и наконец третий распространённый вариант, который в том числе используется 1С - это отслеживание изменений без данных (change tracking + планы обмена). Этот механизм является способом оптимизации хранения огромного количества данных об изменениях, которые мы получаем во втором вышеописанном случае. Далее мы рассмотрим именно этот механизм подробнее.

 

Три конкурирующие роли

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

  • Первая роль – регистратор изменений. Это какой-то кусок кода, который регистрирует изменения и добавляет новые записи об изменениях в таблицу (insert).
  • Вторая роль – экспортер изменений. Это некий кусок кода, который эти изменения забирает, куда-то выгружает и фиксирует, что выгрузил (select + update).
  • И всегда есть третья роль, которую я назвал «терминатор изменений». Если всё время регистрировать изменения, то таблицы для их регистрации будут разрастаться, вызывая в конечном итоге деградацию производительности системы.Их надо периодически чистить (delete).

Есть еще четвертый случай, но он очень редкий. Это импортер. Он является конкурентом с точки зрения системы регистрации изменений и обмена данными только в том случае, когда ему необходимо зарегистрировать импортированные изменения для передачи в другие узлы-получатели данных. Текущий узел используется как транзитный.

Три основные роли всегда конкурируют между собой за ресурсы и за записи таблицы регистрации изменений.

 

Физическая структура плана обмена

При создании плана обмена в конфигураторе, в СУБД для него создается таблица с полями, которые показаны на слайде – это скриншот структуры таблицы плана обмена из SQL-сервера. На слайде показано, что это за поля и для чего они используются.

А это – структура таблицы регистрации изменений. В ней хранятся ссылки на объекты, которые изменились в базе. Такая таблица создается на каждый объект метаданных, входящий в план обмена. Я специально взял самый простой случай. Понятно, что бывают дополнительные реквизиты, табличные части для настроек и т.д, но для простоты восприятия они убраны.

Здесь приведено описание основных полей таблицы регистрации изменений.

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

Для таблицы регистраций изменений создаются два индекса – кластерный и обычный.

Кластерный индекс нужен для того, чтобы работать с конкретными отдельно взятыми объектами, записями. Поля этого индекса следующие:

  • Поскольку каждый индекс создается по узлу, то поля «_NodeTRef» и «_NodeRRef» определяют, какой это узел и какого плана обмена. «_NodeTRef» определяет план обмена, а «_NodeRRef»  узел этого плана обмена.
  • В индекс включены оба этих поля, потому что многие операции, которые используются компонентом плана обмена, всегда делаются в привязке к кому-то узлу.
  • Поле «_IDRRef» – это, в данном случае, ссылка на объект. Я для примера взял справочник, который является ссылочным типом данных, но здесь может быть больше полей, если речь идет о регистрах сведений, накоплений и т.д. - табличных типах данных.

Обычный уникальный индекс отличается от кластерного только тем, что к полям, которые мы уже рассмотрели, добавляется поле «_MessageNo», которое позволяет работать в контексте номера сообщения. Порядок следования полей концептуально иной. Мы видим, что сначала по индексу идет узел, потом номер сообщения, а потом уже объекты. Это интересный момент – так в планы обмена интегрируется инфраструктура сообщений.

 

Операции с анализом SQL кода

Регистрация изменений

Рассмотрим основные операции. Повторюсь, есть три программных роли. Основная роль – это регистрация изменений. На слайде представлен упрощенный для понимания код. Для менеджера ПланыОбмена, вызываем метод ЗарегистрироватьИзменения(), передаем в параметры Узел и Ссылку (в данном случае регистрируется изменение по элементу справочника «Номенклатура»).

Как производится регистрация изменений на уровне SQL-кода?

  • Как только мы вызвали ЗарегистрироватьИзменения(), начинается транзакция, где первой операцией выполняется UPDATE. Как можно увидеть, мы в таблице регистрации изменений меняем номер сообщения («_MessageNo»), устанавливаем ему значение NULL. Обратите внимание, что 1С сразу пытается зарегистрировать этот объект (делает в этой таблице UPDATE), а в понимании 1С у объекта, зарегистрированного к выгрузке, значение «_MessageNo» равно NULL.
  • Следующей операцией производится проверка – есть ли там вообще этот объект (прошел ли UPDATE), а для этого выполняется SELECT. Обратите внимание, что не используются условия типа IF @@ROWCOUNT=0, просто с помощью SELECT проверяется, есть ли там что-нибудь. В условии можно увидеть «_IDRRef», он здесь потому, что регистрацию я вначале делал по конкретной ссылке.
  • Если SELECT вызывающему коду возвращает, что ничего не зарегистрировалось, то тут же выполняется INSERT. Можно увидеть, что в параметры передается NULL, который будет присваиваться полю «_MessageNo». Если отработает UPDATE, то этого INSERT может и не быть.

В любом случае, запросы UPDATE и SELECT будут выполнены всегда. Кроме этого следует отметить, что транзакция выполняется с уровнем изоляции определённой на уровне СУБД по умолчанию, для SQL Server это Read Commited. Если это версия 1С, которая использует управляемый режим блокировок, то это Read Commited Snapshot.

Я сначала подумал – зачем так сделано? Почему бы сначала не сделать SELECT, а потом решить – делать нам UPDATE или INSERT? Разница есть потому, что когда мы в транзакции сделаем SELECT, а потом захотим сделать что-то еще, другая транзакция в момент сразу же после нашего SELECT’а может успеть изменить запись. Это может нарушить логику регистрации изменений. Поэтому сразу делается UPDATE, что обеспечивает эксклюзивную блокировку записи по условиям предиката WHERE. Таким образом обеспечивается безопасность логики последующих команд SELECT и INSERT.

 

Момент регистрации изменений

Момент автоматической регистрации изменений:

1. Начало транзакции записи документа.

2. ПередЗаписью.

3. ПередЗаписью (подписка на событие).

4. ПриЗаписи.

5. ПриЗаписи (подписка на событие).

6. ОбработкаПроведения.

7. ОбработкаПроведения (подписка на событие).

8. Регистрация изменения объекта во всех планах обмена, в состав которых он входит, а также для всех узлов этих планов обмена.

9. Фиксация транзакции записи документа.

Теперь давайте разберемся, в какой момент происходит регистрация изменений.

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

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

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

 

Чтение изменений

Чтение изменений из таблиц регистрации изменений.

Запрос=НовыйЗапрос();

Запрос.Текст ="ВЫБРАТЬ * ИЗ Справочник.Номенклатура.Изменения";

SELECT * FROM [_ReferenceChngR71];

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

На уровне SQL эта операция вызывается очень просто, через обычный SELECT.

Иногда, когда оптимизируют обмены, выборку изменений делают не полностью по узлу, а точечно по ссылкам. Изменения сначала получают через запрос, потом их как-то порционируют, а потом делают ПланыОбмена.ВыбратьИзменения(), куда в третий параметр передают массив ссылок , чтобы выбрать только эти изменения и их выгрузить.

 

Удаление изменений

Третья программная роль – удаление, когда мы чистим все эти регистрации. Вариантов того, что можно передавать вторым параметром – много (это, по сути, фильтры). По факту, ничего особенного тут нет, просто параметр WHERE все время разный.

Условие по узлу есть всегда. Если второй параметр не указывать, таблица изменений по узлу будет очищена полностью.

При удалении по номеру сообщения из таблицы изменений будет удалено все, что было до этого сообщения. В SQL это делается с помощью условия:

_MessageNo <= номер сообщения.

При удалении по конкретной ссылке будут удалены изменения только этого объекта. На слайде вы можете видеть, какой будет WHERE в этом случае.

Все эти варианты работают достаточно быстро, потому что четко попадают в индекс. Я не просто так акцентировал ваше внимание на составе индексов для таблиц изменения. Эти индексы сильно связаны с теми операциями, которые можно делать через менеджер ПланыОбмена (методы ЗарегистрироватьИзменения, УдалитьРегистрациюИзменений, ВыбратьИзменения).

 

Выгрузка изменений в сообщение обмена

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

  • Создаем запись сообщения – ПланыОбмена.СоздатьЗапись();
  • Начинаем запись – ЗаписьСообщения.НачатьЗапись();
  • Выбираем изменения – ПланыОбмена.ВыбратьИзменения();
  • Записываем куда-то эти изменения, например, в «ЗаписьXML»;
  • Закрываем запись сообщения – ЗаписьСообщения.ЗакончитьЗапись();

Здесь важно понимать, что «1С» очень тесно интегрировала инфраструктуру сообщений в планы обмена и интегрировала подсистему регистрации изменений и отправки сообщений таким образом, что без объекта «ЗаписьСообщения» мы не можем поменять номер сообщения в таблице регистрации изменений. Это можно сделать только через объект «ЗаписьСообщения».

Когда мы вызываем ЗаписьСообщения.НачатьЗапись(), в этот момент платформа считывает данные из плана обмена и устанавливает для объекта новое значение свойства «Номер сообщения» – оно всегда равно последнему отправленному номеру плюс единица.

А когда мы вызовем ЗаписьСообщения.ЗакончитьЗапись(), в этот момент зафиксируется, что этот конкретный номер сообщения был отправлен.

Какие возникают основные проблемы?

  • Вызовы методов НачатьЗапись() и ЗакончитьЗапись() нужны только в случае, если мы хотим управлять номером записи. Больше нигде не используются.
  • А ВыбратьИзменения() – это метод, с которым нужно быть очень осторожным, потому что обычно, когда возникают проблемы с производительностью обменов, именно из-за этого вызова возникают блокировки.

Давайте посмотрим, что происходит на уровне SQL-кода, когда мы вызываем метод ВыбратьИзменения().

Выборка изменений, анализ T-SQLкода.

Третий параметр <ФильтрВыборки> (необязательный): объект метаданных, массив ссылок или ссылка на один объект, набор записей (используется отбор набора). По умолчанию используется значение Неопределено – выбираются все изменения.

Когда мы вызываем метод ВыбратьИзменения(), у него есть необязательный третий параметр – ФильтрВыборки, позволяющий все это отфильтровать, т.е. выбрать не все сразу, а частями. Часто для оптимизации используется массив ссылок – например, можно отобрать 100 или 1000 ссылок.

Вот что происходит, когда мы вызываем ВыбратьИзменения(), в SQL. Понимание этого кода объясняет, почему происходят блокировки.

 

Начало транзакции по выборке изменений. UPDATE

Как я уже говорил, есть роль экспортера, который должен выбрать изменения, выгрузить их в какую-то промежуточную транспортную систему и затем сделать отметку, что он эти изменения выгрузил. Делается это при помощи UPDATE в начале транзакции. Начинается транзакция, и для всех записей в таблице регистрации изменений в качестве нового номера сообщения устанавливается значение, равное номеру предыдущего сообщения плюс один. Менеджер планов обмена как бы меняет статус для этих записей, говорит системе: «Я их выгружаю».

Важно отметить, что эта транзакция создается для каждого объекта метаданных по отдельности. Когда мы выбираем изменения, мы указываем узел обмена и номер сообщения. В таком вызове будут выбраны все изменения по узлу обмена со всеми объектами метаданных и прочим. Но блокировать записи этот UPDATE будет по каждому объекту метаданных в отдельности, а не так, что взял и начал обновлять всю базу.

Если этот UPDATE изменяет большое количество записей, он может быть очень длительным. Именно из-за этого происходят блокировки. Блокировки происходят по WHERE, т.е. по узлу (поля «_NodeTRef» и «_NodeRRef») и по номеру сообщения (поле «_MessageNo»), который в данном случае равен NULL, т.е. зарегистрировано. Получается так, что помечаются, выбираются только те сообщения, которые были зарегистрированы для обмена (у которых в качестве номера сообщения стоит NULL). А те, которые до этого были отправлены и помечены (например, не прошла выгрузка или не пришла подтверждающая квитанция), он не блокирует.

Блокировки возникают потому, что есть какие-то объекты, документы, с которыми пользователи часто что-то делают. Если у нас такая система, при которой документ создается один раз, записывается, регистрируется и после этого не перезаписывается, то этих блокировок не будет. И вообще проблема блокировок на регистрации изменений касается только больших систем, где бывают выгрузки по 5 тыс. документов за один раз. В маленьких системах эта тема неактуальна, там с блокировками при регистрации изменений не сталкиваются.

Если на SQL-сервере не настроен запрет на блокировку таблицы (запрет на эскалацию блокировок), то, когда к нему прилетает запрос по изменению 5 тыс. и более записей в одной таблице, планировщик SQL очень часто решает, что с точки зрения управления ресурсами оптимальнее всего заблокировать всю таблицу. В таком случае происходит эскалация блокировок, и по данному объекту метаданных блокируется вся таблица регистрации изменений. Выгружая что-то или пытаясь зарегистрировать новые изменения или удалить их, мы ничего не можем сделать, т.к. таблица заблокирована.

Как с этим бороться?

  • Обычно на моей практике DBA-шники просто запрещают подобную эскалацию блокировок на уровне SQL-сервера.
  • И еще один способ оптимизации связан с тем, что транзакция создается для каждого выгружаемого объекта метаданных по отдельности – можно выгружать каждый объект в отдельном фоновом задании.

 

Следующий шаг. SELECT

Следующим шагом идет SELECT, который выбирает все сообщения из таблицы регистрации изменений. Поскольку после UPDATE сообщений без номера не остается, SELECT выбирает их все, в том числе и те, которые отправлялись раньше.

Поэтому если мы используя систему квитирования что-то выгрузили, но квиток не получили, то в следующий раз мы выгружаем это заново до тех пор, пока не получим подтверждения о загрузке в базе-приемника. И если у нас возникают какие-то проблемы с подтверждением сообщений, то в больших системах объем выгрузки растет экспоненциально: 10, 100, 150, 200 мегабайт – каждый раз выгрузка все больше.

 

Запись изменений в сообщения обмена

Когда мы выбрали изменения, мы их куда-то записываем. Обычно все это грузится в XML-файл, в так называемые сообщения обмена. Бывают системы хитрее, которые используют систему сообщений с помощью RabbitMQ или еще что-то и по факту XML-файл не используют – открывают его только для вида, ничего туда не пишут, он остается пустой. Так тоже можно делать. Это уже вопрос транспорта, какой вы хотите использовать. Но в большинстве случаев, в типовых конфигурациях, например, используются сообщения обмена.

 

Завершение выборки изменений

Далее мы вызываем ЗакончитьЗапись(). В этот момент в таблице плана обмена фиксируется поле «_SentNo» (в данном случае, 26).

Получается, что сначала он устанавливает этот номер в таблице регистрации изменений, но в таблице плана обмена он пока еще остается на единицу меньше. И если у нас в этот момент выгрузка падает, то возникает интересная ситуация. Например, в таблице плана обмена номер сообщения имеет значение 25, а в таблице регистрации изменений уже значение 26. Таким образом, мы можем выбрать из таблицы регистрации изменений то, что должно было быть отправлено, но по какой-то причине не отправилось.

Поэтому надо понимать, что в следующий раз опять появится 26, он не будет инкрементирован до тех пор, пока не выгрузится. Текущий номер сообщения для отправки всегда «плюс 1» от того значения, которое хранится в таблице плана обмена. Это интересный момент, в некоторых случаях его можно использовать.

Почему меняется наименование? Так работает код 1С. Он фиксирует это в таблице плана обмена по узлам – мы же выгрузку делаем по узлам, соответственно, вот это – наименование узла. И 1С почему-то это перезаписывает тем же самым значением. Как вы видите, она перезаписывает все поля. Внутренняя реализация планов обмена не менялась с версии 8.0. Она как была в такой редакции, так с тех пор и не менялась.

 

Загрузка изменений

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

 

Жизненный цикл изменений

В этой таблице я попытался обобщить основные операции плана обмена в разрезе трех основных ролей.

  • У роли регистратора изменений присутствуют три вызова: UPDATE, SELECT, INSERT. INSERT может быть вызван в зависимости от результатов SELECT.
  • Роль терминатора делает DELETE.
  • Роль экспортера делает UPDATE, SELECT. Здесь еще нужно отдельно отметить, что роль экспортера делает UPDATE для таблицы планов обмена – фиксирует выгрузку.

Я разбил это по значениям предиката WHERE, чтобы было понятно, на каких полях могут возникать блокировки. Эти три роли конкурируют за одни и те же записи, потому что в таблице регистрации изменений плана обмена для каждого объекта всегда одна запись. Именно из-за этого возникают конфликты блокировок, потому что когда мы хотим какой-то объект выгрузить, мы его блокируем и если в этот же момент его захотим еще раз зарегистрировать на выгрузку или удалить, то мы наткнемся на ограничение - для всех целей у нас только одна запись. Это – особенность реализации стратегии выгрузки с использованием предварительной регистрации изменений. Это важно, потому что возникают блокировки. Далее я расскажу, как это обойти.

 

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

  • Первое состояние – это новое изменение, когда _MessageNo IS NULL.
  • Второе состояние, когда запись ожидает выгрузки и у нее _MessageNo > _SentNo. Это происходит в сеансе выгрузки, когда мы вызываем:
    • Сначала ЗаписьСообщенияОбмена.НачатьЗапись();
    • Далее ПланыОбмена.ВыбратьИзменения() – в этот момент для записи устанавливается _MessageNo = _SentNo + 1;
    • Запись переходит в состояние «Ожидание выгрузки» – она еще не выгружена, а просто помечена на выгрузку;
    • Следующим шагом идет запись XML;
    • И вызовом метода «ЗакончитьЗапись» мы в таблице планов обмена фиксируем, что мы этот номер сообщения выгрузили: _SentNo = _SentNo + 1.
  • С этого момента у нас _MessageNo = _SentNo, и запись переходит в состояние ожидания удаления – либо по квитанции, либо, если у нас гарантированная доставка, то мы можем удалять ее сразу. Чаще всего используют квитанции.

Таким образом, сеанс обмена данными, когда мы выбираем изменения, куда-то их записываем, а потом фиксируем завершение операции, является распределенной транзакцией с двухфазным фиксированием.

  • На первой фазе устанавливаем значение _MessageNo = _SentNo + 1, т.е. начинаем транзакцию.
  • На второй фазе фиксируем _SentNo = _SentNo + 1.

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

 

Классическое решение проблемы блокировки

Какие проблемы возникают с планами обмена?

На операции ВыбратьИзменения(), в случае большого UPDATE происходят блокировки, следовательно, по этим объектам не проходят удаления и новая регистрация изменений.

Как сделать так, чтобы три роли не конкурировали за одну запись? Надо сказать, что фирма «1С» регистрирует изменения не так, как принято во всем мире. Давайте теперь разберемся, как работает классическая модель регистрации изменений.

Введение: фундаментальная проблема обмена данными.

В классике это выглядит следующим образом.

Мы имеем некий объект, например, элемент справочника, у которого есть изменения. Каждое изменение – это версия объекта (1, 2, 3 и т.д.). В классических системах регистрируются именно изменения по версиям, т.е. в таблице регистрации изменений на один объект существует столько записей, сколько раз мы его меняли. Версией может быть что угодно. Это может быть весь объект, либо только те поля, которые изменились. Есть системы регистрации вообще без данных, где регистрируется просто факт того, что эта ссылка менялась, у нее версия такая-то, а при выгрузке берутся данные, которые находятся в основной таблице (так же, как работает 1С с планами обмена).

Таким образом, в таблицу регистрации изменений всегда падает новая запись – производится INSERT, который никем не блокируется, ему никто не мешает, и он всегда фиксируется. Роль фиксации изменений ни с кем не конкурирует, она сама по себе.

Экспортер знает, какую версию отправил в прошлый раз и сразу выбирает текущие изменения (не делает UPDATE, как у фирмы «1С»). Например, он знает, что в прошлый раз отправил версию 8. Он сразу делает SELECT из этой таблицы всех версий, которые у него зарегистрированы на текущий момент, например, версии 9, 10. Их две, но умная система экспорта умеет их схлопывать, понимать, что изменилось и отправлять только одну версию, например, 10. А в системах, где используется репликация транзакций, каждая версия отправляется отдельно – сначала в целевой системе применяется версия 9, потом версия 10.

Удаление происходит следующим образом: роль терминатор, которая удаляет, уже знает, что версии 1, 2, 3 выгружались, а версии 4, 5, 6, 7 еще нет. Он знает, что последняя версия, которую он удалял, например, была 4-ая, поэтому он версии 1, 2, 3 может спокойно удалить. Он ни с кем не конкурирует, никому не мешает.

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

 

Альтернатива планам обмена

Регистр сведений для регистрации изменений с версионированием

Альтернативная регистрация изменений.

  1. Периодический регистр сведений "РегистрацияИзменений".

- Период (версия изменения)

- Транзакция (идентификатор транзакции SQLServer)

- Объект (ссылка или уникальный идентификатор)

- Данные (например, XMLпредставление объекта)

- Любые другие измерения, ресурсы или реквизиты (например, узлы-получатели данных)

Как это решить средствами 1С? Я встречал очень много альтернативных систем регистрации изменений. Расскажу об одной, наверное, самой простой.

Создаем обычный регистр сведений и практически дублируем в него таблицу регистрации изменений. Что мы сюда включаем?

  • Мы можем включить Период, сделать его периодическим (он будет играть роль версии изменения). Период используют очень часто, но я не очень рекомендую так делать, потому что тогда нам надо постоянно синхронизировать время между серверами. Потому что если в какой-то момент что-то происходит со временем, то в таблице регистрации изменений начинается бардак. Конечно, это бывает редко – у Windows, например, есть достаточно надежная служба синхронизации времени. Но такой риск есть, и я на него в жизни пару раз наталкивался.
  • Идентификатор транзакции SQL Server. Мы сейчас это рассмотрим более подробно.
  • Ссылка на объект или его уникальный идентификатор в строковом представлении и сами данные.
  • Остальные поля необязательны. Сюда можно интегрировать маршрутизацию (узлы, измерения для каких-то выборок и т.д.).

 

Проблема сохранения целостности данных

Какие проблемы хотелось бы учесть при реализации альтернативной регистрации изменений? Помимо проблемы блокировок у нас иногда возникает проблема целостности данных. Потому что некоторые объекты взаимозависимы друг от друга. Например, мы провели документ и параллельно в этой же транзакции проведения записали в какие-то регистры сведений – что-то очень важное для этого документа. При регистрации получилось несколько объектов метаданных, несколько таблиц регистрации изменений, где хранятся данные для этого документа. Но при выгрузке то, что эти объекты взаимосвязаны, не учитывается.

Конечно, классически, когда мы делаем ВыбратьИзменения() у нас идет выборка изменений по всему узлу. Но в больших системах для оптимизации изменения обычно выгружают кусками – порционируют эти сообщения и делают их как можно меньше, чтобы потом, при их загрузке в принимающую систему, транзакция загрузки была как можно меньше – чтобы  выше была конкурентность работы пользователей, и больше пользователей могло работать с системой. Таким образом часто оптимизация заключается в том, что каждый объект метаданных уходит в разных сообщениях. Поэтому может так случиться, что кусок данных для этого документа уйдет в одном сообщении, а регистр сведений в другом. Или у нас может быть несколько связанных документов, например, если мы используем механизм «Интеркампани». Допустим, у нас есть «Реализация», а у другой компании «Поступление» – эти два документа и их движения были образованы в одной транзакции, поэтом должны уехать вместе, а, используя планы обмена и прочее, очень часто бывает так, что документ приезжает, а его движений еще нет.

Как с этим бороться? Напрашивается вывод, что эти объекты нам желательно каким-то образом выгружать в одном сообщении. Как их туда поместить? Нам надо знать, что эти объекты зарегистрировались в одной транзакции. Значит, нам нужен какой-то идентификатор транзакции. Как это сделать средствами 1С я даже не представляю. Нужно специально знать об этом и код 1С уже писать изначально так: начать транзакцию, присвоить ей какой-то идентификатор, и записать идентификатор транзакции в регистр сведений, и только после этого транзакцию зафиксировать. Если этим заниматься в какой-то конфигурации, то придется переписать все. Это нереально.

Выход есть, но не 1С-ный.

 

Порционная выгрузка данных, как метод оптимизации

Чтобы обеспечивать работу своего кастомного регистра сведений, нужно эмулировать работу плана обмена, т.е. зарегистрировать изменения, удалить изменения и т.д.

Для регистрации изменений можно использовать простую экспортную процедуру ЗарегистрироватьИзменения(), код которой я тут накидал. Эта процедура может быть размещена в каком-то общем модуле, я свой общий модуль назвал МойОбменДанными.

В этой процедуре мы для каждого выгружаемого объекта создаем набор записей и пишем эти данные в регистр сведений с помощью метода Набор.Записать (Ложь). Почему «Ложь»? Потому что будет INSERT и все – нет блокировок, совсем. У нас не будет DELETE, как обычно по отбору, у нас будет сразу INSERT, одна команда SQL, ни с кем не конкурирующая. Мы просто все время дополняем регистр сведений своими версиями объектов.

 
Уточнение от 27.11.2020

Для того, чтобы выполнялась одна единственная команда INSERT, необходимо также добавить в процедуру "ЗарегистрироватьИзменениеНабора" ещё строчку кода:
Набор.ОбменДанными.Загрузка = Истина;

Спасибо за замечание bforce (см. комментарий 32).

Подробности в этой статье Сергея Носкова, раздел "Независимые регистры сведений, запись без проверок".

Функция ПолучитьXML(Объект)

ЗаписьXML = Новый ЗаписьXML();

ЗаписьXML.УстановитьСтроку();

ЗаписатьXML(ЗаписьXML, Объект);

Возврат ЗаписьXML.Закрыть;

КонецФункции

В поле «Данные» я просто сериализую объект с помощью функции ПолучитьXML(). Все просто, работает быстро. Не буду говорить о том, что здесь будут накапливаться большие данные, что это XML, что это не оптимально и т.д. Это сделано для упрощения. Вы вольны делать с этим полем все, что хотите. Я видел систему, где регистрировались только изменения реквизитов, т.е. если изменился один реквизит, например, дата документа, то выгружалась только дата и все. Соответственно, в поле «Данные» у меня каким-то образом упакованные данные изменения.

Далее – процедура ЗарегистрироватьУдаление(). Она у меня выделена отдельно, потому что ссылки надо заворачивать в Новый УдалениеОбъекта(Ссылка), чтобы в целевой системе, когда она приедет, я мог это просто распаковать, вызвать «Записать» или «Удалить». И опять же Набор.Записать (Ложь), т.е. INSERT и все.

Вспомогательная функция ИмяФлагаРегистрацииИзменений. Я ее завернул в отдельную функцию, потому что строковые константы вставлять в нескольких частях кода неправильно. Лучше сделать так, через функцию. Если вдруг вы решили поменять название флага, то вы меняете его только в одном месте.

Обратите внимание, что в процедурах ЗарегистрироватьИзменение() и ЗарегистрироватьИзменениеНабора() у нас изменения записываются только в том случае, если у объекта стоит «Истина» в дополнительном свойстве с именем флага. Зачем так было сделано?

Очень часто бывает, что мы хотим регистрировать изменения только в том случае, если объект изменился. Если он не менялся, то зачем его регистрировать и выгружать? Ни к чему. Как это сделать? Если говорить о ссылочных объектах, то разницу значений реквизитов мы можем увидеть только в процедуре ПередЗаписью(). В этой процедуре мы можем проверить, что значения реквизитов в ссылке и в объекте у нас разные. Как только мы вызовем Записать(), они платформой синхронизируются и станут одинаковые.

Поэтому в процедуре ПередЗаписью() мы вызываем нашу процедуру ЗарегистрироватьИзменения().

Когда мы попадаем в эту процедуру в обработчике ПередЗаписью() мы смотрим: если это новый объект, то мы добавляем ему новое дополнительное свойство, присваиваем ему значение «Истина» и возвращаемся. Почему так? Потому что, если мы попытаемся сразу записать ссылку в регистр сведений, то для нового объекта ссылки еще нет. Тут двойная проверка, так как у нас есть не новые объекты, у которых этого свойства пока что нет, и его тоже нужно создать.

Потом в обработчике события ПриЗаписи() мы повторно вызываем процедуру ЗарегистрироватьИзменение(). В этот момент объект уже будет не новый, он посмотрит, установлен ли у него ФлагРегистрацииИзменения, и в зависимости от этого будет записываться в регистр сведений. Эта проверка вставлена сюда на всякий случай, если вдруг мы решили отказаться от регистрации изменений по каким-то причинам. До этого мы флаг добавили, а потом мы можем этот флаг либо удалить из дополнительных свойств, либо поставить ему значение «Ложь».

 

Репликация транзакций, как решение проблемы целостности данных

Как получить идентификатор транзакции? Допустим, мы действительно хотим сделать репликацию транзакций в 1С. Все говорят, что это нереально, но это не так. Это можно сделать, повесив триггер на таблицу регистрации изменений.

У нас есть таблица нашего кастомного регистра сведений для регистрации изменений, куда мы должны записать Transaction_id. У нас она называется «_InfoRg17». Мы на нее вешаем триггер. В SQL-сервере есть процедура, которая возвращает идентификатор текущей транзакции, и мы его записываем в поле _Fld18, которое соответствует полю «Transaction_id». Теперь у нас есть идентификатор транзакции.

Как бы мы ни меняли объекты в транзакции 1С: документ, регистры, два документа связанных, если они записаны в рамках одной транзакции, то в регистр сведений они попадают через триггер, и мы для всех этих изменений получим один и тот же идентификатор транзакции. Потом мы можем это выгружать, как один монолитный кусок данных. Таким образом, мы сохраняем 100%-ную целостность.

Понятное дело, это нарушает лицензионное соглашение фирмы 1С. Я лишь говорю о возможности, а как ей воспользоваться - решайте сами. Например, продукт построения альтернативной РИБ для 1С от одной достаточно известной фирмы работает с использованием такого триггера.

 

Проблема сохранения целостности данных при транспортировке сообщений обмена

Негарантированная доставка (квитирование)

Основная проблема: повторная отправка одних и тех же данных.

Запрос для определения повторно отправленных объектов в разрезе узлов плана обмена.

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

Если вы используете квитирование, то с помощью запроса, представленного на слайде, вы можете узнать, сколько данных вы отправляете повторно в разрезе узлов плана обмена.

Здесь используется левое соединение с таблицей изменений справочника «Номенклатура», поэтому в данном случае мы получим отчёт в разрезе узлов и номенклатуры. Зная количество объектов, и примерно оценив, сколько каждый объект будет весить, вы можете посчитать даже объем данных. Это может быть нужно, например, для обоснования необходимости отказа от квитирования или просто для мониторинга, чтобы понять какие объемы данных у вас в системе летают просто так.

 

Гарантированная доставка

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

Как с этим быть? Это – проблема экспорта. Нужно передать данные в какую-то транспортную систему, которая будет гарантировать доставку, и мы будем точно знать, что пакет там не умрет, он доедет. Тут сразу возникают вопросы. Наверное, лучше всего для этого использовать специализированное программное обеспечение – очереди сообщений и т.д. В то же время нам нужно пометить, что данные отправлены, т.е. мы сформировали сообщение обмена, положили в какую-то другую транспортную систему, и нам надо как-то отметить у себя, что эти данные мы отправили. Желательно это сделать в транзакции. Если мы этого не делаем в транзакции, то у нас есть риск повторной выгрузки, т.е. мы положили в систему, стали записывать в 1С, что мы это отправили, упали и все. 1С не знает, что оно отправилось. Такое может быть. Получается, что когда система восстановится, она выгрузит это повторно.

По сравнению с квитированием, риск – вообще ерунда. Но если это по какой-то причине страшно, то надо думать, как это сделать в транзакции. Это отдельная тема, потому что тогда мы получаем распределенную транзакцию между двумя независимыми системами. В классике это разрешается через DTC, т.е. Distributed Transaction Coordinator. Есть разные способы, как это сделать. Например, можно использовать в качестве транспорта SQL Service Broker, собственную систему отправки сообщений SQL-сервера. Она полностью поддерживает транзакции, причем локальные. Например, когда вы выгружаете что-то в Service Broker в транзакции, то это локальная транзакция для SQL-сервера, а не распределенная. Это дает огромный выигрыш производительности.

Но в основном, такая 100%-ная консистентность данных не нужна. Она нужна в каких-то финансовых системах, где есть что-то, что касается денег – там это нужно. В обычных системах еще раз отправить пакет – не проблема.

С импортом там примерно такая же проблема, только наоборот. Мы должны сначала из транспорта забрать, применить изменения в целевой системе и удалить в транспорте, т.е. сказать транспортной системе, что я уже получил. Опять же при помощи SQL Service Broker эта проблема решается очень легко.

 

Заключение

Я акцентировал внимание на трёх программных ролях, которые обеспечивают обмен данными при помощи регистрации изменений. Рассказал о том, каким образом они взаимодействуют и конкурируют между собой.

1С использует метод регистрации изменений без данных. Особенностью реализации этой методики фирмой 1С является наличие только одной записи регистрации изменений для каждого объекта. Именно это порождает конфликты блокировок обмена данными.

Для решения проблем, связанных с использованием планов обмена 1С, предложена альтернативная реализация средствами платформы.

Кроме этого описана возможность реализации аналога репликации транзакций.

 

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие.

Специальные предложения

Вознаграждение за ответ
Показать полностью
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. acanta 11.09.18 19:29 Сейчас в теме
Возможно история данных в последних версиях может как то решить эту проблему, например регистрация изменений может храниться отдельно от таблицы, которая фиксирует факт выгрузки изменений и получения ответа. Место создания объекта конечно тоже интересно (например как префикс к гуидам).
2. zhichkin 1075 14.09.18 17:51 Сейчас в теме
(1) История данных - это попытка реализовать методику фиксации изменений с данными. Я упоминал о ней в статье. Если тема интересна, то рекомендую ознакомиться как это реализовано, например, в SQL Server - см. Change Data Capture. Обычно эта методика используется для аудита изменения данных и очень редко для обменов.
POWone; acanta; +2 Ответить
5. ПрестарелыйЗаяц 30.10.19 02:06 Сейчас в теме
(2) Дмитрий, у Вас много довольно вдумчивых серьезных публикаций по РИБу, возможно подскажете (может где то есть статья) связанная с причинами и расследованиями пропадания документов, движений документов и прочего. Возможно есть какая то общая методология поиска, кроме как моделировать такие ситуации.
6. zhichkin 1075 30.10.19 10:42 Сейчас в теме
(5) Добрый день! Спасибо.
Какой-то специальной методологии не знаю.

Я пользуюсь моделированием потоков данных.
Определяю точки возможных проблем.
Затем по конкретной ситуации пытаюсь понять как это могло произойти, учитывая текущую модель. Проверяю гипотезу стараясь воспроизвести проблемную ситуацию, используя расширенное логирование.

Могу посоветовать уделить особое внимание тем операциям, которые выполняются вне транзакций СУБД, или событиям, которые происходят асинхронно. Кроме этого необходимо провести аудит кода на правильность обработки исключительных ситуаций.

Например, как может "пропась" документ в РИБ (гипотеза):
1. Пакет ушел из ЦБ в узел.
2. В узле пакет приняли, документ не записался (упал с ошибкой), но пакет в целом приняли.
3. Узел отправил квитанцию.
4. ЦБ квитанцию принял, регистрацию изменений удалил.
11. ПрестарелыйЗаяц 30.10.19 11:37 Сейчас в теме
(6)
елить особое внимание тем операциям, которые выполняются вне транзакций СУБД, или событиям, которые происходят асинхронно. Кроме этого необходимо провести аудит кода на правильность обработки исключительных ситуаций.



Это типовый РИБ, но возникают вообще нереальные вещи, как то:
1) Номенклатура передалась, но единицы измерения нет - я понимаю что единицы измерения подчиненный справочник и в КД это можно настроить, но в РИБе же нет правил конвертации.
2) Документ передался, но движений нет.
3) Документ пропал в ПЕРЕФИРИИ - по сути откуда он ушел, но есть в центре.

Понятно, что какие то конкретные советы дать нельзя. Дело в том, что протоколирования же никакого нет, что исследовать ЖР ?
12. zhichkin 1075 30.10.19 12:50 Сейчас в теме
(11) Очень сложно давать советы, не зная конкретной ситуации. В общих чертах могу сказать следующее:
1) Можно настроить обмен справочником "ЕдиницыИзмерения". Можно посмотреть в сторону ручной регистрации изменений справочника "Номенклатура" - дописывать данные в обмен.
2) Стандартная проблема для РИБ: как правило документ и его движения попали в разные пакеты данных (сообщения обмена).
3) Интересная ситуация. Чудес не бывает - кто-то документ в переферии удалил. Тут можно посоветовать применить расширенное логирование при помощи подписки на событие документа, например, "ПередУдалением".

Если используете БСП, то посмотрите обработку "КонвертацияОбъектовРаспределенныхИнформационныхБаз".
13. ПрестарелыйЗаяц 30.10.19 20:16 Сейчас в теме
(12) Спасибо за консультацию от РИБа отказываемся, но интересно разобраться.
А может разная версия движка 1С по разному отрабатывать распределенный обмен ?
15. zhichkin 1075 31.10.19 00:38 Сейчас в теме
(13) Если мне память не изменяет, то принципы работы РИБ и планов обмена не менялись ещё с версии 1С:Предприятие 8.0 =) Тут всё стабильно =)
POWone; acanta; +2 Ответить
16. ПрестарелыйЗаяц 01.11.19 16:42 Сейчас в теме
(12) Добрый день еще несколько вопросов:

1) Можно настроить обмен справочником "ЕдиницыИзмерения". Можно посмотреть в сторону ручной регистрации изменений справочника "Номенклатура" - дописывать данные в обмен.

Понятно, что можно сделать ручную регистрацию, когда ты делаешь это на КД, то именно с подчиненными справочниками возникают проблемы. Вопрос следующий - средствами РИБ разве не всегда можно обеспечить корректный обмен?

2) Стандартная проблема для РИБ: как правило документ и его движения попали в разные пакеты данных (сообщения обмена).

Это вообще непонятно, что значит разные пакеты? Пакет всего один - текущая выгрузка с номером N или что то не так ? Вместе с объектом в регистрацию попадают все подчиненные объекты (Ссылочные реквизиты, движения) - или это утверждение некорректно ?

3) Интересная ситуация. Чудес не бывает - кто-то документ в переферии удалил. Тут можно посоветовать применить расширенное логирование при помощи подписки на событие документа, например, "ПередУдалением".
Там оказался "проблемый" сам документ - проводится, но не закрывается транзакция, а транзакция потом откатывается. :)
17. zhichkin 1075 03.11.19 11:55 Сейчас в теме
(16)

Вопрос следующий - средствами РИБ разве не всегда можно обеспечить корректный обмен ?

Дайте, пожалуйста, определение термину "корректный обмен" в контексте Вашей задачи.
Общий ответ: корректный обмен Вам может обеспечить только опытный программист. Никакая технология, в том числе РИБ, не решает проблемы сама по себе - это всего лишь инструмент.

Вместе с объектом в регистрацию попадают все подчиненные объекты (Ссылочные реквизиты, движения) - или это утверждение некорректно ?

Утверждение корректно, при условии, что все подчинённые объекты записываются вместе с родительским объектом в одной транзакции.

Однако, очень часто, из-за большого количества зарегистрированных в обмен объектов, в целях оптимизации выгрузки, массивы этих объектов делят на разные сообщения. В таком случае всё зависит от программиста =)

Там оказался "проблемый" сам документ - проводится, но не закрывается транзакция, а транзакция потом откатывается.

Да, такое тоже может быть. Это к вопросу об обработке исключительных ситуаций.
POWone; acanta; +2 Ответить
18. ПрестарелыйЗаяц 12.11.19 13:22 Сейчас в теме
(17)

Спасибо за информацию, с частью вопросов получилось разобраться.
Вопрос следующего характера: иногда возникает ситуация (непонятно когда), что данные "считаются" принятыми, а на самом деле это не так.
Поэтому возникает вопрос: что является признаком "принятости" файла (квитанцией) - изменивший номер принятого сообщения?
В момент получения информации механизм удаляет сообщения из регистрации с номерами меньше либо равно чем?

Вопрос №2. Насколько нормально работает обмен между разными движками: 8.2 и 8.3, по сути все должно быть ок, так как это просто ХМЛ, ну а там кто его знает?

Вопрос №3. В файлах регистрации находятся сообщения для отправки с аномально большими номера, непонятно откуда они там появились. Нормально будет если их удалить?

Вопрос№4 Те планы обмены которые не используются остаются в БД и в них соответственно накапливается регистрация документов, понятно, что обмены с ними отключены. Насколько нормально эти планы просто удалить? Или лучше сделать механизм который не будет регистрировать данные в неактивные планы обмена?

Спасибо.
3. nkroshko 22.11.18 23:14 Сейчас в теме
У меня вопрос по самостоятельной регистрации изменений. В приведенных примерах мы в регистр сведений записываем последнюю версию объекта, выгруженную в xml, но потом нам надо этот объект отправить в базы получатели. Причем конфигурации баз получателей могут отличаться от конфигурации базы отправителя и следовательно надо произвести какую то конвертацию данных. Также состав баз получателей может зависть от самого выгружаемого объекта, например выгружаем его только в базу определенного филиала. Как Вы предполагаете решать данные задачи?
9. zhichkin 1075 30.10.19 10:58 Сейчас в теме
(3) Если отвечать коротко, то есть несколько способов.

Например, фильтры миграции данных или, в терминах 1С, правила регистрации объектов, могут применяться до регистрации изменений. Эту проблему часто называют "фильтрация основанная на содержании" или подобным образом.

Правила конвертации объектов могут применяться на принимающей стороне, но никто не запрещает их применять на отправляющей стороне - в XML можно положить уже сконвертированный объект. Это зависит от самих правил конвертации в том числе.

А вообще рекомендую эту книгу для ознакомления: "Шаблоны интеграции корпоративных приложений", Хоп Грегор, Вульф Бобби
20. superspy2008 26.01.20 23:42 Сейчас в теме
(3)
В контексте XML рассмотрите использование XDTO (общий для всех ваших конфигураций пакет), это наиболее гибкий и простой в реализации вариант
4. YannikAlx 14.12.18 14:40 Сейчас в теме
А как зарегистрировать для обмена записи Регистра сведений?
7. zhichkin 1075 30.10.19 10:46 Сейчас в теме
(4) По ключу записи или по отбору набора записей регистра сведений.
Кроме этого иногда регистрируют весь набор вместе с отбором.
8. YannikAlx 35 30.10.19 10:57 Сейчас в теме
(7)Лучше поздно, чем никогда... Год уж почти прошел!!!
Да я уже все порешал...... )))))))
10. zhichkin 1075 30.10.19 10:59 Сейчас в теме
(8) Да, я сам посмеялся над собой =)
Но на самом деле ответ не столько для Вас, как для тех, кто попадёт на эту страницу может быть ещё через год =)
14. ПрестарелыйЗаяц 30.10.19 20:17 Сейчас в теме
(10) Да, мне такое нужно, а то у нас в коде (видимо за неумением) регистрируют весь РС ЦеныНоменклатуры )))))))))))))))))))
.
19. user1330752 19.12.19 16:16 Сейчас в теме
Прошу помощи. Точнее откровенно: "ПОМОГИТЕ, ПРОШУ"
Я разработчик сторонней системы (не 1С, тобишь). У нас проект, в рамках которого реализуем интеграцию с 1С. У нашей системы есть коннектор к конфигурации "1С: Предприятие". Но непонятно, кем и как он был написан. Мне поставили задачу - переписать для конфигурации УПП. Коннектор работает через планы обмена и COM-подключение.
Запускали этот коннектор - сработало для всех справочников кроме контрагентов. Стали разбираться с разработчиками 1С, оказалось, что в УПП другой состав реквизитов для этого справочника. Подскажите, как формировать XML для плана обмена?

То есть как это выглядит: стандартный механизм планов обмена выгружает изменения отслеживаемых сущностей системы в XML. Мы его получаем, парсим. Потом мы сами составляем XML для отправки в 1С. Выгружаем, запускаем импорт из XML в 1С через те же планы обмена.

Мой вопрос: какой должна быть структура XML отправляемого нами в 1С файла? То есть какие узлы должны быть для сущности "Контрагент". Может это можно как-то получить в 1С-ке? Получим структуру - сможем генерировать ее на основании данных нашей системы.

В инете нигде инфы не нашел. От отчаяния установил себе 1С с УПП и скачал пару учебников. Пока без пользы...
24. zhichkin 1075 19.03.20 01:28 Сейчас в теме
(19) Читаем ИТС, раздел "15.2.2. XML-сериализация". Там всё подробно описано.
21. superspy2008 28.01.20 17:43 Сейчас в теме
В статье допущена существенная ошибка. Новые номера сообщений в таблице регистрации проставляются не процедурой ЗаписьСообщения.НачатьЗапись(), а функцией ВыбратьИзменения(). Только после этой функции можно делать запрос к таблице регистрации и выполнять логику формирования тела сообщения.
22. e-9 24 07.03.20 12:34 Сейчас в теме
(21) а если совсем точно - номер сообщения записывается в БД функцией ЗакончитьЗапись().

Сделал на скорую руку тест в пустой базе +план обмена,+справочник,+ внеш. обработка для теста, с кодом
	фс = ПолучитьИмяВременногоФайла(".xml");
	з = Новый ЗаписьXML;
	з.ОткрытьФайл(фс);
	
	ЗаписьСообщения = ПланыОбмена.СоздатьЗаписьСообщения();
	ЗаписьСообщения.НачатьЗапись(з, Узел);
	НомерСообщения = ЗаписьСообщения.НомерСообщения;
	ЗаписьСообщения.ЗакончитьЗапись();
	//ПланыОбмена.ВыбратьИзменения(Узел, НомерСообщения);
	
	з.Закрыть();
Показать


- при каждом вызове этого кода НомерСообщения увеличивается на 1. А если закомментить ЗакончитьЗапись(), и раскомментить ВыбратьИзменения - номер сообщения каждый раз один и тот же, т.е. не запоминается в БД.
23. zhichkin 1075 19.03.20 01:16 Сейчас в теме
(22) По моему кто-то запутался с номерами сообщений:
- один номер сообщения (_SentNo) находится в таблице плана обмена;
- второй номер сообщения (_MessageNo) находится в таблице регистрации изменений объекта метаданных.

Ниже привожу выдержки из документации ИТС по этому поводу.

Метод "ВыбратьИзменения"
Для выборки изменений предназначен метод ВыбратьИзменения() объекта ПланыОбменаМенеджер. Данный метод имеет два параметра: ссылка на узел, для которого выбираются изменения, и номер сообщения, в которое изменения должны быть помещены. Метод ВыбратьИзменения() возвращает объект типа ВыборкаДанных, содержащий ключи данных, изменения которых были зарегистрированы для узла, переданного в качестве первого параметра. Кроме того, метод ВыбратьИзменения() помещает номер сообщения, переданный в качестве второго параметра, в соответствующие поля отобранных записей таблиц регистрации изменений, если в этих полях содержалось значение NULL.

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


Метод "ЗакончитьЗапись"
Для нормального завершения записи сообщения предназначен метод ЗакончитьЗапись(). При обращении к этому методу производится запись конца элемента XML, содержащего тело сообщения, и конца элемента XML, содержащего все сообщение. После успешной записи элементов XML, завершающих сообщение, сообщение считается отправленным, и его номер запоминается как номер последнего отправленного сообщения от данного узла узлу-получателю.
25. zhichkin 1075 19.03.20 01:31 Сейчас в теме
(21) По поводу метода "НачатьЗапись": я нашёл это место в статье. Там имеется ввиду, что номер сообщения меняется для объекта "ЗаписьСообщения", который находится в оперативной памяти, а не фиксируется в базе данных.
Кстати сказать, ниже по тексту статьи я пишу про фиксацию номера сообщения методом "ВыбратьИзменения" в базе данных.

Ниже привожу выдержки из документации ИТС по этому поводу.

Метод "НачатьЗапись"
У метода НачатьЗапись() два параметра: объект типа ЗаписьXML, через который будет записываться сообщение, и ссылка на узел, которому адресовано сообщение. Метод НачатьЗапись() вычисляет номер сообщения путем прибавления 1 к номеру предыдущего сообщения; производит запись начала элемента XML, содержащего все сообщение, заголовка сообщения целиком, а также начала элемента XML, содержащего тело сообщения. После этого можно приступать к записи содержимого тела сообщения.
28. superspy2008 17.07.20 13:06 Сейчас в теме
(25) добрый день. У меня все встало на свои места, по какой-то причине в сознании путалась работа с реквизитами узла плана обмена и с номерами сообщений в таблицах регистрации в метаданных.
Теперь понятно, что:
1) ЗаписьСообщенияОбмена.НачатьЗапись вешает эксклюзивную блокировку на узел плана обмена, читает номер отправленного сообщения и создает запись в xml;
2) ПланыОбмена.ВыбратьИзменения начинает транзакцию и апдейтами по таблицам регистрации вешает эксклюзивные блокировки на строки, обновляет номера сообщений с null на номер отправленного+1. Но обновляет только строки с номером is null, т.е. чем чаще обмен, тем меньше время блокирования и вероятность эскалации. Но с update много нюансов может быть в зависимости от того, как 1С строит индексы, я информацией не владею на таком уровне;
3) После обновления всех таблиц регистрации происходит выборка всех записей таблиц, транзакция фиксируется, блокировки удаляются
4) ЗаписьСообщенияОбмена.ЗакончитьЗапись обновляет номер на узле, снимает с него блокировку и закрывает xml.

Здесь все понятно кроме пункта 3 - в какой конкретно момент закрывается транзакция? Подскажите, пожалуйста. Всего вариантов может быть два - сразу после ПланыОбмена.ВыбратьИзменения или только после завершения цикла по ВыборкаИзменений.Следующий.
Условно если транзакция закрывается после выборки изменений, то на сервере должен быть поднят в память весь список объектов, в момент их обработки в цикле данные в базе могут стать неактуальными. Если транзакция закрывается после полного прохода по выборке - в базе висят блокировки на зарегистрированные объекты и вся работа с объектами будет происходить синхронно. Что-то не понятен механизм
26. user1202750 04.04.20 13:25 Сейчас в теме
Подскажите пожалуйста, сделал программную регистрацию для некоторых документов из конфигурации Управление холдингом через план обмена Универсальный формат.(односторонний обмен) После выгрузки в базу приемник не очищаются сообщения, то есть отправленные объекты не удаляются из регистрации в базе приемнике, постоянно разростается таблица Изменений , как сделать так что бы в случае успешной доставки удалялись записи в источнике ?
29. superspy2008 17.07.20 13:45 Сейчас в теме
(26) обычно это происходит в следующем порядке:

// Инициализировать механизм для последовательного чтения XML
Чтение = Новый ЧтениеXML;
Чтение.УстановитьСтроку(СообщениеОбмена);
Квитанция = ПланыОбмена.СоздатьЧтениеСообщения();
Квитанция.НачатьЧтение(Чтение, ДопустимыйНомерСообщения.Любой);
	
// Обработать содержимое сообщения и записать обновления в базу
ПрочитатьСодержимое(Чтение);  
	
// Удалить из плана записи с номерами, обработанными на стороне другой системы
ПланыОбмена.УдалитьРегистрациюИзменений(Квитанция.Отправитель, Квитанция.НомерПринятого);
	
// Освобождение ресурсов
Квитанция.ЗакончитьЧтение();	
Чтение.Закрыть();
Показать
27. Andreynikus 1218 27.04.20 18:51 Сейчас в теме
Давненько не читал посты где так так глубоко, обстоятельно и подробно раскрывается тема.
Большое спасибо автору за труды!
SirYozha; POWone; +2 Ответить
31. Alexwarsis 07.08.20 16:45 Сейчас в теме
Все увидел, затупил впереди ненужный тег был(к моему предыдущему сообщению если оно появилось после модерации)
32. bforce 456 24.08.20 15:36 Сейчас в теме
пишем эти данные в регистр сведений с помощью метода Набор.Записать (Ложь). Почему «Ложь»? Потому что будет INS ERT и все – нет блокировок, совсем. У нас не будет DELETE, как обычно по отбору, у нас будет сразу INSERT, одна команда SQL, ни с кем не конкурирующая. Мы просто все время дополняем регистр сведений своими версиями объектов.


Здесь есть нюанс, который описан в https://infostart.ru/1c/articles/527518/#независимые_РС_Режим_2_Запись_без_замещения (под заголовком Независимые РС. Режим 2. Запись без замещения.). Один единственный INSERT будет при соблюдении двух условий ОбменДанными.Загрузка = Истина и Набор.Записать(Ложь).
Без первого условия, согласно упомянутой статье, будет целая простыня из запросов, включая создание временной таблицы, два INSERT и SELE CT. Если смотреть только по количеству запросов, то запись в режиме замещения выглядит более быстрой (DELETE + INSERT).

Я бы предложил этот нюанс в Вашей статье исправить, чтобы он не вводил в заблуждение.
33. zhichkin 1075 27.11.20 13:14 Сейчас в теме
(32) Спасибо за замечание! Проверил SQL Profiler'ом - да, всё так и есть. Добавил Ваше уточнение в текст статьи.
Оставьте свое сообщение

См. также

Обмен данными. Консистентность vs Многопоточность Промо

Интеграция v8 1cv8.cf Бесплатно (free)

Рассмотрим теоретические основы обмена данными. Какие бывают обмены, какие гарантии при этом даются, зачем идти на компромиссы и что при этом может пойти не так. Есть ли идеальная схема?

03.09.2019    14426    m-rv    1    

Собираем данные для отчетов из +100 баз

Поиск данных Интеграция Управленческие v8 Бесплатно (free)

Ведущий разработчик ГАОУ ДПО ТемоЦентр Василий Попов на онлайн-митапе Инфостарта «Интеграционные решения в 1С» поделился кейсом о том, как собрать данные для отчетов из +100 баз, какой стек технологий для этого использовать, и к каким проблемам нужно быть готовым.

вчера в 12:00    250    pallid    5    

Описание формата 1С JDTO (JSON data transfer object)

Интеграция Перенос данных из 1C8 в 1C8 v8 Бесплатно (free)

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

16.07.2021    3953    zhichkin    32    

Ошибка синхронизации документа "Отчет переработчика" и боль типового обмена (УНФ - БП)

Перенос данных из 1C8 в 1C8 v8 УНФ Россия УУ Бесплатно (free)

В данной статье поделюсь доработкой, а точней исправлением типового обмена УНФ - БП, документа "Отчет переработчика", и заодно опишу подход к решению подобных задач. Здесь не будет описано, что такое "МенеджерОбменаЧерезУниверсальныйФормат", "xdto", "EnterpriseData", по этим пунктам должны быть базовые знания.

08.06.2021    796    con-men    0    

Как прикрутить ГУИД к регистру сведений Промо

Практика программирования Перенос данных из 1C8 в 1C8 Разработка v8 Бесплатно (free)

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

16.04.2019    22055    m-rv    17    

Особенности online-обмена между старыми и новыми типовыми

Перенос данных из 1C8 в 1C8 БСП (Библиотека стандартных подсистем) v8 8.3.14 8.3.6 8.3.8 КА1 КД ДО Бесплатно (free)

Столкнулся с неприятной особенностью потери части данных при обмене УСО (УПП) - ДО.

01.06.2021    2346    echo77    7    

Пример организации HTTP сервиса на 1С: Документооборот. Источник 1С: ЕРП => Приемник 1С: Документооборот

Документоборот 2 Интеграция v8 ДО Бесплатно (free)

Статья - пример для разработчика, как можно, не используя подсистему Интеграция с Документооборотом, управлять процессами, а именно на нашем примере прерывать выполнение процессов в 1С: Документооборот. Используя данный пример, можно организовать http-сервис в любой конфигурации 1С, которая поддерживает механизм HTTP сервисов.

13.05.2021    1858    Flover    0    

Настраиваем авторизацию пользователей 1С через Okta

Интеграция v8 Бесплатно (free)

Чем больше в компании различных конфигураций и сервисов, тем актуальнее становится проблема единой системы авторизации single Sign-On. Его лидером практически безоговорочно считается Okta. Но на просторах интернета очень мало информации про интеграцию 1С с Okta через протокол OpenID Connect. Что ж, настало время восполнить недостающие пробелы и перевернуть эту печальную страницу в вашей истории

30.04.2021    3064    ripreal1    13    

Повышаем эффективность разработки правил обмена Промо

Практика программирования Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

Как повысить скорость и качество разработки правил обмена? Как вести групповую разработку правил обмена? Как облегчить сопровождение правил обмена после передачи в эксплуатацию? Об этом и многом другом вы можете узнать из этой статьи.

25.06.2018    29753    olegtymko    48    

Добавление нового документа в формат обмена EnterpriseData (получение)

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Россия Бесплатно (free)

Данная статья - логическое продолжение (ссылка на первую часть ниже) доработки обмена, но уже на стороне базы приемника.

27.04.2021    769    con-men    1    

Добавление нового документа в формат обмена EnterpriseData (отправка)

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Россия Бесплатно (free)

Для меня встала задача добавить новый документ, созданный в расширении, в формат обмена EnterpriseData, между БП - УНФ. Изначальный поиск решения не дал результата. Методом проб и ошибок у меня сформировалось свое решение, которым спешу поделиться, чтобы систематизировать информацию в текст и услышать плюсы, минусы подхода. Все доработки осуществляются в расширении, в котором и был создан новый документ.

21.04.2021    1761    con-men    5    

Правила обмена больше не нужны

Внешние источники данных Обмен через XML Перенос данных из 1C8 в 1C8 Распределенная БД (УРИБ, УРБД) WEB v8 Бесплатно (free)

Есть несколько общепринятых подходов к написанию обмена между 1С-системами, каждый из которых упирается в длительное изучение технологии, мучительную отладку правил конвертации и написание большого количества сервисного кода, в котором потом тяжело разобраться. О принципах работы универсального фреймворка liteExchange, который реализует быстрые обмены между 1С и внешними системами, и берет на себя всю техническую обвязку по стандартному преобразованию данных, на INFOSTART MEETUP Saint Petersburg.Online рассказал Николай Крылов.

17.03.2021    9639    Nikola23    36    

Универсальный обмен между идентичными конфигурациями через REST интерфейс OData. Часть І: Справочники Промо

Перенос данных из 1C8 в 1C8 v8 Бесплатно (free)

Сейчас все чаще интеграции различных конфигураций проектируются через HTTP-сервисы - они и работают быстрее, и "войти" в режим отладки гораздо проще, тем самым обойдя "черный ящик" универсального обмена через xml, например. Более года назад я начал работать в компании, в которой разработчики работали с конфигурациями 1С в режиме совместимости еще 8.2.16 (менять режим совместимости в типичных базах мы не хотели) - а как Вы наверное знаете, если интересовались HTTP-сервисами в 1С, их использование в режиме совместимости 8.3.4 и ниже недопустимо - и здесь я уже не надеялся на разработку и использование HTTP-сервисов. Но позже меня заинтересовал такой "сервис" как REST интерфейс OData, так как его можно использовать не меняя режим совместимости конфигурации - именно он и стал для меня идеальным вариантом решения "нетривиальных" задач.

11.05.2018    24571    V.Stavinsky    11    

«БИП: Бизнес-Процессы». Интеграция с Telegram и Конструктор чат-ботов

Управление бизнес-процессами (BPM) Интеграция v8 УУ Бесплатно (free)

В статье приводятся примеры настройки автоматических оповещений в системе «БИП: Бизнес-Процессы» с использованием мессенджера Telegram. Также, приводятся примеры создания и настройки произвольных чат-ботов с использованием Конструктора чат-ботов.

15.02.2021    877    YuriYuriev    0    

Архитектурное решение интеграции баз 1С с использованием брокера сообщений Rabbit MQ

Интеграция v8 1cv8.cf Бесплатно (free)

При решении задач интеграции баз данных можно использовать различные средства «транспорта» сообщений. Одним из таких механизмов является брокер сообщений «Rabbit MQ». Такие механизмы очередей сообщений удобно использовать для организации обмена между информационными системами с различной структурой данных, когда велик объем передаваемой информации и требуются гарантии успешной доставки сообщений, а также когда поддержание работоспособности иных способов передачи, например через файлы, становиться слишком трудоемким. Брокер сообщений Rabbit MQ широко описан в сети, но 1С пока не имеет штатных механизмов работы с ним, поэтому их приходится дорабатывать. Рассмотрим пример архитектуры 1С с его использованием.

12.02.2021    1369    Koder_Line    2    

Перенос данных из ЗУП 2.5 в ЗУП 3.1

Зарплата Перенос данных из 1C8 в 1C8 v8 v8::СПР ЗУП2.5 ЗУП3.x Россия БУ Бесплатно (free)

Довольно часто сталкиваюсь с тем, что у коллег возникает вопрос, как правильно выполнить перенос данных из ЗУП 2.5 в ЗУП 3.1. (Неужели еще кто-то до сих пор работает в ЗУП 2.5? Да, и очень много людей)

25.01.2021    6636    VAAngelov    68    

Взаимодействие между базами 1С через COM Промо

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Рассмотрено много особенностей взаимодействия между базами 1С по COM технологии

10.08.2015    168622    tormozit    70    

Перенос документов 1С из одной базы в другую

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Здравствуйте, коллеги! В своей практике работы с 1С для решения задач бизнеса мне неоднократно приходилось применять инструменты переноса документов 1С из одной базы в другую, причем работать приходилось как с однотипными конфигурациями, так и с разными. Этим интереснейшим опытом я и поделюсь в данной статье.

23.01.2021    16167    Koder_Line    9    

Объединение баз ЗУП

Перенос данных из 1C8 в 1C8 v8 v8::СПР ЗУП3.x БУ Бесплатно (free)

Есть база ЗУП 3.1, в которой ведется одна организация, все данные из нее нужно перенести в общий ЗУП, обе базы типовые. Используем для переноса КД 2.0.

10.01.2021    1556    roger83    0    

HTML редактор/editor (Wysiwyg) для WebKit 1С (CMS, B2B), альтернатива TinyMCE и стандартному ФорматированныйДокумент

WEB Интеграция v8 v8::УФ 1cv8.cf Бесплатно (free)

Suneditor - отличная замена HTML редактору TinyMCE (бесплатному), в публикации с открытым кодом подключим его в 1С с WebKit, скачать HTMLeditor обработку можно бесплатно.

28.12.2020    2978    SizovE    25    

Использование инструментов разработчика для отладки обменов КД 2.0 Промо

Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

Пара трюков, благодаря которым жить становится намного проще...

05.05.2017    28489    unichkin    6    

Неожиданное использование XDTO

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Расскажу про свой опыт, как XDTO может помочь в отладке обменов данных. И какие полезности можно почерпнуть для себя при работе с XDTO.

05.12.2020    2801    simon_sidoruk    22    

Чтение вложенных свойств Структур Структуры, Соответствий, свойства через точку, разбор JSON

Практика программирования WEB Интеграция Универсальные функции v8 Бесплатно (free)

JSON: {user.device.type} - как получить значение {type}? А если вложенность значительно глубже? Как проверить, что оно заполнено или удалить его - всё это в публикации с открытым кодом и даже без рекурсии. Бонусом разбор дерева значений - ДанныеФормыЭлементДерева, СтрокаДереваЗначений.

17.11.2020    1964    SizovE    2    

Сказ о том, как в одной крупной компании документооборот внедряли, или проблемы типовых обменов между КА и ДО

Интеграция Документоборот 2 Перенос данных из 1C8 в 1C8 v8 ДО КА2 Бесплатно (free)

Приветствую всех. Сегодня пойдет речь о том, как на одной крупной компании внедряли 1С:Документооборот 2.1 в связке с КА 2.4. Вроде бы системы типовые, мы практически не добавляли ничего в них, но проблем было столько, что я решил изложить их в статье. Может, кому-то пригодится это в дальнейшем, и не придется тратить кучу времени на поиск решений.

10.11.2020    6294    maks_20    23    

Приемы обработки больших данных в 1С Промо

Универсальные обработки Математика и алгоритмы Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Рассказ об эффективных приемах организации обработок больших объемов данных на платформе 1С

07.08.2015    70124    tormozit    28    

Простой пример разработки регулярного обмена с использованием БСП на примере ERP 2.4 и УПП 1.3

БСП (Библиотека стандартных подсистем) Перенос данных из 1C8 в 1C8 v8 1cv8.cf УПП1 КД ERP2 Россия Бесплатно (free)

Данный вариант подойдет тем, кто хочет настроить "свой" регулярный обмен с добавлением "своих" планов обмена с использованием правил обмена на КД 2.1.

27.10.2020    5888    байт    14    

Структура обработки загрузки номенклатуры поставщика с примерами и комментариями (часть 2)

Интеграция Практика программирования v8 1cv8.cf Бесплатно (free)

В статье опишу вариант обработки для загрузки номенклатуры поставщика, блок загрузки номенклатуры и доп. реквизитов.

17.10.2020    924    malikov_pro    3    

Управление соляриями из 1С через Arduino

Интеграция v8 1cv8.cf Здравоохранение, медицина, стоматология УУ Бесплатно (free)

Мой опыт автоматизации сети соляриев с интеграцией 1С и оборудования соляриев с помощью платформы Arduino.

01.10.2020    2762    impextr    32    

Настройка типового обмена данными между: 1С: Предприятие Бухгалтерия ред. 3.0 (БП 3.0) и 1С: Управление торговлей ред. 10.3 (УТ 10.3). Промо

Перенос данных из 1C8 в 1C8 v8 УТ10 Россия Бесплатно (free)

В этой статье я опишу, как настраивается типовой обмен данными между БП 3.0 и УТ 10.3.

29.01.2014    278656    arr    56    

Взаимодействие 1С со сторонними продуктами посредством REST и Golang (middleware). Часть 3 - ElasticSearch

Интеграция Журнал регистрации v8 1cv8.cf Бесплатно (free)

Как в статье №1 этого цикла выгрузим через прослойку журнал регистрации (xml формат) в ElasticSearch. Статья будет иметь практическую направленность в минималистичном стиле

14.09.2020    1906    dmitry-irk38    4    

Интеграция с Трелло. Готовый код

Обмен данными 1С Интеграция Agile (XP, SCRUM, Канбан) v8 Бесплатно (free)

Код основных действий, интеграция с API Трелло.

19.08.2020    4093    Yashazz    14    

Интеграции с сервером SQL. Быстро и просто

Интеграция Внешние источники данных v8 1cv8.cf Бесплатно (free)

Решаем вопросы экспорта/импорта данных в базы отличного от 1С происхождения.

06.07.2020    3550    Infector    4    

Отладка правил обмена 7.7, 8 Промо

Перенос данных из 1С7.7 в 1C8.X Обмен через XML Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

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

29.10.2013    52351    pyrkin_vanya    70    

Мониторинг факта выполнения обмена с помощью сервиса healthchecks.io

Интеграция Системное администрирование v8 1cv8.cf Россия Бесплатно (free)

В статье опишу вариант простого мониторинга обработчиков, запускаемых по расписанию.

30.06.2020    2321    malikov_pro    7    

Как мы запилили в АЙТАТ.РФ обработку-бота, чтобы ускорить отгрузку в 2 раза или Реальный опыт внедрения нового механизма "Трансляция событий" от 1С-Коннект

Интеграция v8 Бесплатно (free)

Статья о внедрении и использовании в решениях задач нового механизма от 1С-Коннект. Будет полезно тем кто использует интеграцию 1С-Коннект с 1С Предприятие. На текущий момент механизм "Трансляция событий" находится в бета-тестировании и доступен только закрытому списку приглашенных участников. Выражаем благодарность разработчикам механизма "Трансляция событий".

24.06.2020    2123    direwest    4    

Маркировка лекарственных препаратов. Часть первая "Быстрая интеграция"

Интеграция Розничная торговля v8 1cv8.cf Фармацевтика, аптеки Россия УУ Бесплатно (free)

Данный цикл будет посвящен маркировке лекарственных препаратов (далее ЛП), нюансам работы с "1С: Библиотека интеграции с МДЛП", доступной для скачивания на сайте ИТС, методиками работы с регистраторами выбытия, и проблемам, с которыми пришлось столкнуться при интеграции. Эта статья будет представлять из себя краткую инструкцию, что делать, когда маркировка уже близко и необходимо быстро внедрить ее. Надеюсь, она станет подспорьем в данной задаче. Будут приведены рекомендации, как в короткие сроки с минимально необходимой функциональностью и минимумом чтения документации произвести интеграцию библиотеки МДЛП и выполнить начальные настройки. Также будут даны рекомендации по быстрым, но важным, на мой взгляд, доработкам.

23.06.2020    8890    IssakN    37    

Обмен по расписанию типовыми средствами. Промо

Распределенная БД (УРИБ, УРБД) Обмен через XML Перенос данных из 1C8 в 1C8 v8 1cv8.cf Россия Бесплатно (free)

Часто перед интеграторами стоит задача организовать автообмен (по расписанию или при наступлении какого-либо события) данными между различными конфигурациями. В этой статье я попробую изложить простую инструкцию, как это можно сделать средствами, заложенными в типовые конфигурации 1С (ЗУП, БП, УПП и т.д.). Для обмена используется подсистема "Обмен данными" из БСП

20.06.2012    105007    kser87    52    

Диадок. Подключаемый модуль. Отладка

Интеграция Внешние источники данных v8 1cv8.cf Бесплатно (free)

Небольшой пример, как работать с подключаемым модулем Диадок (для изменения УПД перед выгрузкой на сайт Диадок.). Отладка подключаемого модуля, если не смогли подключить стандартную отладку.

17.06.2020    10276    John_d    14    

Конвертация данных 2. Использование подключаемых обработок в правилах обмена. Конвертация дерева значений

Обмен данными 1С Обмен через XML Перенос данных из 1C8 в 1C8 v8 КД Бесплатно (free)

Разработка правил обмена с использованием подключаемых обработок. В качестве примера рассмотрена реальная задача конвертации дерева значений.

15.06.2020    5299    Drivingblind    9    

Конвертация данных 2.1. Методика переноса остатков

Перенос данных из 1C8 в 1C8 v8 1cv8.cf УУ Бесплатно (free)

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

12.06.2020    12762    aximo    21    

Заготовка для загрузки файлов по ftp Промо

WEB Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

3 процедуры и 1 макет

03.06.2013    31067    anig99    6    

1C# – 1С моей мечты

Интеграция v8 Бесплатно (free)

Встроенных в платформу 1С возможностей не всегда хватает для построения сложных интеграционных схем между различными 1С и не-1С-решениями на базе MS SQL Server. Как сделать интеграцию между SQL-базами более гибкой с помощью платформы 1С# на конференции Infostart Event 2019 Inception рассказал Дмитрий Жичкин.

01.06.2020    12713    zhichkin    36    

Обработчик "После завершения транзакции" своими руками

Практика программирования Интеграция v8::blocking Бесплатно (free)

Обработчик "Сразу после завершения транзакции" очень востребован в механизме обмена мгновенными сообщениями, развитием которого фирма 1С заинтересовались настолько, что уже создала "Сервисы интеграции". Но платформа 8.3.17 всё еще не имеет полноценного обработчика "После записи" в подписках на события.

31.05.2020    3659    barelpro    63    

Интеграция Camunda BPM и 1С

WEB Интеграция v8 Бесплатно (free)

Быстрый старт. Только практические примеры. Установка, запуск и публикация бизнес-процесса на сервере Camunda BPM. Управление бизнес-процессами из 1С при помощи Camunda REST API.

12.05.2020    5802    zhichkin    30    

Интеграция «1С:Управление производственным предприятием» с «1С:Документооборот» Промо

Перенос данных из 1C8 в 1C8 Документооборот и делопроизводство Документооборот и делопроизводство v8 КА1 УПП1 ДО Бесплатно (free)

В данной статье пойдет речь о возможности интеграции 1С:Управление производственным предприятием ред. 1.3 с 1С:Документооборот КОРП и о том, что может получить предприятие от этой интеграции.

18.02.2013    65589    Vladimir_Konyrev    38    

Механизм XDTO

Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

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

12.05.2020    6651    totchaz    4    

Как мы загружаем данные в "Центр управления кассами Магнита"

Внешние источники данных Интеграция v8 1cv8.cf Бесплатно (free)

Статья о том, как мы делали механизм загрузки больших объемов данных в "Центр управления кассами Магнита"

08.05.2020    5626    chernenko_vv    26    

Интеграция СуперОкна7 и УНФ

Интеграция Внешние источники данных v8 УНФ Россия Бесплатно (free)

Изучаем базу данных СуперОкна7, смотрим возможности передачи и получения информации.

08.05.2020    2873    vostok1.dz    3    

Особенности обмена данными с использованием "ручной" регистрации Промо

Распределенная БД (УРИБ, УРБД) Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Эта статья рассчитана на программистов, которые используют обмен данными с помощью метода "ВыбратьИзменения" и последующую их запись. Только для планов обменов, имеющих "ручную" регистрацию.

14.01.2013    36220    logarifm    6    

Синхронизация БИТ:СКУД 8 с Parsec.Net 2.5

Интеграция Внешние источники данных v8 1cv8.cf Бесплатно (free)

Настройка синхронизации БИТ:СКУД 8 с Parsec.Net.2.5, выгрузка данных из внешней системы контроля доступа.

04.05.2020    4685    RPGrigorev    0    

Измерительная лаборатория с использованием 1С+Ардуино

Периферийные устройства Интеграция v8 Россия Бесплатно (free)

1С в автоматизации "научных" и около... экспериментов.

02.05.2020    4945    maxlab    16    

Интеграция БИТ:СКУД с типовой конфигурацией

Интеграция v8 1cv8.cf Россия Бесплатно (free)

Интеграция БИТ:СКУД с типовой конфигурацией, обновление БИТ:СКУД в составе конфигурации и отдельно. Обновление системы защиты.

26.04.2020    5974    RPGrigorev    0    

Интеграция 1С и BI-системы: мой опыт с коннектором ATK BIView

Интеграция v8 1cv8.cf Россия Бесплатно (free)

Интеграция 1С и BI-системы: мой опыт с коннектором ATK BIView.

06.04.2020    5623    Flyerink    2