Dans certaines situations, le comportement d’une source de données ne correspond pas à celui attendu par la gestion du code HTTP par défaut de Power Query. Les exemples ci-dessous montrent comment contourner cette situation.
Dans ce scénario, vous allez utiliser une API REST qui renvoie occasionnellement un code d’état 500, indiquant une erreur de serveur interne. Dans ces cas, vous pouvez attendre quelques secondes et réessayer, parfois quelques fois avant de renoncer.
ManualStatusHandling
Si Web.Contents une réponse de code d’état 500 est générée, elle lève une DataSource.Error valeur par défaut. Vous pouvez remplacer ce comportement en fournissant une liste de codes en tant qu’argument facultatif pour Web.Contents:
En spécifiant les codes d’état de cette façon, Power Query continuera à traiter la réponse web normalement. Toutefois, le traitement normal des réponses n’est souvent pas approprié dans ces cas. Vous devez comprendre qu’un code de réponse anormal a été reçu et effectuer une logique particulière pour le gérer. Pour déterminer le code de réponse renvoyé par le service web, vous pouvez y accéder à partir de l’enregistrement meta qui accompagne la réponse :
Selon qu’il s’agit responseCode de 200 ou de 500, vous pouvez traiter le résultat normalement, ou suivre votre logique d’attente de nouvelle tentative que vous allez développer dans la section suivante.
IsRetry
Power Query dispose d’un cache local qui stocke les résultats des appels précédents à Web.Contents. Lors de l’interrogation de la même URL pour une nouvelle réponse ou lors d’une nouvelle tentative après un état d’erreur, vous devez vous assurer que la requête ignore tous les résultats mis en cache. Pour ce faire, incluez IsRetry l'option dans l'appel à la Web.Contents fonction. Dans cet échantillon, nous allons définir IsRetry à true après la première itération de la Value.WaitFor boucle.
Value.WaitFor
Value.WaitFor() est une fonction d’assistance standard qui peut généralement être utilisée sans modification. Il fonctionne en créant une liste de nouvelles tentatives.
producer Argument
Cela contient la tâche à réessayer (éventuellement). Il est représenté en tant que fonction afin que le numéro d’itération puisse être utilisé dans la producer logique. Le comportement attendu est celui qui producer sera renvoyé null s'il est déterminé qu’une nouvelle tentative est nécessaire. Si quelque chose d’autre que null est renvoyé par producer, cette valeur est renvoyé par Value.WaitFor.
delay Argument
Il s’agit de la logique à exécuter entre les nouvelles tentatives. Il est représenté en tant que fonction afin que le numéro d’itération puisse être utilisé dans la delay logique. Le comportement attendu consiste au renvoi par delay à une durée.
count Argument (facultatif)
Un nombre maximal de nouvelles tentatives peut être défini en fournissant un nombre à count l'argument.
En résumé
L’exemple suivant montre comment ManualStatusHandling et Value.WaitFor peut être utilisé pour implémenter une nouvelle tentative retardée en cas de réponse 500. Le temps d’attente entre les nouvelles tentatives double avec chaque tentative, avec un maximum de cinq nouvelles tentatives.
let
waitForResult = Value.WaitFor(
(iteration) =>
let
result = Web.Contents(url, [ManualStatusHandling = {500}, IsRetry = iteration > 0]),
status = Value.Metadata(result)[Response.Status],
actualResult = if status = 500 then null else result
in
actualResult,
(iteration) => #duration(0, 0, 0, Number.Power(2, iteration)),
5)
in
if waitForResult = null then
error "Value.WaitFor() Failed after multiple retry attempts"
else
waitForResult
Découvrez comment configurer l’option Configurer Exécuter après dans Microsoft Power Automate pour gérer efficacement les erreurs et bénéficier d’insights sur les paramètres d’action de flux.