Personnalisations suivies par des ensembles de mises à jour
Les ensembles de mises à jour peuvent suivre les personnalisations des tables, des champs et des enregistrements d’application.
- Où la table dispose d’un attribut de dictionnaire update_synch .
- Où il existe un gestionnaire spécial pour suivre les changements apportés à plusieurs tables.
- Lorsque l’administrateur n’a pas exclu un champ des mises à jour.
En général, les ensembles de mises à jour capturent des informations de configuration, mais pas des données de tâche ou de processus. Par exemple, les ensembles de mises à jour suivent les définitions d’éléments du catalogue de services et les données de configuration connexes telles que les variables et les choix de variables. Toutefois, si vous testez le catalogue de services en passant des commandes, les ensembles de mises à jour ne suivent pas les demandes de commande, les éléments et les tâches du catalogue.
Les ensembles de mises à jour ont une capacité limitée à transférer des données sous forme de fichiers d’application. Pour des transferts de données plus volumineux, exportez les données et importez-les à l’aide d’un jeu d’importation ou d’un service Web.
update_synch attribut
Pour afficher la liste des tables où les personnalisations sont suivies, accédez à et filtrez sur les attributs CONTAINS update_synch.
update_synch à un enregistrement de dictionnaire. Lorsqu’il n’est pas utilisé correctement, cet attribut peut entraîner des problèmes de performances majeurs ou rendre l’instance indisponible. Pour cette raison, l’attribut update_synch n’est pas accessible aux clients.update_synch sur une table pour laquelle il n’est pas prédéfini afin d’éviter les problèmes suivants :- Certaines tables de base nécessitent une gestion de mise à jour spéciale, car elles représentent des informations sur plusieurs tables. Lorsque l’attribut
update_synchest ajouté à ces tables, des enregistrements de mise à jour en double sont créés, ce qui entraîne des conflits majeurs difficiles à résoudre et à réparer. - L’utilisation de l’attribut update_synch pour migrer des enregistrements de données entre des instances peut entraîner des problèmes de performances, car il n’est pas prévu à cette fin. Pour migrer des données, utilisez une importation d’instance à instance.
Reportez-vous à la section Jeux d’importation.
Manutentionnaires spéciaux
Certains changements nécessitent des gestionnaires spéciaux, car ils représentent des informations sur plusieurs tables. Ces changements sont regroupés dans une seule entrée d’ensemble de mises à jour afin que tous les enregistrements soient correctement mis à jour lorsque la personnalisation est validée. Les changements suivants sont suivis à l’aide de gestionnaires spéciaux :- Workflows
- Sections de formulaire
- Listes
- Listes connexes
- Listes de choix
- Entrées du dictionnaire système
- Étiquettes de champs
Listes de choix
Les ensembles de mises à jour stockent les options de choix nouvelles et mises à jour sous forme d’enregistrements distincts dans les tables Version de mise à jour [sys_update_version] et Mise à jour du client [sys_update_xml]. Par exemple, vous créez une table Activité [u_activity] qui étend la table Tâche. Vous ajoutez ensuite une nouvelle option de choix au champ État de la tâche qui n’est visible que pour votre table étendue (par exemple, Mon état).
Lorsque vous publiez ces changements en tant qu’ensemble de mises à jour, la mise à jour contient uniquement les enregistrements de mise à jour et de version du choix que vous avez ajouté à la table de u_activity. Les options de choix dans la table de tâches ne sont pas affectées.
Changements apportés au dictionnaire
- Suppression de tables
- Modification d’un type de données de colonne
Les ensembles de mises à jour n’effectuent pas de suivi de la suppression des tables du dictionnaire système. Au lieu de cela, les clients doivent supprimer manuellement les tables de l’instance cible. Alors que les ensembles de mises à jour suivent les changements de type de données, l’instance cible ignore tout changement entraînant une perte de données et ajoute à la place un message de journal sur l’action. Les clients peuvent utiliser le journal pour effectuer manuellement des changements de type de données sur l’instance cible.
Pages d’accueil et pages de contenu
Les pages d’accueil et les pages de contenu ne sont pas ajoutées aux ensembles de mises à jour par défaut. Ajoutez des pages à l’ensemble de mises à jour actuel en les déchargeant.
La fonctionnalité des pages d’accueil, qui organise les informations de votre instance pour raconter une histoire sur vos données, se trouve dans les tableaux de bord sur les nouvelles instances. Sur les instances mises à niveau avec Next Experience cette option activée, les utilisateurs peuvent afficher les pages d’accueil existantes si elles disposent d’une URL directe, mais ils ne peuvent pas les créer ni les modifier. Les tableaux de bord réactifs et Analytics Center les tableaux de bord prennent en charge la fonctionnalité de la page d’accueil.
Utilisez l’outil d’aide à la dépréciation de Page d’accueil pour convertir les pages d’accueil de votre instance en tableaux de bord réactifs.
Modifications de l’application
Le système crée un ensemble de mises à jour distinct pour chaque application qui contient uniquement les changements associés à l’application. Cela garantit que les paramètres d’accès de chaque application sont correctement évalués et appliqués lors de la validation des changements d’ensemble de mises à jour.