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

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

Как это можно сделать без использования ЗаписьСообщенияОбмена?

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

т.е. в планах обмена в реальности ничего более нет - только регистрация

(0) Погугли когда именно номер присваивается зарегистрированным изменениям.

а почему бы просто не удалить регистрацию?

сделал без записи в файл. точнее нужно только НачатьЗапись и ВыбратьИзменения. Первое присваивает номер, второе этот номер проставляет всем пустыми записям. Дальше просто записывем пустой файл.

(3) именно это и нашел и Чистова

(4) просто удалить нельзя. надо сначала выбрать с присвоенными номером. именно с присвоенным. хотя по идее можно было бы просто взять все изменения в запросе ...

фиг его знает. так как-то кажется надежнее.

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

(1) нужен только для регистрации. дальше формируется xml произвольного формата. изменения сразу удаляются. предлагал сделать регистр сведений, сказали делать ПО. ну ПО так ПО.

(7) проще удалять регистрацию по объектно

(6) Если нужно получить изменения, записать в файл и удалить, тогда зачем номер?

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

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

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

(4) Даже если "изменения сразу удаляются" как в (8), то смысл в номере все равно есть, чтобы после окончания выгрузки объектов удалить регистрацию только по тем объектам, которые были выгружены (и не изменены за время выгрузки). По этому номеру это и определяется.
Т.к. за время выгрузки не только могли добавиться к обмену новые объекты (без номера), но и сам это объект мог перезаписаться (стать тоже без номера).

(11) Повторил )

(12) Номер выступает маркером, что объект попал в очередную обработку выгрузки

(15) Задумка была хорошая, но...

(15) что это нам дает?

(17) Что нужно удалить такой объект после выгрузки, чтоб он не попал в следующую

*удалить его регистрацию

(19) я несколько раз видел готовые решение по подобной схеме - номера не использовались.

(20) Это неверный подход, который не учитывает многопользовательский режим работы.

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

А многопользовательская там запись или нет... Алгоритм в целом там несложный и на первый взгляд вполне себе годный. Именно для целей регистрации новых изменений объектов... Не помню только включалась ли там блокировка записей новых хоть на какие-то транзакции или нет... Похоже что да - транзакции там тоже использовались в узких местах!

(20) Ну значит вместо номера у каждого выгружаемого объекта был какой-то другой маркер. Не блокировать же его до конца успешной выгрузки? Иначе как узнавать, что объект уже можно удалить из очереди выгрузки?

(22) Да, разумеется, и блокировки, и транзакции - всё это используется. Но и этого - мало. Помимо этого, когда мы пишем типа "ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(Узел, Номер)", мы "фиксируем" состав зарегистрированных изменений текущего сенса обмена на неопределенное время без установки блокировки всей работы с базой всех. Несколько сложно сказал, надеюсь поймут.

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

... и каждый остался при своём мнении.

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

(27) поэтому нужно пообъектно. заблокировал - выгрузил объект - удалил запись

(28) 1. Такой атомарный подход может не работать тогда, когда нужна логика выгрузки "все или ничего".
2. Зачем блокировать, когда можно не блокировать? В чем тебе кажется преимущество перед описанным в (13)?

(29) если все или ничего, то нужно подтверждение загрузки тогда

(30) Вовсе нет. Просто внешней системе может быть не нужным какой-то один объект, если вместе с ним нет всего остального сопутствующего.

(31) если файл не загрузится (например некорректно сформировался файл) - то ты уже потеряешь инфу о том какие объекты нужно выгрузить.

(27) массив именно записей, а не самих объектов.

(32) Вовсе нет. Что-то ты мешаешь в кучу.
Всякие системы есть, которым надо кормить пакеты (строки/файлы) и которые не умеют в обратку подтверждать.
Это конечно же не значит, что они умеют разбирать эти строки/файлы пообъектно и им можно выгружать пообъектно, ведь они могут быть рассчитаны всегда только на определенный состав объектов в прилетевшем пакете ("протокол обмена").
Так что ты что-то намешал.

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

