Personnalisations suivies par ensembles de mises à jour

Les ensembles de mises à jour peuvent suivre les personnalisations des tables, des champs et des enregistrements d’application.

Les ensembles de mises à jour suivent les personnalisations dans ces conditions :

• Lorsque la table comporte un attribut de dictionnaire update_synch .
• Lorsqu’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 les informations de configuration, mais pas les données de tâche ou de processus. Par exemple, les ensembles de mises à jour suivent les définitions d’éléments de 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 les transferts de données volumineux, exportez les données et importez-les avec un jeu d’importation ou un service Web.

Ne combinez pas l’utilisation des ensembles de mises à jour et du référentiel d’applications pour le développement d’applications incluses dans le périmètre. Cela entraînera de nombreux problèmes, notamment des changements ignorés, des erreurs de validation, etc. Une fois que vous avez installé une application à partir du référentiel d’applications, vous devez continuer à développer et à publier dans le référentiel d’applications pour tous les développements futurs. Si vous décidez de développer une application à l’aide d’ensembles de mises à jour, vous devez continuer à utiliser exclusivement cette méthode.

Attribut update_synch

Pour afficher la liste des tables dans lesquelles les personnalisations sont suivies, accédez à Définition du système > Dictionnaire et le filtre sur les attributs CONTIENT update_synch.

Avertissement :

N’ajoutez pas l’attribut update_synch à un enregistrement de dictionnaire. Lorsqu’il est mal utilisé, cet attribut peut entraîner des problèmes de performances majeurs ou entraîner l’indisponibilité de l’instance. Pour cette raison, l’attribut update_synch n’est pas accessible aux clients.

Une règle par défaut bloque l’utilisation de l’attribut update_synch sur une table pour laquelle il n’est pas prédéfini afin d’éviter les problèmes suivants :

• Certaines tables principales nécessitent une gestion spéciale des mises à jour, car elles représentent des informations sur plusieurs tables. Lorsque l’attribut update_synch est ajouté à ces tables, des enregistrements de mise à jour en double sont créés, provoquant des conflits majeurs difficiles à dépanner 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 les données, utilisez une importation d’instance à instance.

  Voir Jeux d’importation.

Gestionnaires 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

Avertissement :

Les sections de formulaire, les listes, les listes connexes, les listes de choix et les étiquettes de champ des gestionnaires spéciaux suppriment et réinsèrent des enregistrements. Cela peut entraîner des résultats inattendus et une perte de données s’il existe des champs faisant référence aux tables.

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 pour le choix que vous avez ajouté à la table u_activity. Les options de choix de la table de tâches ne sont pas affectées.

Avertissement :

N’utilisez pas de listes de choix volumineuses dans les ensembles de mises à jour. Cela conduit à des validations d’ensembles de mises à jour excessivement longues.

Modifications du dictionnaire

Habituellement, l’utilisation d’ensembles de mises à jour vous empêche d’appliquer des modifications de dictionnaire qui entraînent une perte de données. Les modifications bloquées du dictionnaire sont les suivantes :

• Suppression de tables
• Modification du type de données d’une colonne

Les ensembles de mises à jour ne suivent pas la suppression de 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 qui entraîne une perte de données et ajoute à la place un message de journal sur l’action. Les clients peuvent utiliser le journal pour effectuer des changements de type de données manuellement sur l’instance cible.

Remarque :

Les aperçus d’ensembles de mises à jour ne vérifient pas les problèmes d’incohérence de type, car l’instance cible ignore les changements entraînant une perte de données. En outre, l’utilisation d’ensembles de mises à jour pour supprimer une colonne d’une table peut entraîner une perte de données dans certaines circonstances. S’il y a des données dans la colonne sur l’instance cible, ces données sont supprimées, ainsi que la colonne elle-même, lorsque l’ensemble de mises à jour est validé. Un message d’avertissement s’affiche si vous tentez de valider un ensemble de mises à jour qui supprime une colonne. Le message indique qu’une ou plusieurs mises à jour de suppression entraînent la suppression des données et précise les mises à jour de suppression.

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. Ajouter des pages à l’ensemble de mises à jour actuel en les déchargeant.

Important :

La fonctionnalité des pages d’accueil, qui organisent les informations de votre instance pour raconter une story sur vos données, se trouve dans les tableaux de bord des nouvelles instances. Sur les instances mises à niveau avec Next Experience activé, les utilisateurs peuvent afficher les pages d’accueil existantes s’ils ont une URL directe, mais ils ne peuvent pas les créer ou les modifier. Les tableaux de bord réactifs et Centre d'analyse les tableaux de bord prennent le relais de la fonctionnalité de la page d’accueil.

Utilisez l’outil d’aide à la dépréciation de la page d’accueil pour convertir les pages d’accueil de votre instance en tableaux de bord réactifs.

Pour en savoir plus, consultez :

• Tableaux de bord dans le centre d’analyse.
• Utiliser des tableaux de bord réactifs.

Changements d’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’ensembles de mises à jour.