Partager via

Résolution de conflits de schéma qui se produisent dans l'entrepôt de données

  • Article

Des conflits de schéma se produisent lorsqu'un ensemble d'attributs pour les champs signalables diffère à travers des collections de projets d'équipe. Lorsqu'un conflit de schéma se produit, les données associées à ce schéma ne peuvent pas se déplacer dans l'entrepôt de données, ni dans le cube de données SQL Server Analysis Services. Vous devez corriger tous les conflits de schéma pour débloquer le traitement des données associées pour l'entrepôt et permettre aux rapports associés d'afficher des données actuelles.

Important

Vous pouvez débloquer l'entrepôt de données en cas de conflits de schéma en installant Service Pack 1 (SP1) pour Visual Studio Team Foundation Server 2010. Une fois SP1 installé, les champs qui ne sont pas en conflit sont traités normalement. Des valeurs Null sont assignées aux champs au conflit jusqu'à ce que le problème soit résolu, ensuite procédez normalement.

De plus, le système génère un événement de notification pour chaque conflit qu'il détecte. En s'abonnant à l'événement, vous pouvez maintenant recevoir des alertes lorsque les conflits de schéma se produisent pour un projet d'équipe défini pour une collection.

Toutes les données signalables issues de tous les projets d'équipe définis dans toutes les collections de projets relatives à un déploiement de Visual Studio Team Foundation Server sont écrites dans un seul et même entrepôt de données relationnelles. Les données de cet entrepôt sont ensuite traitées et écrites vers le cube. La collecte de données dans un seul et même entrepôt de données prend en charge la création de rapports entre collections de projets d'équipe. Toutefois, étant donné que les champs sont gérés distinctement pour chaque collection de projets, des conflits de schéma peuvent se produire lorsque différentes définitions sont assignées à un ou plusieurs attributs d'un champ auquel le même nom de référence de création de rapports a été assigné.

Dans cette rubrique

  • Messages d'erreur qui vous alertent des conflits de schéma

  • Sources de conflits de schéma

  • Résoudre des conflits de schéma

  • Vérifier que des conflits de schéma sont résolus

Messages d'erreur qui vous alertent des conflits de schéma

Lorsqu'un conflit de schéma se produit, un message d'erreur s'affiche dans les emplacements suivants :

  • Le journal des événements du serveur de couche Application.

    Notes

    Team Foundation Server enregistre chaque jour un message d'erreur vers le journal des événements jusqu'à ce que le conflit de données soit résolu.

  • Un rapport fourni avec les modèles de processus MSF et que vous affichez via le Gestionnaire de rapports.

  • Un tableau de bord fourni avec les modèles de processus MSF et que vous affichez via le portail du projet.

    Notes

    Vous pouvez déterminer de quand date la dernière mise à jour d'un rapport ou tableau de bord en accédant à l'horodatage Date de la dernière mise à jour, qui s'affiche dans l'angle inférieur droit de chaque rapport et tableau de bord. L'horodatage correspond au moment le plus récent auquel chaque travail de l'adaptateur d'entrepôt planifié, pour chaque collection de projets, s'est achevé avec succès. Le calcul d'horodatage inclut les travaux de l'adaptateur personnalisés et ignore les travaux de l'adaptateur dont l'exécution est bloquée par le service Web de contrôle d'entrepôt.

    Si un conflit de schéma empêche l'entrée de certaines données dans l'entrepôt de données pour un rapport, l'horodatage du rapport ne sera pas mis à jour.

En plus des messages précédents, vous pouvez obtenir davantage d'informations en utilisant l'opération GetProcessingStatus du service Web de contrôle d'entrepôt. Pour plus d'informations, consultez Traiter manuellement l'entrepôt de données et le cube Analysis Services pour Team Foundation Server.

Sources de conflits de schéma

Les conflits de schéma se produisent lorsqu'un administrateur de projet exécute l'une des actions suivantes :

  • Il ajoute un champ signalable à un type d'élément de travail d'une collection de projets, et les attributs assignés à ce champ ne correspondent pas à ceux d'autres collections de projets.

  • Il modifie un attribut assigné à un champ d'élément de travail utilisé dans plusieurs collections de projets, bien que ces modifications soient en conflit avec les assignations d'autres collections.

    Notes

    Un administrateur de projet peut éviter les erreurs de la liste précédente uniquement en examinant les assignations d'attributs pour les champs définis à travers plusieurs collections de projets dans un déploiement.

Des erreurs surviennent lorsqu'un champ a le même nom de référence ou le même nom de référence de création de rapports dans plusieurs collections de projets et lorsqu'un ou plusieurs des attributs suivants pour ce champ ne correspondent pas dans deux collections ou plus :

  • name : nom convivial du champ, qui s'affiche comme option lorsque vous créez une requête d'élément de travail.

  • reportingname : nom qui apparaît dans les rapports. Si vous ne spécifiez pas de valeur, la valeur assignée à l'attribut name est utilisée.

  • reportable/reportingtype : détermine si les données du champ sont disponibles pour être incluses dans les rapports, et le cas échéant, le type signalable (par exemple, None, Detail, Dimension ou Measure).

    Notes

    L'élément FIELD utilisait l'attribut reportable, et la commande witadmin changefield utilise l'attribut reportingtype. Ces attributs définissent les mêmes informations.

  • type : type des données que le champ accepte (par exemple, Integer, HTML, String, Double ou DateTime).

