Добрый день, коллеги! Сразу оговорюсь. Это читал: v8: Как узнать транзакция в текущий момент есть ?

Тем не менее есть реальный кейс, требующий узнать завершилась ли транзакция. Необходимо сделать онлайн обновление остатков во внешней системе.
Изначально идея была такой: Сделать подписку на событие РегистрНакопленияНаборЗаписей.ТоварыНаСкладах.ПриЗаписи и оттуда обновлять остатки. (в действительности все чуть сложнее, но не суть)

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

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

Но как понять, что они обновились - пока не понятно. Есть идеи?

ИМХО через план обмена.

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

(2)+ В смысле не обязательно все остатки сохранять а некий хеш, банально общее кол-во например.

(1) А чем поможет план обмена? В смысле зарегистрировать изменения, а потом "когда-то" их передать во внешнюю систему? Но задача стоит это делать онлайн. Но чтобы не заставлять ждать пользователя - "псевдо-онлайн". То есть сразу после того, как изменения завершены. Ситуация осложняется еще и тем, что например во время перепроведения документа реализацияТоваровУслуг остатки меняются 4 раза:
1. Удаление движений резервов товаров
2. Удаление движений товаров
3. Создание движений резервов
4. Создание движений товаров.

Сейчас эти изменения накапливаются (в памяти) и осталось их только в нужный момент сбросить во внешнюю систему, но вот как определить "нужный момент"

(2) Так примерно и делается. В событиях запоминаются товары по которым происходят изменения. Дальше в "нужный момент" я бы снимал остатки по ним и передавал.

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

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

(0) Сравнить поле Версия Регистратора

    Если ДвижениеМарок<>Неопределено Тогда    
        ОбъектРасширения=АСФРасширенияФункционала.ПолучитьОбъектРасширения();
        Если ОбъектРасширения<>Неопределено Тогда
            КоличествоПопыток=0;
            Пока Истина Цикл
                Попытка
                    Если ОбъектРасширения.Спать(1000)=Ложь Тогда
                        Прервать;
                    КонецЕсли;
                Исключение
                    Прервать;
                КонецПопытки;
                ТекущаяВерсияДанных=АСФОбщегоНазначения.ЗначениеРеквизитаОбъекта(ДвижениеМарок,"ВерсияДанных");
                Если ТекущаяВерсияДанных=НоваяВерсияДанных Тогда //Документ записан, основная транзакция зафиксирована.
                    Прервать;
                КонецЕсли;
                КоличествоПопыток=КоличествоПопыток+1;
                Если КоличествоПопыток>5 Тогда
                    Возврат;
                КонецЕсли;
            КонецЦикла;
        КонецЕсли;
    КонецЕсли;

Поле ВерсияДанных

Ага, ок, поковыряю. Спасибо

Это, епстественно, в ФоновомЗадании

(8) +100500 так правильнее чем через сигнальный файл/запись в РС/Константу и т.п.

(10) Ну это ясен перец. Не первый день замужем ))

(0) что мешает читать статус из фонового задания?

ТС не понимаю.
Остатки надо выгружать только в том случае если они отличаются от прежде выгруженных по некоему расписанию проверяя это.

Если стоит задача асинхронной выгрузки остатков (сразу после изменения) это глупо потому что может никогда не быть достаточного промежутка когда остатки "не меняются"

(13) Статус чего?

(14) Речь не о промежутке (типа когда ничего не проводится, тогда и выгружаем). Речь о том, что когда закончил проводиться конкретный документ - выгружаем остатки, на которые он повлиял. Если в это время проводится другой документ влияющий на те же самые остатки - мы их выгрузим еще раз, когда он закончит проводиться

(15) Ну так повесь на "после записи" документа запуск фонового

(16)+ После записи выполняется при нормальном проведении (не фоновом) после проведения вроде же

Все, что нужно знать о Гарри - вы можете увидеть в (16)

(18) Хочешь сказать я не правильно понимаю картинку тут https://its.1c.ru/db/pubdevguide83/content/612/hdoc ?

(18) Если это намек что документы могут проводиться массово и обработкой программно то понятно дело надо это учесть чтобы не плодить фоновые

(16) А давай я тебя забаню? Утомительно смотреть на твою чушь.
(19) Да, ты неправильно понимаешь тот момент, когда док может проводиться из формы списка, к примеру.

