Créer des mises à jour facultatives et clients

Lorsque vous installez une application à partir du référentiel ou ServiceNow® du magasin d’applications, vous pouvez définir une série de propriétés pour définir le comportement de suppression et de traitement des choix. C’est ce que l’on appelle une fonctionnalité « d’auteur-électif ».

Vue d'ensemble

Vous trouverez des détails sur ces propriétés dans la Skipped records that occur during application installation rubrique. Grâce à ces propriétés, vous pouvez accepter ou refuser les suppressions et les mises à jour selon que vous utilisez votre propre application ou une application tierce.

Toutefois, lorsque vous effectuez une installation à partir du contrôle de source, ces enregistrements ne sont pas ignorés, sauf lorsqu’un fichier d’application global est réclamé par une autre application globale. À l’exception des com.glide.apps.include_my_deletes et com.glide.apps.include_global_deletes qui désactivent complètement le traitement du dossier author_elective_update, ces propriétés ne sont pas efficaces pour les applications installées source.

Remarque :

Un fichier « absent » détecté dans le chargement Delta pour le contrôle de source est très différent d’une charge utile Supprimer hébergée dans le dossier author_elective_update. Author_elective_update propriétés n’empêchent pas le chargement Delta dans le contrôle de source de supprimer le fichier.

De même, les ensembles de mises à jour protègent les personnalisations que vous effectuez dans une instance contre les changements entrants qui forcent une décision d’aperçu. Avant de valider un ensemble de mises à jour, un aperçu doit être exécuté pour tenter de détecter les collisions. Vous devez résoudre tous les problèmes d’aperçu avant de valider les changements. Le contrôle de source peut vous demander de dissimuler un changement local, mais le résultat de l’installation est de charger ce qui est présent dans le code source, même si un changement a été effectué localement.

Le chargement de ce qui est présent dans la source est difficile lorsque les propriétés doivent avoir des versions différentes en fonction de la cible de l’installation. Par exemple, il est difficile de résoudre ce problème lorsqu’une propriété contenant une URL d’intégration diffère en fonction du rôle de production de l’instance. Le marqueur is_private est efficace avec une installation de contrôle de source et ne remplace pas la propriété si défini, ce qui atténue ce problème.