Skip to main content

Tâche HTTP

Pendant l'exécution de votre plan, vous pouvez créer une tâche pour envoyer des requêtes HTTP à un point de terminaison d'une application tierce. Par exemple, lorsqu'une tâche précédente s'exécute, vous pouvez envoyer un message HTTP à un point de terminaison désigné avec les informations de cette tâche.

Dans la vue Plan, vous pouvez créer des tâches HTTP afin d'envoyer une demande aux points de terminaison avant ou après l'exécution d'autres tâches. Vous pouvez également utiliser la tâche HTTP pour générer un jeu de données avec une réponse d'appel API qui peut être utilisée dans le workflow Designer Cloud. Ces tâches sont spécifiées dans le panneau contexte de droite.

  • Une tâche HTTP est une requête entre Alteryx One Platform et une autre application. Ces demandes sont transmises en utilisant HTTP et peuvent être interprétées par l'application réceptrice pour agir.

    Note

    Votre application réceptrice peut exiger que vous mettiez sur liste blanche l'hôte et le numéro de port ou l'adresse IP de la plateforme. Consultez la documentation de votre application.

  • Une tâche HTTP est l'un des types de tâches disponibles dans un plan. Pour en savoir plus, consultez la page Vue plan.

Limites

  • Pour le jeu de données d'entrée (Charger la configuration à partir du jeu de données) :

    • Lignes : 10 000.

    • Taille de fichier : 1 Go.

    • Taille de ligne : 100 Mo.

  • Les requêtes HTTP ont un délai d'expiration de 30 secondes.

  • Les certificats de sécurité personnalisés ne peuvent pas être utilisés.

Conditions préalables

Conditions requises pour l'application réceptrice

Pour envoyer une requête HTTP à une application cible, celle-ci doit être configurée pour recevoir la requête :

  • Les requêtes provenant de l'extérieur du domaine d'application doivent être activées.

    Note

    Votre application réceptrice peut exiger que vous mettiez sur liste blanche l'hôte et le numéro de port ou l'adresse IP de la plateforme. Consultez la documentation de votre application.

  • Vous devez obtenir l'URL du point de terminaison auquel envoyer la requête HTTP.

  • Vous devez obtenir tous les en-têtes HTTP qui doivent être insérés avec chaque requête HTTP.

  • Si la requête doit être signée, une configuration supplémentaire est nécessaire. Les détails sont indiqués ci-dessous.

Création d'une tâche

  1. Faites un glisser-déposer de la tâche HTTP depuis le panneau de gauche vers le canevas du plan.

  2. Dans le panneau de droite, sélectionnez Tâche HTTP. Le panneau Tâche HTTP s'affiche.

Plans_HTTP_Task.png

Figure : Tâche HTTP

Champ

Description

Méthode

Sélectionnez la méthode HTTP à utiliser pour transmettre le message. La méthode appropriée dépend de l'application réceptrice. La plupart des cas d'usage nécessitent la méthode POST.

URL

L'URL où la demande HTTP est reçue par l'autre application.

En-tête

Insérez les en-têtes de contenu HTTP en tant que paires clé-valeur. Par exemple, si le corps choisi est au format JSON, vous devez inclure l'en-tête suivant :

key: Content-Type
value: application/json

Note

Vous devrez peut-être soumettre un jeton d'authentification comme valeur pour la clé d'autorisation.

Corps

(Méthodes POST, PUT, PATCH uniquement). Le corps de la demande envoyée à l'application réceptrice. Le corps de la demande est structuré comme suit :

{"text":"My text message to the receiving application."}

Astuce

Dans les champs dédiés au corps ou à l'en-tête de la demande, vous pouvez insérer des références de métadonnées concernant la définition du plan, l'exécution en cours, les tâches déjà exécutées, les données de colonne ainsi que les sources de données. Pour plus d'informations sur les métadonnées disponibles, consultez Références de métadonnées de plan.

Clé secrète

(Facultatif) Une clé secrète peut être utilisée pour vérifier la charge utile de la demande. Cette valeur secrète doit être insérée à cet emplacement et doit être incluse dans le code utilisé pour traiter les demandes dans l'application réceptrice. Insérez ici la valeur secrète sous forme de chaîne sans guillemets.

