21 décembre 2020

Lorsqu’il s’agit de travailler avec les fonctions Azure dans un environnement sans serveur, il n’est pas rare de se sentir un peu dépassé. Le fonctionnement interne des applications de fonctions et la façon dont elles traitent les demandes des applications frontales peuvent être un mystère. Dans cet article de blog, nous explorerons les concepts derrière les fonctions Azure et comment elles peuvent être utilisées en conjonction avec Azure Data Factory.

Les fonctions Azure fournissent un moyen d’exécuter votre code dans un environnement cloud sans avoir à gérer des serveurs. Lorsqu’une application frontale soumet une demande pour exécuter votre code de fonction, elle passe par un framework de fonctions durables composé d’un déclencheur, d’un orchestrateur et de fonctions d’activité. Azure Data Factory sert d’interface pour exécuter votre fonction Azure, et le résultat de sortie peut être ensuite traité dans votre flux de travail Data Factory.

Un des aspects clés des fonctions Azure est leur capacité à se dimensionner dynamiquement en fonction de la demande. À mesure que vous soumettez davantage de demandes de fonctions Azure parallèles à partir de votre Data Factory, l’application de fonctions se dimensionne à partir d’instances “Toujours prêtes” à des instances “Préchauffées” et finalement à des “Instances maximales” disponibles pour votre application de fonctions. Cette évolutivité garantit que vos fonctions peuvent gérer efficacement des charges élevées.

Lorsque vous travaillez avec des fonctions durables PowerShell, il est important d’établir la confiance dans la version d’exécution prise en charge et les possibilités d’échange de données entre l’orchestrateur et les fonctions d’activité. Bien que ces dernières ne soient peut-être pas bien documentées, explorer et expérimenter ces capacités peut conduire à des informations précieuses.

Dans mon parcours d’utilisation des fonctions Azure dans Data Factory, j’ai atteint jusqu’à présent deux étapes importantes. La première étape a consisté à obtenir un aperçu initial de ce qui est possible avec les fonctions Azure dans Azure Data Factory. La deuxième étape a consisté à permettre l’exécution de fonctions de longue durée pour éviter les échecs de Data Factory. Ces étapes m’ont aidé à comprendre la puissance et la flexibilité des fonctions Azure dans un scénario d’intégration de données.

Récemment, j’ai découvert une approche plus simple pour interroger l’état des processus de fonctions de longue durée dans Data Factory. Auparavant, j’utilisais une combinaison de conteneur de boucle “Jusqu’à”, d’activités d’attente et d’appel Web pour vérifier l’état de l’exécution de mon application de fonctions. Cependant, j’ai réalisé que cela peut être remplacé par une seule activité d’appel Web. Lorsque vous exécutez initialement votre fonction Azure durable, il fournit instantanément un code d’état HTTP d’exécution de 202 (Accepté). L’activité Web dans Azure Data Factory peut ensuite interroger l’URI statusQueryGetUri de votre fonction Azure jusqu’à ce que le code d’état HTTP devienne 200 (OK). Cela élimine la nécessité d’une logique complexe et simplifie le processus.

L’exécution parallèle de fonctions Azure est une exigence courante dans de nombreux projets. Cependant, il peut y avoir des cas où certaines opérations doivent être limitées et séquencées artificiellement. Dans de tels scénarios, il est important de s’assurer que les instances de fonction ne deviennent pas indisponibles pour les flux de travail existants de Data Factory. En déplaçant la logique de limitation de l’activité de fonction Azure vers Data Factory, vous pouvez éviter ce problème et maintenir la disponibilité de vos fonctions.

La nouvelle approche consiste à ce que l’instance de fonction Azure se termine avec un code d’état HTTP de 200 (OK) lorsqu’elle rencontre une situation de limitation. Elle fournit également un statut de sortie d’exécution supplémentaire indiquant qu’elle doit être réexécutée. Le conteneur de boucle “Jusqu’à” dans Data Factory peut ensuite gérer deux scénarios : lorsque le code d’état HTTP est 200 (OK) et que le statut de sortie personnalisé est “OK”, il sort du conteneur de boucle et passe à l’activité suivante. Si le code d’état HTTP est 200 (OK) mais que le statut de sortie personnalisé n’est pas “OK”, l’exécution continue avec un autre appel à la fonction Azure durable et la vérification de l’état actuel de la fonction.

Avec cette nouvelle approche, les conflits dans l’exécution des fonctions peuvent être gérés de manière élégante, et le flux de travail de Data Factory peut s’adapter en conséquence. La fonction Azure dispose désormais de deux niveaux de sondage HTTP : la collecte naturelle de l’état du webhook et la logique personnalisée dans Data Factory pour vérifier si le statut OK reçu du webhook est réellement OK.

Comprendre les fonctions Azure et leur intégration avec Azure Data Factory ouvre un monde de possibilités pour l’intégration et le traitement des données. En tirant parti de la scalabilité et de la flexibilité des fonctions Azure, vous pouvez créer des flux de travail robustes et efficaces qui gèrent des scénarios de données complexes.

Restez à l’écoute pour plus d’articles sur SQL Server et les technologies Azure !