Содержание
- Справка по проекту
- Позаботьтесь о том, что места достаточно
- Процесс миграции нуждается в постоянном мониторинге
- Запись данных в режиме ОбменДанными.Загрузка = Истина не регистрируется как изменение к выгрузке
- Под ДО 3.0 придется адаптировать загружаемые из ДО 2.1 данные
- Проведение ревизии старых задач в работе
- Интеграция с ERP, ЗУП, БП и др.
Справка по проекту
Состав команды: архитектор, бизнес-аналитик, разработчики 1С, ответственные за переход и отдельно по ДО, а также три системных администратора с функциями разработчиков. Если вы еще не ознакомились описанием на ИТС по миграции с Документооборота 2.1 на Документооборот 3.0, то рекомендую сделать это перед прочтением данной статьи.
База проекта:
- Количество Пользователей — 1 600+
- Количество Документов в базе — 394 000+
- Новых документов в рабочий день — 500-700
- Количество задач (всего) — 4 600 000+
- Количество задач в день — 3 000-5 000
Запуск миграции: что важно сделать перед стартом
Позаботьтесь о том, что места достаточно
Дело в том, что смена редакции 1С:Документооборота (далее ДО) 2.1 на 3.0 происходит не посредством обновления конфигурации базы данных, а переносом всех необходимых данных из 2.1 в пустую базу 3.0 через файловый обмен. Сразу после включения миграции размер базы 3.0 начнет увеличиваться. После перехода на 3.0 и до момента отключения процесса миграции обе базы будут работать параллельно и занимать место. Процессы, запущенные в 2.1 необходимо завершить в 2.1, так как до момента их завершения базы 2.1 и 3.0 будут работать параллельно.
База с ДО 2.1 должна запоминать, какие данные уже были выгружены и изменялись ли они после последней выгрузки. За это отвечает подсистема «Отметки времени». Из-за необходимости хранения большого количества информации (см. База по проекту) после включения миграции размер базы ДО 2.1 может увеличиться примерно в 2-3 раза.
Платформа 1С не сразу физически удаляет записи таблиц из базы данных, а в процессе миграции в базе ДО 3.0 будет происходить и запись, и удаление данных из-за их постоянной перезаписи, поэтому по мере необходимости рекомендуется выполнять сжатие таблиц информационной базы.
Процесс миграции нуждается в постоянном мониторинге
Перед началом процесса миграции рекомендую обновиться до последней актуальной версии ДО 2.1, т.к. с каждой версией ДО ошибок миграции становится все меньше. Если возникла ошибка при выгрузке или загрузке данных, то их необходимо оперативно исправлять. Будет полезно настроить рассылку писем об ошибках загрузки.
Готовьтесь к тому, что процесс миграции — небыстрый (см. База по проекту). Разные метаданные будут загружаться с разной скоростью. Миграция выводит статистическую информацию о дате начала загрузки, количестве загруженных объектов, количестве объектов всего — на основании этих данных рассчитывает оставшееся время загрузки. Не стоит планировать на основании этого времени, т.к. оно не учитывает скорость загрузки каждого типа данных и вы получаете только среднюю скорость загрузки Документа, Задачи, Рабочей группы и т.п. Например, на нашем проекте процесс миграции занял 4 месяца, а закладывали только неделю.
Рабочие группы увеличивают время загрузки. Основной причиной большой потери времени при загрузке стали Рабочие группы. Если рабочая группа, рассчитанная для 3.0 состоит из большого количества записей, то загрузка будет происходить медленно. При загрузке каждого последующего участника рабочей группы будут перезаписаны все уже загруженные участники. Соответственно скорость записи каждого нового участника будет увеличиваться.
Основную проблему вызвали документы, в которых не были заполнены рабочие группы (права рассчитывались на основании политик доступа).
Если в политиках доступа была указана рабочая группа с большим количеством участников, например, все пользователи, то для документа рабочая группа рассчитывалась с полным перечнем участников, где каждый — это отдельная запись.
Если количество пользователей в базе 100, то это не вызовет больших проблем, но если пользователей — 10 000, то загрузка только одного документа займет больше суток. Ситуация может возникнуть, не только на документах, но и на прочих видах объектов доступа. Мы заполнили рабочие группы для всех объектов доступа. Ваше решение может отличаться.
Рабочие группы для 3.0 рассчитывает регламентное задание «Заполнение рабочих групп для перехода на ДО 3.0». Обработка идет порционно. Механизм берет 10 документов с еще незаполненными рабочими группами, рассчитывает их и записывает. В базе клиента было больше 10 документов, у которых алгоритм расчета рабочих групп выдавал пустой результат. Это были ошибочные документы, с незаполненным видом документа. В какой-то момент регламентное задание начало получать только эти 10 документов и рассчитывать по ним пустые рабочие группы. При следующем вызове регламентного задания в выборку для расчета рабочей группы попадали те же 10 документов. Поэтому убедитесь, что у вас отсутствуют документы с незаполненным видом документа. Пустой вид документа может быть не единственной причиной расчета пустой рабочей группы — проверяйте, что регламентное задание не зациклилось.
Выгрузка данных. Этапы загрузки: выгрузка исторических данных, выгрузка изменений с момента запуска миграции, онлайн загрузка изменений сразу за пользователем.
Выгрузка данных идет значительно быстрее загрузки. Выгруженные, но еще не загруженные пакеты просто накапливаются. Многие объекты информационной базы после первоначального создания изменяются несколько раз с разницей в несколько дней. Если выгрузка данных произойдет сразу после записи, а затем и после каждого изменения, то объект будет загружен столько раз, сколько был выгружен (см. рис.1 и 2). А результат будет такой же, как при загрузке последнего пакета. Выгрузку изменений можно «ставить на паузу» — для этого достаточно отключить регламентное задание. Как только выгруженные пакеты будут загружены, то можно снова включить регламентное задание. При этом не стоит давать загрузке простаивать, лучше всего всегда иметь небольшое количество пакетов в очереди для загрузки. Это предотвратит многократную загрузку данных и позволит лучше контролировать процесс загрузки.
рис.1
рис.2
Запись данных в режиме ОбменДанными.Загрузка = Истина не регистрируется как изменение к выгрузке.
В таких случаях необходимо добавлять отметки времени вручную, либо убрать запрет на регистрацию отметки времени в подписках на события. Мы придерживались подхода, что любые изменения в ДО 2.1 должны быть зарегистрированы в отметках времени и загружены в ДО 3.0. Пример кода для регистрации в отметках времени по разным типам можно посмотреть в процедурах:
ОтметкиВремениСобытия.СсылочныеОбъектыПриЗаписи
ОтметкиВремениСобытия.СсылочныеОбъектыПередУдалением
ОтметкиВремениСобытия.РегистрыПередЗаписью
ОтметкиВремениСобытия.КонстантыПриЗаписи
[Файл можно скачать в начале статьи]
Под ДО 3.0 придется адаптировать загружаемые из ДО 2.1 данные
Точнее адаптировать много данных — это схемы БП, шаблоны файлов, дополнительные реквизиты и сведения, скрипты и прочее. Как только начинаются работы по адаптации 3.0, перед началом работы пользователей — лучше отключить миграцию изменений по этим объектам, чтобы данные не затирали внесенные изменения. Если в версии 2.1 будет изменен какой-нибудь скрипт, то внесенные изменения в 3.0 будут стерты. После начала работ по адаптации рекомендуется отключать перенос изменений соответствующих метаданных.
Проведение ревизии старых задач в работе
Миграцию с ДО 2.1 рекомендуется отключать только после того, как будут завершены все незавершенные процессы. Необходимо провести ревизию перед началом миграции и завершить все старые зависшие процессы.
Интеграция с ERP, ЗУП, БП и др.
В ДО 2.1 была возможность редактирования документов документооборота прямо из базы интегрированной системы. В версии 3.0 такой возможности нет. Для внесения изменений в документы необходимо перейти по гиперссылке в документооборот и редактировать документы напрямую. Из интегрированных систем оставили только возможность прикладывать файлы.
Будут потеряны связи с документами, созданными из 2.1 в интегрируемых системах. Это происходит т.к. имя объекта метаданных в XDTO пакете для внутренних документов — DMInternalDocument, а в 3.0 — DMDocument. Интеграция с ДО 3.0 «не видит» данных об интеграции с ДО 2.1 из-за переименования идентификатора метаданных. При этом сами данные продолжают храниться в системе.
Для решения этой задачи мы воспользовались обработкой, которая создавала копию записей о связанных объектах для ДО 2.1 с идентификатором, который «видит» интеграция с ДО 3.0. Можно не создавать копии, а исправить идентификатор метаданных, но в этом случае будет проблематично вернуться к интеграции с ДО 2.1. Также можно было «научить» интеграцию видеть и идентификатор DMDocument, и DMInternalDocument, но это потребовало бы внесения правок в конфигурацию каждой из интегрируемых систем.
[Файл можно скачать в начале статьи]
Интеграция с другими базами (ERP, ЗУП, БП и др) рассчитана на интеграцию только с одной базой: или с 2.1, или с 3.0. Пока не завершены все процессы в 2.1, не отключена миграция многие интегрируемые объекты недоступны для редактирования. Внести изменения в объект, мигрировавший из 2.1 из интегрируемой системы невозможно. Для этого нужно переходить в 2.1.
В материале основные моменты, с которыми столкнулась наша команда, работая на проекте по переходу с ДО 2.1 на ДО 3.0. Для описания всех нюансов не хватит книги (шутка). Надеюсь, что материал будет полезен! Делитесь в комментариях своими кейсами, задавайте вопросы — так материал будет полнее и полезнее для коллег. Если на проектах сталкивались с аналогичными ситуациями, но использовали иное решение, тоже пишите.
Автор: Елена И.
Проверено на следующих конфигурациях и релизах:
- Документооборот КОРП, релизы 2.1.32.6
- Бухгалтерия предприятия, редакция 3.0, релизы 3.0.165.21
- Зарплата и управление персоналом КОРП, редакция 3.1, релизы 3.1.31.13
