Вступление

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

В разных случаях для снижения объемов данных можно применять разные инструменты: для ссылок в личных папках автоочистка или управляемые папки, для справочников – текущий период или частные способы серверной фильтрации и т.д. Видно, что отдельный инструмент закрывал собой отдельную задачу, но какого-то общего способа “сделать все хорошо” не было.

И вот на сцену взобралось архивирование объектов. Да, речь не о том буквальном архивировании, которое применено, например, к схемам задач. Речь идет о разделении всех объектов системы на станы нужных в повседневной и оперативной работе и тех, которые представляют собой историческую ценность, но регулярно на глаза попадаться не должны.

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

• ускорить поиск и открытие справочников, так как архивные записи не загружаются с SQL-сервера;
• показывать только объекты, необходимые в текущей работе, в результатах поиска и списках справочников за счет скрытия архивных объектов;
• уменьшить размер базы данных за счет переноса документов из SQL-хранилища в файловое.

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

Итак, начнем.

Спасение утопающих

Логично было бы предположить, что наиболее остро проблема избыточных данных стоит в тех организациях, у которых нет ФХ и все данные замкнуты в БД SQL SERVER. Со временем объем базы увеличивается до непристойных значений, а пользователи нещадно тянут и тянут десятки и сотни тысяч строк в единый список (но я до сих пор не могу себе представить этакого паучка-делопроизводителя с парой десятков глаз, чтобы все это просмотреть одновременно). И, казалось бы, вот он выход – примените архивирование документов и используйте в оперативной работе только оперативные данные, не гоняя при этом избыточные мегабайты по сети и дискам.

Но справочная система говорит, что для списания документов в архив в системе должно быть развернуто архивное файловое хранилище. На деле это необязательное условие! Можно настроить правило архивирования документов, не указывая значения реквизита “Перенести в хранилище” или выбрав SQL-Server storage и выполнить поиск\перенос документов. Для наглядности приведу скрин (очередность шагов представлена цифрами):

В результате получаем архивирование подходящих под критерии документов:

А вот и подтверждение:

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

Что же получает администратор системы, для которой имеются файловые хранилища для документов? Ответ – несколько новых и, на мой взгляд, удобных возможностей.

Удобный трансфер от SQL до … SQL?

Если в справочнике хранилищ у вас есть одно или несколько ФХ, то даже не включая использование архивных данных, мы получаем простой и удобный визуальный инструмент для поиска и переноса тел документов между любыми хранилищами. Как и в случае с прежним инструментом (см. сценарий Мастер переноса документов между хранилищами) документы можно переносить как из SQL Server в ФХ, так и обратно. Плюс этого лайфхака в простоте выбора документов и возможности переноса “на лету”: выбрал критерии --> выполнил поиск (чтобы удостовериться, что критерии верные) --> и тут же запустил перенос через кнопку “Перенести в архив”.

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

Оперативный архив документов

Теперь проверим подробнее работу механизма архивирования уже с включенными архивными данными. Справочная система говорит о том, что для переноса документов в архив нужно настроить и использовать именно архивное ФХ (и в прежних версиях так и было, пусть без механизма архивных данных). На практике же администратор может использовать любое хранилище из доступных в справочнике “Хранилища текстов документов” для списания документов в архив. Любое, но отличное от текущего. В результате, архивные документы могут находиться в архивном ФХ, оперативном ФХ и даже в самой базе данных SQL Server`а! К чему эта информация: нередко клиенты не могут позволить себе развернуть еще одно ФХ для необязательных нужд (хранение малоиспользуемых документов, к примеру). Так теперь это делать и необязательно. Можно обойтись единственным ФХ. Пример размещения архивных документов в оперативном ФХ представлен на рисунке выше.

I`ll be back

Как и указано в справочной документации, чтобы вернуть вспять помещенный в архив объект, он может быть отредактирован пользователем с соответствующими правами или привилегиями в системе. Однако, я бы дополнил список возможных вариантов вернуть, например, документ из архива системы. Если коротко, то обращайте внимание на примечание в формах карточек. Так, в любой карточке, где видим предупреждение “Документ находится в архиве системы.” Не стоит вносить необязательные и не требующиеся изменения.

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

Список правообладателей доступен для изменения и если добавить\удалить строки, то сам документ в результате будет извлечен из архива, то есть вернется в список оперативных объектов\поиски.

Это же актуально и для реквизитов на форме Состояние документа. Приведу простой пример из опыта: есть типовой маршрут с обработкой документа. На определённом(ых) блоке вложенный в задачу документ переносится в архив. Однако в том же маршруте, далее по схеме, меняется стадия жизненного цикла документа. В результате запланированная клиентом логика не отработала: задача успешно завершена, а вложенный документ успел попутешествовать и в архив и обратно.

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

Заключение

Так выглядит результат моего знакомства с механизмом архивных данных в системе. Вероятно, многие из читателей уже также применяли его на практике и набрали свой уникальный опыт. Если вам есть, чем поделиться, то прошу отметить в комментариях, как вам помогло архивирование, и/или на какие подводные камни вы, возможно, наткнулись.