Obtención de datos Real Time en Power Pages

Obtención de datos en Power Pages

Si alguna vez has trabajado con Power Pages, como bien sabrás, hay “dos” formas de obtener datos vía estándar (ahora entenderemos por qué esas comillas), y por otro lado otras dos formas vía desarrollo.

Las formas que hay estándar son los formularios básicos y avanzados (basicform, advancedform), en los que se puede leer los datos de un registro vía formulario, y la otra es visualizar los datos vía lista de entidades (entitylist). Para poder customizar los estándar, simplemente tienes que elegir desde qué entidad vas a mostrar los datos y para poder visualizarlos eliges el formulario o bien la vista que quieras mostrar.

En cambio, para vía desarrollo podemos realizarlo de las siguientes formas, o bien vía fetchxml o bien mediante la API de Power Pages.

El fetchxml se obtiene mediante liquid, y se hace en el background, por lo que es super positivo para no dejar trazas en la network por si necesitamos un poco más de seguridad para que los usuarios no puedan capturar estas trazas y meterse en el medio. El código quedaría algo así:

{% fetchxml MyQuery %}
<fetch>
...
</fetch>
{% endfetchxml %}

En el caso de que lo hagas con la API de Power Pages Sería algo así:

var responseJson = await fetch([Portal URI]/_api/accounts?$select=name&$filter=accountid eq '{{request.params.id}}')
var response = await responseJson.json()

Caché

Una vez que hemos entendido las formas de las que se pueden obtener los datos vamos a enteder un poco la caché del Portal. Según la página de learn dice lo siguiente: “Para mejorar la escalabilidad y el rendimiento, los sitios web de Power Pages almacenan en caché los datos que se consultan desde Microsoft Dataverse. Este almacenamiento en caché se realiza en el servidor de aplicaciones para todos los datos comerciales y metadatos del sitio web y es diferente del almacenamiento en caché de recursos estáticos basado en el navegador o en la red de entrega de contenido.” … “Esta caché de datos de configuración para cualquier tabla se actualiza automáticamente cuando se cambia cualquier registro. La actualización automática de caché tiene un acuerdo de nivel de servicio de 15 minutos. Cualquier cambio realizado para un registro de configuración estaría automáticamente disponible en el sitio web en 15 minutos.”

Esto que quiere decir, que la caché del Portal dura 15 minutos, y eso significa que los datos no nos vienen en real time, si no que son “near real time”.

A continuación os voy a poner unos ejemplos para que veais cuando si y cuando no se refresca el Portal y comentaremos los resultados:

  1. 1. Se crea un registro a través de un entityform. Aparece automáticamente en la entitylist de los registros.--> La caché se refresca automáticamente.
  2. 2. Se crea un registro a través de la API. No aparece automáticamente en la entitylist de los registros. --> La caché NO se refresca automáticamente.
  3. 3. Se crea un registro a través de un entityform. No aparece automáticamente en un liquid fetchxml ó API Get --> La caché NO se refresca automáticamente.
  4. 4. Se crea un registro a través de la API. No aparece automáticamente en un liquid fetchxml ó API Get --> La caché NO se refresca automáticamente.
Como podeis comprobar, la caché funciona de forma particular y no se puede borrar de forma API o de forma manual. (Bueno, la única forma manual es ser Administrador y poder ir a /_services/about y borrar la caché, o bien desde el editor de diseño, pero no creo que queráis tener una persona 24/7 borrando la caché.)

Expliquemos un poquito la caché en la recolección de registros:

  1. 1. Se hace la petición de obtener datos.
  2. 2. Esa petición se manda via API a donde el sistema tiene alojado nuestro Power Pages.
  3. 3. El sistema primero comprueba en su caché si ha hecho esa MISMA petición anteriormente. (Fijaos que pongo MISMA en mayúscula, es superimportante para después)
  4. 4. Si esa petición está dentro de la caché, se obtienen los datos y se devuelven, es decir, actua nuestra caché de 15min.
  5. 5. En el caso de que esa petición no esté, se recogen los datos de D365 y se guarda la peticion y los datos en la caché.
Estos 5 pasos de arriba actuan cuando se muestran los datos en cualquiera de sus formas de entityform, entitylist, api o fetchxml.

¿Pero entonces qué sucedió en el paso? “Se crea un registro a través de un entityform. Aparece automáticamente en la entitylist de los registros.—> La caché se refresca automáticamente.”

Pues bien, cuando se crea un registro mediante entityform, la caché se limpia para que se pueda mostrar dentro de un entitylist.

Solución

Pero vamos al grano, ¿cómo podemos solucionar en un fetchxml o en un API Get el poder mostrar datos en Real Time?

Si recordáis, explicando la caché, en el tercer paso pusimos: “El sistema primero comprueba en su caché si ha hecho esa MISMA petición anteriormente.”

Ahí lo tenemos, necesitamos crear una petición diferente para poder obtener los datos en Real Time. Pero… ¿cómo podemos hacer esa petición?

Pues bien, lo más lógico es que se ponga siempre una fecha que sea siempre dinámica, y gracias a Liquid vamos a poder obtenerla.

En un fetch:

{% fetchxml MyRequest %}

<fetch>
...
      <condition attribute="createdon" operator="on-or-before" value="{{now | date_to_iso8601 }}" />
</fetch>

{% endfetchxml %}

Lo que estamos haciendo es recoger el fetch con los registros cuyo created on sea antes que ahora mismo, es decir, esa condición se va a cumplir siempre. Pero si veis, la parte de “{{now | date_to_iso8601 }}” nos va a devolver siempre un dato diferente, porque esto nos devuelve: “2023-09-17T17:20:46Z”. Por tanto, la query siempre va a ser diferente y nunca será la misma, por tanto estamos haciendo un bypass a la caché y siempre vamos a obtener datos en “real time”.

Lo mismo sucedería con Javascript, si se pone la query de ’’ pero con Javascript, vas a obtener los datos en “real time”.

Resumen

Espero que estoy os haya ayudado a poder obtener los datos en real, sin necesidad de esperar esos 15 minutos de caché, ya que esto puede ser tedioso sobre todo si necesitais recoger datos de pago o cualquier dato que necesitéis que se haya creado en D365 y lo necesiteís ya.

Acordaos de realizar una query diferente a cada momento, ya os he puesto el truco de: ’’

Pero si tenéis algún otro también lo podéis compartir para que pueda editar este blog y así ayudar a más personas.

Siempre podéis contactarme a través de me@victorsolaya.com, cualquier duda o sugerencia.

Únete a la newsletter