Рекомендации по настройке

Следуйте этим рекомендациям, чтобы избежать проблем с производительностью, удобством использования и поддержкой с Dynamics 365 Field Service.

Сведение к минимуму настраиваемых полей в формах

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

Чтобы избежать проблем с производительностью:

  • Сведите к минимуму количество настраиваемых полей во всех формах. Хорошая идея — начать с формы заказа на работу, если это ваша самая используемая форма в приложении Field Service.
  • Среди настраиваемых полей минимизация полей типа подстановка и вложенные сетки будет иметь наибольшее влияние на производительность формы, например на время загрузки.
  • Переместите настраиваемые поля (особенно поля подстановки и вложенных сеток) с первой вкладки формы на другие вкладки формы.
  • По умолчанию скройте реже используемые поля в форме.

Не изменяйте готовые веб-ресурсы, наборы параметров, роли безопасности или рабочие процессы

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

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

Не изменяйте, не редактируйте и не удаляйте поля даты или статусы системы

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

Не редактируйте и не удаляйте стандартные поля из форм

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

Чтобы избежать ошибок:

  • Скрывайте ненужные поля из формы.
  • Переместите ненужные поля на другую вкладку формы.

Вот только один пример: процессы Field Service вычисляют значение поля Ожидаемое время прибытия в записи резервирования резервируемых ресурсов, чтобы указать, когда ожидается прибытие на место работника передней линии. Если вашей организации это поле не требуется, скройте его в форме, но не удаляйте.

Дополнительные сведения см. в следующих статьях:

Не редактируйте значения набора параметров (набора выбора)

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

Чтобы избежать ошибок:

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

Вот только один пример: заказ на работу Field Service по умолчанию включает поле под названием «Состояние системы». Это поле является набором параметров (типа «набор выбора») с такими параметрами, как Незапланированный, Запланированный, Выполняется, Завершено, Отменено и т. д. Каждый из этих параметров имеет метку и соответствующее числовое значение. Системные администраторы могут редактировать метки наборов параметров (например, «Незапланированные»), но никогда не должны редактировать соответствующее числовое значение метки.

Использование меньшего числа пользовательских скриптов и следование рекомендациям

Специалисты по настройке системы пишут сценарии, обычно веб-ресурсы JavaScript, для выполнения бизнес-логики. Однако пользовательские сценарии могут вызвать проблемы с производительностью, ошибки и осложнения при обновлении.

Чтобы избежать этих проблем:

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

Более полно следуйте рекомендациям по сценариям форм, включая следующие рекомендации:

Сведите к минимуму количество сетевых запросов и объем данных, запрашиваемых в событии OnLoad

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

Избегайте использования синхронных сетевых запросов

Синхронные сетевые запросы могут вызывать медленную загрузку страниц и отсутствие реакции от форм. Вместо этого используйте асинхронные запросы. Дополнительные примеры см. в этой записи блога. Кроме того, рассмотрите возможность использования «async and wait» в любом сценарии, когда требуется несколько сетевых вызовов для одной и той же сущности и записи; подробнее см. здесь.

Избегайте включения ненужных библиотек веб-ресурсов JavaScript

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

Избегайте загрузки всех скриптов в событие Onload

При наличии кода, который поддерживает только события OnChange для столбцов или событие OnSave, не забудьте установить библиотеку скрипта данных с обработчиком событий для этих событий, а не события OnLoad. Таким образом можно отсрочить загрузку этих библиотек и увеличить производительность при загрузке формы.

Используйте свернутые вкладки, чтобы отложить загрузку веб-ресурсов

Если веб-ресурсы или компоненты iFrame включены в разделы внутри свернутой вкладки, они не загружаются, если вкладка свернута. Они загружаются, когда вкладка разворачивается. При изменении состояния вкладки происходит событие TabStateChange. Любой код, необходимый для поддержки веб-ресурсов или объектов iFrame на свернутых вкладках, может использовать обработчики событий для события TabStateChange и уменьшать объем кода, который в противном случае должен бы находиться в событии OnLoad.

Избегайте дублирования сетевых запросов в клиентском коде

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

Избегайте использования ролей и вызовов конкретных пользователей системы, если соответствующая информация доступна в API XRM

Используйте API-интерфейсы XRM, чтобы избежать сетевых запросов на получение информации о привилегиях пользователя. См. следующую статью об отказе от синхронных запросов. Точно так же избегайте вызовов системных пользователей, если информация из API-интерфейсов XRM соответствует вашим требованиям.

Настройка параметров видимости по умолчанию

Избегайте использования в событии OnLoad скриптов форм, скрывающих элементы форм. Вместо этого настройте параметры видимости по умолчанию для элементов форм, которые могут быть скрыты и не отображаться по умолчанию при загрузке формы. Затем, используйте скрипты в событии OnLoad, чтобы отобразить элементы формы, которые требуется отобразить.

Дополнительные сведения см. в следующих ресурсах:

Запускайте средство проверки решений для своих скриптов

Средство проверки решений Power Apps — это полезный инструмент от Microsoft, который проверяет решения Power Apps на наличие проблем и дает рекомендации по передовому опыту. Эти проблемы включают проблемы с JavaScript, HTML, подключаемыми модулями и пользовательскими действиями рабочего процесса.

Дополнительные сведения см. в следующих ресурсах:

Используйте асинхронные рабочие процессы вместо синхронных

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

Чтобы избежать проблем с производительностью, выполняйте рабочие процессы асинхронно.

Активирование готовых процессов Field Service и планирования ресурсов

Field Service и планирование ресурсов поставляются с множеством процессов, которые выполняют необходимую бизнес-логику.

Деактивированные процессы могут привести к ошибкам.

Чтобы избежать проблем, убедитесь, что все процессы Field Service и оптимизации планирования находятся в активном состоянии. Регулярно запускайте Центр работоспособности решений Field Service, чтобы определить, находятся ли процессы в деактивированном состоянии.

Запуск Центра работоспособности решений для обнаружения проблем

Центр работоспособности решений позволяет получить более полное представление о состоянии вашей среды и обнаруживать проблемы с вашей средой Dynamics 365. Центр работоспособности решений запускает правила в экземпляре для проверки конфигурации среды, которая может со временем изменяться в результате естественных операций системы. Некоторые из правил относятся к Dynamics 365 Field Service, и вы можете запускать правила по требованию при возникновении проблемы. Некоторые правила автоматически срабатывают, когда Field Service устанавливается или обновляется.

Регулярно запускайте набор правил Центра работоспособности решений Field Service для наблюдения за работоспособностью вашей среды.

Замечания, связанные с быстродействием мобильного приложения

Настройка мобильного приложения также может повлиять на производительность. Дополнительные сведения см. в этой статье: Вопросы производительности при настройке мобильного приложения