Identificar y resolver problemas comunes

Completado

Dos formas comunes en las que puede usar Monitor como parte de su proceso habitual de creación de aplicaciones son:

  • Reactiva: conoce un problema y necesita ayuda para identificar la causa raíz. Por ejemplo, si alguien que está usando su aplicación notificó la existencia de un error, puede usar Monitor para identificar la causa. Por lo general, tendrá una buena idea de dónde se produce un error en una aplicación y puede usar Monitor para observar eventos para una acción específica en la aplicación.

  • Proactiva: como parte de su proceso normal de creación de aplicaciones, antes de lanzar su aplicación a los usuarios, puede usar Monitor para identificar posibles problemas. Al realizar pruebas proactivas, la mayoría de las veces ejecutará la aplicación mientras Monitor captura eventos. Al revisar el registro de eventos, puede buscar tiempos de respuesta prolongados, otras anomalías o errores. Los problemas que se identifican de manera proactiva en la etapa de compilación harán que los usuarios vean menos problemas en producción y darán como resultado la percepción de una aplicación de mayor calidad.

En el resto de este módulo se examinará cómo identificar y resolver problemas habituales mediante Monitor.

Independientemente del enfoque que utilice, le recomendamos que comience la captura con un registro de eventos vacío. Puede realizar esta tarea seleccionando el botón Borrar datos en Monitor antes de iniciar sus acciones en la aplicación que está probando.

¡![Captura de pantalla que muestra el botón Borrar datos resaltado]

Usar nombres de control significativos

Los nombres de control que se incluyen en los eventos capturados son correlaciones clave del evento con respecto a dónde se produjo en su aplicación. El uso de nombres adecuados para los controles puede facilitarle el trabajo con los datos del evento. Considere el siguiente ejemplo en el que se comparan los nombres generados de forma predeterminada con otros más significativos y recomendados. Como puede ver, sería más sencillo identificar qué control estaba involucrado en la actividad cuando se usan nombres significativos.

¡![Captura de pantalla que muestra nombres genéricos frente a nombres significativos y cómo pueden hacer que los datos sean más útiles]

Buscar eventos similares

Cuando trabaja para identificar el origen de un problema, una tarea habitual que puede llevar a cabo es encontrar otras ocurrencias que puedan estar relacionadas. Monitor le facilita dicha tarea al ofrecer dos enfoques para filtrar los datos de eventos que se han capturado. Puede usar la opción de filtro global para buscar en todas las columnas de los datos del registro de eventos. Puede encontrar el filtro global en la esquina superior derecha de Monitor.

![Captura de pantalla de la opción Filtrar en Monitor]

El uso de este filtro resulta útil cuando no tiene un campo específico en el que está buscando los datos. Por ejemplo, quiere buscar en todas las columnas algo que coincida con un patrón, como el nombre de un control o una acción del conector.

Cada columna también ofrece la posibilidad de filtrar y brindar más opciones de filtrado específicas por tipo de datos. Puede activar el filtro de columna seleccionando la flecha situada junto al nombre de cada columna y, a continuación, seleccionando Filtrar por.

![Captura de pantalla que muestra la opción Filtrar por]

También puede aplicar la opción Filtrar por en varias columnas al mismo tiempo, de manera que puede crear criterios que incluyen más de una columna con los valores solicitados. Cuando tiene filtros en varias columnas, cada evento debe cumplir los requisitos para que se muestren todos los filtros de columna.

El uso de las funcionalidades de filtrar puede resultar útil si ha capturado numerosos eventos y desea aislar problemas específicos.

Identificar y resolver errores

Normalmente, los errores se encuentran porque presentaron un mensaje de error al usuario o desencadenaron alguna lógica de control de errores en la aplicación. Monitor es útil en estos casos porque tiene información más detallada sobre el error específico cuando el error afecta a un conector. A medida que el control de errores de la aplicación se vuelve más sofisticado, el error también puede ser absorbido por la lógica de control de errores, y la única forma de verlo es observando los datos capturados. Esta situación es un buen ejemplo de cómo la supervisión proactiva de las aplicaciones puede detectar errores que no esperaba o no sabía que se estaban produciendo.

La manera más sencilla de identificar un error en el registro de datos del evento es examinar la columna de resultados que contiene la palabra Error en lugar de Correcto.

![Captura de pantalla en la que se muestra el error en el registro de eventos]

Otra forma de identificar errores es a partir de un indicador de círculo rojo que se situará al principio de las líneas que contienen errores.

Con frecuencia, la columna de estado contendrá un código de estado HTTP detallado que le brindará una categoría de error más específica. La información resultante suelen contener un resumen de texto del código de estado. Para obtener más información sobre los diferentes valores de código de estado HTTP, consulte Enumeración de HttpStatusCode.

Para trabajar en la resolución de errores, la mejor información procederá de las pestañas Fórmula, Solicitud y Respuesta en el área Detalles, que se muestra cuando selecciona uno de los errores. La fórmula resulta útil para correlacionar lo que causó el error en la aplicación, pero la solicitud y la respuesta proporcionarán detalles subyacentes.

