Как обезличить базу 1с
Иногда возникает необходимость передать/продемонстрировать свою базу ЗУП третьим лицам. Например, вам нужно отдать копию своей базы ЗУП сотруднику подрядчика, разрабатывающего вам нетиповой обмен с вашей бухгалтерской базой.
Или, скажем, вы хотите продемонстрировать свои доработки базы ЗУП сторонним заказчикам и вам нужно быстро создать обезличенную "демо" базу.
При этом нужно сохранить конфиденциальность данной копии базы ЗУП, чтобы никто не смог "воспользоваться" (как именно придумайте сами :)) персональными данными, указанными в ней.
Скрытием данной конфиденциальной информации и занимается данная обработка, при этом данные в базе остаются читаемыми и приятными глазу :)
Всего можно выполнить 9 действий:
- Перемешать ФИО в регистре сведений "ФИОФизическихЛиц" – произвольным образом перемешивает фамилии, имена и отчества в регистре с учетом пола физ. лица
- Заполнить ФИО в справочнике по регистру сведений - процедура заполняет реквизит ФИО в справочнике по перемешанным выше данным регистра сведений, процедура также очищает реквизиты ИНН, СНИЛС и Дату рождения в справочнике "Физические лица"
- Перемешать паспортные данные в регистре - случайным образом перемешивает все паспортные данные в соответствующем регистре сведений
- Установить всем физ лицам одинаковую контактную информацию - берет первую попавшуюся таблицу с контактной информацией и устанавливает её всем остальным физ лицам
- Переименовать подразделения и должности - последовательно переименовывает подразделения и должности по маске "Подразделение 1/2/3", "Должность 1/2/3", после этого по тому же алгоритму переименовываются позиции штатного расписания.
- Очистить регистр склонений - очищает регистр сведений, где хранятся склонения по падежам всех обезличенных выше данных
- Очистить краткий состав документов - очищает значение реквизита "КраткийСоставДокумента" во всех документах системы, где он присутствует. В этом реквизите в строке хранится краткий перечень физ. лиц документа
- Затереть реквизит физическое лицо в справочнике "Пользователи"
- Очистить регистр сведений "Версии объектов"
Для надежности перемешивание ФИО можно сделать не один раз, это даст более "точный" результат.
Внимание: все действия, которые выполняет данная обработка являются необратимыми. Перед выполнением обязательно делайте БЭКАП, все действия рекомендуется делать ТОЛЬКО в тестовой базе.
Обработка тестировалась на версии ЗУП 3.1.8.216 на платформе 8.3.13.1690, но будет работать и на более ранних версия платформы и ЗУП 3.1.*
Методика расследования причин медленной работы операции на примере открытия управляемой формы
Для начала необходимо убедиться, что проблема стабильно воспроизводится (в одинаковых условиях) и что все пункты с описанием применения методики выполнены. Для этого можно сделать следующее:
Сбор и анализ стандартных данных
Разберем пример для операции открытия формы документа "Табель учёта рабочего времени".
Мы организовали тестовый стенд, на котором наша проблема воспроизводится под пользователем с полными правами. К этому стенду мы можем подключаться как напрямую с удаленной рабочей станции в режиме тонкого клиента, так и в режиме веб-клиента через публикацию на веб-сервере.
Настройка технологического журнала на клиенте может быть такой:
Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 1С:Предприятие) мы в отдельном каталоге Client_Full увидим данные только клиентских приложений (хотя при этом подкаталоги других процессов тоже будут созданы, но они буду пустыми). Свойство Interface не собираем, так как оно дублируется более "человек читаемым" свойством IName (хотя даже последнее нам в данном примере не обязательно нужно).
После настройки технологических журналов и проверки корректности замера времени ОценкиПроизводительности БСП выполняем повторение операции с включенной отладкой.
Замеры времени средствами БСП будут выглядеть следующим образом:
Везде далее будем рассматривать верхний в этом списке замер от последнего повторения, его длительность 13,022 секунды.
Замер отладчиком конфигуратора изображен на следующем рисунке:
Как видно, сумма длительности всех строк, связанных с открытием формы составила всего 1,523 секунды.
'00010101' + ТекущаяУниверсальнаяДатаВМиллисекундах() / 1000
а для миллисекунд взять остаток от деления на 1000 (то есть просто последние три цифры, обратите внимание на "779" на следующей картинке).
Точное время начала замера (минут:секунд.миллисекунд): 25:10.779
Точное время окончания замера (минут:секунд.миллисекунд): 25:23.801
Найдем теперь записи технологического журнала, соответствующие данному замеру, они будут примерно следующими:
Здесь видно, что соответствующий нашему замеру серверный вызов SCALL завершился примерно за 10,1 секунды, это соответствует интервалу между запросом VRSREQUEST и ответом VRSRESPONSE.
Причем время начала замера почти совпадает с началом вызова, то есть событием VRSREQUEST, что собственно ожидаемо, так как замер БСП начинается на клиенте и должен быть непосредственно перед командой открытия формы. А вот окончание вызова сервера случилось раньше, чем окончание замера, что значит, что эта разница во времени пришлась на часть работы клиентского приложения.
Итак, промежуточный итог по длительностям замеров разными способами показывает соответствие нашей ситуации ограничениям и выполнение неравенства: 1,5 < 10,1 < 13.
Стандартными инструментами не удается увидеть причину проблем низкой производительности работы (открытия) управляемой формы, поэтому воспользуемся следующими помощниками:
- Отладчик операционной системы: Windows Performance Recorder для сбора метрик и Windows Performance Analyzer для их визуализации и анализа;
- Анализатор сетевых протоколов Wireshark или прокси-сервер Fiddler Web Debugger.
Установим и запустим Windows Performance Recorder ("C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\WPRUI.exe"), укажем настройки:
После того, как их подготовили, перейдем в тонкий клиент 1С, откроем форму списка документов и непосредственно перед воспроизведением проблемной операции запустим сбор данных WPR (кнопка Start).
После открытия формы в тонком клиенте запись можно остановить и открыть ее для анализа. В открывшемся окне найдем по PID 5508 (его можно определить в диспетчере задач ОС или по логам ТЖ) наш тонкий клиент 1С и должны получить примерно следующую картинку:
По данным Windows Performance Analyzer видим, что у нас нет серьезной нагрузки по дискам, а поток тонкого клиента потребляет 100% ЦП на протяжении длительного времени вплоть до завершения замера.
Запомним этот результат и проанализируем траффик.
Запустим Wireshark и повторим проблемную операцию в тонком клиенте 1С:Предприятие с прямым подключением к серверу приложений 1С.
При сборе данных с помощью Wireshark (и отбору по пакетам с сервером-источником равным серверу приложений 1С:Предприятие) запуск открытия формы документа будет выглядеть примерно так:
Здесь каждая такая строка – это пакет (или если точнее, то "кадр", frame), который в свою очередь является частью общего большого пакета поверх протокола TCP (PDU – Protocol Data Unit). Если их сложить, получим пакет около 70 Кб. Стоит обратить внимание, что это будет размер с учётом сжатия, а если без него – то должны получить что-то около 2500 – 3500 Кб данных.
Устанавливаем и запускаем Fiddler, на панели инструментов ищем "Browse", выбираем любимый браузер и запускаем в нем необходимое нам приложение (информационную базу 1С:Предприятие). После запуска переходим в форму списка документов (готовимся воспроизвести сценарий), возвращаемся в Fiddler и включаем сбор траффика (кнопка F12), переходим в браузер и открываем форму документа. После её открытия сбор траффика можно отключить и заняться его анализом. Мы должны получить примерно следующее:
В данном дампе достаточно быстро находится относительно большой пакет искомого размера, выбираем его в списке слева, а в правой части окна переключаемся на страницу Inspectors, выбираем там просмотр заголовков (Headers), и так как у нас пакет является сериализованным json (Content-Type: application/json), то попросим Fiddler десериализовать его для нас.
После этого в окне предпросмотра отобразится древовидная структура ответа (response), которая передается с сервера на клиент и содержит так много данных. Далее нам необходимо проанализировать её и найти наиболее проблемные места. Может помочь кнопка Expand All, которая развернёт все элементы дерева, но это может занять некоторое время. Чтобы его сократить, сначала поймем, что именно нужно искать.
Подведем промежуточный итог:
- Проблем с медленной работой прикладного кода 1С или запросов нет.
- Большая часть времени открытия формы состоит из сетевого взаимодействия.
- Размер пакета с формой подозрительно велик.
- После получения пакетов имеем высокую утилизацию ЦП тонким клиентом 1С (или веб-клиентом).
- Потерянное время находится где-то между окончанием/началом работы прикладного кода 1С и сетевой передачей.
Из всех этих пунктов для нас наиболее полезным и требующим дополнительного анализа является тезис "Размер пакета с формой подозрительно велик".
Какие могут быть причины для такой ситуации? В общем случае их несколько:
- Сама по себе большая и сложная форма с большим количеством экранных элементов и реквизитов. Наверное, редкий и точно не очень правильный случай, лучше такого избегать на этапе проектирования систем.
- Простая форма, но много данных в реквизитах формы (включая данные объекта), в особенности:
- Хранилище значения, Строка(0);
- Большие коллекции (Таблица, Дерево, Список);
- Произвольный тип (концентрация проблем).
Так как наша проблема (у вас может быть по-другому) воспроизводится даже при очень небольшом количестве данных в ТЧ, и реквизитов у документа (т.е. объекта формы) совсем не много, то их мы не рассматриваем. Остаются реквизиты формы, не равные основному реквизиту "Объект".
Среди них находится несколько реквизитов, имеющих произвольный тип. Могут выглядеть так:
Сопоставляем эти данные с уже собранным ранее замером с помощью конфигуратора, и видим заполнение этих структур достаточно большим количеством элементов (например, можно 5059 в реквизите "СвойстваИзмерений").
Снова вернемся к дампу траффика в Fiddler и найдем там элемент, отвечающий за параметры формы (response/props). Увидим там примерно следующее:И если развернем далее эти элементы, убедимся, что их там несколько тысяч, каждый из которых представляет собой вложенную структуру вида:
Найдем прикладной код, заполняющий эти параметры, и убедимся, что данных там действительно достаточно много (2-3 Мб), и они представляют собой большое количество сложных вложенных структур.
Отключив заполнение данных реквизитов, убеждаемся, что проблема с производительностью формы исчезает, что значит, что причина была найдена правильно.
Выводы и рекомендации
Длительная работа открытия формы обусловлена сериализацией и десериализацией больших коллекций значений при передаче их между клиентом и сервером.
Для того чтобы оценить степень влияния всех факторов, которые имеют значения в этом процессе, можно сделать несколько тестов (замеров), изменяя эти факторы и оценивая корреляцию их значений и длительности. В нашем случае причиной проблем были структуры, хранящие данные справочников территорий и условий труда, поэтому изменяли количество этих элементов и пробовали замерять передачу с клиента на сервер этих данных (процедура ДанныеДляРедактированияВХранилище).
В следующей таблице приведены результаты таких замеров в нашем примере. Сразу следует оговориться, что не стоит никаким образом рассматривать в ней абсолютные значения, так как это будет зависеть еще и от конфигурации компьютера, сети, версии платформы и многого другого, связанного именно с нашим примером. Для нас же важны зависимости и их характер (линейная, экспоненциальная и т.д.). Предлагаем вам проанализировать их самостоятельно (или даже повторить замеры на актуальной версии платформы в вашей среде).
Принимая во внимание полученные таким образом данные, можно предложить следующие возможные пути решения:
Существует достаточно много обработок для обезличивания баз данных. Некоторые универсальны, некоторые ориентированы на конкретные объекты метаданных. Предлагаю простое, понятное и прозрачное, а главное - легко модифицируемое решение, которое универсально подходит для обезличивания любой базы и требует минимум навыков.
Речь идёт об использовании системы "Конвертация данных 2". Суть проста - всю черновую работу по чтению, записи, модификации данных берёт на себя штатный механизм, а разработчику остаётся только указать места, где требуется обезличивание. При этом всё управляемо и без подвохов - не нарушатся ссылки, логическая целостность, не пострадает функциональность. Главное - указать объекты и поля, которые обезличить. И весь инструментарий КД к нашим услугам.
Идея проста: создаём конвертацию, берём копию базы (ну или не копию), из неё выгружаем в файл и обратно в неё же загружаем этот файл, и готово. Итак:
1. Выгружаем описание нужной базы, создаём конвертацию, в качестве источника и приёмника указываем одну и ту же конфигурацию.
2. При необходимости, параметрами определяем объекты, подлежащие обезличиванию (опять же, их удобно будет указать в пользовательском режиме средствами отбора и периода в Универсальном обмене XML). Тут, очевидно, можно по-всякому - и через собственные произвольные выборки, и стандартными запросами, смотря по конкретике задачи. Хоть принудительно "ВыгрузитьДанныеПоПравилу", хоть как. Например, определив массив:
3. Поскольку база одна и та же, смело используем стыковку по GUID. Если под обезличивание попадают поля, уникально идентифицирующие элемент данных, то это единственный надёжный способ, поэтому флаг продолжения поиска выключаем (казалось бы - зачем? а затем, что битые ссылки иногда вынуждают КД продолжить поиск уже по ключевым полям).
4. Обезличиваем нужные реквизиты нужных объектов любым нравящимся способом - например, сделать наименования равными кодам:
С тем же успехом можно:
Простор для фантазии)
5. При необходимости обрабатываем не только справочники, документы и независимые регистры сведений, но и константы, если они простых типов:
6. Если в базе есть регистры и прочие вторичные данные, чьи поля простых типов зависят от неких операций (обычно от проведения документов), то перепроводим:
7. И только со значениями перечислений трудновато, разве что, исходя из точного понимания механизма, действительно аккуратно подменить на некое обезличенное значение, например:
Ещё можно перекидывать через ПараметрыОбъекта, тогда с любыми данными полная свобода манёвра, но больше хлопот.
Всё. Принцип я описал, конкретных реализаций возможна масса. При обезличивании проводящихся документов не забывайте отключать и затем включать итоги.
Логирование, отладка - всё уже есть штатно.
Замечу, что таким же образом можно шифровать и затем дешифровать содержимое баз. Достаточно сделать две конвертации - одна будет зашифровывать, хешировать, как-либо ещё преобразовывать данные, выгружая в файл. Затем файл передаём, хоть по незащищённому каналу. Затем вторая конвертация согласно принципам шифровки грузит из файла в базу.
Очень часто для демонстрации конфигурации, базы данных для разработки, для передачи для нужд разрабочиков требуется обезличить данные в базе.
Именно для этого создана данная обработка.
Вне зависимости от типа базы, она проходит по всем справочникам, которые есть в конфигурации, вы выбираете, какие справочники и реквизиты нужно обезличить.
Если реквизит текстовый, то он обезличится простым текстом с указанием кода.
Если Дата - поставит дату 01.01.2000.
Если числовое, то поставит 0.
Табличные Части не обрабатываются.
ВНИМАНИЕ! Проверьте что запускаете обработку, ТОЛЬКО НА ДУБЛИКАТЕ базы.
Тестировалось на самописных конфигурациях. 1С:Предприятие 8.3 (8.3.18.1334)
Со своими задачими справлялась на все 100%.
Анонимная база, обезличивание данных в базах 1с. Управляемые формы.:Специальные предложения
А в чем отличие (или преимущество от типовой) от 1С)?
(1) а что-то я не в курсе был, что за обработки такие - напишите о них, чтобы не скачивать и не тестить.
1с даже не соизволили картинки приложить к своим обработкам и мало-мальский обзор написать. (1) В нашем случае Конфигурация самописная, полностью с нуля.
Я пытался запустить обработку, но она начала выдавать ошибки, поэтому было решено самому написать то, что нужно + немного универсальности на будущее для других наших конфигураций.
Основное преимущество это простота и универсальность, доступная даже для начинающих разработчиков.
В самом коде можно легко разобраться и понять где находится момент изменения данных, и скорректировать под себя как называть и менять значение реквизита при выполнении кода.(4) идея хорошая. Но для этого нужно:
- чтобы у вас была установлена конфигурация КД,
- в вашей конфигурации должен быть модуль универсального обмена,
- у вас есть время для того выгрузить файл, написать правила обмена
- выгрузить файл с данными и загрузить обратно.
Если к этому добаить что:
- конфигурация очень динаминая и дорабатывается регулярно,
- меняются реквизиты и объекты, которые чувствительны к конфиденциальности.
То писать правила и выгружать данные займет много времени.Данная обработка удобна, когда в команду входит новый разработчик и надо развернуть базу у него, но при этом все конфиденциальные данные скрыть.
Или надо передать базу 3му лицу для анализа каких либо данных, работоспособности и т.д. - тут достаточно скопировать базу, запустить обработку почистить и передать.
Именно для для таких ситуация удобна данная обработка.Опишу свою ситуацию:
- в вашей конфигурации должен быть модуль универсального обмена, Нет, достаточно обработки, которых везде как грязи и из КД тоже можно выгрузить.
В нашей ситуации нужна была демонстрация работы базы по ZOOM потенциальным клиентам. Причем она работает только когда сделано много настроек и есть объем данных на 3 месяца.
Как это сделать за 1 вечер? Пришлось делать копию и делать обработку, которая скрывала личные и персональыне данные.
На демонтрации люди не видели и не имели представления о конкретной Организации пример которой был показан.
- у вас есть время для того выгрузить файл, написать правила обмена Это время в разы меньше времени на написание собственной обработки - выборки, отборов, механизма записи.
Это также сопоставимо со временем тестирования собственной обработки, только потрачено на другое будет.
конфигурация очень динаминая и дорабатывается регулярно, меняются реквизиты и объекты, которые чувствительны к конфиденциальностиЕдинственный реальный довод в пользу универсальной собственной обработки. С этим согласен.
Я сперва применял обфускацию средствами КД тоже для клиентов, но потом решили, что сделать демку один раз проще. Потом применял для партнёрских и субподрядных контор, чтобы они могли оценить объём работ, и вот тут подход себя оправдал на 100%
skype: live:di-sem@programmist_1C
Обезличивание информации в базе 1С. Изменение конфиденциальной информации 1С.
Чтобы было понятно о чем обработка приведу пример.
Справочники контрагенты и номенклатура до обезличивания:
Справочники контрагенты и номенклатура после обезличивания:
Обработку можно скачать тут.
Просто распакуйте (перетащите) вложенный в архив файл (с расширением epf), например, на рабочий стол и открывайте его прямо из 1С через меню Файл->Открыть.
Если у вас управляемый интерфейс (такси и прочее), то меню вызывается через левый верхний кружок со стрелкой вниз.
В обработке есть 2 вкладки: "Список объектов" и "Общие настройки изменения данных".
Список объектов - тут можно выбрать объекты, которые нужно скрыть от посторонних глаз.
Общие настройки изменения данных - тут выбираете алгоритм обезличивания. Достаточно просто проставить галочки.
Внимание. Все манипуляции ни в коем случае не выполнять на рабочей базе. Обработку запускать только в копии базы!
Как запустить обработку обезличивание базы 1с если у вас управляемые формы(последние версии конфигураций).
Нужно сделать так.
Чтобы запустить 1с предприятие в режиме толстого клиента нужно в окне настройки запуска баз указать ключ /RunModeOrdinaryApplication
Читайте также: