Cómo inspeccionar fácilmente peticiones OData
OData Si bien en el título hablo de peticiones OData, en realidad estoy refiriéndome a todas las peticiones a APIs REST que realice una aplicación web. Pero como trabajo sobretodo con UI5, los enfocaremos a servicios OData.
¿Qué es OData?
OData u Open Data Protocol, es un protocolo abierto que permite la creación y consumo de APIs REST.
Los desarrolladores web estamos acostumbrados a trabajar con las herramientas de desarrollo de los navegadores web, especialmente en Chrome. Pero el resto de compañeros de equipo no frontenders también deberían tener un mínimo de conocimientos de estas herramientas. La más importante para ellos probablemente sea el inspector de llamadas.
En este artículo vamos a hacer un tour rápido por la sección Network de las dev tools de Chrome. Está especialmente pensado para introducir a los compañeros funcionales del equipo e incluso abapers. Así podrán ser autónomos para inspeccionar qué llamadas se están haciendo y si los datos que trae la llamada son los mismos que el frontend está pintando. También veremos el apartado OData Requests de la extensión para Chrome UI5 Inspector.
Peticiones batch
Antes de empezar, quiero hacer un apunte sobre las peticiones en batch. Inicialmente, en UI5 las peticiones se hacían directamente al servicio sin batch. Era asi porque el ODataModel V1 no tenia esta opción activada por defecto. El cambio vino con el ODataModel V2 de UI5, en el cual si que viene activada la opción por defecto.
Empaquetar las peticiones en llamadas batch tiene su razón de ser. El navegador puede gestionar un máximo de peticiones paralelas a diferentes recursos. Ese máximo va a depender del navegador, en la siguiente tabla podemos ver el límite de conexiones paralelas por dominio:
| Navegador | Conexiones por dominio |
|---|---|
| Chrome | 6 |
| Edge | 6 |
| Internet Explorer 11 | 13 |
| Firefox | 6 |
| Opera | 6 |
| Safari | 6 |
Este límite de conexiones incluye tanto peticiones a API como a recursos estáticos. Con recursos estáticos me refiero a ficheros html, js, css, etc.
Si la aplicación solo hace unas pocas llamadas a servicios, no supone un gran problema. Pero si se hacen muchas peticiones… Necesitamos un mecanismo para empaquetar las máximas peticiones a APIs en una sola y así reducir el total de conexiones. Ese mecanismo es utilizar batchs.
Todo esto lo explico porque inspeccionar estas llamadas es algo más tedioso. En el listado de peticiones no veremos la llamada a primera vista. Por suerte, la extensión UI5 Inspector tiene un apartado específico que lo facilita mucho en la mayoría de casos. En seguida entenderás a que me refiero.
Inspector de llamadas
Lo primero que debemos hacer es abrir nuestra aplicación UI5 en Chrome. Paralelamente, abriremos las herramientas de desarrollo pulsando la tecla F12. Si por lo que fuera no se abre, puedes acceder desde el menú (tres puntos en vertical en la parte superior derecha) —> Más herramientas —> Herramientas para desarrolladores. Tiene esta pinta:
La pestaña que nos interesa es Network. Sin entrar en detalle, estas dos pestañas también pueden ser útiles:
- Elements: para visualizar el árbol del DOM y trastear con CSS
- Console: podemos visualizar los logs de la aplicación y utilizarlo como playground javascript
Bien, accedemos a la pestaña Network.
Como puedes ver, tengo marcado el flag Disable cache, así nos aseguramos de que el navegador siempre tiene la última versión de todos los recursos. No te preocupes, una vez cierres las herramientas de desarrollo volverá a funcionar en el modo habitual. También he activado la barra de filtrado (embudo azul), desde donde podemos buscar o filtrar peticiones.
A continuación tenemos un gráfico temporal en el que podemos visualizar las peticiones que se han ido haciendo. Se puede apreciar un máximo de 6 filas paralelas, que es el límite del que hemos hablado antes.
En el listado de llamadas de la captura podemos ver las peticiones típicas de una aplicación UI5. Empieza con el core de UI5 sap-ui-core.js, que en un entorno productivo puede aparecer dos veces debido al CacheBuster. Sigue descargando las librerías necesarias de UI5, en este caso las librerias sap.ui.core y sap.m. Continúa descargando los ficheros de idioma, css, etc.
Las columnas son configurables, las mas “importantes” son: el método de la petición, el estado de la respuesta, el tipo de petición, el tamaño descargado y el tiempo que ha tardado. Además tenemos visión de la “cascada de llamadas” o Waterfall.
El tiempo de la petición se desglosa en distintas fases. Si mantienes el cursor encima del gráfico de tiempo de cada petición, podrás ver el detalle exacto.
En el pie de la ventana disponemos del resumen total. Es un acumulado que a cada petición se va actualizando. Nos muestra el total de peticiones a recursos hechas, el tamaño transferido, el tiempo total hasta la última petición, cuanto ha tardado el DOM en parsearse inicialmente y el tiempo que ha tardado en hacer la carga inicial de la aplicación.
Servicios OData
Para comprobar si un servicio OData está en uso, podemos buscar por el término metadata en el listado de peticiones. El metadata es un fichero descriptor del servicio en el que estan definidos todas las entidades, navegaciones, etc. disponibles:
En ese listado podemos ver que se han cargado 6 servicios OData. Haciendo clic en cada fila podemos ver el detalle clasificado en diferentes apartados. La pestaña Headers nos dará información de la URL, con la que podemos identificar que servicio és. También podemos ver el método de la petición, en este caso un GET, así como el estado de la respuesta 200 OK:
En esta pestaña también podemos ver las cabeceras HTTP, tanto de la petición de la aplicación como de la respuesta del servicio. En la pestaña Preview visualizaremos la respuesta del servicio. En el caso del metadata, veremos un XML en el que podremos ir desplegando las etiquetas para facilitar la lectura.
Peticiones normales
Una petición normal a un servicio, es decir, sin batch, aparecerá en el listado de llamadas por el nombre del endpoint como tal. A continuación tenemos una petición al servicio de la captura anterior, llamado ZN_PATIENT_CORE_SRV. La url completa de cada petición la podremos ver en la pestaña Headers, con la que identificaremos a qué servicio esta atacando la petición:
Al ser una petición GET, podemos ver los parámetros en la propia URL. En este caso, tenemos un GET a la entidad ET_DESPLEGABLESSet filtrada por APLICACIO = 'MLH' y TIPUS ='SEU'.
Igual que con la respuesta del metadata, podemos visualizar la respuesta de forma amigable en la pestaña Preview:
Como vemos, este tipo de peticiones son muy sencillas de inspeccionar.
Peticiones batch
En el caso de que las peticiones sean en batch, veremos algo parecido a esto:
Debes tener en cuenta que cada línia donde encontramos un $batch, contiene como mínimo una petición. Además, puedes observar que la petición batch utiliza el método POST. Toda la información de cada petición se enviará en el Payload de esa petición. Si accedemos a la pestaña Payload de la petición batch, podremos obtener la información de que peticiones incorpora:
En este caso, tenemos empaquetadas más de una petición GET a ET_DESPLEGABLESSet. En el caso de existir un Payload, como seria el caso de los create (POST) o update (PUT o MERGE), tambien lo visualizaremos aquí. Para consultar las respuestas de cada petición navegaremos a la pestaña Preview:
Como ves, aquí puede ser difícil de leer los datos. Por suerte, el formato de la respuesta es un JSON. Las puedes ver en las líneas 11 y 22 de la captura. Ten en cuenta que hay una correspondencia con pestaña Payload, por lo que la primera petición será la primera respuesta, etc. Para poder visualizar mejor los datos, copiaremos la línea entera de la respuesta. Ahora cambiaremos a la pestaña Console y lo pegaremos al lado del icono >. A continuación, pulsamos Enter. Debajo de lo que acabamos de introducir, obtendremos el mismo “visor” que teníamos en las peticiones normales, en el que puedes desplegar el objeto para consultarlo más fácilmente:
Otra opción es pulsar la tecla Esc. Si no funciona, puedes ir al menú de las herramientas de desarrollo (tres puntos verticales en la esquina superior derecha) —> Show console drawer. Con esto abriremos la Consola en la parte inferior de la ventana sin cerrar el listado de peticiones.
UI5 Inspector
Si bien esta sería la forma “normal” de inspeccionar llamadas, en UI5 disponemos de una extensión para desarrolladores llamada UI5 Inspector. Una vez instalada, aparecerá una opción nueva llamada UI5 en las herramientas de desarrollo. Una vez dentro, tenemos cuatro pestañas. La pestaña OData Request nos ayudará a inspeccionar la gran mayoría de peticiones OData. Digo gran mayoría porque de vez en cuando no es capaz de pintar algún function import ☠️ u alguna que otra llamada.
La primera diferencia con respecto a la pestaña Network es que las llamadas batch las visualizamos como un agrupador de peticiones. Así es muchísimo más sencillo inspeccionar las peticiones que contiene:
Y la segunda diferencia es que podemos ver tanto los datos de la petición como los datos de la respuesta. Pero esta vez lo haremos de una forma más amigable, sin tener que hacer uso de la consola:
Como ves, es muy fácil inspeccionar las peticiones OData. Si eres programador UI5, puedes compartir este artículo con el resto de tu equipo para que dejen de preguntarte qué llamada se está haciendo en algún momento determinado 😂. Y si no lo eres, no veo ningún impedimento para que también lo compartas 🤪.