Вы находитесь здесь:
Планирование и тестирование безопасной среды миграции
Если вы помогли создать базу знаний Classic Knowledge, вы знаете, что планирование критически важно. На самом деле планирование - самая важная часть миграции на Lightning Knowledge.
Требуемые версии
| Доступно в: Salesforce Classic и Lightning Experience. Просмотр поддерживаемых версий. |
Тестирование безопасной среды
Перед выполнением производственной миграции выполните миграцию в безопасной среде. Мы настоятельно рекомендуем тестирование в безопасной среде полной копии. Существует высокая вероятность повреждения данных при использовании безопасной среды с частичной копией. Этапы выполнения миграции в безопасной среде аналогичны производственной миграции. После планирования миграции и просмотра предмиграционного контрольного списка выполните миграцию «Один тип статьи» или «Несколько типов статей».
Предмиграционный контрольный список
Независимо от наличия одного или нескольких типов статей в Knowledge, просмотрите весь контрольный список перед выполнением тестирования безопасной среды.
Типы статей
При миграции из Classic в Lightning Knowledge типы статей соотносятся с новыми типами записей с тем же именем, что и типы статей. Они соотносятся с именем API, а не с именем метки. Выполните следующие проверки перед миграцией и помните о следующих ограничениях.
- Разверните неразвернутые типы статей для миграции.
- Определите и безвозвратно удалите ненужные типы статей.
- Измените параметры метаданных в типах статей Knowledge в настройках. Например, добавьте тип статьи, удалите тип статьи, измените параметры типа статьи или измените доступ профиля к типам статей.
- Измените стандартный тип статьи на «Нет».
Удалите следующие зависимости. Когда средство миграции деактивирует старые типы статей, эти объекты не всегда удаляются, что приводит к сбою миграции.
- Объекты, резюмированные другими объектами
- Задания отчета, ссылающиеся на определение настраиваемого объекта
- Типы статей, на которые ссылается параметр «Вклад агента»
- Типы статей, на которые ссылается параметр «Рекламная акция ответов»
- Настраиваемые объекты, используемые правилами соответствия
- Типы статей, используемые правилом управления повторами
- Управляемые удаления, указывающие на тип статьи
- Типы статей с неудаляемыми дочерними настраиваемыми полями из других управляемых пакетов
- Типы статей, на которые ссылаются другие функции, например, классы Apex или потоки данных
Включение Lightning Knowledge блокируется, если пакеты, созданные в текущей организации, содержат тип статьи. Чтобы включить Lightning Knowledge, удалите типы статей из пакетов, созданных в текущей организации.
Макеты страниц
Чтобы предоставить пользователям отличную работу с макетами и доступ к соответствующим полям, настройте макеты страниц. После миграции можно назначить разные макеты страниц для каждого типа записи и профиля пользователя. Убедитесь, что они правильно настроены во время миграции. Перед началом миграции удалите ненужные макеты страниц.
Рекомендации по полям
При соотнесении полей из нескольких типов статей в один тип записи помните о следующих рекомендациях.
- Поля формулы не мигрируют. После миграции создайте поля формул в объекте Knowledge и пересмотрите формулы, чтобы ссылаться на новый объект.
- Зависимости полей не мигрируют. Средство миграции переносит поля. Однако, он не мигрирует их параметры зависимости полей.
- Раскрывающиеся списки и раскрывающиеся списки со множественным выбором соотносятся только при наличии одинаковых значений раскрывающегося списка, одинаковых деактивированных значений или одного глобального раскрывающегося списка. Зависимые раскрывающиеся списки не могут быть перенесены. Параметры раскрывающегося списка мигрируют, а соотнесение между ними нет. Вы сбросите их после миграции. Кроме того, стандартные значения для раскрывающихся списков и флажков не мигрируют в Lightning Knowledge.Совет Организация может иметь два поля раскрывающегося списка, А и Б. А - это управляющий раскрывающийся список, а Б - зависимый раскрывающийся список. Средство миграции мигрирует как А, так и Б, но они становятся отдельными раскрывающимися списками, и вам нужно пересмотреть их параметры зависимости полей.
- При соотнесении полей с другими полями выберите целевое поле в раскрывающемся списке, определяющем, какое из них является основным.
- Если размер поля уменьшен до миграции, но статьи содержат больше символов, чем до уменьшения размера поля, весь текст отображается в Classic. Однако, после миграции размер поля усекается в новом объекте, что означает, что дополнительные символы не отображаются. Например, если в Classic поле с 500 символами увеличено до 1000, в поле может быть 1000 символов, но в Lightning отображается только 500 из них.
- Флажки обязательных полей не мигрируют. Поэтому обязательные поля должны быть переосмыслены после миграции каждой организацией, поскольку они все находятся в одной таблице. Рекомендуем управлять обязательными полями посредством макетов страниц или правил проверки, если они не являются обязательными для всех записей всех типов записей.
- Мигрировавшие поля называются «Имя типа_поля статьи». Данная конвенция удаляет конфликты имен полей.
- Удаленные поля (неактивно удаленные поля, хранящиеся в течение 30 дней) не мигрируют.
Настройки и управляемые (или неуправляемые) пакеты
Проверьте настраиваемые элементы до и после миграции, чтобы убедиться, что они переместились в новый объект Knowledge. Иногда они ломаются, поэтому приготовьтесь оценить этот аспект организации при выполнении миграции безопасной среды (перед миграцией в производстве). После миграции настройте настраиваемые элементы, ссылающиеся на тип статьи, чтобы указать на новый объект Knowledge.
Удалите все пакеты, содержащие тип статьи. Если вы не удалите эти пакеты, вы не сможете включить Lightning Knowledge или запустить средство миграции Lightning Knowledge.
Средство миграции Lightning Knowledge не работает в Developer Edition, если задать пространство имен для пакетирования.
Ниже указаны примеры настроек, которые нужно учитывать в оценках пост-миграционного периода.
- SOQL, запрашивающий имя конкретного объекта
- Страницы Visualforce, ссылающиеся на старые типы статей
- Код, использующий наборы полей
- Код Apex, ссылающийся на старые типы статей
- Настраиваемый код, использующий вызовы API, ссылающиеся на типы статей
- Логика приложения клиента, например, текущий код API
- Пакеты AppExchange
- Правила проверки
- CRUD (на тип статьи)
- Приложения, использующие API метаданных в наборах полей или компактных макетах
Рекомендации по файлам и вложениям
Файлы из настраиваемых полей файлов в статьях Classic Knowledge перемещаются в стандартный объект Files. После миграции пользователи могут просматривать и прикреплять файлы в связанном списке файлов. При запуске Lightning Knowledge Migration Tool выберите базовый параметр доступности для применения к мигрировавшим статьям. Вы можете сделать файлы доступными всем пользователям, имеющим доступ к статье, включая пользователей-гостей и пользователей Experience Cloud, или только внутренним пользователям. Если внутренним пользователям требуется доступ к файлам, которые недоступны внешним пользователям, полномочия отдельных файлов можно настроить после миграции. Чтобы минимизировать усилия по настройке доступа к файлам, выберите параметр доступности, применимый к большинству файлов.
Предмиграционные рекомендации и постмиграционные рекомендации
Соотнесение: соберите сложные идеи соотнесения посредством электронной таблицы или организационного инструмента. Использование электронной таблицы или организационного инструмента дает представление о том, как соотнести базу Knowledge в Lightning.
Подготовка к проверке: сохраните или распечатайте несколько статей заранее, чтобы потом сравнить их и проверить успешную миграцию.
Записи, принадлежащие неактивными пользователям: версии статей Knowledge (kav), связанные с неактивными пользователями, могут стать причиной проблем во время миграции. Для успешной миграции статей с неактивными ответственными параметр организации «Обновление записей с неактивными ответственными» должен быть включен. Если этот параметр выключен в вашей организации, средство миграции временно включает его во время миграции. Найдите нужный параметр в разделе «Ин терфейс п | тановки».
Параметры обращений и ответов:
- В параметрах обращения в разделе «Разрешить пользователю создавать статью на основе обращения» установите стандартный тип статьи на «Нет».
- В параметрах ответа в разделе «Разрешить пользователям создавать статью на основе ответа» задайте типу статьи по умолчанию значение «Нет».
Примечание по обслуживанию: Остановка действий базы Knowledge во время миграции производства
Чтобы предотвратить потерю данных, убедитесь, что пользователи не редактируют базу Knowledge во время миграции. Это действие наиболее важно для организаций с несколькими типами статей, поскольку миграция занимает больше времени, а модель данных существенно меняется. После начала миграции важно завершить процесс как можно скорее. Тщательно спланируйте, чтобы обеспечить минимальный простой пользователей базы Knowledge.
Прежде чем выполнять миграцию производства, сообщите о едином бюллетене компании, чтобы убедиться, что все изменения в базе Knowledge, ее структуре и статьях прекратятся во время миграции. Тем не менее, пользователи и клиенты могут читать статьи во время миграции. В организациях с несколькими типами статей переключение на статьи в Lightning происходит в начале этапа активации.
Ниже указаны примеры действий, которые должны быть прекращены во время миграции.
- Редактирование статей
- Создание статей
- Изменение статуса публикации статей
- Изменение настройки Knowledge, включая изменения в категориях данных
- Вызовы API, изменяющие настройки Knowledge или статьи
- Триггеры Apex, изменяющие или создающие статьи Knowledge
- Голосования по статье
- Ссылка на обращение
- Ссылка на заказ-наряд или позицию заказ-наряда
- Добавление сообщений ленты, изменение сообщений ленты или отслеживание статьи
- Редактирование файлов, вложенных в статьи
- Добавление соотнесений тем со статьями на сайтах Experience Cloud
Подготовка к использованию средства миграции Lightning Knowledge
После планирования и успешного тестирования безопасной среды обратитесь в службу поддержки Salesforce и сообщите, что готовы выполнить миграцию в производственной организации. Прежде чем включить инструмент в производстве, мы просим вас рассказать о результатах миграции безопасной среды. У вас есть одна организация типа статьи или несколько организаций типа статьи? Используйте соответствующее руководство и переместите базу Knowledge из Classic в Lightning.
