Scripting et modifications

Avant d’écrire du code, tenez compte de l’impact sur les mises à niveau et l’adoption de nouvelles fonctionnalités ServiceNow. Des précautions particulières doivent être prises lors de la modification des artefacts et des processus de base de référence.

Prenez en compte les éléments suivants avant d’écrire un script :

• Évaluez le besoin. La logique est-elle essentielle au fonctionnement de l’application ?
• Déterminez si ServiceNow peut être configuré pour répondre à l’exigence sans code.
• Exploitez les options, telles que Concepteur de flux, Agent virtuel et les politiques d’interface utilisateur, pour tirer parti des options de la plateforme sans écrire de code.
• Les approches low-code et no-code de la logique sont plus faciles à déboguer et à mettre à niveau.

Exemples de situations dans lesquelles un scripting est approprié :

• Création d’actions du Flow Designer
• Création d’une Scripted REST API
• Création d’une logique pour les applications incluses dans le périmètre dans Script Includes
• Personnalisation et création de widgets pour Service Portal

Évaluez les besoins professionnels et envisagez une route sans code avant d’utiliser une solution scriptée.

Soyez au courant des améliorations de ServiceNow. Par exemple, dans la version Orlando, les conversations Virtual Agent ont plus d’options sans code que London. Lisez les notes de version et d’autres publications. Obtenez une certification et restez à jour avec vos certifications.

Pour mieux comprendre quand personnaliser, consultez le guide de réussite Innover à grande échelle sur le Customer Success Center.

Modification du comportement par défaut

Dans le passé, l’une des stratégies utilisées consistait à copier l’artefact pour mettre à jour et désactiver l’original. L’approche copier/désactiver n’est plus recommandée en raison des problèmes suivants :

• Les développeurs ne peuvent pas dire si un artefact désactivé a été mis à niveau sans recherche.
• Deux fichiers, l’original et la copie, doivent être conservés. La maintenance double à chaque fois qu’une personnalisation est effectuée.
• À chaque version, l’enregistrement personnalisé vieillit.
  • les clients ne bénéficient pas des améliorations incluses dans une nouvelle version.
  • Une nouvelle version peut dépendre de la mise à jour de l’enregistrement d’origine.
  • Les développeurs peuvent apporter d’autres modifications pour compenser l’inactivité de l’enregistrement d’origine.

Un script dans lequel seul le marqueur Actif est modifié sera mis à jour, mais le script n’apparaît pas sur la liste ignorée. Avec la stratégie de copie et de désactivation, un développeur a moins de visibilité sur les personnalisations et ne peut pas facilement évaluer ou revenir à la version de base de référence.

Plutôt que de copier et de désactiver l’artefact d’origine, modifiez-le directement. Le moteur de mise à niveau ServiceNow ajoute la dernière version à l’historique des versions et signale que l’artefact a été ignoré. Les développeurs peuvent voir qu’une nouvelle version est disponible avec la mise à niveau.