Explorer les modèles d’intégration

En fonction de votre analyse, planifiez l’intégration et identifiez le meilleur modèle pour vos besoins. La liste suivante de modèles d’intégration n’est pas exhaustive. Vous pouvez constater qu’une combinaison de ces modèles correspond le mieux à votre scénario.

Chaque modèle traite des scénarios métier spécifiques et des contraintes techniques :

• Modèle de déclencheur instantané : ce modèle reflète la façon dont les utilisateurs interagissent avec les systèmes. Une action pilotée par l’utilisateur déclenche une série prédéfinie d’actions.
• Modèle piloté par les événements : ce modèle nécessite un déclencheur automatique, tel qu’une réponse aux événements se produisant dans un système donné.
• Modèle de consolidation des données : ce modèle est essentiel pour les organisations avec plusieurs systèmes de gestion qui nécessitent une image complète de leurs données sur leurs différents systèmes.
• Modèle d’architecture orienté service : ce modèle implique généralement plusieurs flux entre les systèmes, ce qui permet une intégration modulaire et évolutive dans des environnements complexes.
• Modèle de synchronisation : ce modèle conserve les données synchronisées entre différentes bases de données et répond aux exigences réglementaires et de performances.

Modèle de déclencheur instantané

Le modèle de déclencheur instantané est piloté par l’utilisateur et intuitif. Il lance un flux d’intégration lorsqu’un utilisateur effectue une action, par exemple en appuyant sur un bouton dans une application Power App. Ce modèle est idéal pour les scénarios où les données sont nécessaires à la demande et non en continu.

Exemple de scénario

Une application Power App permet aux responsables de produits de passer en revue les commentaires des clients et de créer des plans d’action. Certaines spécifications techniques sont stockées dans le système de gestion du cycle de vie des produits Oracle. Au lieu de copier l’intégralité du jeu de données dans Dataverse, l’application inclut un bouton pour extraire des données si nécessaire.

Les raisons d’intégrer plutôt que de rediriger les utilisateurs vers Oracle sont les suivantes :

• Expérience utilisateur médiocre
• Problèmes de sécurité
• Coûts des licences

Compte tenu de l’efficacité des intégrations Power Platform, l’une de ces raisons peut justifier l’implémentation.

Conception de flux

Utilisez un flux cloud instantané déclenché par une pression sur un bouton dans l’application.

Ce diagramme illustre le modèle de déclencheur instantané, où une action initiée par l’utilisateur récupère les données d’un système externe et les écrit dans Dataverse :

Le flux comprend les étapes suivantes :

1. Demandez des enregistrements d’Oracle à l’aide de paramètres (tels que l’ID de produit) fournis par l’application.
2. Retournez des enregistrements d’Oracle à l’application.
3. Écrire des enregistrements dans Dataverse.

Ces données sont ensuite reflétées dans l’interface Power Apps.

Considérations:

• Les modèles de données entre Oracle et Dataverse peuvent différer, nécessitant des étapes de transformation.
• Les déclencheurs instantanés ne sont pas vraiment instantanés. Le temps d’exécution dépend de la complexité de la disponibilité et de la transformation du système.
• Ajoutez des indicateurs visuels dans l’application pour afficher la progression et autoriser l’annulation si l’opération prend trop de temps.
• Dans les grandes organisations, les demandes simultanées de nombreux utilisateurs peuvent forcer le système.
• Les intégrations peuvent échouer pour différentes raisons. Vérifiez que l’application fournit des commentaires aux utilisateurs pendant l’exécution. Évitez les scénarios où les utilisateurs sélectionnent un bouton et ne reçoivent aucune réponse, ce qui entraîne une mauvaise expérience utilisateur.

Modèle piloté par les événements

Les architectures pilotées par les événements (également appelées déclencheurs automatiques) répondent aux modifications apportées aux systèmes sans interaction directe avec l’utilisateur. Par exemple, les déclencheurs peuvent être configurés pour répondre à un enregistrement créé dans Dataverse, les e-mails entrants, les fichiers ajoutés à OneDrive et tout autre événement. Ce modèle est intuitif et évolutif, ce qui le rend idéal pour automatiser les processus métier en fonction des événements système.