(34) в данном случае пообъектно система умеет принимать. ибо в следующий заход прилетит 1 документ

(35) Лучше б на одном простом (конкретном) примере.
Ну типа дано: на узле зарегистрировано два документа.
Далее начинается процесс выгрузки по твоему алгоритму и что там внутри происходит?
1. Получаем массив объектов к выгрузке (два документа?)
2. Крутим цикл, выгружаем каждый документ.
3. Пока выгружали второй, первый в базе поменяли.
4 ???

(37) это смотря когда очишать список регистрации

(36) Хз о чем ты

(39) о том что пакет вполне может быть из 1 элемента, ибо в регистрации может быть только 1 элемент

(37) т.к. он был зареан лишний раз, то выборка записей зареганных будет больше, чем выгруженных.

- Открываем транзакцию (новые записи от остальных сеансов блочатся)
3.1 Считываем зареганные по узлу в массив и чистим узел
4. Перебираем выборку зареганных
4.1 находим в списке Выгруженных объект - удаляем
4.2 ищем далее - в выгруженных уже пусто - регаем объект по узлу
-- Фиксируем транзакцию (блокировка снимается)

(41) 1. Почему зареганных будет больше, чем выгруженных?
Выгружено два (первый и второй документ), и зарегано на момент начала транзакции (до очистки регистрации на узле) тоже эти два документа.
2. По твоему пункту 4.1 первый документ будет найден в списке выгруженных и удален с узла.

(40) Предположим, что:
- в каждом пакете должны быть обязательно все свежесозданные объекты (товары, например), которые в приемник еще не передавались, иначе приемник не сможет принять такой пакет
и
- все товары из каждого документа мы не передаем в пакете, если они не свежесозданные (не зарегистриованы на узле)

(42) когда у тебя идет изменений объекта в базе, то новая регистрация изменений ложится в таблицу регистраций с пустым номером, новой записью, а не затиранием старой. Выборка из таблы регистраций вернет записи с дублями без номеров пакета, но с такими же объектами. Не все будут с дублями - новые измененные будут "лишние"

(44) Стоп, так ты же писал что не пользуешься номерами как маркерами?

(45) количество записей в выборках - там же номер пакета ключевое поле.

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

(43) товары передавай раньше документов и все

(46) Так мы вроде (20) обсуждаем?

(45) сами номера не нужны. Нужны именно массивы любых зареганных объектов в любом количестве записей. Можно не номера пакетов, а время. Не важно как, но важно, что они избыточны.

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

(51) Ясно, спс. Мое "маркер" то же самое и означало (пох какой там номер отправленным присваивается).

(48) 1. И все равно непонятно, зачем ты предлагаешь блокировать каждый объект, когда это можно не делать.
2. И при предлагаемом тобою пообъектном удалении регистрации информация о регистрации безвозвратно утеривается, если до завершения выгрузки возникает какая-нибудь невосстановимая ошибка - что с этим делать будем?

(53) Не блокировать объекты, нет.

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

(53) не теряется ничего = если транзакция не зафиксилась - регистрация восстановится в полном объеме, даже того, чего можно и не восстанавливать

(54) Это ты сейчас про какой подход отвечаешь? Я-то про (28)

(54) блокировка добавления регистрации - это равносильно блокировки записи

(57) Но ты-то предлагаешь блокировать каждый объект на время его выгрузки, что куда дольше, чем то, что там Фрэнки описывал (у него однократная блокировка в конце и только на время чтения и очистки реги), так?

Продолжаете изобретать велосипед?

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

PS: у меня план обмена РИБ и мне все ваши пообъектные изыскания совсем не в тему.

(59) :-) В ентрерпраййз дата , если судить по отзывам - нет уже прежней халявы, к которым привыкли в РИБ обменах

(59) "у меня план обмена РИБ и мне все ваши пообъектные изыскания совсем не в тему" // Так между идентичными-то конфами сам бог велел максимально атомарно (пообъектно) передавать