Le tableau suivant fournit des exemples d'assignations d'attributs qui provoqueront des conflits de schéma. Dans ces exemples, le nom de référence de création de rapports et le nom de création de rapports ne sont pas assignés.

Attribut

Collection de projets 1

Collection de projets 2

Conflit de schéma

Type

Chaîne

Entier

Les types de données ne correspondent pas.

ReportingName

Activité

Activité commune

Les noms de création de rapports ne correspondent pas.

Signalable

Détail

Dimension

Les types de création de rapports ne correspondent pas.

Résoudre des conflits de schéma

Vous pouvez examiner le journal des événements sur le serveur de couche Application pour obtenir plus d'informations sur le champ qui provoque un conflit de schéma. Après avoir déterminé quel(s) champ(s) provoque(nt) le conflit, vous devez suivre ces étapes :

  1. Examinez les attributs assignés au champ dans toutes les collections de projets. Vous pouvez utiliser la commande witadmin listfields, qui a la syntaxe suivante :

    witadmin listfields /collection:CollectionURL /n:RefName [/unused]

    Pour plus d'informations, consultez Gestion des champs d'éléments de travail (witadmin).

  2. Déterminez de quelle façon vous souhaitez résoudre le conflit :

    • Modifier l'attribut pour le champ dans une collection de projets pour établir la correspondance aux assignations faites dans d'autres collections de projets. Vous devez prendre cette mesure lorsque les équipes utilisent le champ des mêmes façons dans des rapports semblables ou pour la création de rapports interprojets.

    • Recréer une étiquette pour le nom de référence de création de rapports du champ conflictuel. Vous devez prendre cette mesure lorsque les champs sont utilisés de différentes façons ou vous devez gérer un champ différent. Dans ce cas, le champ n'est pas utilisé par les équipes qui travaillent dans des collections de projets différentes pour la création de rapports interprojets.

      Pour plus d'informations, consultez Ajout et modification de champs d'éléments de travail pour prendre en charge la création de rapports.

    • Marquer un champ comme non signalable pour une ou plusieurs collections. Vous devez prendre cette mesure lorsque le champ n'est pas utilisé pour les rapports concernant ces collections de projets.

    • Supprimer le champ de la collection de projets d'équipe. Vous devez prendre cette mesure si le champ n'est utilisé par aucun projet d'équipe ou rapport.

      Notes

      Si vous supprimez un champ utilisé dans un rapport, le rapport ne s'affichera plus correctement.

  3. Modifier l'attribut assigné à un champ, selon les décisions que vous avez prises à l'étape précédente. Vous pouvez utiliser la commande witadmin changefield, qui a la syntaxe suivante :

    witadmin changefield /collection:CollectionURL /n:RefName [/name:NewName] [/syncnamechanges:true | false] [/reportingname:ReportingName] [/reportingrefname:ReportingRefName] [/reportingtype:Type] [/reportingformula:Formula] [/noprompt]

  4. Pour supprimer un champ d'une collection de projets, vous pouvez utiliser la commande witadmin deletefield, qui a la syntaxe suivante :

    witadmin deletefield /collection:CollectionURL /n:RefName

    Important

    Si vous supprimez un champ définitivement, vous supprimez le champ et toutes les données qu'il stocke du stockage des données.

Vérifier que des conflits de schéma sont résolus

Vous pouvez vérifier que les conflits de schéma ont été résolus en traitant les entrepôts de données à la demande, puis en vérifiant si les rapports ont été mis à jour. Sinon, vous pouvez attendre l'exécution des travaux de l'adaptateur d'entrepôt, d'après leur planification par défaut. Par défaut, la base de données relationnelle est traitée à quelques minutes d'intervalle. En revanche, le cube Analysis Services est traité toutes les deux heures par défaut.

Notes

Pour plus d'informations sur le service Web de contrôle d'entrepôt, consultez Traiter manuellement l'entrepôt de données et le cube Analysis Services pour Team Foundation Server.

  1. Traitez l'entrepôt de données relationnelles à la demande à l'aide de l'opération ProcessWarehouse du WarehouseControlService.

  2. Traitez le cube à la demande à l'aide de l'opération ProcessAnalysisDatabase du WarehouseControlService.

  3. Ouvrez un tableau de bord ou Gestionnaire de rapports et vérifiez que les rapports sont mis à jour. Pour plus d'informations, consultez Tableaux de bord (Agile) ou Rapports (Agile).

Si des messages d'erreur continuent d'apparaître, vous pouvez obtenir plus d'informations sur les conflits de données et les adaptateurs bloqués affectés en exécutant l'opération GetProcessingStatus du WarehouseControlService.

Voir aussi

Référence

Gestion des champs d'éléments de travail (witadmin)

Concepts

Création, personnalisation et gestion de rapports pour Visual Studio ALM

Autres ressources

Ajout et modification de champs d'éléments de travail pour prendre en charge la création de rapports

Traiter manuellement l'entrepôt de données et le cube Analysis Services pour Team Foundation Server