Загрузка данных. Библиотека конвейерного обмена данными
Интеграция - Перенос данных 1C
Бесплатные
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Узнавайте о новых бесплатных решениях в нашей телеграм-группе Инфостарт БЕСПЛАТНО
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Загрузка данных в библиотеке Конвейерного обмена данными: от входящего сообщения до проведенного заказа
В предыдущей статье мы выбирали объекты в 1С, запускали регистрацию к обмену и проверяли маршруты. Теперь пройдем входящий путь: возьмем сообщение с заказом, загрузим его вместе со складом и товарами, выполним отложенное проведение и посмотрим, что изменилось в базе. Затем загрузим обновление существующего заказа и исправим сообщение, которое завершилось ошибкой.
Пример построен на демонстрационном расширении Конвейерного обмена данными.
Технические подробности вынесены в спойлеры «Как это устроено» под соответствующими шагами. Основную последовательность можно пройти через формы. Программный запуск всей входящей очереди показан отдельно.
Рубрикатор
| Шаг | Что делаем | Что получаем |
|---|---|---|
| 1. Подготавливаем пример | Проверяем данные и регламентные задания | Исходное состояние очередей |
| 2. Разбираем сообщение | Выбираем заказ от WEB | Отправителя, тип и данные для загрузки |
| 3. Загружаем заказ | Запускаем обработку выбранной записи | Заказ и задания отложенной обработки |
| 4. Выполняем проведение | Обрабатываем задание заказа | Рассчитанный итог и движения |
| 5. Загружаем обновление | Меняем данные существующего заказа | Тот же документ с новым составом |
| 6. Разбираем ошибку | Сравниваем два режима команды загрузки | Сообщение в регистре ошибок |
| 7. Исправляем и повторяем | Сохраняем исправленное тело и загружаем его | Заказ и новое задание проведения |
| 8. Подключаем свой сценарий | Разбираем точки интеграции | Основу для собственного загрузчика |
1. Подготавливаем пример: что уже есть в demo
Откройте подсистему «Конвейер обмена данными» и найдите три списка:
- «Входящая очередь сообщений (КОД)» — сообщения, ожидающие первичной загрузки;
- «Ошибки загрузки сообщений (КОД)» — сохраненные сообщения, которые не удалось обработать штатным проходом;
- «Отложенный процессинг (КОД)» — операции, которые предстоит выполнить над записанными объектами.
После начального заполнения эти списки содержат разные данные. Первую пачку demo уже попыталось загрузить: корректные данные записаны, неудачные сообщения сохранены в ошибках, для объектов созданы задания процессинга. Вторая пачка оставлена для самостоятельной работы. В ней 22 сообщения: 10 заказов, 6 товаров и 6 складов.
Для статьи рассмотрим работу с тремя сообщения второй пачки:
Значение demo_case в заголовках |
Назначение |
|---|---|
pending-order-single |
Новый заказ IN3000101, один товар, количество 5 |
pending-order-update |
Обновление заказа IN3000004, новое количество 12 |
pending-order-invalid-date |
Заказ IN3000111 с неверным месяцем в дате |
Для повторения всей последовательности измените значение константы "Версия демо-данных" на 0.
Модуль Демо_КОД_ОбновлениеИнформационнойБазы выполняет заполнение по версиям. Версия 1 создает исходные объекты. Версия 2 добавляет 16 сообщений, версия 3 — еще 18 сообщений с заказами. Генерация фиксируется, после чего запускается загрузка только начальных демо-сообщений версий 2 и 3. Затем добавляются 10 сообщений с заказами версии 4 и 12 сообщений со справочниками версии 5, которые остаются во входящей очереди.
В заголовках сохраняются demo_version, demo_case и expected_result. Они помогают отличить учебные примеры и понять ожидаемый результат. После достижения версии данных 5 повторный запуск начального заполнения ничего не генерирует.
2. Разбираем входящее сообщение
Во входящей очереди найдите pending-order-single. Его отправитель — WEB, тип сообщения — order. Тело содержит номер и дату заказа, склад и массив строк items.
Тело этого демо-сообщения выглядит так:
{
"guid": "bce02003-0004-4000-8000-000000000101",
"number": "IN3000101",
"date": "2026-09-02T12:00:00",
"posted": true,
"warehouse": {
"guid": "bce02003-0001-4000-8000-000000000001",
"code": "D3WH00001",
"name": "Склад новых заказов"
},
"items": [
{
"line_number": 1,
"product": {
"guid": "bce02003-0003-4000-8000-000000000001",
"code": "D3PR00001",
"name": "Товар новых заказов"
},
"quantity": 5
}
]
}
Отправитель и тип хранятся в полях записи очереди. Именно по ним выбирается сценарий. Значения внутри JSON описывают прикладные объекты, которые этот сценарий должен записать.
Поля guid и posted заказа текущий загрузчик не использует. Он ищет заказ по номеру и дате, а после записи ставит отдельное задание проведения. Поэтому posted: true не проводит документ непосредственно при загрузке; значение false также не отменяет постановку этого задания.
В переопределяемом модуле задана связь отправителя с обработкой-реестром:
РеестрыПоОтправителям["WEB"] =
Метаданные.Обработки.Демо_КОД_РеестрСценариевЗагрузка_ОбменССайтом;
Диспетчер получает реестр, затем выбирает массив сценариев по типу сообщения:
РеестрСценариев = ПолучитьОбъектОбработки(РеестрМета)
.РеестрКонвейеровРегистрации();
СценарииЗагрузки = РеестрСценариев[Сообщение.ТипСообщения];
Имя РеестрКонвейеровРегистрации() сохранено и у реестра загрузки: в текущем коде используется именно оно. Ключами этого реестра служат строки order, product и warehouse.
Для каждого сценария диспетчер собирает цепочку и создает контекст. В Контекст.Вход находятся исходное сообщение, прочитанный JSON и узел отправителя; в Контекст.Выполнение — сценарий и параметры запуска.
Связь отправителя с реестром и поиск узла обмена настраиваются отдельно. В demo строка WEB сопоставляется с узлом плана Демо_КОД_ОбменСайтом по коду. Если реестр или необходимый узел не найден, загрузка завершается ошибкой.
3. Загружаем заказ вместе со складом и товарами
Выберите строку pending-order-single и выполните «Загрузить сообщение». Команда обрабатывает текущую запись списка. Флажок «Вызывать исключение» пока оставьте включенным: при создании формы он включается автоматически. При успешном выполнении запись исчезнет из входящей очереди независимо от состояния флажка.
Откройте документ Демо_Заказ с номером IN3000101. Проверьте дату, склад и табличную часть: должна быть одна строка с товаром D3PR00001 и количеством 5.
Теперь откройте отложенный процессинг и найдите задание для этого заказа с видом обработки «Проведение». Загрузчики связанных справочников также ставят задания «Запись». Если задание для той же пары «объект — вид обработки» уже было в очереди, новая постановка устанавливает состояние «К обработке», сбрасывает счетчик и текст ошибки, обновляет момент постановки.
В этом примере склад D3WH00001 и товар D3PR00001 уже созданы первой пачкой. Загрузчики находят их по GUID, обновляют реквизиты и снова ставят задания записи. Новый объект здесь — сам заказ IN3000101.
Для нового заказа до выполнения процессинга ожидается следующая картина:
| Что проверяем | После загрузки |
|---|---|
| Документ и строка товара | Записаны |
| Количество в строке | 5 |
| Общее количество заказа | 0 |
Движения по регистру Демо_Заказы |
Отсутствуют |
| Задание проведения | Находится в очереди |
Сообщение уже обработано, а прикладная операция над заказом еще ожидает выполнения. Исчезновение записи из входящей очереди само по себе не подтверждает проведение документа.
Обработчик Демо_КОД_Обработчик_JSONВЗаказ ищет документ по точному совпадению номера и даты. Если документ найден, получает его объект; иначе создает новый. Затем устанавливает ОбменДанными.Загрузка = Истина и заполняет шапку.
Склад обрабатывается через Демо_КОД_Обработчик_JSONВСкладыХранения. Товары из items[].product собираются в массив и передаются загрузчику товаров:
Контекст.Выполнение.Вставить("ИзолированныйВызов", Истина);
СсылкиТоваров = ОбработчикТоваров.Обработать(Контекст, ДанныеТоваров);
ЗаполнитьТовары(Заказ, СтрокиЗаказа, СсылкиТоваров);
Дочерний обработчик возвращает ссылки в порядке входного массива. Повтор товара сохраняет свою позицию, а product: null дает пустую ссылку. По этим позициям заполняются строки заказа и количество из quantity.
Флаг ИзолированныйВызов относится к одному вызову: обработчик считывает и сбрасывает его при входе, возвращает собственный результат и не продолжает цепочку. Запись данных при этом выполняется обычным для загрузчика способом.
После подготовки связанных объектов заказ записывается вместе со своим заданием проведения в одной транзакции. Общей транзакции на все сообщение при первичной загрузке нет: склад или товар, успешно записанный до последующей ошибки, может остаться в базе.
4. Выполняем отложенное проведение
В списке «Отложенный процессинг (КОД)» выберите задание проведения заказа IN3000101 и нажмите «Обработать запись». Команда выполняет одну операцию для текущей строки списка.
После успеха задание удаляется. Повторно откройте заказ и проверьте «Общее количество»: теперь оно должно равняться 5. В регистре накопления «Заказы (регистр, Демо)», доступном в подразделе «Данные», отберите движения по этому заказу. Должна появиться одна строка со складом, товаром и количеством 5.
| Проверка | После загрузки | После проведения |
|---|---|---|
| Количество в строке | 5 | 5 |
| Общее количество | 0 | 5 |
| Движения заказа | Нет | Одна строка с количеством 5 |
| Задание проведения | Есть | Удалено |
Аналогичный пример есть у справочников: обычная запись заполняет «Наименование для поиска» наименованием в верхнем регистре без пробелов по краям. Для нового загруженного элемента поле остается пустым до выполнения записи. У уже существовавшего элемента оно может сохранять прежнее значение до следующего процессинга.
При желании выберите задания «Запись» для товара D3PR00001 и склада D3WH00001 и обработайте их по одному. Это отдельные операции: проведение заказа само по себе не выполняет задания его справочников.
В модуле заказа расчет итога расположен после проверки признака загрузки:
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
ОбщееКоличество = Товары.Итог("Количество");
Поэтому запись загрузчиком сохраняет полученные реквизиты и строки, а вычисление откладывается. Процессинг получает объект заново и выполняет обычное проведение. Обработчик проведения формирует по одному движению на каждую строку табличной части.
Задание определяется парой «Ссылка — Вид обработки». При ручном запуске оно блокируется и обрабатывается в транзакции независимо от состояния и достигнутого лимита попыток. Успешная операция снимается с очереди, в том числе через подписки на события объекта.
Если ручное выполнение завершится ошибкой, изменения откатятся, исключение будет показано пользователю, а состояние задания и его счетчик останутся прежними. Регламентный процессинг при неудаче сохраняет новую ошибку и увеличивает счетчик попыток.
Массовый процессинг выбирает задания в состояниях «К обработке» и «Ошибка» со счетчиком ниже лимита, по умолчанию — пяти попыток. Порядок определяется моментом постановки, затем ссылкой и видом обработки. Зависимости между заданиями таким порядком не описываются; если прикладному сценарию нужна строгая очередность операций, ее следует реализовать отдельно.
5. Загружаем обновление существующего заказа
В первой пачке начального заполнения есть заказ IN3000004 от 02.09.2026 12:00:00. После ее загрузки он содержит одну строку с товаром D3PR00002 и количеством 7,25, склад — D3WH00002. Сначала выполните его задание проведения и убедитесь, что общее количество и движение также равны 7,25.
Теперь во входящей очереди найдите pending-order-update и загрузите его командой «Загрузить сообщение». В теле переданы те же номер и дата, поэтому загрузчик должен обновить существующий документ. Склад сменится на D3WH00001, а в табличной части останется одна строка с товаром D3PR00001 и количеством 12. Для проверки сопоставления сравните ссылку документа до и после загрузки: она должна остаться прежней.
До нового процессинга общее количество и прежнее движение сохраняют значение 7,25. В очереди снова появляется задание проведения. Выполните его и проверьте результат:
| Состояние заказа | Количество в строке | Общее количество | Количество в движении |
|---|---|---|---|
| До обновления, после первого проведения | 7,25 | 7,25 | 7,25 |
| После загрузки обновления | 12 | 7,25 | 7,25 |
| После повторного проведения | 12 | 12 | 12 |
При повторном проведении набор движений формируется заново. Для этого примера должна остаться одна строка с количеством 12.
Загрузчик полностью очищает табличную часть перед заполнением из items. Пустой массив очищает состав заказа, а warehouse: null очищает склад. Порядок строк определяется порядком массива; отдельной сортировки по line_number нет.
У товара поле category имеет собственные правила: если его нет в JSON, существующая категория сохраняется; явное category: null очищает ее. Вложенный объект категории загружается вместе с постановкой своего задания записи. Правила для отсутствующих полей и null не являются общими для всех загрузчиков.
Справочники товаров, категорий и складов сопоставляются по GUID, который используется как идентификатор ссылки 1С. У заказа правило другое: точное совпадение номера и даты. GUID заказа из JSON в этом поиске не участвует.
Эти правила определяют поведение конкретного demo. Для своего обмена нужно отдельно выбрать устойчивый ключ сопоставления. Совпадение номера и даты само по себе не обеспечивает защиту от всех случаев повторной или параллельной доставки.
6. Разбираем ошибку загрузки
Найдите во входящей очереди pending-order-invalid-date. В его теле указан заказ IN3000111, а значение даты содержит месяц 13:
"date": "2026-13-01T12:00:00"
Убедитесь, что флажок «Вызывать исключение» включен, и выполните «Загрузить сообщение». Загрузчик должен сообщить: «Неверный формат даты заказа: 2026-13-01T12:00:00.» Запись останется во входящей очереди: в этом режиме исключение передается вызывающей стороне, а сообщение не переносится в регистр ошибок.
Теперь снимите флажок «Вызывать исключение» и повторно выполните ту же команду для той же строки. Ошибка загрузчика и тело сообщения сохранятся в регистре ошибок, а исходная запись будет удалена из входящей очереди. Команда по-прежнему обрабатывает только текущую запись: другие сообщения второй пачки остаются на месте.
Откройте «Ошибки загрузки сообщений (КОД)» и найдите пример по заголовку pending-order-invalid-date или номеру заказа IN3000111 в теле. При выборе записи форма показывает сохраненное сообщение и подробное представление ошибки.
| Способ запуска | Что происходит при ошибке загрузчика |
|---|---|
| «Загрузить сообщение», флажок «Вызывать исключение» включен | Ошибка передается пользователю, сообщение остается во входящей очереди |
| «Загрузить сообщение», флажок «Вызывать исключение» снят | Текущее сообщение сохраняется в ошибках и удаляется из входящей очереди |
| Штатный вызов диспетчера без параметров | Обрабатывается вся доступная очередь; ошибочные сообщения сохраняются в ошибках и удаляются из входящей очереди |
Форма передает диспетчеру два параметра: состояние флажка ВызыватьИсключение и ключ текущего сообщения, состоящий из номера и идентификатора. Поэтому поведение при ошибке определяется режимом вызова, а не самим фактом ручного запуска.
Сообщение может остановиться еще до записи объекта. Поврежденный JSON не позволит создать контекст, неизвестный отправитель — выбрать реестр или определить узел, неподдерживаемый тип — найти сценарий. Проверки даты и идентификаторов выполняются в прикладных загрузчиках.
В demo предусмотрен обработчик Демо_КОД_Обработчик_ВалидацияПоJSONSchema. В текущем реестре его подключение закомментировано. Пример с неверной датой обнаруживается загрузчиком и при отключенной проверке схемы.
Если включить JSON Schema первым этапом сценария, понадобится доступная внешняя компонента из поставки demo и настроенные схемы. Не следует ожидать, что все нарушения схемы будут отклоняться и без этого этапа: у загрузчиков свой набор проверок.
При записи ошибки сохраняются номер и идентификатор сообщения, отправитель, тип, заголовки, тело и подробная ошибка. Узел обмена сохраняется, если его удалось определить. Это позволяет повторно выполнить загрузку после исправления данных или настроек.
Для массового запуска из серверной команды тестовой обработки или консоли кода, вне внешней транзакции, можно вызвать:
КОД_ДиспетчерЗагрузкиСообщений.ПрочитатьВходящуюОчередьСообщений();
Без параметров диспетчер использует ВызыватьИсключение = Ложь и обрабатывает доступную очередь порциями до ее исчерпания. Размер порции задает константа КОД_ПорцияЗагрузкиСообщений; при нуле используется 100. Сообщения выбираются по номеру, затем по идентификатору.
Вызов затронет и остальные сообщения второй пачки. При ошибке отдельного сценария диспетчер сохраняет сообщение в ошибках, удаляет входящую запись и продолжает работу. Ошибка самого сохранения в регистр ошибок или удаления из очереди может прервать проход. Отдельной команды массовой загрузки в форме входящей очереди нет.
Для основного примера этот вызов не требуется. Если выполнить его дополнительно, итоговое состояние остальных очередей будет отличаться от последовательности с тремя выбранными сообщениями.
7. Исправляем сообщение и повторяем загрузку
В регистре ошибок выберите запись с заказом IN3000111. В поле «Сообщение» замените неверную дату на корректную:
"date": "2026-09-02T12:00:00"
Дальше выполните действия в таком порядке:
- Нажмите «Сохранить измененное сообщение».
- Оставьте выделенной только исправленную запись.
- Нажмите «Загрузить выбранные сообщения».
- Проверьте исчезновение записи ошибки и появление заказа
IN3000111. - Найдите его задание проведения и выполните «Обработать запись».
Сохранение — отдельный обязательный шаг. Повторная загрузка читает тело из регистра. Несохраненный текст редактора в нее не передается, а переключение строки или обновление формы может заменить его сохраненным значением. Сохранение нового тела само по себе не сбрасывает счетчик попыток, признак контроля или прежний текст ошибки.
Для одной успешно исправленной записи ожидается сообщение:
Загружено: 1. С ошибками: 0. Уже удалено: 0.
У этого демо-заказа пустой массив items. После проведения его общее количество должно остаться нулевым, а движений не будет. Успех проверяем по созданному документу, его проведению и снятию задания с очереди.
В форме есть еще две команды. «Взять на контроль» устанавливает признак контроля и ответственного для выбранных записей. Штатная повторная обработка такие записи пропускает. «Загрузить все сообщения» запускает обработку всего регистра ошибок независимо от отбора списка; записи на контроле и с исчерпанным лимитом попыток пропускаются.
Ручная команда «Загрузить выбранные сообщения» делает одну попытку для каждой выбранной записи, включая записи на контроле и записи с достигнутым лимитом. Поэтому для исправленного сообщения можно выполнить ручную попытку без сброса счетчика.
Модуль КОД_ПовторнаяЗагрузкаСообщений восстанавливает сообщение из регистра и снова выбирает сценарии по отправителю и типу. Используются те же загрузчики, что и при первичной обработке.
Если в ошибке сохранен заполненный узел обмена, он имеет приоритет над новым поиском по строке отправителя. При пустом узле вызывается настройка ПриОпределенииУзлаОтправителя(). Поэтому изменение соответствия отправителей само по себе не заменяет уже сохраненный узел в старой записи ошибки.
Вокруг повторной загрузки открывается транзакция: запись ошибки блокируется, выполняются все сценарии сообщения, затем запись ошибки удаляется. При успехе изменения фиксируются вместе. При неудаче прикладные изменения откатываются, а новый текст ошибки и счетчик сохраняются отдельной транзакцией.
По умолчанию массовый повтор допускает до пяти неудачных повторных попыток. Первичная ошибка создается с нулевым счетчиком. Массовый проход может сразу повторно выбрать неудачную запись, пока та не достигнет лимита: задержка между попытками в этом коде не задается.
Перед массовым повтором стоит устранить причину ошибки. Для исправления отдельного сообщения достаточно сохранить его тело и выполнить одну выбранную попытку.
8. Подключаем собственный сценарий загрузки
В разобранном примере диспетчер выбирает сценарий, конвейер организует вызовы, а загрузчик определяет правила записи прикладных объектов. Для нового типа сообщения понадобятся следующие настройки.
Связь отправителя с реестром. Она задается в КОД_ДиспетчерЗагрузкиСообщенийПереопределяемый.РеестрыСценариевПоОтправителям(). В ПриОпределенииУзлаОтправителя() настраивается соответствие транспортного отправителя узлу плана обмена.
Описание сценария. Реестр возвращает соответствие «тип сообщения → массив сценариев». В каждом сценарии указываются конвейер и упорядоченный массив обработчиков. В demo сценарий order содержит базовый конвейер загрузки и обработчик Демо_КОД_Обработчик_JSONВЗаказ; склад и товары он вызывает сам.
Прикладной загрузчик. Он определяет, как найти объект, какие реквизиты изменить, что означает пустой массив или null, какие проверки выполнить и какую операцию поставить в отложенную обработку.
Подключение процессинга. Состав поддерживаемых объектов задается непосредственно в типе измерения Ссылка регистра КОД_ОтложенныйПроцессинг. В ядре разрешены ссылки на документы и справочники — ДокументСсылка и СправочникСсылка; в demo перечислены конкретные ссылки на заказ, товар, категорию и склад. При добавлении своего объекта включите его тип ссылки в это измерение и проверьте применимость подписок. Определяемый тип КОД_ОбъектыОтложеннойОбработки удален из текущих исходников.
Проверка КОД_ОтложенныйПроцессинг.ТипПоддерживается() читает типы прямо из метаданных измерения. Скрипт синхронизации ядра сохраняет этот прикладной состав типов в demo. Для уже подготовленного загрузчиком объекта запись и постановка задания выполняются вместе:
НачатьТранзакцию();
Попытка
Объект.Записать();
КОД_ОтложенныйПроцессинг.Зарегистрировать(
Объект.Ссылка, Перечисления.КОД_ВидыОбработкиДокументов.Запись);
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ВызватьИсключение;
КонецПопытки;
Для документа, который нужно провести, используйте вид обработки Проведение. Если прикладные правила запрещают отложенное проведение закрытых документов, настройте функцию КОД_ПодпискиНаСобытияПереопределяемый.ДокументЗакрытДляОтложенногоПроведения(). В demo она возвращает Ложь: отдельного статуса закрытия у демо-заказа нет.
Обработчики реализуют методы Следующий() и Обработать(Контекст, Вход = Неопределено). Конвейер связывает их в заданном порядке. Если явный вход не передан, прикладной загрузчик может взять данные из Контекст.Вход.ДанныеСообщения.
Экземпляры создаются через КОД_ДиспетчерЗагрузкиСообщений.ПолучитьОбъектОбработки(). Внутри вызывается переопределяемая процедура ПриПолученииОбъектаОбработки(): здесь можно подставить другую реализацию, сохранив контракт. Через эту фабрику обработчик заказа получает и дочерние загрузчики.
Границы транзакций задает реализация загрузки и вызывающий код. Само включение этапа в цепочку не делает несколько записей одной атомарной операцией.
У обработчиков Демо_КОД_Обработчик_JSONВЗаказ, Демо_КОД_Обработчик_JSONВТовары и Демо_КОД_Обработчик_JSONВСкладыХранения есть собственные формы. В них можно выбрать «План обмена (узел)» и «Сценарий», вставить JSON и нажать «Загрузить». Форма показывает результат на вкладке «Сообщение → объект». Для заказа передается объект JSON, для самостоятельной загрузки товаров или складов — массив.
Такая форма создает контекст выбранного сценария и вызывает непосредственно свой обработчик в режиме Отладка. Полный набор этапов сценария, включая добавленный перед загрузчиком валидатор, не запускается. Режим отладки останавливает передачу следующему этапу, но сохраняет прикладные объекты и задания процессинга.
В форме весь вызов обработчика, дочерняя загрузка и подготовка таблицы результата охвачены общей транзакцией. При ошибке записи откатываются, а ошибка показывается в таблице результата. Исходная запись входящей очереди при этом не обрабатывается и не удаляется, сообщение в регистр ошибок не переносится. Эти формы удобны для проверки загрузчика; шаги 3–7 статьи выполняются через формы очередей.
Что учитывать в текущей реализации
- Пример начинается с уже сохраненного сообщения. Прием по HTTP, чтение брокера и подтверждение внешней системе остаются задачами транспортного слоя. Исчезновение записи из входящей очереди описывает состояние обработки внутри demo.
- Границы транзакций зависят от точки входа. При загрузке из входящей очереди каждый связанный объект сохраняется со своим заданием; общей транзакции сообщения и его удаления нет. При повторе из регистра ошибок все сценарии сообщения и удаление ошибки охвачены общей транзакцией. Собственная форма загрузчика также открывает общую транзакцию, но вызывает только этот обработчик с его дочерними загрузчиками.
- Новая загрузка снова ставит прикладную операцию в очередь. До ее выполнения вычисляемые поля и движения существующего объекта могут отражать прежние данные. Для нового заказа они еще не сформированы.
- Режимы обработки ошибок различаются. Во входящей очереди поведение задает флажок «Вызывать исключение». Ручной повтор из регистра ошибок при неудаче обновляет ошибку и счетчик. Ручной процессинг объекта передает исключение без изменения задания и его счетчика.
- Обновление объекта не означает однократную доставку. Текущий поиск заказа по номеру и дате и поиск справочников по GUID — прикладные правила сопоставления. Гарантии обработки повторов, параллельных потребителей и внешних подтверждений требуют отдельного решения.
- Обратная регистрация учитывает контекст операции. Загрузчики передают отправителя и устанавливают запрет возврата ему через дополнительные свойства объекта. Отложенное проведение выполняется как самостоятельная локальная операция и не переносит эти свойства. Если для объекта подключен исходящий обмен, его результат нужно проверять с учетом этого различия.
Проверено на следующих конфигурациях и релизах:
- 1С:Библиотека стандартных подсистем, редакция 3.1, релизы 3.1.12.348
Вступайте в нашу телеграмм-группу Инфостарт
