Bonnes pratiques pour la génération de flux
Afin de garantir des performances optimales dans Workflows, suivez les bonnes pratiques pour générer vos flux.
Utilisation efficace du point de terminaison de l'API
Le point de terminaison de l'API Workflows permet à un client externe d'invoquer un flux via HTTP. C'est une fonctionnalité performante, car elle étend les flux au-delà de ceux démarrés par la bibliothèque de connecteur intégrée. Toutefois, ces flux requièrent une attention particulière afin de garantir leur bon déroulement. Consultez À propos de l'invocation d'un flux de point de terminaison d'API.
Délais d'expiration du point de terminaison de l'API
Le principal défi lié à l'utilisation du point de terminaison de l'API est que le moteur Workflows ne garantit pas la latence. Cela signifie que, bien que les flux s'exécutent rapidement la plupart du temps, les temps d'exécution des flux peuvent varier de 10 fois ou plus.
Comme le point de terminaison de l'API ferme sa connexion au client au bout de 60 secondes, un flux échoue si l'opération prend plus de temps. Certains clients HTTP qui invoquent un flux de point de terminaison de l'API pourraient avoir un délai d'expiration encore plus bas que le délai d'expiration de l'API par défaut. Par exemple, les appels incorporés Okta ont un délai d'attente par défaut de 3 secondes.
Structurer les flux de manière asynchrone
Lorsque vous travaillez avec des flux de point de terminaison d'API, il est conseillé de structurer votre flux de façon à ce qu'il soit traité de manière asynchrone. Cela signifie que l'appelant (client HTTP) ne doit pas attendre une réponse spécifique.
Ceci est particulièrement important lors de l'intégration avec les appels Okta. Par exemple, considérons un flux qui commence par le crochet incorporé enregistrement ou importation synchrone. Au lieu de cela, vous pouvez restructurer ce flux avec des événements Okta qui utilisent les cartes d'événements asynchrones créées par l'utilisateur et de profil d'utilisateur Okta mis à jour. La transition vers le modèle asynchrone est plus avantageuse pour les deux systèmes. Un exemple courant est l'enregistrement de l'inscription et de l'importation d'un nouvel utilisateur dans un système tiers. S'il n'est pas indispensable qu'il soit présent instantanément, le modèle asynchrone offre une meilleure expérience.
Placer d'abord la carte de fermeture du connecteur API dans un flux
Une façon de gérer le risque lié au délai d'expiration consiste à fermer la connexion HTTP aussi rapidement que possible. Il est conseillé d'ajouter la carte Fermeture du connecteur API comme première carte du flux. Cela permet au moteur Workflows de libérer immédiatement sa connexion HTTP vers l'appelant (client HTTP). Le moteur Workflows traite ensuite le reste du flux de manière asynchrone. Consultez Fermer.
Il est également recommandé d'utiliser une combinaison des cartes Flux d'appel asynchrone et Retour de contrôle de flux brut. Cela vous permet de commencer à traiter le travail de manière asynchrone et d'avoir un contrôle précis sur la réponse HTTP. Consultez Flux d'appel asynchrone et Retour brut.
Conserver la simplicité et la rapidité des flux synchrones
Si un client exige une réponse synchrone, prêtez une attention particulière à l'architecture du flux pour vous assurer que vous n'introduisez pas de risque de latence et de délai d'expiration inutile.
-
Évitez les appels vers des réseaux externes. Les appels peuvent prendre des centaines de millisecondes de latence, sans compter le temps que prend le service externe pour traiter les données. Les appels externes se produisent dans les cartes de connecteur et les cartes HTTP. Si des appels vers des réseaux externes sont requis, créez un flux d'aide et utilisez la carte Flux d'appel asynchrone pour supprimer les appels du flux synchrone.
-
Une fois que la réponse est prête, renvoyez-la immédiatement. Vous pouvez utiliser la carte Fermeture du connecteur d'API pour renvoyer une valeur pendant que le reste du flux poursuit son traitement.
Utilisation efficace du moteur Workflows
Le moteur Workflows exécute de nombreuses petites actions plus efficacement qu'un petit nombre de grandes actions. Les flux qui utilisent une mémoire excessive peuvent être limités ou arrêtés pour protéger les ressources du système. Il s'agit de techniques importantes pour améliorer les performances du flux et éviter les problèmes de mémoire insuffisante, de limitation, de retard d'exécution, d'exécutions bloquées ou autres.
Utiliser des flux d'aide pour diviser les tâches de traitement volumineuses
Lorsque vous pouvez générer plusieurs flux asynchrones, le moteur Workflows planifiera intelligemment le travail pour terminer votre flux aussi rapidement que possible. Si vous avez une grande quantité de travail asynchrone à effectuer à partir de votre flux parent, il est conseillé d'utiliser la carte Flux d'appel asynchrone. Cette carte continue à traiter votre flux parent pendant que le moteur exécute simultanément le flux d'aide qui est spécifié en entrée.
Si vous avez une longue liste d'éléments à traiter, il est conseillé d'utiliser la carte Pour chacun - Ignorer les erreurs. Cette carte prend une liste et exécute un flux d'aide pour chaque élément de cette liste, avec une simultanéité facultative. Si le nom de la carte indique qu'elle ignore les erreurs, cela n'est vrai que du point de vue du flux parent. Vous pouvez gérer les erreurs dans vos flux d'aide. Consultez Pour chacun - Ignorer les erreurs.
Éviter les blocs de gestion des erreurs complexes
Pour éviter les erreurs d'analyse causées par une gestion d'erreurs complexes, Okta recommande de ne pas dépasser trois blocs Si erreur imbriqués.
Filtrer les grands ensembles
Si vous n'avez besoin de traiter qu'un sous-ensemble d'éléments d'une liste, filtrez-les à l'aide de la carte Filtre au lieu d'arrêter prématurément un flux d'aide. Consultez Filtre.
Bien que les flux d'aide soient préférables à un traitement complet dans un seul grand flux, n'oubliez pas que la création et l'exécution des flux d'aide engendrent des frais. Si vous pouvez les éviter pour les tâches que vous n'avez pas besoin de traiter, l'exécution de votre flux est plus efficace.
Éviter de transmettre des listes dans les flux d'aide
Lorsque vous travaillez sur une liste d'éléments et que vous utilisez une carte Pour chacun, utilisez la section Avec les valeurs suivantes pour transmettre uniquement les données dont le flux d'aide a besoin. Vous pouvez extraire des éléments de données individuels de la liste que vous parcourez en utilisant l'interface pour choisir chaque élément à transmettre. Par exemple, si vous travaillez sur une liste d'utilisateurs, ne transmettez au flux d'aide que les champs obligatoires d'un seul utilisateur au lieu de l'objet utilisateur complet.
Dans la mesure du possible, utiliser des actions de diffusion en flux continu
Les actions de diffusion en flux continu prendront des listes de résultats et exécuteront automatiquement un flux d'aide pour chaque élément de manière asynchrone. Ce processus est optimisé de sorte que le flux parent effectue la pagination des données et crée les flux d'aide en ne consommant que peu de mémoire.
N'oubliez pas que les options de jeux de résultats sans diffusion en flux continu entraînent une utilisation accrue de la mémoire de flux. Les cartes qui contiennent l'option Stream Matching Records dans le champ Jeu de résultats prennent en charge les actions de diffusion en flux continu. Les cartes d'action Rechercher des utilisateurs, Répertorier des utilisateurs avec la recherche et Répertorier des utilisateurs affectés à des applications pour le connecteur Okta renvoient des listes et prennent en charge la diffusion en flux continu. Voir Configurer l'option de diffusion correspondante avec un flux auxiliaire.