Project Online 2013: sólo 45 campos de texto para el servicio de oData

Si se comprueban los límites y restricciones de software para Project Online 2013 se descubrirá el siguiente cuadro respecto a los campos ofrecidos por el servicio de oData para reporting:

“For reporting, there are also limits to how many single-value custom fields, of each type, get stored in the reporting schema.

Project custom fields Timesheet custom fields Task and Resource custom fields, combined
45 text fields 45 text fields 45 text fields
150 lookup tables 150 lookup tables 150 lookup tables
150 of all other custom field types (cost, date, duration, number, flag) 150 of all other custom field types (cost, date, duration, number, flag) 150 of all other custom field types (cost, date, duration, number, flag)

Note    While you can create more custom fields than these limits, only this many custom fields will be included in the OData feed. You are not able to choose which of the fields are included.”

Vaya, 45 campos personalizados de tipo texto disponibles para los informes…¿suficientes o pocos? Depende de la personalización del proyecto, normalmente es un número razonable.

A efectos prácticos se permiten más de cuarenta y cinco campos de texto y este límite probablemente irá aumentando con el tiempo. También es verdad que el número de campos de texto soportados por oData depende del número de campos personalizados (Enterprise Custom Fields) de tipo multilínea utilizados: cuántos más campos de este tipo se implementen para el proyecto menos campos de texto de cualquier tipo serán devueltos.

No obstante, este límite en proyectos muy grandes y con un alto grado de personalización es bastante molesto. Obliga a pensar con atención los campos a utilizar (especialmente los necesarios para los informes) y deja poco margen a la improvisación. Cuando se supera el límite que marca el sistema, los campos de texto que se creen después simplemente no están disponibles para el servicio oData. De hecho, se podrá encontrar el siguiente error en la cola de Project del tipo “Reporting (Custom Field Metadata Sync)”:

QueueCustomFieldMetadataSyncError

Si se pulsa en el enlace “Click to view the error details” aparecerá, entre otros, el siguiente error:

Reporting message processor failed:

  • ReportingCustomFieldMetadataChangeMessageFailed (24002) – Unable to add the custom field: ‘xxxx’.Max capacity reached in the Column Pool Tables. MSP_Epm_AddCustomField failed.. Details: id=’24002′ name=’ReportingCustomFieldMetadataChangeMessageFailed’ uid=’GUID-Del-Campo’

Cada vez que se crea un campo de texto nuevo, Project Online ejecuta un trabajo en la cola tratando de añadir al mismo en las tablas del sistema que almacenan los campos que se devuelven por la fuente oData. Como se ha llegado al máximo de su capacidad, se produce un error y el campo no se inserta. Por lo tanto, no se añade a los campos disponibles para los informes.

Entonces, ¿qué hacer si se quieren añadir nuevos campos cuando se ha alcanzado este límite? Y esto, por muy cuidadoso que se haya sido, no es demasiado extraño: cambios a última hora, modificaciones por parte de los stakeholders cuando revisan los informes…en fin, cualquier situación o imprevisto que suele surgir en un proyecto.

Para dar una respuesta veamos primero cómo funciona el servicio de reporting. Está claro que existe algún tipo de restricción global con los campos personalizados de tipo texto a devolver por la fuente oData, probablemente por temas de rendimiento. Por simplificar, digamos que existe una especie de “buffer” para los campos de texto y que tiene un tamaño determinado.

Por lo tanto, el servicio devolverá más campos de tipo texto si la mayoría son de texto simple, que ocupan menos espacio que los multilínea.

¿Y qué campos son devueltos por la fuente oData? Pues el comportamiento es el de una pila: a medida que se van creando campos de tipo texto para el proyecto estos se van añadiendo a la pila hasta que se llega al límite de su capacidad. Una vez alcanzado este punto los nuevos campos de texto que se vayan creando para el proyecto no estarán disponibles en oData, simplemente no aparecerán en el modelo.

¿Y qué se puede hacer si necesitamos consumir otros campos diferentes o campos nuevos para los informes? En ese caso, habrá que “hacer hueco” en la pila de campos y eliminar (sí, ELIMINAR) campos de los que se pueda prescindir para dar cabida a tantos campos de texto nuevos como sean necesarios. Tras esto, se irían creando los nuevos campos de texto personalizados en Project hasta completar de nuevo la pila.

Así pues, los pasos a seguir para el planeamiento de los campos de texto (dentro de lo posible según las condiciones de cada proyecto) serían los siguientes:

  1. Planificar los campos de proyecto personalizados de tipo texto necesarios para el negocio
  2. Discriminar cuáles de estos serían necesarios para los informes. Hay que tener en cuenta que este es el mayor problema ya que las decisiones respecto al reporting se suelen dejar para la fase final del proyecto.
  3. Crear los campos de texto en Project empezando por los necesarios para los informes y acabando por los campos multilínea que no vayan a ser utilizados en los mismos.

Actualización 06/12/2015

El 3 de Diciembre del 2015 Microsoft actualizó los límites para los campos personalizados disponibles mediante REST para los informes. Puedes ver mis comentarios en esta entrada.


 

Anuncios

2 comentarios sobre “Project Online 2013: sólo 45 campos de texto para el servicio de oData

Los comentarios están cerrados.