Comparaison de personnalisation et configuration avec ServiceNow Studio
Il existe des différences importantes entre la personnalisation et la configuration ServiceNow des applications. La ServiceNow plateforme est conçue pour inclure la personnalisation et la configuration, mais la façon dont vous le faites peut avoir des impacts significatifs sur ServiceNow le support, la mise à niveau vers les futures ServiceNow versions de la plateforme et les fonctionnalités de la ServiceNow plateforme.
- Personnalisez une application uniquement si elle étend l’intention initiale de l’application. Par exemple, ajouter des fonctionnalités informatiques à ITSM un workflow de déplacement, mais pas en ajouter. Au lieu de personnaliser à outrance une application, créez-la à l’aide App Engine de produits, tels que Creator Studio ou ServiceNow Studio.
- Configurez autant que possible avant de personnaliser une application.
- Si vous ajoutez du code ou apportez d’autres modifications aux fonctionnalités prêtes à l’emploi, vous en êtes propriétaire.
Qu’est-ce que la configuration ?
La configuration consiste à utiliser ServiceNow des outils et des fonctionnalités intégrés pour modifier le comportement d’une application sans modifier les flux ou le code qui fait partie de l’installation de base de référence sur une ServiceNow instance.
La configuration peut prendre la forme de l’utilisation ServiceNow d’outils intégrés pour ajouter des tables et plus encore, de la définition de paramètres à l’échelle de l’instance, ainsi que de l’utilisation de code pour étendre les fonctionnalités d’une application afin de répondre aux besoins de l’entreprise, tant que le code ne modifie pas l’installation du code de base. L’ensemble de la plateforme est conçu pour que vous puissiez ajouter du code de configuration.
Si vous ajoutez du code, tel que des scripts de workflow, vous en devenez propriétaire, même si cela ne modifie pas l’installation du code de base. Cela inclut la prise en charge de l’impact qu’il a sur l’ensemble ServiceNow de la plateforme. Les problèmes qui découlent de l’ajout de code ne relèvent pas de l’assistance ServiceNow au débogage.
La restauration d’une configuration ne devrait nécessiter aucune modification du code de base de référence.
- Formulaires : configurez les tables, les champs, les types de données, les valeurs par défaut et les dépendances de champ pour configurer les données que vous capturez et affichez.
- Éléments d’interface utilisateur : modifiez les mises en page, ajoutez des listes connexes, ajoutez des boutons et changez les noms de champs.
- Catalogue de services: configurez les portails où vos clients peuvent demander des éléments de catalogue, tels que des offres de services et produits.
- ACL : empêchez les utilisateurs non autorisés d’accéder aux formulaires et aux données.
- Valeurs des propriétés système : Modifiez l’expérience de l’application pour tous les utilisateurs.
Qu’est-ce que la personnalisation ?
La personnalisation désigne tout changement apporté aux flux ou au code qui fait partie de l’installation de base de référence sur une ServiceNow instance. Vous utilisez des ServiceNow produits ou du code pour personnaliser les applications.
Si vous ajoutez du code, vous en devenez propriétaire, même s’il ne modifie pas l’installation de base. Cela inclut la prise en charge de l’impact qu’il a sur l’ensemble ServiceNow de la plateforme.
- Scripting : personnalisez ServiceNow à l’aide de scripts à l’aide de JavaScript. Cela inclut la création de scripts clients, de scripts côté serveur et de règles métier avec une logique complexe qui modifie le code de base de référence.
- Tables personnalisées : développez des tables personnalisées pour prendre en charge des données spécialisées qui ne rentrent pas dans des tables standard.
- Intégration : personnalisez l’intégration avec des systèmes externes, tels que des API et des services Web, pour un échange de données transparent.
- Widgets et portails : créez des widgets et des portails personnalisés pour fournir des fonctionnalités et des expériences utilisateur uniques.
- Workflows : créez et modifiez des workflows à l’aide Studio de workflowde . Créez et gérez des playbooks, des flux, des actions, des tables de décision et des intégrations à partir d’un environnement de conception unique pour automatiser les tâches. La mise à niveau vers une nouvelle version d’un flux nécessite de réappliquer vos personnalisations.
Outils de personnalisation et de configuration
ServiceNow offre de nombreux outils et fonctionnalités, tels que des règles métier, pour modifier le comportement prêt à l’emploi des ServiceNow applications. La personnalisation ou la configuration d’une application dépend de la façon dont elle est utilisée. L’utilisation de ces outils pour modifier la base de code installée constitue une personnalisation. L’utilisation de ces outils pour ajouter du code qui ne modifie pas les flux ou la base de code installée constitue une configuration. Dans les deux cas, vous êtes propriétaire du code que vous ajoutez ainsi que de l’impact qu’il a sur la ServiceNow plateforme.
- Politiques d’interface utilisateur : modifiez dynamiquement la visibilité des champs et des attributs sur un formulaire en fonction des entrées de l’utilisateur.
- Règles métier : déclenchez automatiquement des actions en fonction des conditions spécifiées.
- Actions d’interface utilisateur : étendez et personnalisez les formulaires et les listes en ajoutant des boutons, des éléments de menu contextuel ou d’autres éléments d’interface utilisateur qui effectuent des actions spécifiques lorsqu’ils sont cliqués.
- Scripts côté client : scripts qui s’exécutent dans le navigateur de l’utilisateur lorsque certaines actions se produisent sur un formulaire ou une page d’interface utilisateur.
- Scripts côté serveur : scripts qui s’exécutent sur le serveur ServiceNow ou la base de données, par exemple, pour mettre à jour les champs d’enregistrement lorsqu’une requête de base de données s’exécute.
Qu’est-ce que la personnalisation ?
La personnalisation consiste pour les utilisateurs à utiliser des outils d’application prêts à l’emploi pour modifier l’apparence d’une application uniquement pour eux-mêmes. Les administrateurs peuvent modifier l’apparence pour tous les utilisateurs, et cela est considéré comme une configuration. Par exemple, un utilisateur choisit d’utiliser le mode sombre ou les colonnes de table à afficher.
La personnalisation ne modifie pas l’installation du code de base sur une ServiceNow instance. Ainsi, la personnalisation n’a pas d’impact sur le support client ni n’interfère avec les mises à niveau vers de nouvelles ServiceNow versions.
Ramifications de la personnalisation ServiceNow des produits
La ServiceNow plateforme est extrêmement flexible et conçue pour embrasser la personnalisation et la configuration afin de répondre à un large éventail d’exigences commerciales. Toutefois, la ServiceNow personnalisation des applications peut avoir des impacts importants sur ServiceNow le support, la mise à niveau vers les futures ServiceNow versions de la plateforme et les fonctionnalités de la plateforme. Au lieu de personnaliser les ServiceNow applications, envisagez d’utiliser App Engine des produits de développement, tels que Creator Studio et ServiceNow Studio pour créer de nouvelles applications.
La ServiceNow plateforme utilise un cadre de travail qui prend en charge les applications dans leur façon de traiter les tâches, la façon dont les formulaires sont affichés dans plusieurs navigateurs et l’expérience utilisateur globale. ServiceNow s’appuie sur l’intégrité du cadre de travail pour développer et fournir une assistance de manière cohérente. Les personnalisations peuvent altérer ce cadre de travail, modifier les fonctionnalités de la plateforme et altérer les workflows et la possibilité d’évolutivité.
Pour en savoir plus, voir Customer Updates table. Notez que la complexité de la gestion des personnalisations augmente considérablement à mesure que le nombre de personnalisations augmente.
La personnalisation de la base de code installée peut s’avérer coûteuse, générer une dette technique, allonger votre cycle de mise à niveau et compliquer les futures mises à niveau de plateforme, car le code personnalisé peut ne pas migrer facilement vers de nouvelles versions de plateforme. Le code personnalisé peut modifier les fonctionnalités standard de la ServiceNow plateforme de manière inattendue. Évaluez soigneusement les demandes de personnalisation et n’avez recours à la personnalisation que lorsqu’il existe une valeur commerciale évidente et qu’il n’y a pas d’alternative. Dans la mesure du possible, évitez la personnalisation en utilisant plutôt la configuration.
- Vous êtes responsable du maintien de la personnalisation à l’avenir.
- Service client et assistance ne prend pas en charge les problèmes causés par le code personnalisé. Si c’est la cause des problèmes, l’équipe d’assistance vous conseillera probablement de revenir au code prêt à l’emploi.
Quelle est la position sur la prise en charge de la Service client et assistance personnalisation ?
La ServiceNow Service client et assistance position sur la personnalisation est que si vous ajoutez du code, vous le possédez et ses conséquences. Pourquoi ? L’assistance clientèle n’est pas au courant de votre logique métier personnalisée, ne sait pas quel doit être le comportement attendu, ne peut pas reproduire le problème sur une instance prête à l’emploi et les ingénieurs de l’assistance clientèle ne sont pas des spécialistes de l’implémentation certifiés, ils ne sont donc pas certifiés pour examiner la logique du code personnalisé.
Alternatives à la personnalisation
- Utilisez la configuration plutôt que la personnalisation.
- Soumettez une demande d’amélioration à l’équipe ServiceNow de développement. Chaque demande est évaluée et, si elle est approuvée, sera intégrée à une version ultérieure.
- Créez une application à l’aide App Engine des produits du développeur pour gérer les fonctionnalités souhaitées.
Quand utiliser App Engine les produits de développement au lieu de les personnaliser
- Si la personnalisation étend l’objectif de l’application, il est préférable de la personnaliser. Par exemple, vous pouvez ajouter des fonctionnalités informatiques à ITSM.
- Si la personnalisation n’étend pas l’objectif prévu de l’application, il est préférable de créer une application à l’aide App Engine de produits de développement. Par exemple, ne réutilisez pas le ITSM workflow pour créer un workflow de demande de déplacement.
Par exemple, ITSM est conçu pour gérer les problèmes informatiques. Le personnaliser pour gérer les demandes de déplacement va au-delà de l’intention initiale de ITSM. Étant donné que les demandes informatiques et les demandes de déplacement ont des workflows différents, il est préférable de créer une application de demande de déplacement à l’aide App Engine d’outils de développement, tels que Creator Studio et ServiceNow Studio, plutôt que de personnaliser ITSM.
Pour plus d'informations, consultez Utiliser App Engine au lieu de personnalisations.
Exemples d’utilisation App Engine des produits pour développeurs
ServiceNow Les produits fonctionnent mieux lorsqu’ils sont utilisés comme prévu. Si vous vous retrouvez à personnaliser fortement une application pour la réutiliser, il est préférable de créer une application à l’aide App Engine de produits de développement.
- Vous avez un nouveau cas d’utilisation pour une application qui ne s’aligne sur aucun workflow de produit.
- Vous avez un cas d’utilisation qui pourrait être créé en personnalisant fortement une application prête à l’emploi, mais qui ne correspond pas à ce que l’application existante était censée faire.
- Votre société dispose d’un groupe d’utilisateurs ou d’un processus business qui doit être distinct du workflow du produit prêt à l’emploi.
Directives pour la personnalisation des ServiceNow produits
- Maximisez d’abord les options de configuration.
- Évitez de copier des objets. Mettez plutôt à jour les objets en place dans la mesure du possible, à l’exception Portail de services des widgets et autres éléments destinés à être réutilisés.
- La valeur par défaut est « ajouter avant modification ». Cela signifie que vous devez, par exemple, ajouter des champs aux formulaires plutôt que de modifier le type d’un champ existant. Évitez d’utiliser les mêmes noms en tant qu’objets, méthodes ou classes prêts à l’emploi lors de leur ajout.
- Réduisez le nombre de champs que vous ajoutez à un formulaire. Plus il y a de champs dans un formulaire, plus le chargement peut prendre longtemps.
- Exportez les enregistrements d’origine en tant que copies de sauvegarde avant de les personnaliser. Gardez une trace de leurs sys_id prêts à l’emploi au cas où vous auriez à les restaurer à l’avenir.
- Utilisez les applications incluses dans le périmètre comme valeur par défaut pour tout nouveau développement personnalisé.
- Documentez toutes les personnalisations. Ajoutez des commentaires expliquant pourquoi vous avez personnalisé (y compris une justification commerciale). Vérifiez tous les commentaires avant d’effectuer une mise à niveau pour déterminer si vous pouvez revenir au code prêt à l’emploi.
- Créez des tests pour toutes les personnalisations. Rédigez des tests Framework de tests automatisés (ATF) pour toutes les personnalisations, dans la mesure du possible.
- Utilisez régulièrement HealthScan pour identifier les personnalisations inutiles.
- Les objets de référence doivent être personnalisés si nécessaire afin que la résolution des conflits et la prise de décision puissent être enregistrées de manière appropriée dans les mises à jour. Les personnalisations masquées peuvent amener les administrateurs à négliger les mises à jour des évaluations futures au cas où des annulations ou des fusions seraient nécessaires.
- Testez votre personnalisation pour tous les cas d’utilisation. Inclure des tests de performance et l’introduction de conséquences imprévues.
- Les administrateurs sont chargés de vérifier que leurs personnalisations fonctionnent après une ServiceNow mise à niveau de plateforme et de suivre les personnalisations effectuées.
Gestion des personnalisations lors de la mise à niveau
Les personnalisations déclenchent la création par la plateforme de sys_update_xml enregistrements, qui sont stockés dans la table Customer Updates (Mises à jour du client). Ces enregistrements ne sont pas mis à jour lors des mises à niveau de version de plateforme. ServiceNow les marque comme enregistrements ignorés dans le ServiceNow Moniteur de mise à niveau. Pour vous assurer qu’ils sont portés avec succès vers l’instance mise à niveau, vous devez traiter manuellement les changements ignorés. Pour en savoir plus, voir Customer Updates table.
- Conserver chaque personnalisation
- Revenir à l’état prêt à l’emploi
- Fusionner votre personnalisation avec le système de base pour résoudre les conflits