Най-добри практики за персонализиране

Статия
06/30/2023

Следвайте тези най-добри практики, за да избегнете проблеми с производителността, използваемостта и поддръжката Dynamics 365 Field Service.

Намаляване на потребителските полета във формуляри

Системните персонализатори добавят персонализирани полета към формуляри на обекти, за да събират информация, специфична за тяхната индустрия и бизнес, да изпълняват бизнес процеси и да събират информация, за която да докладват. Твърде много потребителски полета във формуляр обаче могат да причинят проблеми с производителността.

За да избегнете проблеми с производителността:

Намаляване на броя на потребителските полета във всички формуляри. Започването с формуляра за поръчка за работа е добра идея, ако това е най-използваният формуляр в приложението "Полева услуга".
Сред персонализираните полета минимизирането на полетата за тип справка и подмрежата имат най-голям ефект върху производителността на формуляра, като например времето за зареждане.
Преместване на потребителски полета (особено справки и подмрежи) от първия раздел на формуляра в други раздели на формуляри.
Скриване на по-малко използваните полета по подразбиране във формуляра.

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

Персонализирането, вземането на зависимости или персонализираното извикване на готови уеб ресурси, набори от опции, права за достъп или работни потоци не се поддържа и може да доведе до нежелано поведение на системата.

Организациите, които персонализират тези компоненти, може да не видят веднага проблеми в своята среда. Въпреки това, тъй като Microsoft пуска промени в персонализираните готови компоненти, тези промени не се прилагат към най-горния слой на този компонент. Конкретният персонализиран слой отменя всички бъдещи промени, които в крайна сметка причиняват непредвидими грешки и поведение.

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

Модифицирането, редактирането или изтриването на полета и състояния за дата може да повлияе на бизнес логиката и да причини проблеми с актуализациите на решенията. Примери за дата на работна поръчка са времето от обещаното и времето до обещаното . Примерите за полета за състояние включват състояние на системата за работна поръчка и състояние на системата за споразумение.

Не редактирай и не премахвай външни полета от формуляри

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

За да избегнете грешки:

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

Ето само един пример: Процесите на полева услуга изчисляват стойността на полето Очаквано време на пристигане в записа за резервиране на ресурси, за да покажат кога се очаква работник на първа линия да пристигне на място. Ако вашата организация не се нуждае от това поле, скрийте го във формуляра, вместо да го премахвате.

За повече информация вижте тези статии:

Не редактирай стойностите на набора от опции (избор)

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

За да избегнете грешки:

Редактирайте само етикетите на набора от опции и никога не редактирайте стойностите на опциите на готовите полета.
Не премахвайте никакви опции за избор.
Не добавяйте никакви опции за избор.

Ето само един пример: Работната поръчка за полева услуга включва по подразбиране поле, наречено "Състояние на системата". Това поле е набор от опции (тип "избор") с опции като "Непланирано", "Планирано", "В процес на изпълнение", "Завършено", "Отменено" и т.н. Всяка от тези опции има етикет и свързана числова стойност. Системните администратори могат да редактират етикетите на набори от опции (като "Непланирани"), но никога не могат да редактират свързаната числова стойност на етикета.

Използвайте по-малко персонализирани скриптове и следвайте най-добрите практики

Системните персонализатори пишат скриптове, обикновено JavaScript уеб ресурси, за да изпълняват бизнес логика. Персонализираните скриптове обаче могат да причинят проблеми с производителността, грешки и усложнения при надстройване.

За да избегнете тези проблеми:

Минимизиране на скриптове, изпълнявани при натоварване.
Не пишете скриптове, които извикват много данни или пишете множество скриптове, които извикват едни и същи данни.

Следвайте повече форма скрипт най-добрите практики, включително следните най-добри практики:

Минимизиране на броя на мрежовите заявки и количеството данни, поискани в събитието OnLoad

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

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

Синхронните мрежови заявки могат да причинят бавно зареждане на страници и неотговарящи форми. Вместо това използвайте асинхронни заявки. Вижте тази публикация в блога за още примери. Освен това обмислете използването на "async and wait" във всеки сценарий, при който са необходими множество мрежови повиквания за един и същ обект и запис; Повече подробности можете да намерите тук.

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

