¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
MSDN Library
Este artículo se tradujo de forma manual. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original

Agregar o modificar campos de elementos de trabajo para admitir la creación de informes

Los campos de elemento de trabajo se utilizan para realizar el seguimiento de los datos de un tipo de elemento de trabajo, para definir los criterios de filtro de las consultas y para usarlos en los informes. Todos los campos, a excepción de los campos de sistema, que desea que aparezcan en un informe deben definirse en el archivo de definición para los tipos de elemento de trabajo de cuyo seguimiento se encargará el campo. Los campos de sistema se definen automáticamente para cada tipo de elemento de trabajo. Sin embargo, deben incluirse en el formulario de elemento de trabajo para que admitan la entrada de datos.

Para que se admita la generación de informes, puede agregar campos o cambiar los atributos de los campos existentes. Al agregar o modificar campos, debe aplicar una convención de nomenclatura sistemática para asegurarse de que ese datos se agrupan de forma lógica en las carpetas del cubo de SQL Server Analysis Services.

En este tema

Para obtener una lista de los campos sobre los que se puede crear un informe definidos en las plantillas de procesos predeterminadas, vea Referencia de campos para informe para Visual Studio ALM.

Antes de agregar o modificar un campo, tenga en cuenta los siguientes procedimientos recomendados:

  • Determine si puede usar un campo que ya esté definido en la colección de proyectos de equipo que contiene su equipo de proyecto. El uso de campos existentes es compatible con la generación de informes entre proyectos.

  • Determinar si puede usar un campo que ya esté definido en otra colección de proyectos de implementación de Visual Studio Team Foundation Server. El uso de campos existentes es compatible con la generación de informes entre proyectos.

  • No puede haber más de 1.024 campos en cada colección de proyectos ni más de 1.024 campos para informes distintos en todas las colecciones de proyectos de cada una de las implementaciones de Team Foundation Server. Los campos combinados computan como un único campo para informes.

  • Establezca un procedimiento estándar y revise el proceso para agregar y modificar los campos de las plantillas de procesos, los proyectos de equipo o las colecciones de proyectos.

  • Utilice una convención de nomenclatura sistemática al etiquetar los campos de informes. Al asignar los nombres de forma sistemática en todas las colecciones de proyectos de equipo de una implementación de Team Foundation Server, se asegura de que el esquema de cubo y el almacenamiento son más coherentes y fáciles de usar y evita que se produzcan conflictos de esquema en el almacenamiento. Para obtener más información, vea Resolver los conflictos del esquema que se producen en el almacén de datos.

    Puede asignar hasta cuatro atributos de etiqueta a un campo de elemento de trabajo:

    Nota Nota

    Los campos que se definen en las plantillas de procesos de Microsoft Solutions Framework no tienen asignado ningún nombre de informe ni ningún nombre de referencia de informe. De forma predeterminada, se utilizan los atributos de nombre y nombre de referencia.

    • name . Nombre descriptivo del campo que aparece en los menús desplegables de las consultas de elementos de trabajo. El nombre descriptivo debe ser único entre todos los campos que están definidos en un proyecto de equipo. Además, el nombre descriptivo puede ser diferente de la etiqueta que aparece y que está asignada al campo del formulario de elemento de trabajo. Para obtener más información, vea Referencia del elemento Control de XML.

    • refname . Etiqueta única que está asignada al campo y que lo distingue de todos los demás campos que están definidos en la colección de proyectos de equipo. El valor asignado a refname no se puede cambiar.

      Para consultar los requisitos y las restricciones de los nombres descriptivos y los nombres de referencia de los campos, vea Convenciones de nomenclatura para objetos de seguimiento de elementos de trabajo.

    • reportingname . Atributo opcional. Nombre que se usa para identificar un campo en los informes. Cuando no está definido de forma explícita, se usa el valor asignado a name.

    • reportingrefname . Atributo opcional. Etiqueta única que está asignada a un campo para informes y que lo distingue de todos los demás campos para informes definidos en todas las colecciones de proyectos de equipo. Cuando no está definido de forma explícita, se usa el valor asignado a refname. Para obtener información sobre las convenciones de nomenclatura recomendadas, vea Procedimientos recomendados para la asignación de nombres de referencia de informes, más adelante en este mismo tema.

      Nota Nota

      Los nombres de referencia de informes solo pueden verse en los informes de tabla dinámica o en el cubo de Analysis Services.

