Risolvere conflitti di schema che si verificano nel data warehouse

I conflitti di schema si verificano quando un set di attributi per i campi segnalabili differisce fra le raccolte di progetti team. Quando si verifica un conflitto di schema, i campi che non sono in conflitto vengono elaborati come al solito, ma ai campi in conflitto vengono assegnati valori NULL finché non vengono risolti i conflitti e successivamente vengono elaborati nel modo consueto. Inoltre, il sistema genera un evento di notifica per ogni conflitto rilevato. Sottoscrivendo l'evento, è possibile ricevere avvisi in caso di conflitti di schema di eventuali progetti team definiti per una raccolta. È necessario correggere ogni conflitto di schema per sbloccare l'elaborazione dei dati associati per il warehouse e consentire la visualizzazione di dati correnti nei rapporti associati.

Tutti i dati segnalabili da tutti i progetti team definiti in tutte le raccolte di progetti per una distribuzione di Visual Studio Team Foundation Server vengono scritti in un solo data warehouse relazionale. I dati vengono quindi elaborati da tale warehouse e scritti nel cubo. La raccolta di dati in un solo data warehouse supporta la creazione di rapporti fra gli insiemi di progetti team. Poiché tuttavia i campi vengono gestiti distintamente per ciascuna raccolta di progetti, possono verificarsi conflitti di schema quando definizioni differenti vengono assegnate a uno o più attributi di un campo a cui è assegnato lo stesso nome di riferimento di creazione rapporti.

In questo argomento

• Messaggi di errore che avvisano dei conflitti di schema

• Origini dei conflitti di schema

• Risoluzione di conflitti di schema

• Verifica della risoluzione di conflitti di schema

Messaggi di errore che avvisano dei conflitti di schema

Quando si verifica un conflitto di schema, verrà visualizzato un messaggio di errore nei percorsi seguenti:

• Il log eventi per il server a livello applicazione.

  Nota

  Team Foundation Server registra un messaggio di errore nel log eventi ogni giorno finché non viene risolto il conflitto di dati.

• Un rapporto fornito con i modelli di processo MSF e visualizzabile tramite Gestione rapporti.

• Un dashboard fornito con i modelli di processo MSF e visualizzabile tramite il portale del progetto.

  Nota

  È possibile determinare la data dell'aggiornamento più recente di un rapporto o di un dashboard, se si individua il timestamp Data ultimo aggiornamento visualizzato nell'angolo inferiore destro di ogni rapporto e dashboard.Il timestamp corrisponde all'ora più recente in cui ogni processo dell'adattatore del warehouse per cui è pianificato il completamento, per ogni raccolta di progetti, ha completato correttamente l'elaborazione.Il calcolo del timestamp include i processi dell'adattatore personalizzati e ignora i processi dell'adattatore per cui l'esecuzione del servizio Web di controllo warehouse è bloccata.

  Se un conflitto di schema blocca l'inserimento dei dati nel data warehouse per un rapporto, non verrà aggiornato il timestamp per il rapporto.

Oltre ai messaggi precedenti, è possibile ottenere ulteriori informazioni utilizzando l'operazione GetProcessingStatus del servizio Web di controllo warehouse. Per ulteriori informazioni, vedere Elaborare manualmente il data warehouse e il Cube Analysis Services per Team Foundation Server.

Origini dei conflitti di schema

I conflitti di schema si verificano quando un amministratore di progetto esegue una delle azioni riportate di seguito:

• Aggiunge un campo segnalabile a un tipo di elemento di lavoro in una raccolta di progetti e gli attributi assegnati a tale campo non corrispondono a quelli presenti nelle altre raccolte di progetti.

• Modifica un attributo assegnato a un campo elemento di lavoro utilizzato in più di una raccolta di progetti, sebbene tali modifiche creino conflitti con le assegnazioni nelle altre raccolte.

  Nota

  Un amministratore di progetto può evitare gli errori descritti nell'elenco precedente solo rivedendo le assegnazioni degli attributi per i campi definiti in più raccolte di progetti in una distribuzione.

Si verificano errori quando un campo dispone dello stesso nome di riferimento o dello stesso nome di riferimento di creazione rapporti in più raccolte di progetti e uno o più degli attributi seguenti per tale campo non corrispondono in due o più raccolte:

• name: nome descrittivo del campo visualizzato come un'opzione quando si crea una query elemento di lavoro.

• reportingname: nome visualizzato nei rapporti. Se non viene specificato alcun valore, verrà utilizzato il valore assegnato all'attributo name.

• reportable/reportingtype: definisce se i dati estratti dal campo sono disponibili per l'inclusione nei rapporti, e in caso positivo, il tipo segnalabile (ad esempio, None, Detail, Dimension o Measure).

  Nota

  L'elemento FIELD utilizza l'attributo reportable e il comando witadmin changefield utilizza l'attributo reportingtype.Questi attributi definiscono le stesse informazioni.