(21) Пруф можно? Насчет формы списка.

ЗЫ Забань мне как раз поработать надо

(21)+ Не хочется лазить в документы, думал обойтись событиями

(22) Какой пруф тебе нужен? Что у формы списка нет события ПослеЗаписиНаСервере?

(24) https://i.paste.pics/626e4c920fe52a0065746d46b8b86fe8.png

(25) Что это?

(26) Проведение из формы списка с подпиской на событие ОбработкаПроведения для всех документов

(27) И че, оно ПослеЗаписиНаСервере? Транзакция уже зафиксировалась?

(28) А фуй знает, проверять надо.

Давай, Егор, проверяй.

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

Функция ПолучитьВерсиюДанныхИзБД(Ссылка)
    Запрос = Новый Запрос("ВЫБРАТЬ
                          |    ЗаказПокупателя.ВерсияДанных
                          |ИЗ
                          |    Документ.ЗаказПокупателя КАК ЗаказПокупателя
                          |ГДЕ
                          |    ЗаказПокупателя.Ссылка = &Регистратор");
    Запрос.Параметры.Вставить("Регистратор", Ссылка);
    Выборка = Запрос.Выполнить().Выбрать();
    
    Если Выборка.Следующий() Тогда
        Возврат Выборка.ВерсияДанных;
    КонецЕсли;
    Возврат Неопределено;
КонецФункции

Но получаю тот же результат, что и НаборЗаписей.Отбор.Регистратор.Значение.ВерсияДанных

(31) Да конечно будет то же самое, запись в базу же уже произошла.
Я чет только теперь понял, что у тебя просто остатки еще не пересчитались в (0).
Движения есть, а остатки пока еще не актуальные.
А вот когда они пересчитываются и в этой ли транзакции, тут хз, если честно.
ИМХО, в фоновом брать остатки перед этими движениями и накатывать движения этого набора записей ручками.

(32) + Правда будет проблема, если тут транзакция откатится, а данные во внешнюю уже ушли.

(32) Запись то произошла, но транзакция еще не... А стоп. Ща попробую из фонового.. Это ж я из одного сеанса пробую. Понятно, что будет одно и то же.

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

(34) Тебе в Фоновое надо передать версиюданных из ПриЗаписи(), из основной транзакции, когда она будет уже обновленной.
И в фоновом ждать, когда же в БД обновиться ВерсияДанных, сравнивая ее с переданной.

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

(37) НаборЗаписей.Записать(Истина) - источник нехилых проблем.

(36), да, так и делаю. Вроде это решает проблему. Единственное при откате фоновое не дождется, но это вроде решается установкой таймаута на время заведомо большее, чем время проведения документа.

Спасибо!

(0) >Необходимо сделать онлайн обновление остатков во внешней системе

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

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

(41) > Онлайн - не с целью загрузить вычислительные мощности побольше. А скорее наоборот с целью не делать обмен раз в минуту например, когда основное время в базе ничего не происходит.
Тогда, ИМХО, ты зря так делаешь. Если проверки очень легкие, то никакой проблемы делать их ежеминутно или даже чаще - нет. В то время как запускать из транзакции фоновое задание без особой необходимости не кажется мне замечательным со всех сторон решением. Особенно при пакетных проведениях.

(42) Ну можно отслеживать групповую обработку и ожидать ее завершения. Тут еще политика вмешивается. Клиент хочет "онлайн". На вопрос как часто мы должны обновлять информацию во внешней системе ответ: Она там должна быть актуальной ВСЕГДА )))
Ну хрен с вами, любой каприз за ваши деньги

(43) Поставь расписание каждые 5 секунд и успокойся

(43) Это стандартный ответ заказчика, не осознающего всех плюсов-минусов. Для него вопрос "выбирайте - онлайн или по расписанию" звучит как "выбирайте - хорошо или плохо". Ясен пень, он хочет "онлайн", даже если на самом деле настоящий онлайн ему абсолютно некритичен. Заказчики вообще в подавляющем большинстве случаев не представляют сложностей взаимодействия систем. Для них это естественная магия. Оно должно "само и сразу, а разве иначе бывает?". Тут уже умение донести.