Debería utilizar un campo que ya esté definido si ese campo coincide con la información sobre la que desea realizar el seguimiento y crear los informes. Para utilizar un campo existente, siga estos pasos:

  • Identifique el campo que desea utilizar. Use el comando witadmin listfields para identificar los campos y los atributos que están definidos en todas las colecciones de proyectos. Para obtener más información, vea Mostrar los campos definidos en una colección de proyectos de equipo, más adelante en este mismo tema.

  • Determine si se trata de un campo para informes y si los atributos para informes satisfacen sus necesidades de generación de informes.

  • Si no es un campo para informes, use witadmin changefield para cambiar el atributo para informes en las colecciones de proyectos en las que se utiliza. Para obtener más información, vea Cambiar los atributos de informes de un campo, más adelante en este mismo tema.

  • En las colecciones de proyectos en las que no se está definido el campo, agréguelo en los archivos de definición XML para los tipos de elemento de trabajo que desee utilizar para realizar el seguimiento de los datos. Para obtener más información, vea Agregar campos para admitir informes, más adelante en este mismo tema.

Puede usar el comando witadmin listfields con los campos de lista y sus atributos. Puede mostrar un campo específico o todos los campos definidos en una colección de proyectos. El comando witadmin listfields tiene la siguiente sintaxis:

witadmin listfields /collection:CollectionURL /n:RefName 

Para obtener más información, vea Administrar campos de elementos de trabajo [witadmin].

Los campos para informes tienen establecido el atributo reportable con el valor Detail, Dimension o Measure. Los atributos siguientes determinan el modo en que los campos de elemento de trabajo se exportan y se procesan en las bases de datos de almacenamiento de datos:

  • reportingtype . Para incluir un campo en los informes, debe asignar uno de los siguientes valores al atributo reportable:

    • Asigne Detail para exportar el campo a la base de datos de almacenamiento relacional pero no al cubo. Tal y como se muestra en el ejemplo siguiente, solo debe usar el tipo Detail en los campos Integer, Double, String o DateTime:

      <FIELD refname="MyCorp.Summary" name="Summary" type="String" reportable="detail">
      
    • Asigne Dimension para exportar el campo a la base de datos de almacenamiento relacional y al cubo. Tal y como se muestra en el ejemplo siguiente, solo debe usar Dimension en los campos Integer, String, o DateTime. Este valor resulta útil si desea incluir campos que se usan para filtrar informes (por ejemplo, campos que tienen listas de valores válidos).

      <FIELD refname="MyCorp.Category" name="Category" type="String" reportable="dimension">
      
    • Asigne Measure para admitir el procesamiento de valores precalculados en el cubo. Utilice el tipo Measure solamente para campos de tipo Integer y Double.

      Si asigna Measure como valor de reportingtype, debe asignar sum como valor de formula, tal y como se muestra en el ejemplo siguiente:

      <FIELD refname="MyCorp.Cost" name="Cost" type="Integer" reportable="measure" formula="sum">
      
  • reportingrefname . Puede asignar un nombre de referencia diferente a un campo que esté marcado como campo para informes. Si no se especifica ningún valor, se usa el valor asignado al atributo refname.

    Puede usar este atributo para combinar o diferenciar los campos incluidos en los informes. Para combinar dos campos que tienen nombres de referencia distintos y están definidos en colecciones de proyectos diferentes, asigne el mismo valor de reportingrefname a ambos. Para distinguir dos campos con el mismo nombre de referencia pero que están definidos en colecciones de proyectos diferentes, asigne un valor de reportingrefname diferente a cada campo.

    Siempre que sea posible, deberá combinar los campos para minimizar el número de campos del almacén de datos y para mantener los campos para informes dentro del límite máximo, que es de 1024. Puede generar informes entre grupos con campos combinados.

  • reportingname . Puede asignar una etiqueta diferente a un campo que se use para mostrar los datos de los informes. Si no se especifica ningún valor, se usará el nombre descriptivo asignado en el atributo name. El valor asignado a reportingname aparece en el cubo. El valor asignado a reportingrefname no aparece.

    Nota importante Importante

    Debe seguir los procedimientos recomendados para etiquetar los campos de informes de forma que estén agrupados juntos en los informes de tabla dinámica. Para obtener más información, vea Procedimientos recomendados para asignar nombres de referencia de informes.

