Identificación y evaluación de las opciones de diseño

Hay al menos dos opciones de diseño para una posible solución, como se describe a continuación:

Opción 1: página de datos con origen REST Connector

• El control de autocompletar genera una página de datos a nivel de nodo que, a su vez, genera un conector REST.
• La página de datos a nivel del nodo se actualiza una vez por semana.

Opción 2: página de datos con origen de datos local

• Un programador de trabajos ejecuta las llamadas del conector REST y conserva los datos recuperados en una tabla local.
• El control de autocompletar genera una página de datos a nivel de nodo que, a su vez, genera una definición de reportes que consulta los datos persistentes localmente.
• La página de datos de nivel de nodo puede actualizarse con frecuencia (por ejemplo, una vez al día) porque sus consultas de datos son locales.
• El Programador de trabajos está configurado para ejecutarse una vez por semana en un solo nodo.

La opción 1 funciona y es fácil de implementar. La opción 2 también funciona, pero es más compleja de implementar en comparación con la opción 1.

La opción 1 requiere que cada nodo WebTier se actualice llamando al conector REST muy lento, lo que podría causar una experiencia de usuario desagradable en la carga inicial. Sin embargo, con la opción 2, el conector REST muy lento solo se llama una vez y se ejecuta en un nodo de procesamiento en segundo plano. Los usuarios de WebTier de la opción 2 nunca ven este retraso inicial porque el nodo de WebTier con el que se comunica su navegador tiene un DP de nivel de nodo que ha consultado datos locales en vivo de carga rápida.

Estas dos opciones de diseño ofrecen un equilibrio entre el tiempo de implementación y mantenimiento, o una experiencia de usuario mejorada. La opción recomendada depende de qué factores son más importantes. La opción 1 puede ser aceptable y una opción más deseable debido a su simplicidad. La opción 2 garantiza una experiencia de usuario inicial mejorada, que tal vez sea preferible.

Opción 3:

La opción 3 es similar a la opción 1, pero aprovecha el método de carga de página de datos para solicitar que la página de datos se cargue de forma asíncrona en algún punto anterior del proceso, para dar tiempo suficiente para completar la carga antes de que se necesiten los datos. En el peor de los casos, esto sucede al iniciar sesión. La carga preventiva se puede lograr a través de una figura inteligente o similar.

Esta opción proporciona los siguientes resultados:

Una especie de procesamiento en segundo plano (usa un solicitante en segundo plano).
•  Gestión óptima de la memoria (tantas páginas de datos de alcance de nodo como la opción 1).
•  No es necesario conservar los datos remotos en Pega.
•  Hace un viaje al almacén de datos remoto por nodo; la opción 2 hace un viaje por grupo

Opción 4: 

Una variante de la opción 2, pero ejecuta el Programador de trabajos en todos los nodos para que dispare automáticamente la carga de la página de datos del alcance del nodo a la misma hora cada semana para cada nodo (quizás después de vaciar cualquier dato, la página todavía se considera nueva, lo que se puede realizar con una actividad). 

Esta opción proporciona los siguientes resultados:

•    Requiere el mismo número de viajes remotos que la opción 1.
•    Elimina la necesidad de conservar una copia local.
•    Proporciona la misma experiencia de usuario que la opción 2 (suponiendo que las páginas de datos se carguen antes de que un usuario necesite los datos).

Para las opciones 3 y 4, el diseño deseado para una solución es una compensación entre el tiempo de implementación y mantenimiento, con poca diferencia en la experiencia del usuario entre las dos opciones a medida que se resuelve el problema de carga inicial. Otros factores contribuyentes que pueden influir en la evaluación son la posible reutilización de reglas y la evolución futura de la aplicación.