Mejores prácticas al crear un ticket de soporte

La creación de una incidencia de soporte técnico eficaz de Power BI o Fabric requiere proporcionar información específica para ayudar a Microsoft a solucionar el problema rápidamente. En este artículo se proporcionan procedimientos recomendados e información clave para incluir al enviar solicitudes de soporte técnico, lo que le ayuda a obtener una resolución más rápida. La información específica necesaria depende de su problema y no todas las sugerencias se aplican a cada caso.

Información que se va a proporcionar a Microsoft

Dependiendo de su problema específico, es posible que se le pida que proporcione la siguiente información.

1. Dirección URL de la página del explorador donde experimenta el problema. La dirección URL proporciona información sobre dónde (área de trabajo) experimenta el problema y el tipo de característica o el identificador.

2. Ubicación del problema (servicio Power BI Desktop/ Power BI/ ambos) Esta información siempre es relevante para una solicitud de servicio. Si se produce un error en un proceso en el servicio Power BI, pero se realiza correctamente en Desktop, o viceversa, esta información proporciona información útil a Microsoft en cuanto a la posible causa del problema. Otro ejemplo sería donde el mismo código M funciona en un conjunto de datos, pero se produce un error en un flujo de datos. Además de estos dos ejemplos, hay muchos escenarios en los que es posible solucionar el problema mediante la identificación exacta de dónde se produce y dónde no.

3. Códigos de error

   Si se genera un código de error cuando algo va mal, realice una copia de ese código de error. Microsoft guarda información detallada sobre todos los códigos de error y usa esta información para diagnosticar el problema. Es poco probable que el código de error resuelva el problema por sí solo, pero acelera significativamente el proceso de solución de problemas.

   Sugerencia

   Use el botón Copiar para recuperar el código. No envíe una captura de pantalla. Los códigos de error son largos (normalmente 30 caracteres) y la transcribir manualmente desde una captura de pantalla aumenta la posibilidad de que se produzca un error.

4. Los orígenes de datos y el modo de almacenamiento que se usa la información del origen de datos siempre son relevantes para una solicitud de servicio. Cada origen de datos tiene ciertos problemas solo relevantes para sí mismos. Cuando se utilizan varias fuentes, use el método de prueba y error para identificar qué fuentes contribuyen al problema.

   Power BI también se comporta de forma diferente cuando se usan distintos modos de almacenamiento. Las tres opciones principales del modo de almacenamiento son:

   • Importación
   • Direct Query
   • Conexión dinámica

   También hay dos casos especiales:

   • Almacenamiento en modos mixtos (modelos compuestos)
   • Direct Query para conjuntos de datos PBI y Analysis Services

   Para identificar los orígenes de datos que se usan en Power BI Desktop, seleccione Configuración de orígenesde datos> de datos en el archivo actual. En el servicio Power BI, vaya a la página de configuración en la sección de las Credenciales del origen de datos o mediante la vista de linaje. Para acceder a esta información, seleccione "Ver linaje" o cambie la vista del área de trabajo de la lista al linaje.

   Sugerencia

   Para comprender el modo de almacenamiento que se usa, póngase en contacto con el desarrollador del informe o revise el archivo PBIX.

5. ID de capacidad

   El identificador de capacidad permite a Microsoft conocer el tipo de capacidad que se usa (por ejemplo, Premium). Solo el administrador de capacidad puede buscar el identificador de capacidad. Si es el administrador de capacidad, abra el portal de administración y seleccione Configuración> de capacidadPower BI Premium y seleccione el nombre de la capacidad. El identificador de capacidad es la última parte de la dirección URL.

   https://app.powerbi.com/admin-portal/capacities/ XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

   Como alternativa, el administrador de capacidad puede usar esta API REST para recuperar el identificador de capacidad.

6. Identificador del conjunto de datos

   Si el problema afecta a un conjunto de datos, el identificador ayuda a Microsoft a identificar el conjunto de datos correcto e investigar los procesos que se ejecutan en ese conjunto de datos. Para buscar el identificador del conjunto de datos, vaya al área de trabajo que contiene el conjunto de datos y abra la configuración del conjunto de datos. El identificador del conjunto de datos es la última parte de la dirección URL (datasets/dataset-id).

   https://app.powerbi.com/groups/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/settings/datasets/ XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

7. Copia del archivo PBIX (solo consultas de importación)

   Al experimentar un problema con un modelo de importación, tener el archivo PBIX ayuda al ingeniero de soporte técnico a reproducir el problema y acelerar la solución de problemas. Si el PBIX contiene información confidencial, asegúrese de compartir una versión anónima.

   Importante

   Asegúrese de confirmar con las partes pertinentes de su organización antes de compartir información potencialmente confidencial.

8. Registros de puerta de enlace

   Los registros de puertas de enlace son necesarios al solucionar cualquier problema de puerta de enlace o red. Para analizar el rendimiento de la puerta de enlace usted mismo, use la plantilla Supervisión del rendimiento de la puerta de enlace. Para obtener más información, consulte Exportación de registros para una incidencia de soporte técnico.

9. Información de diagnóstico

   Siga los pasos de la recopilación de diagnósticos de Power BI Desktop para ver y recopilar información de diagnóstico.

10. Flujo de datos JSON

    Esta opción es útil cuando se usa un flujo de datos. Para exportar el código JSON y compartirlo con el ingeniero de soporte técnico, vaya al área de trabajo, seleccione el elemento de flujo de datos y elija Export.json.

    

Preguntas más frecuentes

Además de la información estándar descrita anteriormente, la siguiente información ayuda al ingeniero de soporte técnico a solucionar el problema.

¿El problema solo se produce en una capacidad específica?

¿Se resuelve el problema al cambiar a otra capacidad o a otra capacidad compartida? A veces, los problemas son específicos de determinados entornos.

¿Afecta el problema a todos los usuarios?

¿El problema en toda la empresa afecta solo a un número determinado de personas o solo a una persona?

¿Se trata de un problema nuevo para algo que estaba trabajando anteriormente?

¿Se inició el error sin realizar ningún cambio en el lado del usuario o se desencadenó por algún tipo de cambio o una nueva implementación? Identificar el punto de interrupción ayuda a reducir la posible causa principal.

¿El problema es más estrecho o más amplio que inicialmente experimentado?

¿El problema afecta a todos, algunos o solo a una "cosa"? Por ejemplo, si el problema está relacionado con las API, ¿funcionan otras API? Si se trata de un problema de exportación, ¿todos los informes se ven afectados? Si se trata de un problema de capacidad, ¿todas las capacidades se comportan de la misma manera? Si un informe no se actualiza y contiene varios orígenes de datos, ¿se ha probado cada origen por separado?

¿Ya ha intentado realizar los pasos de solución de problemas?

Esta información acelera la resolución del problema evitando la repetición. Sin embargo, en determinadas circunstancias, es posible que el ingeniero de soporte técnico quiera repetir los pasos que ha realizado.

¿Puede replicar el problema en un formulario más sencillo?

A veces no puede compartir información confidencial con Microsoft. Intente replicar el problema mediante una versión simplificada del problema y proporcione pasos de reproducción confiables al ingeniero de soporte técnico.