Exemple de scénario

Un service de service client utilise une application connectée à Dataverse pour travailler sur des cas et fournir automatiquement des mises à jour aux clients, sans écrire manuellement des e-mails. Seules les modifications spécifiques, telles que l’ajout d’une note ou la modification de l’état, doivent déclencher des notifications.

Utilisez un déclencheur automatique dans Power Automate pour répondre à ces événements. Le flux écoute les modifications apportées aux enregistrements Dataverse et envoie des notifications lorsque des conditions définies sont remplies.

Ce diagramme montre le modèle de déclencheur automatique, où les modifications apportées à Dataverse lancent automatiquement des actions en aval qui mettent à jour les clients avec les informations de cas pertinentes :

Configuration de déclencheur

Configurez le flux comme suit :

• Indiquez le type de modification à surveiller.
• Définissez les colonnes à répondre à l’aide du paramètre Select Columns .
• Utilisez le paramètre Filtrer les lignes pour garantir que seuls les modifications d’état côté client déclenchent le flux, ainsi que les autres exigences de filtrage.

Évitez d’implémenter cette logique dans le flux lui-même à l’aide d’une If action. Utilisez des paramètres de déclencheur pour réduire les exécutions inutiles et améliorer les performances.

Éviter les conflits logiques

Évaluez la logique d’événement pour empêcher le comportement inattendu :

• Évitez les boucles où un événement déclenche une action qui retengue le même événement.
• Empêcher plusieurs mises à jour d’entraîner des notifications rapides et répétées.
• Concevez les flux de travail pour gérer les cas limites et éviter les exécutions excessives.

Considérations relatives au volume et à la fréquence

Comprendre le volume attendu d’événements déclenchés. Les services de notification (e-mail, SMS et autres) limitent le nombre de messages que vous pouvez envoyer dans un délai donné.

• Estimer le nombre d’événements par jour ou par mois.
• Implémentez des mécanismes de limitation ou de régulation de débit.
• Préparez un plan d’atténuation pour des pics inattendus dans la fréquence des événements.

Modèle de consolidation des données

La consolidation des données (également appelée déclencheur planifié) permet aux organisations d’unifier les informations sur plusieurs systèmes pour prendre en charge les rapports et les processus opérationnels. Bien que l’analytique nécessite souvent des jeux de données complets, les cas d’usage opérationnels se concentrent sur la récupération uniquement des données nécessaires pour effectuer des tâches métier.

Exemple de scénario

Une entreprise utilise trois systèmes hérités pour gérer les principales fonctions métier : SAP pour les commandes et comptes clients, Oracle pour l’inventaire des produits et IBM pour la gestion du contenu liée au client. L’organisation a commandé une nouvelle application Power Platform pour utiliser l’IA pour prédire la meilleure action suivante pour chaque client en fonction des données historiques. L’application doit collecter des informations pertinentes à partir des trois systèmes et générer un plan d’action de vente pour les responsables commerciaux afin de guider l’engagement.

Approche d’intégration

L’intégration ne nécessite pas de mises à jour en temps réel ou de déclencheurs pilotés par les événements. Au lieu de cela, utilisez un processus planifié en fonction de la fréquence à laquelle le personnel commercial interagit avec les clients.

Dans ce cas d’usage, un déclencheur planifié consolide les données comme suit :

• Demande uniquement les données nécessaires de chaque système
• Retourne les données dans un format compatible avec Dataverse
• Charge les données dans le modèle IA à des fins d’analyse

Ce diagramme illustre le modèle de consolidation des données planifié, où un processus périodique collecte des informations à partir de plusieurs systèmes et charge le jeu de données combiné dans Dataverse :

Configuration du déclencheur planifié

Les déclencheurs planifiés offrent des options de périodicité flexibles, d’une fois par seconde à une fois par an. Elles sont prévisibles dans le temps, mais peuvent devenir imprévisibles en volume si l’étendue des données augmente ou que la croissance dépasse les attentes.

