Откатить бизнес процесс 1с
Обновлено: 07.07.2024
Стартанул бизнес-процесс, прошел несколько точек и теперь надо не продолжать его выполнение, а вернуться к предыдущей точке. задачи созданные на предыдущей точке я удалил (пометил на удаление), а текущее состояние БП не изменилось (пунктирные прямоугольники где были на блок-схеме, там и остались). Подскажите плиз как его откатить назад?
Это придется к каждой точке бп добавлять еще условие. блок схема слишком стремная и нечитабельная получиться. Неужели нет другого варианта?
Как вариант рассматриваю - при пометке на удаление задачи связанной с данным бп, очищать реквизит БизнесПроцесс, тогда вроде откатывает нормально. Неужели проще никак не сделать?
нафига бизнеспроцессы с откатами? они для того и нужны, чтоб отслеживать состояние. в правильный вариант по моему.
ну иногда юзеры косячат - не тот вариант выбирают, или принимается решение по какому то из этапов бп, а потом оно пересматривается (множество факторов могут быть тому причиной) и возникает необходимость откатить его назад на один или несколько этапов. вот и озадачился этой проблемой
>задачи созданные на предыдущей точке я удалил (пометил на удаление), а текущее состояние БП не изменилось (пунктирные прямоугольники где были на блок-схеме, там и остались) не валите в кучу task - задачи возникающие в БП и состояние самого БП
дык между ними же непосредственная связь, как не валить их в кучу?
Собираюсь реализовать вариант из . остановите меня кто нибудь! Предотвратите создание пятиколесного велосипеда!
почему зло? какие траблы могут возникнуть? что подразумевается под правильной схемой?
Ах, вы об этом. я сначала и собирался так делать, но потом прикинул как будет выглядеть схема в итоге и передумал (бп состоит из 19 этапов с множеством условий и ветвлений и сейчас схема выглядит еще нормально, но добавить еще с десяток условий и она станет абсолютно нечитабельной).
Не принято так делать, любой человек думает что БП у него идет ровно по схеме, если у тебя будут какие то скачки, то это будет вызывать как минимум недоумение
Ну вот все равно что дали тебе пылесос, а к нему инструкцию, там кнопка нажмешь - включится, не нажмешь не включится. И вот стал он у тебя сам включаться в любое время суток. Списался ты с разработчиками, и тут оказывается что у него есть фича, если слишком пыльно вокруг то он сам включается без твоего ведома. Естественно фича в инструкции не упомянута. только разработчики о ней знают? Какого бы тебе было?
не должен кто-либо иметь возможность удалить или отменить выполнение задачи
ты сам писал " или принимается решение по какому то из этапов бп, а потом оно пересматривается (множество факторов могут быть тому причиной)" так вот это ничто иное как стрелка взад. потому как если это возможно это надо отражать. если это невозможно отразить - значит нельзя так делать . на то они и бизнесс процессы.
если сделать правильную карту маршрута, то данные вопросы возникать не будут
Ладно, убедили. сделаю через стрелки взад, посмотрим что из того получится. Всем спасибо!
vde69, а у тебя часом не осталось картинок твоих БП, за которые тебя сильно хвалили в ? С файлообменника их просто уже благополучно удалили, а хотелось бы посмотреть.
Посмотри бизнес процесс закрытия месяца в УПП. Там реализован именно откат. Как - не смотрел
Скажу сразу, ранее практически не попадалось задач по бизнес-процессам. А тут пришлось с нуля в также не знакомой мне области создавать подсистему "Претензионно-исковая деятельность".
Проект сдан, теперь началась работа пользователей и появилась потребность администрирования их работы. Всё, что находилось в 1С блогосфере - было по созданию бизнес-процессов и ничего не нашлось толкового по отмене задачи ошибочной и тем более по отмене ошибочного перехода в вложенный БП (бизнес-процесс далее).
Конечно, прилагаемая обработка не взлетит у Вас! У меня свои названия БП и Задача исполнителя так же не стандартно названа. Но для понимания принципа, как образец к действию сгодится для начинающих (а опытные могут дать свои замечания и критику).
Шапка наполнена реквизитами под учет моих карт и моих БП. У меня 11 БП, которые могут стартовать в одном из двух БП, дальше вызовом вложенных сливаются в один маршрут и по цепочке маршрута могут циклически вызываться из одного в другой и снова возвращаться в середину.
Судебное ведение дела уходит то в Апелляцию, может в Кассацию. Из них вызывается Сопровождение в суде, мировое соглашение или на Исполнительное производство. Очень запутанные схемы и пользователи естественно будут ошибаться и не то выбирать при выполнении очередной задачи.
По схемам у меня раздвоение более чем на две ветки не случается и поэтому в шапку забил поля под две ветки. Сначала потерял время над попыткой автоматизации заполнения задачами шапки при выборе документа Претензия, это у меня ведущий документ - из которого централизованно ведется весь ход и управление маршрутом\задачами. Но автоматизации не вышло, это нужно было предусмотреть на стадии проектирования. А я когда проектировал предусмотрел это мне казалось, но только для линейных схем. В задаче у меня был предусмотрен реквизит - Следующая задача и он заполнялся при создании следующей задачи. Но после разделения на две ветки, одна задача созданная из двух уже теряется в этой цепочке.
Тогда принял решение не терять время, на будущее решил, нужно будет создать регистр сведений для записи последовательности задач исполнителя, но это на будущее. А сейчас сделал просто вывод сразу всех полей без управления их видимостью в зависимости от ситуации на маршруте и пользователю выводится карта текущая с отметками выполненных и ожидающих выполнения задач. Пользователь уже сам, проанализировав карту, решает, какую задачу следует удалить и отменить выполнение предыдущей - они выведены в шапку всегда. Напомню, поля заполняются автоматически при выборе документа Претензия.
Так же при переходе в вложенный БП, если это первый шаг нового БП и он ожидает выполнения, то поле с выполненной задачей 1 будет заполнено последней выполненной задачей из БП вызвавшего это вложенный БП. Поле Предыдущий БП заполнится исходным БП. Отменить в этот момент можно текущий БП, при этом автоматом отметятся к удалению задача которая ожидает выполнения в вложенном БП, отменится выполнение предыдущей задачи из вызвавшего БП, удалится ведущая задача, которую автоматически создал БП при создании вложенного и в моем случае ещё свои мелкие необходимости, как например перезапись реквизита Текущий БП у документа Претензия.
Так же замечу, у меня при удалении задачи исполнителя дополнительно производятся нужные в моём частном случае действия, как например установка дополнительных свойств у объекта, для отмены проверки установки пометки удаления на задачу. Это у меня программно запрещено пользователю! Иначе там сразу начался ужас в данных. Но это все сопутствующая лирика.
Так же в правой части шапки добавил возможность руками выбрать из списка точек, нужную точку маршрута и автоматом подтягивается к ней предыдущая точка. Это понадобилось для случая, когда раздвоение маршрута одной веткой упёрлось в точку слияния и этот шаг у нас становится выполненным, но что бы его отменить - придется его отдельно выбрать руками. Автоматом его не определить так просто. Там же, справа, расположена командная кнопка "Отмена выбранной задачи" и под кнопкой пояснение боле менее подробное. Логика работы кнопки зависит от состояния задачи в поле Ручной выбор задачи. Если она выполнена, то предыдущая тоже выполнена и первое нажатие кнопки отменит выполнение выбранной задачи. Карта при этом обновит состояние, она вообще обновляется при основных действиях и есть кнопка обновления карты и заодно кнопка для левого поля шапки обновить задачи. Так вот, вернемся к нашей кнопке в правом поле. Второе нажатие уже удалит отмененную с выполнения первым нажатием задачу и отменит выполнение у предыдущей. Третий раз нажимать не надо, проверок на все случаи не вставлял)))
Спасибо awk, принял замечание по установке транзакции и заодно ещё скорректировал некоторые моменты, в частности получение ведущей задачи у удаляемого БП. Вот скорректированный код основных процедур, кто-то успел скачать уже обработку без исправления к сожалению, а там действительно транзакции не правильно в корне установлены были.
Процедура удаления не выполненного шага и отмены выполнения предыдущего или удаления входа в вложенный БП:
В точке разделения создаются задачи в каждой из ветвей (рис.2), далее каждая ветвь выполняется параллельно, а задача в точке Действие4 будет создана тогда, когда будут выполнены все задачи каждой ветви (рис.3)
Всегда ли система ведет себя подобным образом. Давайте выясним. Для начала обратим внимание на то, в какой последовательности создаются задачи после точки разделения (рис.4)
По номеру задачи можно увидеть, что первой была создана задача в точке Действие3. Теперь в модуле бизнес-процесса для этой точки опишем следующий обработчик при создании задач:
Процедура Действие3ПриСозданииЗадач ( ТочкаМаршрутаБизнесПроцесса , ФормируемыеЗадачи , Отказ )
Для каждого ЗадачаОбъект Из ФормируемыеЗадачи Цикл
Такой обработчик приведет к тому, что создаваемая задача сразу будет выполнена. Стартуем новый бизнес-процесс с картой маршрута, приведенной на рис.1. И что мы увидим? После выполнения задачи Действие3 была создана задача Действие4 (рис.5), несмотря на то, что другие ветви процесса еще не выполнены! Тех, кто попытается воспроизвести указанную ситуацию, предупреждаю: у вас вместо написания обработчика для точки Действие3 может оказаться необходимым написать обработчик автовыполнения задачи для точки Действие1 или Действие2. Точка действия, автовыполнение которой "ломает" схему процесса - это именно та точка, в которой создается первая задача после точки разделения. От чего зависит последовательность создания задач, будет рассмотрено ниже.
Далее выполним задачу Действие4 и убедимся, что процесс идет дальше, не дожидаясь завершения задач в точках Действие1 и Действие2 (рис.6)!
Далее, когда выполним задачи Действие1 и Действие2, снова создается задача Действие4 (рис.7).
Такого поведения простой схемы маршрута никак нельзя предположить, исходя из приведенного в начале статьи описания. Может это какая-то ошибка отображения схемы? Нет, на самом деле все так и происходит. Бизнес-процесс не только выполняется дальше точки слияния, не ожидая завершения задач в параллельных ветвях, но и создает повторно задачи в точках маршрута, следующих за точкой слияния после завершения параллельных ветвей . Смотрим список задач по нашему процессу и видим по 2 задачи для точек Действие4 и Действие5 (рис.8)
О чем это говорит? Фактически это означает, что при автоматическом выполнении задачи Действие3 мы получим поведение бизнес-процесса, соответствующее схеме, приведенной на рисунке 9, то есть точка слияния при выполнении одной ветви пропускается. Но это тоже не всегда верно. Если в точке Действие4 мы не будем выполнять первую из созданных задач, до появления второй задачи в результате выполнения параллельных ветвей до точки слияния, то следующая задача в точке Действие5 будет создана только при выполнении обеих задач в точке Действие4, то есть бизнес-процесс как бы исправляет допущенную ранее ошибку игнорирования точки слияния. Далее по схеме маршрута будет создаваться только по одной задаче. Тем, кого заинтересовало такое поведение бизнес-процесса, предлагаю убедиться в этом самостоятельно.
Рассмотрим другой пример. Предположим, что точка Действие3 является не точкой действия, а точкой вложенного процесса. Для простоты используем следующую схему вложенного бизнес-процесса (рис.10)
Если в событии Условие1ПроверкаУсловия ничего не выполнять, такой процесс завершается сразу после старта, не создавая ни одной задачи. На практике такое может встретиться и в более сложных процессах, если необходимость выполнения задач процесса возникает только при выполнении каких-то условий. Заменим точку Действие3 точкой вложенного бизнес-процесса и получим схему, приведенную на рисунке 11.
Проверяем работу бизнес-процесса со вложенным процессом и убеждаемся в аналогичном поведении. На рисунке 12 – схема бизнес-процесса после старта.
Всегда ли проявляется такое поведение в подобных схемах? Давайте разберемся. Обратим внимание на то, что задачи в точке разделения создаются в том порядке, в каком были добавлены линии в точке разделения. Это можно увидеть, если вывести имена соединительных линий (рис.13).
Попробуем поменять местами Линия2 и Линия4. И наконец-то при старте нового процесса мы видим ожидаемый результат (рис.14)
Обращаю внимание, что линии обязательно надо поменять местами. Если просто переименовать линии, выходящие из точки разделения, результат останется прежним. Другим способом исправления приведенной проблемы является удаление связи Линия2 , добавление новой связи в точке разделения и соединение ее с точкой вложенного процесса.
При автоматическом выполнении задачи, привязанной к первой по порядку добавления линии точки разделения, если после этой задачи сразу следует точка слияния , эта точка слияния игнорируется и создается следующая по схеме маршрута задача. Если не обращать внимания на последовательность связей, можно при создании внешне одинаковых схем получить разное поведение бизнес-процесса.
Эту зависимость следует учитывать и при доработке существующих схем. Допустим, мы решили, что вместо одной задачи в точке Действие1 на рисунке 14, которая у нас начала работать так, как требуется, должен быть вложенный процесс, который при определенных условиях, может выполниться автоматически по условию аналогично рисунку 10. Тогда при старте нашего процесса мы увидим знакомую картину с игнорированием точки слияния (рис.15)
В заключение отмечу, что указанное поведение бизнес-процессов было замечено еще на платформе 8.1 и продолжает проявляться на последних релизах 8.2. При подготовке статьи тестирование выполнялось на релизе платформы 8.2.15.310.
Практически все описано в анонсе публикации, но еще чуть-чуть.
Вы разработчик. Пишите код, запускаете отладку, накликиваете за пользователя какие-то данные. Или даже за нескольких пользователей - в нескольких сессиях параллельно, если бизнес-процесс сложный. Или запускаете "накликанный" на эталонных данных сценарный тест. Ловите ошибку, идете в конфигуратор исправлять, чтобы повторить все заново.
Если к следующему циклу "накликивания" надо вернуть исходное состояние данных, то можно написать (лень!) и запускать обработку, которая восстановит данные, или восстанавливать каждый раз в базу резервную копию (каждый раз сохранять наработку в cf, восстанавливать копию, перезапускать конфигуратор, восстанавливать наработки. в общем - отпадает. а если тут еще и хранилище. уууу. ).
Или прицепляем данное расширение, настраиваем фиксацию и автоматическое восстановление данных и после каждого цикла просто перезапускаем отладку. Данные восстанавливаются самостоятельно.
Или вы - инженер сопровождения. У вас тестовая база с "исходными" данными и вы пытаетесь повторить ошибку, возникающую у пользователя. После короткого времени ошибка не повторена, а контекст данных "испорчен".
Переключаетесь в список истории изменения данных, нажимаете одну кнопку, ждете несколько секунд. Вуаля, контекст данных восстановлен, ищите ошибку заново.
С разработкой видеоинструкций отдельная боль. Собственно, идея оттуда и пришла. Коллега, который занимался созданием видеоинструкций, реализовывал свою версию подобной разработки. Но она не покрывала восстановление данных всех объектов ИБ.
При разработке сценарных тестов тоже должно пригодится!
Ограничения
Слукавил немного. Эта разработка тоже не покрывает восстановление данных ВСЕХ объектов ИБ. Не восстанавливается первоначальное состояние регистрации объектов в узлах планов обмена и хранилищ настроек.
Все же остальное фиксируется в истории и восстанавливается вполне успешно - объекты ссылочных типов, движения регистров любых типов, константы.
Понятно что разработка построена на событиях. Поэтому главное ограничение - версия платформы. Подписки на события в расширениях появились в 8.3.17. Поэтому использовать данную разработку на более старых версиях платформы не получится. А вот режим совместимости конфигурации (не забудьте синхронизировать режим расширения с ним) может быть достаточно "старым" - от 8.3.12.
Также при добавлении расширения в конфигурацию желательно снять флаги безопасного режима и защиты от опасных действий.
Механика
Из объектов, несущих данные, в расширении есть справочник для фиксации истории изменений и настроечный регистр сведений.
В справочнике фиксируются объекты в состоянии "до изменения". Прирост времени выполнения при включенной фиксации данных по моим замерам составляет до 10%. Для работы в тестовой базы для процессов сопровождения/разработки /настройки считаю показатель вполне приемлемым.
При восстановлении данных восстанавливаются только самые первые версии измененных объектов. То есть если документ (или регистр по определенному отбору) меняли десять раз, то в истории изменения зафиксируются все, но восстановится он только один раз - по самой первой фиксации. Это значительно сокращает время восстановления.
При восстановлении объекты имеют ОбменДанными.Загрузка = Истина. Объекты восстанавливаются в порядке, обратном порядку записи истории, хотя при восстановлении "среза первых" это необязательный атрибут. Документы при этом не проводятся, поскольку наборы записей регистров фиксируются и восстанавливаются отдельно.
Восстановление происходит в транзакции. После успешного восстановления история изменений очищается.
Можно восстановиться до определенной записи в истории, если сможете правильно определить эту самую нужную вам запись. Тогда история зачистится только до этой строки.
А еще можно поставить закладки в историю в нужные вам моменты (спасибо коллеге, подсказавшему идею в комментариях) и восстанавливаться до них.
Настройка
Она элементарна.
Можно включить тотальную фиксацию изменений (первая на скриншоте). Тогда фиксироваться будет все, в том числе изменения данных в фоновых заданиях. Именно такой вариант я и рекомендую.
При этом варианте можно дополнительно настроить автоматическую очистку данных при старте или заверешении работы системы.
Можно включить фиксацию изменений для отдельного пользователя (он "сам" должен это сделать) и для текущей сессии.
Такие варианты могут использоваться с дополнительными оговорками, поскольку не гарантируется целостность восстанавливаемых данных из-за того, что в истории не фиксируются действия других пользователей.
Но, возможно, кому-то это будет полезно.
При записи истории изменений может достаточно быстро расти размер базы. Но я не рекомендую использовать запись истории без периодического восстановления данных или очистки истории (справочник легко чистится непосредственным удалением элементов) на продолжительном отрезке времени.
В любом случае, это расширение не предназначено для работы в "боевой" базе. Это инструмент исключительно для IT-специалистов и использования исключительно в тестовых базах!
Заключение
Разработка тестировалась на платформе 8.3.18.1289 на базах ЗУП (3.1.16.134) и ERP (2.4.12.64 и 2.5.6.98).
Разработкой активно пользуются коллеги, занимающиеся видеоинструкциями и сценарными тестами.
Жду обратной связи, всем спасибо за внимание!
Версия 1.0.0.2 (от 21.06.2021)
Изменения в версии:
Версия 1.0.0.3 (от 22.07.2021)
Изменения в версии:
Специальные предложения
Думал, тут что-то хитрое придумано, но
расширение не предназначено для работы в "боевой" базе
Хотя, всё-равно, это хорошая штука для тестовых баз.
И для демо-серверов
Такие варианты могут использоваться с дополнительными оговорками, поскольку не гарантируется целостность восстанавливаемых данных из-за того, что в истории не фиксируются действия других пользователей.
По хорошему, тут как раз можно было бы и заморочиться. Обычно это нужно как раз в рабочей базе и как раз по одному пользователю-тестировщику (+ все остальные). Тогда можно было:
1. Зафиксировать версию объекта до изменения тестировщиком
2. Для остальных пользователей при чтении объекта читать зафиксированную версию (это самое сложное)
3. Фиксировать отдельно версию после изменений других пользователей.
Или даже проще
1. Фиксировать отдельно версию тестировщика (оставляя оригинальные данные - вернее сразу восстанавливая их)
2. При чтении данных тестировщиком - читать зафиксированную отдельно версию
Организовать чтение зафиксированную версии из отдельного источника, пожалуй, самое сложное - причём именно поймать момент чтения и подменить одни данные на другие.
Можно восстановиться до определённой записи в истории, если сможете правильно определить эту самую нужную вам запись. Тогда история зачистится только до этой строки.На эту тему рекомендую сделать простую доработку - явно назначаемые временнЫе маркеры (с комментариями) - которыми можно было бы фиксировать (интерактивно или програмно) временные отсечки - и потом просто восстанавливаться на состояние перед этим маркером.
А вот это можете пояснить?
И вот это тоже, хотелось бы пояснить подробнее
(1) Спасибо за развернутый комментарий и хорошие вопросы. Талантом писателя, в том числе и технического, к сожалению, не наделен)
Думал, тут что-то хитрое придумано, ноВосстановление происходит в транзакции
Самый простой способ "откатить" изменение данных - выполнять изменения в транзакции, которую потом не фиксировать. Здесь как раз нет никаких транзакций (кроме платформенных и прописанных в коде конфигурации, разумеется) именно при изменениях данных. А восстанавливаются они действительно в транзакции, дабы сохранить целостность данных и истории изменения в случае возникновения ошибки при восстановлении.
Накликивать данные можно часами, восстановление в транзакции будет занимать десятки секунд или минуты.
расширение не предназначено для работы в "боевой" базе
Ну, это чисто мое мнение. использовать-то можно. на свой страх и риск. Но я бы не стал :-)
Про фиксацию данных и их подмену для разных пользователей. Тема интересна чисто с технической точки зрения. Но тут вопрос скорее к овчинке и выделке.
В тех эко-системах серверов и ПО, где работаю я, восстановление довольно свежего "боевого" бэкапа в тестовую базу занимает совсем непродолжительное время и такие доработки и сопутствующие риски неактуальности данных в боевой базе - вещи нецелесообразные.
Но код открыт полностью - все в Ваших руках)
Про "временные маркеры" и комментарии к ним. Очень хорошая идея, постараюсь реализовать в ближайшее время. Спасибо!
А вот это можете пояснить?Поэтому главное ограничение - версия платформы. Подписки на события в расширениях появились в 8.3.17. Поэтому использовать расширения на более старых версиях платформы не получится. А вот режим совместимости может быть достаточно "старым"
Тут очепятка, сори (если я правильно Вас понял). Сейчас отредактирую: "Поэтому использовать расширения" заменю на "Поэтому использовать данную разработку"
И вот это тоже, хотелось бы пояснить подробнееОбъекты восстанавливаются в порядке, обратном порядку записи
Тут как раз все просто: справочник истории с числовым кодом и с автонумерацией. В процессе восстановления данных определяется набор восстанавливаемых элементов и восстанавливаются они по отсортированному по этому коду в обратном порядке списку. (2)Вопросы был про вот эту фразу - видимо я что-то не знаю о режимах совместимости и о требованиях к ним в расширениях
А вот режим совместимости может быть достаточно "старым" Тут как раз все просто: справочник истории с числовым кодом и с автонумерацией. В процессе восстановления данных определяется набор восстанавливаемых элементов и восстанавливаются они по отсортированному по этому коду в обратном порядке списку.
Нее. я не понимаю. Допустим восстановление идёт на некую строку (как Вы пишите) - по факту - на некоторый момент времени - тут сразу на ум приходит периодический регистр сведений - но у Вас справочник - тогда нужен просто срез последних данных (ключа данных - и это тот ещё вопрос - т.к. для ссылочных типов всё просто - это их ссылка, а для регистров (особенно неподчинённых и не периодических) всё куда сложнее); да и как Вы храните версию - целиком - или только изменённую часть - если только изменённую - то боле-менее понятно что Вы делаете) - получили срез - и просто перезаписали объекты из версии среза - если они хранятся целиком - никакого обхода по версиям не нужно делать.
А, вот, если Вы храните данные по изменённым полям (например у документа изменили дату - то сохраняете в своё хранилище - по ключу ссылке - имя реквизита "Дата" и его прошлое значение), то на срезе не будет плоской таблицы текущих версий - нужно сделать обход в глубину (в прошлое) и восстановить каждый изменённый реквизит каждого объекта - причём один раз (только последний) - а это уже куда сложнее и дольше.
А с регистрами - так вообще можно только полные версии хранить - всего набора. или нужно целиком хранить ключ - измерения - и далее имя изменившегося ресурса/реквизита и значения - но обычно ключи тут как раз очень длинные - и проще весь набор хранить (в идеалае запаковав по методу колоночных баз данных).
Я это всё говорю не просто так - так как имею опыт разработки системы версионирования данных на 1С - а Ваше решение по сути таковым и является
А вот режим совместимости может быть достаточно "старым"Поначалу я настройку сделал на константах. При тестировании очередной базой, к которой я "прилепил" расширение, была ERP 2.4. У нее режим совместимости был 8.3.14 и он не пропускал констант в расширении. Они появились в появились в 8.3.16. Я переделал настройки на регистр сведений в итоге.
Это и явилось причиной появления данной фразы в публикации.
Вы сейчас в комментариях вытягиваете все, что я недосказал в публикации)). По сути, просите пересказать все внутренности разработки. Ну что ж, код открыт, секрета никакого, извольте, коли не хотите скачивать, тратить мани и время на изучение чужого кода. Искренний технический интерес хороших специалистов мною очень уважаем и льстит мне не меньше лайков :-)
Действительно, "обратный" порядок восстановления данных не играет никакой роли. Сделал так "на всякий случай". Даже прогрессбар работает в форме восстановления от 100% к нулю :-) Ведь о т к а т же :-) (и правда ИС "запикивает" это слово!)
Главное - локализовать "первичные" версии объектов и наборов данных, которые и будем восстанавливать.
И тут действительно есть идентификатор данных, его поле видно на одном из скринов. И в случае со ссылочным типом данных там действительно "сидит" уникальный идентификатор из ссылки.
А вот в случае регистров (на скрине как раз наборы записей различных регистров, в историю запакованные) там находится. назовем это неким "хэшем" отбора регистра, созданным на основе сериализованного в JSON массива, содержащего все элементы отбора.
Таким образом имя метаданных (разумеется полное, вида "РегистрСведений.СостоянияСотрудников") и данный "хэш" дадут нам уникальный ключ данных.
Сами же данные хранятся в виде JSON-представления объекта (всего набора записей, например), будь то ссылочный тип, или набор данных регистра, или значение константы. Я его даже не упаковываю в хранилище со сжатием, пытаясь таким образом не повлиять на скорость выполнения основных операций.
Именно поэтому я говорю, что длительное накопление истории приведет к увеличению размера базы.
(4)Ничего не вытягиваю, просто пытался на скорую руку понять как глубоко Вы копали. Оказалось не глубоко, и это всё как раз обусловлено теми сценариями, которые Вы предлагаете к использованию (и тем как использовали на практике). Они вполне себе имею право на жизнь. для данной разработки.
То что версия объекта записывается целиком как раз может сильно влиять и на производительность записи и на производительность восстановления (но да - так проще, хотя и не компактно) когда они очень большие (а это не редкость, скажем, для документов в оптовой и и в розничной торговле, или при бюджетировании и много где ещё), а модифицируют в них обычно как раз "помелчи". Но для тестовых баз и так сойдёт.
Хеши отбора регистра - вещь правильная - но ни один алгоритм хеширования не гарантирует уникальности хеша. Поэтому все хеш-коллекции используют хеш-только как первый индекс, сравнивая потом полные ключи. Но для тестовых баз, наверное, и так сойдёт.
Обратный порядок - замедляет восстановления - Вам нужен только срез до выбранного момента
Обратный отсчёт индикатора - идея плохая - она намекает об отмене процесса (который до этого шёл в прямом направлении) - а у Вас идёт процесс отмены изменений - это вполне себе нормальный процесс - лучше измените на прямое направление - не смущайте народ - вот не применится транзакция этого процесса (а это легко может произойти, скажем, из-за блокировок) - вот тогда можете визуализировать декриментирование индикатора прогресса.
Сжимать JSON можно отдельно - в фоновом задании - это не будет шибко тормозить основную работу - вообще в фоне можно много оптимизации сделать
Восстанавливать тоже можно в фоне. рисуя красивый прогресс и его обратку на клиенте без блокировки сессии - если транзакция не будет принята - пока будет идти фоновая отмена этой транзакции (хотя момент завершения отмены в СУБД не поймать)
Читайте также: