dsdred
Дмитрий Сидоренко

(55) Оказывается в 8.3.23
https://wonderland.v8.1c.ru/blog/segmentatsiya-dannykh/

Ошибся с 8.3.21

(58)

Цитата
Для хранения сообщений сервиса интеграции все же, не неких обезличенных сообщений.

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

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

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

Цитата
А какие плюсы вы видите?

1 Скорость записи https://infostart.ru/1c/articles/2062957/
2 Не нужно придумывать регистры под задачи оповещения, рассылки сообщений и т.д. https://infostart.ru/1c/articles/2059507/
То есть мы просто создаем канал и все, не нужно придумывать структуру, она идеальна под любые сообщения.
3 Нет проблем с блокировками
4 При создании в расширении не зависит от типов
5 Меньше кода при работе с ними

Есть минусы которые мне честно говоря не нравится.
1 Нет возможности ввести статус (Новый, прочитан, прочитан с ошибкой).
2 Нет возможности скопировать сообщение "1 в 1" в другой канал средствами встроенного языка. (только sql запросом)

Но эти минусы можно решить

(56) а какие цели были у механизма "Сообщения сервисов интеграции"?
Из названия же помоему понятно - для хранения сообщений.
Новые поля в нем добавляются через свойство "Параметры" имеющее тип Соответствие.

Тоесть чтобы добавить ещё один параметр доработка не требуется в отличие от регистра.

Про невозможность использовать запрос - спорный момент.
У механизма есть встроенный отбор.

Что ещё не так?

(54)расскажите про одни минусы. Мне просто интересно.

(22)Доброе утро.
В замерах все указано.

Замер с пустым телом сообщения в один поток:
Сервисы интеграции показали себя лучше регистров, запись прошла примерно на 17-19% быстрее.

и т.д.

Спасибо за статью. Доклад был замечательный!

(17) Спасибо за дополнение.

(10)На сообщения сервисов интеграций ничего лишнего не повешено.
Нет ни подписок и прочих вещей, поэтому я думаю что для обменов они прям очень хорошее нововведение.

(13)Рад что статья понравилась.

Не забывайте, что в реальных базах на регистры могут быть повешены подписки на события, различные проверки, создание версий, блокировки. Поэтому на чистой базе 10-20% это очень прилично.

(9)

Цитата
Спасибо большое за Вашу работу!

Рад, что статья понравилась.

Цитата
Уточните, пожалуйста, запись набора регистра сведений выполнялась в режиме замещения, то есть получается так, что сначала удаляются все записи в регистре сведений, а затем пишется набор с n-ым количеством записей ?

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

Цитата
Самый быстрый вариант записи в регистр сведений был в своё время описан в статье Сергея Носкова. Код выглядит вот так (объяснение в статье по ссылке):

В принципе можно провести замер и так, там чуть чуть код поправить конфигурацию.

Спасибо за замечание.