Créer des structures de données d’intégration approfondies
Lors de la création de micro-apps, vous pouvez avoir besoin d’accéder aux tables de votre système d’enregistrement cible qui sont séparées par plus de deux niveaux de la table parent. En raison des limitations actuellement présentes dans l’intégration HTTP, une solution pour répondre à cette exigence est possible.
Cet article fournit des informations sur la façon d’accéder aux tables de votre système d’enregistrement cible lorsque ce cas d’utilisation se produit. Cette solution n’est pas simple, mais si vous suivez la description ci-dessous, vous pouvez créer des structures de données plus profondes.
Cas d’utilisation
Vous souhaitez créer une micro-app qui permet à un utilisateur d’approuver une demande sur ServiceNow. Pour utiliser cette micro-app, l’utilisateur doit pouvoir effectuer les opérations suivantes :
- Recevoir et ouvrir une notification
- Recevoir une page avec une liste d’éléments à approuver
- Afficher les détails de chaque élément
- Afficher les détails du demandeur
- Approuver ces demandes
Les détails nécessaires à la création d’une action ou d’une page pour chacune de ces étapes sont stockés dans les tables récupérées via des points de terminaison. Toutefois, la table contenant les données de l’approbateur (table avec les données contenant la liste des éléments) se trouve à un écart de plus de deux niveaux de tables d’un autre emplacement de données.
Conditions préalables de la solution
Pour créer cette solution, vous devez utiliser une combinaison de chaîne d’appels d’API enfant et de fusion de tables décrite à la section Configurer l’intégration.
Conditions préalables :
- Vous avez défini votre cas d’utilisation de bout en bout ; vous savez quels éléments doivent être exécutés dans votre micro-app et quelles informations votre utilisateur voit et utilise.
- Vous avez créé le point de terminaison pour renvoyer les données de table dont vous avez besoin à partir de votre système d’enregistrement cible.
Remarque :
Les tables et les clés primaires configurées ne peuvent pas être modifiées après la configuration initiale.
- Vous connaissez les fonctionnalités Ajouter des appels d’API supplémentaires et Fusionner les tables de l’intégration HTTP.
Afficher et créer la structure de vos données
Lors de la création de vos micro-apps, le modèle conventionnel pris en charge par la plate-forme de micro-apps est destiné aux tables séparées d’un seul niveau (modèle N+1).
Vous pouvez voir ce modèle en vérifiant la configuration de votre intégration mise en place lors de l’intégration HTTP. Par exemple, vous pouvez voir que l’élément Ticket se trouve à un écart d’un niveau des balises (tags), mais aucun de ces éléments n’est directement connecté à comments_w_users.
Certaines relations sont créées automatiquement lors de la configuration du point de terminaison, et vous les voyez dans la référence de table de l’intégration. Toutefois, pour ce cas d’utilisation spécifique, vous devez créer des définitions manuelles pour créer les relations entre les tables.
Stratégie de fusion de structures de données
Lors de la conception de la structure de données pour créer vos micro-apps dans ce scénario, tenez compte des points importants suivants :
- Choisissez l’appel d’API parent en fonction de la structure de données que vous devez réaliser pour créer votre micro-app. Considérez comment utiliser la synchronisation incrémentielle pour votre ensemble de données et l’API qui renverra uniquement la structure de données mise à jour. Cette API doit être définie comme l’élément parent.
- Dans la mesure du possible, configurez uniquement une relation « un-à-plusieurs » (one-to-many) plutôt qu’une relation « plusieurs-à-un » (many-to-one). Les configurations « plusieurs-à-un » entraînent des appels d’API répétitifs et auront un impact sur l’efficacité de la synchronisation des données.
- Tenez compte de la source de la notification dont vous avez besoin et de la manière dont elle est configurée afin que votre utilisateur ne reçoive qu’une seule notification dans les cas où la fusion de tables est configurée et où les données peuvent être dupliquées.
- L’API parent doit toujours être l’objet le plus volatile.
Utilisez les méthodes Fusionner les tables suivantes pour les cas spécifiques :
- Un-à-un (One-to-one) : utilisez Fusionner en tant que détail. Lorsque cette option est sélectionnée, un seul enregistrement stocké dans la base de données contient tous les attributs des API parent et enfant. Les valeurs enfant sont utilisées lorsque l’attribut est présent dans les appels d’API parent et enfant.
- Un-à-plusieurs (One-to-many) : utilisez Fusionner en tant que sous-liste. Tous les attributs parent sont stockés avec chaque enregistrement enfant.
- Plusieurs-à-un (Many-to-one) : généralement la configuration « plusieurs-à-un » n’est pas un scénario pour les appels d’API enfant. Vous devez considérer la méthode la plus appropriée, que ce soit pour utiliser la fusion de tables ou la configuration manuelle de la relation d’entité (aucune fusion n’est appliquée). Si aucune fusion n’est appliquée, seul le premier enfant est stocké ; les autres enfants sont ignorés en raison de la détection de clé primaire dupliquée.
Définir des relations manuelles
Pour définir manuellement les relations, il doit y avoir une colonne commune dans les deux tables à utiliser pour créer une relation. Vous pouvez vérifier cela dans la section des tables et des relations de l’intégration des données. Si deux tables séparées ont une colonne en commun, vous pouvez créer manuellement une relation entre elles. Si aucune colonne commune n’existe, vous devez créer des relations comme dans l’exemple illustré dans la procédure suivante.
Cas d’utilisation avancé
Si vous ne pouvez pas créer de structures de données au-delà de n+1 en utilisant la relation de colonne commune, vous pouvez créer une structure de données aplatie à l’aide d’une combinaison d’appels d’API enfant et de fusion de tables. Le « cas d’utilisation avancé » général suit le principe de base suivant :
- Configurez votre intégration.
- Modifiez la structure de votre table.
- Créez vos chaînes d’appels d’API à partir de votre table principale vers la table à laquelle vous souhaitez l’associer.
- Fusionnez les tables en utilisant la fonction de fusion de tables dans une méthode décroissante (par exemple, parent à enfant).
- Lorsque votre grande table est créée, revenez à la table parent et ignorez toutes les entités de table.
Par exemple, pour la création d’une micro-app avec request-list>item list>item details>approver, la micro-app doit être capable d’afficher la demande et les détails de l’approbateur. Toutefois cette configuration n’est pas possible en raison de la limitation actuelle des relations n+1. Vous pouvez utiliser la fonction de fusion de tables pour résoudre ce problème.
Lors de la création de votre point de terminaison de données, propagez la structure de table du point de terminaison de données parent (request-list) au point de terminaison enfant (approver) dans la liste d’éléments.
Vous pouvez ensuite définir une option pour fusionner tous les éléments, du point de terminaison de données parent à cette API enfant à l’aide d’une stratégie de fusion de tables. Par conséquent, tous les éléments se trouvant dans la table parent s’affichent dans la structure de données de l’API enfant (item-list).
La configuration de cette méthode signifie que trois niveaux de données se trouvent dans une grande table de base de données. Cette nouvelle table peut être utilisée pour créer la page selon le cas d’utilisation défini lorsque vous avez commencé à créer vos micro-apps. Cette méthode peut être utilisée pour autant de niveaux requis.
Exemple d’appel d’API enfant et de fusion de table
L’exemple suivant illustre le workflow général de création d’une structure de table pour atteindre des données au-delà d’une relation n+1. Chaque utilisation individuelle doit être conçue en fonction du cas d’utilisation individuel que vous souhaitez créer pour votre micro-app. Assurez-vous que vous maîtrisez votre système d’enregistrement d’intégration cible et que vous comprenez bien le résultat de votre structure lorsque vous utilisez cette méthode.
Créer une chaîne d’appels d’API
- Accédez à la page Chargement des données liée à votre intégration :
- Ajoutez autant d’appels d’API enfant à partir de votre point de terminaison racine au point de terminaison enfant de destination que nécessaire :
Lorsque vous avez terminé, vous pouvez afficher la structure de vos données sur la page principale Chargement des données.
Fusionner les appels d’API parent aux appels d’API enfant
Maintenant, fusionnez la table racine/table parent aux points de terminaison enfants dans l’ordre jusqu’à ce que vous atteigniez la table de destination :
- Sélectionnez Modifier dans le menu des points de suspension de votre intégration.
- Sélectionnez Modifier dans le menu des points de suspension pour le point de terminaison enfant de votre intégration racine.
- Accédez au bas de la page Modifier le point de terminaison de données et sélectionnez Modifier pour configurer la fusion des tables :
Répétez ce processus autant de fois que nécessaire pour chaque table enfant de la séquence jusqu’à ce que vous atteigniez la table de destination qui vous permettra de construire votre micro-app.
Ignorer les appels d’API répétés
Lorsque vous avez terminé, la « chaîne » de fusion revient au point de terminaison racine. Procédez comme suit :
- Sélectionnez Modifier.
- Définissez toutes les tables sur l’état Ignoré :
Cela empêche la table de se charger deux fois dans le cache et améliore ainsi les performances. Vous pouvez maintenant utiliser votre table avec chaînes ou votre table fusionnée pour créer votre micro-app.
Remarques importantes
Tenez toujours compte des éléments suivants lors de la conception de vos données à l’aide de cette méthode :
- Tous les appels d’API parent et enfant ont leur propre structure de données.
- Ces structures sont des ensembles de données différents.
- Si la structure de données est fusionnée (du parent à un enfant), tous les attributs apparaissent dans la structure de données enfant.
- Si la chaîne complète est conservée, les données sont stockées « deux fois ». Vérifiez que la structure de données dans l’appel parent est complètement supprimée car chaque attribut apparaît dans la structure de données enfant.
- Ne laissez pas l’appel d’API parent avec la structure de données telle quelle ; supprimez-la si possible.