Puede convertir un campo existente en un campo para informes cambiando las asignaciones de los atributos del campo que se han definido en una colección de proyectos. Los campos existentes están definidos en una o varias definiciones de tipos de elemento de trabajo. También puede cambiar todos los atributos que determinan el modo en que se procesa un campo en los almacenes de datos.

Puede utilizar la siguiente secuencia de pasos para cambiar la asignación de atributos de un campo:

  1. Puede usar el comando witadmin changefield para cambiar una asignación de atributos de un campo. Puede ejecutar este comando en una colección de proyectos de equipo. Utilice la sintaxis siguiente:

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

    Para convertir un campo existente en un campo para informes, cambie el valor de reportingtype. Por ejemplo, para conseguir que el campo AW.Common.TeamPriority esté disponible para filtrar informes, asígnele el valor Dimension:

    witadmin changefield /collection:http://AdventureWorksServer:8080/AWTeam/Collection1 /n:AW.Common.TeamPriority /reportingtype:dimension 
    

    Para obtener más información, vea Administrar campos de elementos de trabajo [witadmin].

  2. (Opcional) Si tiene más de una colección de proyectos, quizás quiera hacer los mismos cambios que los del campo de elemento de trabajo definido en esa colección. Para evitar los conflictos de esquema en la exportación y procesamiento de los datos a las bases de datos de almacenamiento de datos, debe asignar los mismos valores a estos atributos en todas las colecciones:

    • Tipo de campo (el valor de este campo no se puede cambiar en un campo existente).

    • Tipo de informe.

    • Nombre de informe.

    Para obtener más información, vea Resolver los conflictos del esquema que se producen en el almacén de datos.

  3. Una vez realizados todos los cambios en los campos de elemento de trabajo que desea utilizar en los informes, debe procesar las bases de datos de almacenamiento de datos. Puede utilizar los servicios Web ProcessAnalysis y ProcessWarehouse, que están disponibles en WarehouseControlWebService.

    Con este paso, tendrá la seguridad de que los usuarios de los informes no verán ningún error cuando se modifiquen los atributos de los campos.

    Para obtener más información, vea Administrar campos de elementos de trabajo [witadmin].

Puede agregar campos a la definición de uno o varios tipos de elemento de trabajo. Al agregar el campo, deberá agregar la misma definición de elementos de campo en todos los tipos de elementos de trabajo para los que el campo va a admitir informes. Si desea que el campo admita informes entre proyectos, el campo deberá agregarse a todos los tipos de elemento de trabajo de todos los proyectos de equipo sobre los que se van a crear informes.

Para obtener más información, vea Definir y modificar campos de elementos de trabajo.

Puede comprobar los cambios realizados en los atributos de campo para informes procesando el almacenamiento de datos a petición y comprobando los informes para asegurarse de que están actualizados. O puede esperar hasta que los trabajos de los adaptadores de almacén de datos se ejecuten. De forma predeterminada, la base de datos relacional se procesa cada pocos minutos. Sin embargo, el cubo se procesa de forma predeterminada cada dos horas.

Nota Nota

Para obtener más información sobre WarehouseControlWebService, vea cómo procesar manualmente el almacén de datos y el cubo de Analysis Services para Team Foundation Server.

  1. Para procesar el almacenamiento de datos relacional a petición, use ProcessWarehouse WarehouseControlWebService.

  2. Para procesar el cubo a petición, use ProcessAnalysisDatabase WarehouseControlWebService.

  3. Compruebe que los informes están actualizados. Puede consultar un informe a través del panel o del Administrador de informes. Para obtener más información, vea Paneles del portal del proyecto o Informes (SQL Server Reporting Services).

En el caso de los nombres de referencia de informes, le conviene asignar etiquetas para que pueda localizar fácilmente los campos en el informe de tabla dinámica y el cubo. Para ello, puede aplicar convenciones de nomenclatura sistemáticas, de modo que los campos se agrupen con una secuencia lógica. Además, si la agrupación de los campos no resulta útil, puede cambiar el nombre de referencia de informe de un campo.