La causa más habitual de errores son datos incorrectos o datos que faltan cuando se utiliza un conector. Puede revisar la solicitud para determinar qué se envió al conector que provocó el error.

Aunque el contenido de la solicitud puede variar de un conector a otro, los dos factores más comunes que se deben buscar en la solicitud son la URL y el cuerpo.

¡![Captura de pantalla en la que se muestra la pestaña Solicitud, resaltando la URL y la propiedad del cuerpo]

En la mayoría de los casos, para las acciones del conector que hacen cambios en los datos, la información más valiosa se encontrará en el cuerpo. Normalmente, buscará datos incorrectos o ausentes de lo que esperaba que se enviaran al conector para la solicitud. La comparación del cuerpo de la solicitud con la documentación de la API de acción del conector también puede poner de manifiesto problemas.

En el caso de las acciones de tipo de consulta, la URL suele contener otra información de utilidad en la cadena de consulta.

La pestaña Respuesta contiene los datos que se devuelven desde el conector. Aunque cada conector puede tener una estructura de respuesta definida de forma única, se pueden encontrar muchos errores al examinar las sugerencias del escaneo del mensaje de respuesta. En el siguiente ejemplo, una regla de negocio bloqueó la solicitud para crear un registro de contacto de prueba y se incluyó un mensaje de error en la respuesta.

¡![Captura de pantalla en la que se resalta el mensaje de error en los datos de respuesta].

Aunque el contenido de la solicitud y la respuesta puede parecer demasiado complejo, si hace un análisis rápido de este, a veces pueden aparecer sugerencias que le ayudarán a resolver el problema. Si las sugerencias no son de utilidad, puede proporcionar estos detalles al desarrollador del conector, o el servicio de asistencia técnica puede ayudarle a comprender cómo estaba utilizando el conector.

Identificar y resolver acciones lentas

Aunque es posible que tenga un usuario que le indique qué es específicamente lento en su aplicación, la columna Duración es otro buen indicador. Puede usar un filtro en la columna Duración después de ejecutar la aplicación para poder centrarse solo en las acciones lentas. El valor de la duración se registra en milisegundos (ms). En el siguiente ejemplo, buscaría cualquier entrada del registro de eventos que haya tardado más de un segundo.

¡![Captura de pantalla en la que se muestra el filtro de columna para una duración superior a un segundo]

Si su aplicación lleva a cabo numerosos procesos de carga de datos durante el inicio, debe asegurarse de que el monitor se esté ejecutando y que haya seleccionado la lógica Ejecutar OnStart.

![Captura de pantalla que muestra la opción Ejecutar OnStart en Power Apps Studio]

La forma más habitual de resolver acciones lentas es reducir la cantidad de trabajo que realiza la acción o la cantidad de datos que devuelve la acción. Al analizar la solicitud, es posible que pueda identificar si sus criterios se aprobaron correctamente y si podría proporcionar más criterios para reducir el trabajo. Asimismo, puede examinar la respuesta para identificar si se devuelven más datos de los que necesita. Algunos conectores pueden identificar y devolver automáticamente los datos adecuados, mientras que otros requieren que especifique opciones en la solicitud para devolver solo los datos pertinentes.

Identificar y resolver problemas de delegación

Los problemas de delegación se producen cuando redacta una consulta que contiene criterios que el servicio del conector no puede resolver por completo e implementar de forma remota. Cuando ocurre esta situación, la aplicación envía solo una parte de los criterios al conector para devolver más registros de los necesarios y posprocesar los resultados del conector en la aplicación. El número de registros que se pueden devolver y posprocesar se encuentra limitado por la configuración de una aplicación y su valor predeterminado es 500. Si el conector tiene disponible más registros aptos de los que especifica el límite, los resultados se truncarán y es posible que tenga resultados inexactos en la aplicación.

En muchos casos, el Comprobador de aplicaciones de Power Apps Studio identificará el problema de delegación y podrá resolverlo sin necesidad de Monitor. Monitor también marcará estos eventos y proporcionará más detalles. Si no puede identificar el problema con la información que proporcionó el Comprobador de aplicaciones, revise la solicitud que se envió al conector. Concretamente, debe revisar los datos de los criterios de consulta que faltan, lo que puede ayudarle a entender lo que no puede enviar al conector como criterios delegables.

Con frecuencia, puede resolver problemas de delegación reescribiendo la fórmula para que no incluya cálculos de datos dinámicos en los criterios que se envían al conector. Los distintos conectores admiten diferentes funciones para la delegación y es posible que descubra que lo que funcionó para un conector no funciona para otro. Puede usar Monitor para verificar que la fórmula devolverá los resultados correctos.

En esta unidad se revisaron algunos errores habituales que podría intentar resolver con la herramienta Monitor. Monitor debe ser su herramienta de referencia cuando necesite información más detallada acerca de lo que está sucediendo en su aplicación. Al ejecutar Monitor periódicamente, podrá identificar con rapidez comportamientos anormales y problemas en la aplicación.