Valider le certificat SSL

Lorsque le paramètre est réglé sur true (vrai), les communications HTTPS (SSL) sont établies après vérification de la validité du certificat. Si le certificat est valide, la transmission peut avoir lieu.

Note

Si vous envoyez une demande à un point de terminaison dont le certificat a expiré/n'est pas valide, vous devez désactiver la vérification SSL.

Réessayer

Si le code de statut renvoyé est en dehors de la plage 200-299, la tâche HTTP est considérée comme ayant échoué. Lorsque cette option est activée, la demande est relancée.

Si la demande échoue, cette valeur définit le nombre de nouvelles tentatives. Si ce nombre de tentatives est atteint sans succès, la tâche échoue.

Créer un jeu de données à partir de la réponse

Lorsque cette option est définie sur true (vrai), vous pouvez utiliser le jeu de données pour créer un workflow.

Configuration de la tâche

  1. Définissez les paramètres requis. Pour en savoir plus sur les paramètres, consultez la section Vue plan pour les tâches HTTP.

  2. Vous pouvez spécifier des informations de métadonnées de plan dans les valeurs d'en-tête et le corps de la requête. Pour en savoir plus, consultez la page Références de métadonnées de plan.

  3. Pour tester la connexion, cliquez sur Tester. Un message de confirmation s'affiche.

    Astuce

    Un code de statut 200 indique que le test a réussi.

    Astuce

    Vous pouvez utiliser la méthode GET à des fins de test. Une requête GET ne modifie aucune donnée sur la plateforme cible, mais peut vous permettre de spécifier des éléments dans le corps de la requête.

  4. Pour ajouter la tâche, cliquez sur Enregistrer.

Renommer une tâche

Pour renommer la tâche, cliquez sur le menu Plus > Modifier dans le panneau de droite.

Astuce

Un nom pertinent peut inclure le point de terminaison et la méthode de la plateforme cible, ainsi que les objectifs de la tâche dans votre plan.

Supprimer une tâche

Pour supprimer la tâche, cliquez sur le menu Plus > Supprimer. Confirmez que vous souhaitez supprimer la tâche.

Avertissement

Cette étape est irréversible.

Références de métadonnées de plan

Dans le message de vos autres tâches, vous pouvez faire référence à des métadonnées sur le plan, ses tâches et leur exécution. Pour en savoir plus, consultez la page Références de métadonnées de plan.

Exemples

Message sur le canal Slack

Astuce

Les tâches Slack sont désormais une fonctionnalité de produit prise en charge.

Vous pouvez créer une tâche HTTP pour envoyer un message texte à un canal Slack de votre choix.

Conditions préalables

Configurez votre installation Slack pour recevoir des messages HTTP :

  1. Si nécessaire, créez un canal Slack pour recevoir vos messages.

  2. Créez une application.

  3. Activez les messages HTTP entrants pour votre application.

  4. Spécifiez le canal de réception de vos messages entrants.

  5. Copiez l'URL de la requête HTTP entrante à partir de l'instruction cURL.

Définition de la tâche HTTP

Paramètre

Description

Nom

Ce nom apparaît uniquement dans Alteryx One.

Méthode

Sélectionnez la méthode POST.

URL

Collez l'URL que vous avez copiée depuis Slack.

En-tête

Copiez les en-têtes de contenu à partir de la commande cURL Slack :

key: Content-Type
value: application/json

Corps

{"text":"Your job has completed."}
Vérification

  1. Cliquez sur Tester pour valider le fonctionnement de cette tâche.

  2. Exécutez une tâche et vérifiez si le canal Slack reçoit un message.

Exemples de métadonnées de plan

Vous pouvez référencer les informations de métadonnées de la définition du plan et de l'exécution du plan en cours dans le cadre de la requête de votre tâche HTTP.

Remarques :

  • Vous ne pouvez insérer des références de métadonnées que pour les tâches qui ont déjà eu lieu dans l'exécution du plan avant le début de la tâche HTTP.

  • Chaque tâche de l'exécution en cours est référencée à l'aide d'un code à deux lettres. Exemple :

    {{$http_xx.name}}
Syntaxe

Une référence de métadonnées de plan est construite à l'aide de la syntaxe suivante. Dans la zone de texte appropriée, entrez l'une des valeurs suivantes :

