Personnalisations suivies par des ensembles de mises à jour

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 6 minutes de lecture
  • 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 les conditions suivantes :
    • Lorsque la table possède 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 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 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 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.

    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 à la développer et à la 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 cette méthode exclusivement.

    update_synch attribut

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

    Avertissement :
    N’ajoutez pas l’attribut 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. De ce fait, 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, 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 les instances peut entraîner des problèmes de performances, car il n’est pas prévu à cet effet. Pour migrer les données, utilisez une importation d’instance à instance.

      Reportez-vous à la section 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 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 gestionnaires spéciaux des sections de formulaire, des listes, des listes connexes, des listes de choix et des étiquettes de champs suppriment et réinsèrent des enregistrements. Cela peut entraîner des résultats inattendus et une perte de données si des champs font 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 sous la forme d’un 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 de u_activity. Les options de choix dans la table de tâches ne sont pas affectées.

    Avertissement :
    N’utilisez pas de grandes listes de choix dans les ensembles de mises à jour. Cela conduit à des validations d’ensembles de mises à jour trop longues.

    Modifications du dictionnaire

    En général, l’utilisation d’ensembles de mises à jour vous empêche d’appliquer des changements de dictionnaire qui entraînent une perte de données. Les changements de dictionnaire bloqués comprennent :
    • Suppression de tables
    • Modification d’un type de données de colonne

    Les ensembles de mises à jour ne suivent pas 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.

    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 qui entraînent 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. Si la colonne contient des données 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 il spécifie quelles mises à jour de suppression sont concernées.

    Pages d’accueil et pages de contenu

    Les pages d’accueil et les pages de contenu ne sont pas ajoutées par défaut aux ensembles de mises à jour. Ajoutez des pages à l’ensemble de mises à jour actuel en les déchargeant.

    Important :

    La fonctionnalité des pages d’accueil, qui organise les informations de votre instance pour présenter une histoire sur vos données, se retrouve 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 et Centre d'analyse tableaux de bord réactifs prennent en charge 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.

    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.