Resulta cada vez más importante aplicar una convención de nomenclatura sistemática, ya que todos los datos susceptibles de incluirse en un informe de todos los proyectos de equipo definidos en cada una de las colecciones de proyecto se escriben en un único almacén de datos relacional. Los datos de dicho almacén se procesan y escriben posteriormente en el cubo. Como los campos de elemento de trabajo se administran de forma distinta en cada colección de proyectos, es posible que se apliquen etiquetas diferentes, lo que puede generar un conjunto de datos mal organizado a la hora de crear informes.

Los campos de elemento de trabajo que tienen un tipo de dimensión para informes se corresponden con los atributos de dimensión del cubo. Los atributos de dimensión se organizan en las carpetas en función del nombre de referencia del informe asignado en la plantilla de procesos o en la definición de tipos de elemento de trabajo. A continuación se indican los tipos de correspondencias:

  • Los campos que tienen el prefijo "System" son intrínsecos y aparecen directamente bajo la dimensión Work Item con el prefijo "Work Item".

  • Los demás campos se sitúan en las carpetas cuyo nombre se corresponde con los prefijos de los nombres de referencia. Por ejemplo, los campos que tienen el prefijo "Microsoft.VSTS.Common" aparecen en la carpeta etiquetada como "Microsoft VSTS Common."

Tal y como se muestra en la ilustración siguiente, se agrega una carpeta para cada grupo de campos que comparten un prefijo común:

Estructura de carpetas en cubo de datos OLAP

En la tabla siguiente se muestran los campos cuyos nombres de referencia comienza con "System" y aparecen en el informe de tabla dinámica con el prefijo "Work Item". Estos campos se incluyen directamente en la dimensión Work Item. Todos los demás campos se sitúan en las carpetas cuyo nombre se corresponde con los prefijos de los nombres de referencia.

Nota Nota

Las implementaciones que no utilizan la versión Enterprise de SQL Server Analysis Services no tienen acceso a las características de traducción incluidas en esa versión. En estas implementaciones, los campos se identifican mediante el nombre de referencia completo del cubo, donde '.' se sustituye por '_' (por ejemplo, "System_Id" y "System_Title").

Nombre en el informe de tabla dinámica y el cubo

Nombre de referencia

Tipo de datos

Work Item.Area Path

System.AreaPath

TreeType

Work Item.Assigned To

System.AssignedTo

String

Work Item.Changed By

System.ChangedBy

String

Work Item.Changed Date

System.ChangedDate

DateTime

Work Item.Created By

System.Created By

String

Work Item.Created Date

System.CreatedDate

DateTime

Work Item.ID

System.Id

Integer

Work Item.Iteration Path

System.IterationPath

TreeType

Work Item.Previous State

System.PreviousState

String

Work Item.Reason

System.Reason

String

Work Item.Rev

System.Rev

Integer

Work Item.State

System.State

String

Work Item.Title

System.Title

String

Work Item.Work Item Type

System.WorkItemType

String

En la tabla siguiente se muestran los campos que aparecen en el informe de tabla dinámica de la carpeta con la etiqueta "Microsoft.VSTS.Common" bajo la dimensión Work Item. Estos campos tienen nombres de referencia que comienzan por "Microsoft.VSTS.Common."

Nombre en el informe de tabla dinámica y el cubo

Nombre de referencia

Tipo de datos

Work Item.Activated By

Microsoft.VSTS.Common.ActivatedBy

String

Work Item.Activated Date

Microsoft.VSTS.Common.ActivatedDate

DateTime

Work Item.Closed By

Microsoft.VSTS.Common.ClosedBy

String

Work Item.Closed Date

Microsoft.VSTS.Common.ClosedDate

DateTime

Work Item.Created By

Microsoft.VSTS.Common.CreatedBy

String

Work Item.Created Date

Microsoft.VSTS.Common.CreatedDate

DateTime

Work Item.Resolved By

Microsoft.VSTS.Common.ResolvedBy

String

Work Item.Resolved Date

Microsoft.VSTS.Common.ResolvedDate

DateTime

Work Item.Resolved Reason

Microsoft.VSTS.Common.ResolvedReason

String

Work Item.Priority

Microsoft.VSTS.Common.Priority

Integer

Work Item.Severity

Microsoft.VSTS.Common.Severity

String

Work Item.Stack Rank

Microsoft.VSTS.Common.StackRank

Double

Mostrar:
© 2015 Microsoft