Astuce

Commencez par saisir $, qui donne accès à une arborescence de références de métadonnées pour chacun des types de références de métadonnées. La syntaxe finale est indiquée ci-dessus.

Plans :

Informations de métadonnées provenant de la définition du plan ou de l'exécution du plan en cours :

{{$plan
Informations sur le plan

Le corps de requête suivant contient des références au nom du plan, à l'identifiant de l'exécution du plan et au flux qui vient d'être exécuté :

{"text":"Plan: {{$plan.name}} 
RunId: {{$plan.runId}}
Flow: {{$flow_7p.name}}
Success."}
Informations sur l'exécution du plan

Le corps de requête suivant contient des informations sur l'exécution du plan à l'aide d'horodatages :

{"text":"Plan: {{$plan.name}} 
RunId: {{$plan.runId}}
- plan start: {{$plan.startTime}}
Running time: {{$plan.duration}}

Times:
- last task start: {{$flow_7p.startTime}}
- last task end: {{$flow_7p.endTime}}
"}
Informations sur la tâche HTTP

Vous pouvez faire référence à des informations provenant d'une tâche HTTP qui a déjà eu lieu :

{"text":"{{$http_qg.name}} returned {{$http_qg.statusCode}}."}

Pour en savoir plus, consultez la page Références de métadonnées de plan.

Envoyer des métadonnées d'entrée vers la fonction Clous

Cet exemple montre comment utiliser une tâche HTTP pour fournir des métadonnées de plan aux fonctions AWS Lambda. Une approche similaire pourrait être utilisée pour les fonctions Google Cloud.

Dans ce cas, la valeur rowCount de l'exécution de la tâche de flux est transmise via une tâche HTTP à une fonction AWS Lambda.

Étapes générales :

  1. Définissez votre plan.

  2. Tâche de flux : exécutez le flux pour générer les sorties nécessaires à votre fonction Lambda.

  3. Tâche HTTP : générez une requête HTTP dont le corps inclut une référence à la variable de métadonnées rowCount. Corps de la requête :

    {
 "rowCount": "{{$flow_7p['My Flow Name'].output['My output name'].rowCount}}"
}

  4. Fonctions AWS Lambda : voici un pseudo-code pour Lambda :

    import json
def lambda_handler(event, context):
  httpTaskBody = json.loads(event["body"])
  rowCount = httpTaskBody["rowCount"]

  return {
    'statusCode': 200,
    'body': json.dumps(rowCount)
  }

  5. Fonctions Google Cloud : voici un pseudo-code pour les fonctions Google Cloud :

    def get_row_count(request):
  request_json = request.get_json()
  if request_json and 'rowCount' in request_json:
        rowCount = request_json['rowCount']
    return rowCount
  return 'No rowCount attribute provided'

Créez un jeu de données avec une réponse API pour le workflow Designer Cloud

Utilisez la tâche HTTP dans Plans pour lire et générer des jeux de données avec des réponses d'appel API qui peuvent être utilisées naturellement dans le workflow Designer Cloud.

Définition de la tâche HTTP

Paramètre

Description

Nom

Ce nom apparaît uniquement dans Alteryx One.

Méthode

Champ obligatoire. Sélectionnez la méthode POST ou GET.

URL

Champ obligatoire. L'URL où la demande HTTP est reçue par l'autre application. Exemple : https://example.com/${id}

En-tête

En-têtes de contenu HTTP sous forme de paires clé-valeur au format JSON.

{
  "X-Custom-Header": "value",
  "X-Parametrized-Header": "${wf1.id}"
}

Corps

Le corps de la demande soumise à l'application réceptrice. Peut contenir ${variables}.

{"text":"My text message to the receiving application."}

Étapes générales :

  1. Créez un workflow avec votre entrée.

  2. Créez et exécutez un Plan avec une tâche HTTP pour générer un jeu de données.

    Veillez à désélectionner la case Supprimer le jeu de données avec la réponse d'appel API, afin que la tâche conserve le jeu de données.

  3. Dans Designer Cloud, utilisez le jeu de données généré à l'étape précédente pour créer un workflow en commençant par la réponse API.

    En sélectionnant la case Charger la configuration à partir du jeu de données, vous pouvez charger une configuration (avec tous les paramètres) depuis le jeu de données de sortie de la tâche de workflow en amont.

    Attention

    Consultez la section Limites pour connaître les limites du jeu de données d'entrée.

  4. Dans Plan, ajoutez le workflow en tant que tâche en aval de la tâche HTTP déjà existante. Modifiez le Plan pour que le workflow Designer Cloud utilise comme entrée la sortie de tâche HTTP (définie à l'étape 1).

  5. Vous pouvez planifier le Plan dès maintenant. Cette configuration effectue un appel d'API, la réponse est transmise au workflow Designer Cloud et exécutée. La sortie finale est disponible comme d'habitude.

Vérification des signatures

Avertissement

Selon l'application cible, la mise en œuvre de la vérification des signatures peut nécessiter des compétences de développeur.

Vous pouvez éventuellement configurer la plateforme pour qu'elle signe les requêtes HTTP. La signature des requêtes garantit qu'elles sont envoyées par la plateforme et non par un tiers.

Ci-dessous, découvrez comment créer une signature, afin de pouvoir configurer l'application réceptrice pour qu'elle traite correctement la signature et la requête correspondante.

En-tête de signature

Les requêtes HTTP sont signées en insérant l'en-tête X-Webhook-Signature dans la requête. Ces signatures se présentent sous la forme suivante :

X-Webhook-Signature: t=<timestamp>,sha256=<signature>

emplacement :

  • <timestamp> : horodatage de l'envoi de la signature. La valeur est exprimée en heure UNIX.

  • <signature> : signature SHA256. La plateforme génère cette signature en utilisant un code d'authentification de message basé sur le hachage (HMAC) avec SHA-256.

Plus d'informations sur ces valeurs sont disponibles ci-dessous.

Exemple :

X-Webhook-Signature: t=1568818215724,sha256=55fa71b2e391cd3ccba8413fb51ad16984a38edb3cccfe81f381c4b8197ee07a

Outils de vérification de l'application

En fonction de l'application, il se peut que vous deviez effectuer l'une des séries de tâches suivantes pour vérifier les signatures des tâches :

Note

Il se peut que vous deviez mettre la plateforme sur liste blanche dans votre application. Consultez la documentation de l'application pour plus de détails.

Il se peut que vous deviez créer un codage personnalisé pour votre application. Vous trouverez ci-dessous des détails sur la manière de procéder, y compris un exemple JavaScript.

Traitement des requêtes signées

Horodatage

La valeur de l'horodatage (t=<timestamp>) apparaît au début de la valeur de l'en-tête pour empêcher les attaques par rejeu, où un pirate pourrait intercepter une charge utile valide et sa signature et les retransmettre.

  • Pour éviter de telles attaques, un horodatage est inclus dans l'en-tête de la signature et est intégré dans la charge utile signée.

  • Comme l'horodatage fait partie de la charge utile signée, un pirate ne peut pas modifier sa valeur sans invalider la signature.

    • Si la signature est valide, mais que l'horodatage est trop ancien, vous pouvez alors choisir de rejeter la demande.

    • Par exemple, si vous recevez une requête dont l'horodatage correspond à une date antérieure d'une heure, vous devriez probablement la rejeter.

  • Pour plus d'informations sur les attaques par rejeu, consultez la page https://en.wikipedia.org/wiki/Replay_attack.

Signature

La signature de la tâche comprend, dans sa valeur hachée :

  • La clé secrète (saisie ci-dessus)

  • La valeur d'horodatage

  • Les données de la requête :

    • (POST/PUT/PATCH) : le corps de la requête

    • (GET/DELETE) : l'URL de la requête

Étape 1 : Extraire l'horodatage et les signatures

Fractionner l'en-tête X-Webhook-Signature :

  1. Fractionnez les valeurs en utilisant le caractère , comme séparateur.

  2. Fractionnez chacune des parties à l'aide du caractère =.

  3. Extrayez les valeurs de l'horodatage et de la signature. Dans l'exemple ci-dessus :

    1. horodatage : 1568818215724

    2. signature : 55fa71b2e391cd3ccba8413fb51ad16984a38edb3cccfe81f381c4b8197ee07a

Étape 2 : Créer la signature attendue

Dans l'application réceptrice, vous pouvez recalculer la signature pour vérifier que la requête a bien été envoyée par la plateforme.

  1. Concaténez l'horodatage, le point . et le corps de la demande (méthodes POST/PUT/PATCH) ou l'URL (méthodes GET/DELETE).

  2. Supposons que l'exemple ci-dessus soit la signature d'une requête POST et que le corps de la requête soit test. La valeur concaténée est la suivante :

    1568818215724.test

  3. Vous pouvez maintenant calculer le code d'authentification HMAC dans votre application réceptrice. Dans l'exemple JavaScript suivant, la valeur de la clé secrète est mySecret :

    const crypto = require('crypto');

const message = '1568818215724.test'; // as defined above

const hmac = crypto.createHmac('sha256', 'mySecret');
hmac.update(message)
const expectedSignature = hmac.digest('hex');
Étape 3 : Comparer les signatures

La valeur renvoyée par votre code et la valeur incluse en tant que signature dans l'en-tête X-Webhook-Signature doivent être comparées :

  • Si les valeurs ne correspondent pas, rejetez la requête.

  • Si les valeurs correspondent, calculez la différence entre l'horodatage actuel et l'horodatage de l'en-tête. Si la différence est en dehors de la limite autorisée, rejetez la requête.

  • Dans le cas contraire, traitez la requête normalement dans votre application.

Charger la configuration HTTP à partir du jeu de données

Si vous devez créer une ou plusieurs demandes API dynamiques, vous pouvez utiliser Designer Cloud pour définir une sortie contenant la configuration. Cette sortie est ensuite transmise à la tâche HTTP dans Plans.

Pour définir une sortie avec la configuration et l'utiliser pour la tâche HTTP, procédez comme suit :

  1. Créez un workflow dans Designer Cloud. Pour plus d'informations, consultez la section Créer des workflows.

  2. Dans le workflow, définissez un format de fichier de sortie CSV contenant les colonnes suivantes (les noms ne sont pas sensibles à la casse) :

    • Méthode (chaîne, valeurs : GET | POST | DELETE | PUT),

    • URL (chaîne, l'URL de la demande),

    • En-têtes (chaîne, liste d'en-têtes avec des valeurs au format {« Nom » : « Valeur », « Nom » : « Valeur »,…}),

    • Corps (chaîne).

  3. Accédez à Plans et créez un plan.

  4. Ajoutez une tâche Designer Cloud et sélectionnez le workflow nouvellement créé.

  5. Ajoutez une tâche HTTP après la tâche Designer Cloud et connectez-la à une ligne de connexion.

  6. Dans la configuration HTTP, sélectionnez les cases Charger la configuration à partir du jeu de données et Charger la configuration à partir du jeu de données.

  7. Cliquez sur le bouton Sélectionner un jeu de données d'entrée.

  8. Choisissez la tâche Designer Cloud et ses données de sortie avec la configuration HTTP.

  9. Sélectionnez Confirmer.

  10. La case Créer un jeu de données à partir de la réponse est automatiquement cochée. Vous pouvez personnaliser le nom du jeu de données et exécuter le plan.

Note

Chaque ligne du fichier de configuration de sortie correspond à une demande distincte. La réponse à chaque demande sera ajoutée sous forme de ligne dans le jeu de données de sortie.

Utiliser la réponse HTTP comme entrée de la tâche en aval

Après avoir configuré la tâche HTTP pour créer un jeu de données à partir de la réponse, vous pouvez utiliser ce jeu de données comme entrée des tâches en aval.

Pour utiliser le jeu de données comme entrée d'une tâche en aval, procédez comme suit :

  1. Dans la configuration HTTP, cochez la case Créer un jeu de données à partir de la réponse.

  2. Ajoutez une tâche Designer Cloud après la tâche HTTP et connectez-la à une ligne de connexion.

  3. Dans la tâche Designer Cloud, sélectionnez le workflow souhaité.

  4. Dans la liste des entrées du workflow, sélectionnez Remplacer sur l'entrée que vous souhaitez remplacer par la réponse de la tâche HTTP.

  5. Sélectionnez la tâche HTTP et sa sortie.

  6. Sélectionnez Confirmer et exécutez le Plan.

Dans cette section​: