Crear estructuras de datos de integración en profundidad

Al crear microaplicaciones, es posible que necesite acceder a tablas del sistema de registro de destino que están separadas por más de dos niveles de la tabla principal. A pesar de las limitaciones actuales en la integración HTTP, es posible encontrar una solución al respecto.

En este artículo se proporciona información sobre cómo acceder a las tablas del sistema de registro de destino cuando surge este caso de uso. Esta solución no es directa, pero, si sigue la descripción que se muestra a continuación, puede crear estructuras de datos más profundas.

Caso de uso

Desea crear una microaplicación que permita a un usuario aprobar una solicitud en ServiceNow. Para utilizar esta microaplicación, el usuario debe poder:

• recibir y abrir una notificación
• recibir una página con una lista de elementos para aprobar
• ver los detalles de cada elemento
• ver quién envió la solicitud
• aprobar estas solicitudes

Los detalles necesarios para crear una acción o página para cada uno de estos pasos se almacenan en tablas obtenidas a través de dispositivos de punto final. Sin embargo, la tabla con los datos para el aprobador (la tabla de datos que contiene la lista de elementos) está separada por más de dos tablas de otras ubicaciones de datos.

Requisitos previos de la solución

Para crear esta solución, debe usar una combinación de encadenamiento de llamadas de API secundarias y combinación de tablas descritas en Configurar la integración.

Requisitos previos:

• Ha definido su caso de uso de extremo a extremo con la idea de qué debe ejecutarse en su microaplicación y qué información ve y acciona el usuario final.
• Ha creado el dispositivo de punto final para devolver los datos de tabla que necesita del sistema de registro de destino.

Nota:

Las tablas configuradas y las claves principales no se pueden modificar después de la configuración inicial.

• Ya se ha familiarizado con las funciones Agregar llamadas adicionales a API y Combinar tablas en la integración HTTP.

Ver y crear la estructura de datos

Al crear microaplicaciones, el modelo convencional admitido por la plataforma de microaplicaciones es el de tablas separadas por un solo paso (modelo N+1).

Puede observar esto comprobando la configuración de integración definida durante la integración HTTP. Por ejemplo, puede ver que Ticket está a un paso de tags, pero ninguno está conectado directamente a comments_w_users.

Algunas relaciones se crean automáticamente durante la configuración del dispositivo de punto final, y las verá en la referencia de tabla de la integración. Sin embargo, en este caso de uso específico, debe crear algunas definiciones manuales para crear las relaciones entre tablas.

Estrategia de combinación de estructuras de datos

Al diseñar la estructura de datos para crear sus microaplicaciones en este supuesto, tenga en cuenta los siguientes puntos importantes:

• Elija la llamada API principal según la estructura de datos que debe obtener para crear la microaplicación. Considere cómo usar la sincronización incremental para el conjunto de datos y la API que devolverá solo la estructura de datos actualizada. Esta API debe establecerse como la principal.
• Siempre que sea posible, elija configuraciones “uno a varios”, en lugar de “varios a uno”. Las configuraciones “varios a uno” dan lugar a llamadas API repetitivas y afectarán a la eficiencia de la sincronización de datos.
• Considere el origen de la notificación que necesita y cómo está configurada, de manera que el usuario reciba una sola notificación en los casos en que esté configurada la combinación de tablas y los datos puedan duplicarse.
• La API principal siempre debe ser el objeto más volátil.

Utilice los siguientes métodos de combinación de tablas para los casos específicos:

• Uno a uno: Utilice Fusionar como detalles. En este caso, se almacena solamente un registro en la base de datos, que contiene todos los atributos de las API principal y secundaria. Los valores secundarios se utilizan cuando el atributo está presente en la llamada API principal y secundaria.
• Uno a varios: Utilice Fusionar como sublista. Todos los atributos principales se almacenan con cada registro secundario.
• Varios a uno: Generalmente “varios a uno” no es un escenario para llamadas API secundarias. Debe considerar el método más adecuado, ya sea utilizar combinación de tablas o configuración manual de la relación entre entidades (no se aplica la combinación). Si no se aplica ninguna combinación, solo se almacena el primer elemento secundario y se ignoran otros elementos secundarios debido a la detección de clave principal duplicada.

Definir relaciones manuales