(0) "Тут еще политика вмешивается. Клиент хочет "онлайн". Она там должна быть актуальной ВСЕГДА" - а запаздывание в 5 секунд это ВСЕГДА? а в 1 секунду? в 0,5 секунды это ВСЕГДА?

Не парь себе мозги. Делай через регламент

(46) КАК ТЫ НЕ ПОНИМАЕШЬ! ЗАПАЗДЫВАНИЯ БЫТЬ НЕ ДОЛЖНО! НЕУЖЕЛИ СЛОЖНО СДЕЛАТЬ ЧТОБЫ СРАЗУ? СМОТРИ - ВОТ ЭТИ ЦИФИРКИ ДОЛЖНЫ ПОМЕНЯТЬСЯ ОДНОВРЕМЕННО! ДАЖЕ ЗВУЧИТ ПРОСТО И ПОНЯТНО, РЕБЕНОК ПОЙМЕТ! НЕ НАДО НИЧЕГО УСЛОЖНЯТЬ КАКИМИ-ТО "РЕГЛАМЕНТАМИ"! ПОНАПРИДУМЫВАЮТ ЖЕ! ВЕЧНО ЭТИ ПРОГРАММИСТЫ ВСЕ УСЛОЖНЯЮТ! ЛИШЬ БЫ ДЕНЕГ ПОБОЛЬШЕ СОДРАТЬ!

Там подготовка данных для отправки и коннект к получателю скорее всего 1-5 секунд будет происходить, так что никаких проблем поставить регламент 5 секунд нет.
Для особо взыскательных - хоть каждую секунду, все равно пока не отработал один такт следующий не начинается, если конечно такт РЗ не используется как менеджер побочных ФЗ. Тогда надо реализовывать еще и механизм как попридержать коней.

(41) Учитывая это:

"Но есть пара часов, когда происходит интенсивно и тогда надо чтобы обновлялось как можно быстрее"

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

с 0 утра (ночи) до 12 дня частота 1 минута
с 12 дня до 16 дня частота 5 секунд
с 16 дня до 0 ночи частота 30 секунд

Но вообще можно даже с этим не заморачиваться и просто ставить 1 минуту.

(43) >Тут еще политика вмешивается. Клиент хочет "онлайн".
>Ну хрен с вами, любой каприз за ваши деньги

Как ты не понимаешь, когда ты не обеспечишь ему этот каприз, ты будешь крайним, а не кто-то.

Если те не докопался до исходной проблемы (зачем вообще там остатки), ты не выполнил свою работу как спец по автоматизации.

(0) А внешняя система сама не может при необходимости обращаться к 1с(допустим, к веб-сервису) за актуальными остатками на именно нужную номенклатуру?
Я так понимаю, где-то на сайте идет какой-то заказ товара, и нужно проверить наличие остатков в момент нажатия на кнопку "заказать товар"?

(51) Тут такое дело, что "заминка" при заказе крайне нежелательна. Клиент должен расставаться с деньгами легко и быстро. И временные перебои в работе связки систем не должны останавливать поток бабла и портить впечатления покупателей от чудесного сервиса.
Плюс список остатков обычно тоже нужен. Можно было бы, конечно, дергать одинэсный сервис для этого. Но кэширование и обновление кэша  все равно понадобится. А значит - что в лоб, что по лбу. Либо с той стороны регламент, либо с этой. Тут уже по обстоятельствам. Другое дело, что можно оптимизировать выгрузку/загрузку. И гонять только изменившиеся позиции. Но это усложнение тоже не дармовое. Так что я бы стал с этим заморачиваться только если полная выгрузка остатков начнет создавать проблемы. Но это только на огромном ассортименте случится.

(52) Точные остатки по большому счету не нужны, достаточно вообще троичного "много - средне - мало" показывать клиенту на сайте. Ситуация, когда он заказывал, и оно закончилось - в порядке вещей.
Так что эти онлайн-остатки в 99% просто блажь.

(53) Это в B2C может быть так. А в B2B сплошь и рядом все не так просто.

(53) +100

(54) А если нужно гарантированное резервирование, то и там никакой онлайн не поможет - один фиг бронь будет применяться и конкуренция будет происходить непосредственно в момент дерганья сервиса отправки заказа и отлуп тоже возможен