• Surveiller le temps d’exécution du flux pour éviter les chevauchements ou les retards
• Implémenter des protections pour empêcher la dégradation des performances
• Utiliser Application Insights ou des outils similaires pour vous assurer que le flux s’exécute de manière cohérente

Atténuation des risques

Si un flux planifié prend plus de temps que prévu, il peut perturber les processus métier. Par exemple, un flux conçu pour s’exécuter toutes les 10 minutes peut échouer s’il commence à prendre plus de 10 minutes.

• Surveiller le runtime et définir des alertes pour les anomalies
• Planifier l’extensibilité à mesure que le volume de données augmente
• Garantir la visibilité de l’intégrité des flux pour éviter les défaillances inaperçues

Modèle d’intégration orienté service

Les grandes organisations opèrent souvent plusieurs systèmes entre les services. Ces systèmes évoluent pour dépendre les uns des autres pour terminer les processus métier. La couche d’intégration relie ces systèmes, ce qui permet à chacun d’effectuer sa fonction principale tout en activant la communication entre systèmes.

Exemple de scénario revisité

Poursuivons avec notre exemple de scénario dans lequel l’organisation utilise plusieurs systèmes pour gérer différentes parties de l’entreprise. SAP gère les commandes et comptes clients, Oracle gère l’inventaire des produits et IBM stocke la documentation financière interne. Dataverse exécute des applications pour les ventes, le service client et la gestion des produits. SharePoint prend en charge la gestion interne de la collaboration et de la base de connaissances, tandis que les API Maersk automatisent les processus logistiques.

Ce diagramme illustre le modèle piloté par les événements dans un paysage multi-système, où les mises à jour sur différents systèmes d’entreprise déclenchent des flux automatisés qui coordonnent les données et les actions entre eux :

Chaque système interagit avec d’autres utilisateurs par le biais d’événements planifiés ou d’actions utilisateur manuelles. Aucun flux unique ne sert tous les cas d’usage. Au lieu de cela, la solution nécessite plusieurs flux adaptés à des déclencheurs et processus métier spécifiques.

Éviter les flux monolithiques

La création d’un flux volumineux pour gérer toutes les intégrations n’est pas pratique. Il présente des problèmes de performances, de sécurité et de maintenance. À la place :

• Créer des flux modulaires pour chaque déclencheur et processus
• Optimiser les flux pour des cas d’usage spécifiques
• Étendre l'environnement d'intégration avec des composants gérables

Optimiser les processus inter-systèmes

Recherchez les opportunités de consolider la logique le cas échéant. Par exemple, si un document dans SharePoint doit être envoyé à la fois à SAP et Oracle pendant le même événement, vous pouvez être tenté de créer un flux qui lit le fichier une fois et l’écrit dans les deux systèmes. Tout d’abord, déterminez si la logique que vous créez est trop rigide. Dans un paysage important, les modifications apportées à la façon dont les processus métier fonctionnent sur plusieurs systèmes se produisent aussi souvent que les modifications apportées à ces systèmes.

Évitez la sur-consolidation. Les processus métier et les configurations système changent fréquemment. Une logique rigide et centralisée réduit la flexibilité et augmente la surcharge de maintenance.

Flux de conception qui sont les suivants :

• Modulaire et maintenable
• Scalable entre les services et les systèmes
• Résilient aux changements dans la logique métier et le comportement du système

Ce modèle aboutit à une architecture orientée service , parfois humoristiquement appelée « architecture spaghetti », où les systèmes sont interconnectés par le biais de flux bien définis et conçus à usage unique.

Modèle de synchronisation des données

Utilisez la synchronisation des données lorsque des systèmes identiques stockent des données dans des bases de données distinctes. Bien que le stockage des mêmes données deux fois semble inefficace, ce modèle prend en charge des besoins métier spécifiques, tels que les performances et la conformité réglementaire.

• Performances : l’accès aux données locales améliore la réactivité, en particulier dans les secteurs sensibles à la latence.
• Conformité : les réglementations légales peuvent exiger que les données soient stockées dans les frontières nationales. Les organisations déploient souvent des instances locales avec des processus de synchronisation pour répondre à ces exigences.

Exemple de scénario