• type: tipo di dati accettato dal campo (ad esempio, Integer, HTML, String, Double o DateTime).

Nella tabella riportata di seguito vengono forniti esempi di assegnazioni di attributi che provocano conflitti di schema. In questi esempi, il nome di riferimento del rapporto e il nome del rapporto non sono assegnati.

Attribute	Raccolta di progetti 1	Raccolta di progetti 2	Conflitto di schema
Type	String	Integer	I tipi di dati non corrispondono.
Nome rapporto	Attività	Attività comune	I nomi dei rapporti non corrispondono.
Segnalabile	Dettagli	Dimensione	I tipi dei rapporti non corrispondono.

Risoluzione di conflitti di schema

È possibile rivedere il log eventi sul server a livello applicazione per ottenere ulteriori informazioni sul campo che sta provocando un conflitto di schema. Dopo avere determinato quale campo o quali campi stanno provocando il conflitto, è necessario effettuare i passaggi riportati di seguito:

1. Rivedere gli attributi assegnati al campo in tutte le raccolte di progetti. È inoltre possibile utilizzare il comando witadmin listfields con la seguente sintassi:

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

   Per ulteriori informazioni, vedere Gestire campi di elementi di lavoro [witadmin].

2. Determinare in quale delle modalità riportate di seguito si desidera risolvere il conflitto:

   • Modificare l'attributo per il campo in una raccolta di progetti in modo da renderlo corrispondente alle assegnazioni effettuate nelle raccolte di progetti. È necessario effettuare questa azione quando i team utilizzano il campo negli stessi modi e in rapporti simili o per la creazione di rapporti fra progetti.

   • Riassegnare l'etichetta al nome di riferimento del rapporto relativo al campo in conflitto. È necessario effettuare questa azione quando i campi vengono utilizzati in modi diversi oppure è necessario mantenere un campo diverso. In questo caso, il campo non viene utilizzato da team che operano nelle raccolte di progetti diversi per la creazione di rapporti fra progetti.

     Per ulteriori informazioni, vedere Aggiungere o modificare campi di elementi di lavoro per supportare la creazione di rapporti.

   • Contrassegnare un campo come non segnalabile per una o più raccolte. È necessario effettuare questa azione quando il campo non viene utilizzato per rapporti su tali raccolte di progetti.

   • Eliminare il campo dalla raccolta di progetti team. È necessario effettuare questa azione se il campo non viene utilizzato da nessun progetto team o rapporto.

     Nota

     Se si rimuove un campo utilizzato in un rapporto, tale rapporto non verrà più visualizzato correttamente.

3. Modificare l'attributo assegnato a un campo, in base alle decisioni prese nel passaggio precedente. È inoltre possibile utilizzare il comando witadmin changefield con la seguente sintassi:

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

4. Per eliminare un campo da una raccolta di progetti, è possibile utilizzare il comando witadmin deletefield con la seguente sintassi:

   witadmin deletefield /collection:CollectionURL /n:RefName
   

   Importante

   Se si elimina un campo in modo permanente, verranno rimossi sia il campo sia tutti i dati che archivia dall'archivio dati.

Verifica della risoluzione di conflitti di schema

È possibile verificare la corretta risoluzione dei conflitti di schema elaborando i data warehouse su richiesta e quindi controllando i rapporti per verificare che siano stati aggiornati. Oppure è possibile attendere fino all'esecuzione dei processi dell'adattatore del data warehouse, in base alla rispettiva pianificazione predefinita. Per impostazione predefinita, il database relazionale viene elaborato ogni pochi minuti. Tuttavia, per impostazione predefinita, il cubo di Analysis Services viene elaborato ogni due ore.

Nota

Per ulteriori informazioni sul servizio Web di controllo warehouse, vedere Elaborare manualmente il data warehouse TFS e il cubo di Analysis Service.

1. Elaborare il data warehouse relazionale su richiesta utilizzando l'operazione ProcessWarehouse del WarehouseControlService.

2. Elaborare il cubo su richiesta utilizzando l'operazione ProcessAnalysisDatabase del WarehouseControlService.

3. Aprire un dashboard o Gestione rapporti e verificare che i rapporti siano stati aggiornati. Per ulteriori informazioni, vedere Dashboard o Rapporti (SQL Server Reporting Services).

Se i messaggi di errore persistono, è possibile ottenere ulteriori informazioni sul conflitto di dati e sugli adattatori bloccati interessati eseguendo l'operazione GetProcessingStatus di WarehouseControlService.

Vedere anche

Riferimenti

Gestire campi di elementi di lavoro [witadmin]

Concetti

Aggiungere o modificare campi di elementi di lavoro per supportare la creazione di rapporti

Creare, personalizzare e gestire rapporti per Visual Studio ALM

Altre risorse

Elaborare manualmente il data warehouse TFS e il cubo di Analysis Service