Колкото повече скриптове добавяте към формуляра, толкова повече време отнема изтеглянето им. Обикновено скриптовете се кешират в браузъра ви, след като се заредят за първи път, но производителността при първото гледане на формуляр често създава значително впечатление.

Избягвайте зареждането на всички скриптове в събитието Onload

Ако имате код, който поддържа само събития OnChange за колони или събитието OnSave, уверете се, че сте задали библиотеката със скриптове с манипулатора на събития за тези събития вместо събитието OnLoad. По този начин зареждането на тези библиотеки може да се отложи и да се увеличи производителността по време на зареждането на формуляра.

Използване на свити раздели за отлагане на зареждането на уеб ресурси

Когато уеб ресурси или компоненти на iframe са включени в секции в свит раздел, те не се зареждат, ако разделът е свит. Те се зареждат, когато разделът се разшири. Когато състоянието на раздела се промени, възниква събитието TabStateChange. Всеки код, който е необходим за поддръжка на уеб ресурси или iframe в свити раздели, може да използва манипулатори на събития за събитието TabStateChange и да намали кода, който в противен случай може да се наложи да се появи в събитието OnLoad.

Избягване на дублиране на мрежови заявки в кода от страна на клиента

Множество или дублирани мрежови заявки могат да доведат до забавяне на уеб браузъра и да повлияят на времето за зареждане на формуляра. Намаляването на броя на заявките може да подобри производителността. Алтернатива е да се консолидират мрежовите заявки и да се кешира стойността на заявките. Също така помислете за асинхронни мрежови заявки, както беше споменато по-горе.

Избягвайте да използвате роли и специфични за потребителя повиквания на системата, ако съответната информация е налична в XRM API

Използвайте XRM API, за да избегнете мрежови заявки за получаване на информация за потребителски привилегии. Вижте следната статия за прехода от синхронни заявки. По същия начин избягвайте обажданията на системните потребители, ако информацията от XRM API отговаря на вашите изисквания.

Задаване на опции за видимост по подразбиране

Избягвайте използването на скриптове за формуляри в събитието OnLoad, които скриват елементите на формуляра. Вместо това задайте опциите по подразбиране за видимост на елементите на формуляра, които може да са скрити, за да не се визуализират по подразбиране, когато формулярът се зарежда. След това използвайте скриптове в събитието OnLoad, за да покажете елементите на формуляра, които искате да покажете.

За повече информация вижте тези ресурси:

Изпълнение на проверката на решения на вашите скриптове

Програмата Power Apps за проверка на решения е полезен инструмент от Microsoft, който проверява Power Apps решенията за проблеми и препоръчва най-добрите практики. Тези проблеми включват проблеми с JavaScript, HTML, плъгини и персонализирани дейности на работния процес.

За повече информация вижте тези ресурси:

Използване на асинхронни работни потоци вместо синхронни

Системните персонализатори често пишат синхронни работни потоци, за да изпълняват бизнес логика в реално време, която се изпълнява при промяна на данните в полевата услуга. Изпълнението на работни потоци обаче синхронно намалява производителността.

За да избегнете проблеми с производителността, изпълнявайте работни потоци асинхронно.

Активиране на външни процеси за планиране на полеви услуги и ресурси

Field Service и Resource Scheduling кораб с много процеси, които изпълняват необходимата бизнес логика.

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

За да избегнете проблеми, се уверете, че всички процеси за планиране на полеви услуги и ресурси са в активно състояние. Редовно изпълнявайте центъра за изправност на решения за полеви услуги, за да определите дали процесите са в дезактивирано състояние.

Изпълнение на центъра за изправност на решения за откриване на проблеми

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

Редовно изпълнявайте набора от правила на Field Service Solution Health Hub , за да наблюдавате здравето на вашата среда.

Съображения за ефективността на мобилните приложения

Персонализирането на мобилното приложение също може да повлияе на производителността. За повече информация вижте тази статия: Съображения за ефективност при персонализиране на мобилното приложение