Une société d’appareils médicaux opère dans plusieurs régions d’Europe, en coopération avec les institutions médicales locales. Les lois de chaque région sont claires sur les données médicales : elles doivent être stockées dans les frontières de cette région. Des informations sur les commandes, les produits et l’expédition peuvent être stockées entre les frontières. Pour répondre aux exigences réglementaires, l’entreprise a créé une instance de son application de gestion des clients Power Platform et Dataverse dans chaque région.

Pour prendre en charge les opérations de vente, l’entreprise souhaite synchroniser les données non sensibles, telles que les coordonnées, les commandes et l’expédition, dans toutes les instances. Les données médicales sont exclues de la synchronisation.

Approche d’intégration

Utilisez un flux cloud automatique déclenché par des mises à jour de l’enregistrement de compte. Configurez les filtres pour :

• Surveiller uniquement les champs autorisés
• Empêcher la synchronisation des données restreintes

Cette approche entraîne une intégration ciblée basée sur les événements qui prend en charge la conformité et l’efficacité opérationnelle.

Ce diagramme illustre le modèle de synchronisation piloté par les événements, où les mises à jour d’un environnement Dataverse déclenchent automatiquement les mises à jour correspondantes dans un autre :

Attentes en matière de temps de réponse

Définissez des attentes réalistes pour la vitesse de synchronisation. Power Automate est asynchrone et ne garantit pas les performances en temps réel. Si les utilisateurs professionnels attendent une disponibilité immédiate des données, clarifiez les limitations dès le début du processus de conception.

• Évaluer si Power Automate répond aux besoins en matière de performances
• Éviter le sur-ingénierie pour l’accès en temps réel, sauf si cela est justifié par les exigences métier

De nombreuses demandes d’accès en temps réel n’ont pas de cas d’entreprise fort. Hiérarchiser la clarté, la scalabilité et la facilité de maintenance dans la conception d’intégration.

Au-delà des flux de nuage

Lorsque vous sélectionnez un outil d’intégration, commencez par Power Automate comme option par défaut. Il offre une rentabilité inégalée pour le développement et la maintenance.

Power Automate est l’outil d’intégration préféré pour de nombreux scénarios, car il :

• Fournit un développement rapide avec des connecteurs à faible code
• Réduit les coûts de maintenance à long terme
• Prend en charge un large éventail de déclencheurs et de systèmes
• S'adapte bien à la plupart des scénarios professionnels

Le code personnalisé, Azure Functions, Data Factory ou Service Bus peut vous donner plus de contrôle ou de meilleures performances, mais ils ajoutent de la complexité et du coût. Utilisez ces options uniquement lorsque Power Automate ne répond pas à vos besoins professionnels ou techniques.

Exemple de scénario

Un service bancaire en ligne souhaite qualifier les clients pour les prêts plus rapidement. Le processus de qualification implique des calculs complexes et la récupération des données à partir de plusieurs systèmes pour arriver à un score de risque final. À la suite d’une évaluation initiale, le service bancaire considère que le flux cloud n’est pas adapté en raison de la complexité des calculs.

Toutefois, dans ce cas, une approche hybride est la réponse :

• Power Automate pour gérer la collecte de données avec des connecteurs intégrés
• Calculs complexes encapsulés dans le code personnalisé s’exécutant en tant que fonction Azure, qui peut être mis à l’échelle indépendamment ou dans un connecteur personnalisé

Cette approche hybride équilibre les performances, l’extensibilité et le coût.

Stratégie d’intégration

Ne choisissez pas les outils isolément. Au lieu de cela, combinez leurs forces. Par exemple:

• Utiliser Power Automate pour l’orchestration et la connectivité
• Utiliser Azure Functions pour les tâches nécessitant beaucoup de ressources de calcul
• Utiliser des connecteurs personnalisés pour étendre les fonctionnalités si nécessaire

Chaque décision d’intégration doit prendre en compte le coût total de possession. Les solutions personnalisées peuvent sembler puissantes, mais nécessitent souvent un budget plus important pour le développement, les licences et le support. Justifier des coûts plus élevés avec une valeur commerciale claire.