Para definir relaciones manualmente, debe haber una columna común en ambas tablas para crear una relación. Puede comprobarlo en la sección de tablas y relaciones de la integración de datos. Si dos tablas distintas tienen una columna en común, puede crear manualmente una relación entre ellas. Si no hay ninguna columna en común, debe crear relaciones siguiendo el ejemplo que se muestra en el siguiente procedimiento.

Caso de uso avanzado

Si no puede crear estructuras de datos más allá del modelo N+1 mediante la relación de columna en común, puede crear una estructura de datos aplanada mediante una combinación de llamadas API secundarias y combinación de tablas. El “caso de uso avanzado” general sigue el principio básico de:

1. Configurar la integración.
2. Modificar la estructura de tablas.
3. Crear las cadenas de llamadas de API desde la tabla principal hasta la tabla con la que se quiere combinar.
4. Combinar tablas siguiendo un método de arriba hacia abajo (por ejemplo, de principal a secundaria).
5. Una vez creada la tabla grande, volver a la tabla principal y definir ignorar para todas las entidades de tabla.

Por ejemplo, al crear una microaplicación con request-list>item list>item details>approver, la microaplicación debe poder mostrar la solicitud y los detalles correspondientes al aprobador, pero no puede debido a la limitación actual de solo relaciones N+1. Puede utilizar la función de combinación de tablas para solucionar este problema.

Al crear el dispositivo de punto final de datos, propague la estructura de tabla desde el dispositivo de punto final de datos principal (request-list) al dispositivo de punto final secundario (approver) dentro de la lista de elementos.

A continuación, puede definir combinar todo, del dispositivo de punto final de datos principal a esta API secundaria, mediante una estrategia de combinación de tablas. El resultado es que todo lo que estaba en la tabla principal, se muestra en la estructura de datos de la API secundaria (item-list).

Al configurar de esta manera, se obtienen tres niveles de datos contenidos en una tabla de base de datos grande. Esta nueva tabla se puede usar para crear la página según el caso de uso definido cuando comenzó a crear sus microaplicaciones. Este método se puede utilizar para tantos niveles como sean necesarios.

Ejemplo de combinación de tabla y llamada API secundaria

El siguiente ejemplo muestra el flujo de trabajo general para crear una estructura de tabla que permita acceder a los datos más allá de una relación N+1. Cada uso debe construirse en función del caso de uso individual deseado para la microaplicación. Asegúrese de que está familiarizado con su sistema de registro de integración de destino y que entiende claramente el resultado de la estructura al utilizar este método.

Crear cadena de llamadas de API

1. Vaya a la página Carga de datos de su integración:
2. Agregue tantas llamadas API secundarias desde el dispositivo de punto final raíz al dispositivo de punto final secundario de destino como sea necesario: Cuando termine, podrá ver su estructura de datos en la página Carga de datos principal.

Combinar las llamadas API principal y secundarias

Ahora combine la tabla raíz/principal con los dispositivos de punto final secundarios en secuencia hasta que llegue a la tabla de destino:

1. Seleccione Modificar en el menú de puntos suspensivos de la integración.
2. Seleccione Modificar en el menú de puntos suspensivos del dispositivo de punto final secundario de la integración raíz.
3. Vaya a la parte inferior de la página Modificar dispositivo de punto final de datos y seleccione Modificar para configurar la combinación de tablas: Repita este proceso tantas veces como sea necesario para cada tabla secundaria en la secuencia hasta que llegue a la tabla de destino que le permitirá construir su microaplicación.

Ignorar llamadas API repetidas

Cuando haya terminado, la “cadena” de combinación regresará al dispositivo de punto final raíz. Siga estos pasos:

1. Seleccione Modificar.
2. Establezca todas las tablas en el estado Ignorado: Esto impide que la tabla se cargue dos veces en la caché y, por lo tanto, mejora el rendimiento. Ahora puede usar la tabla encadenada/combinada para crear la microaplicación.

Consideraciones importantes

Tenga siempre en cuenta lo siguiente al construir sus datos con este método:

• Todas las llamadas API principales y secundarias tienen su propia estructura de datos.
• Estas estructuras son diferentes conjuntos de datos.
• Si la estructura de datos se combina (de principal a secundaria), todos los atributos aparecen en la estructura de datos secundaria.
• Si se mantiene la cadena completa, los datos se almacenan “dos veces”: Asegúrese de que la estructura de datos en la llamada principal se elimine por completo, ya que cada atributo aparece en la estructura de datos secundaria.
• No deje la llamada API principal con la estructura de datos tal cual. Elimínela cuando sea posible.