Propriétés du tHTTPClient Standard

• Built-In : propriétés utilisées ponctuellement.
• Repository : sélectionnez le référentiel dans lequel sont stockées les propriétés. Les champs suivants sont automatiquement renseignés à l'aide des données récupérées.

Lorsque vous récupérez des données d'un serveur HTTP, vous pouvez spécifier le formatet le contenu des données récupérées à l'aide du schéma, du bouton Guess schema, de l'option Response body format, de l'option Returned content, de l'option Extract a sub-part of the JSON et de l'option Output key/value pairs. Pour plus d'informations, consultez tHTTPClient : configuration et sortie.

• Built-in : le schéma est créé et stocké localement pour ce composant seulement. Pour plus d'informations concernant les schémas des composants dans l'onglet Basic settings (Paramètres simples), consultez Onglet Basic settings.

• Repository : le schéma existe déjà et est stocké dans le Repository. Ainsi, il peut être réutilisé dans des Jobs et projets. Pour plus d'informations concernant les schémas des composants dans l'onglet Basic settings (Paramètres simples), consultez Onglet Basic settings.

Le composant génère automatiquement le schéma en fonction des paramètres associés du composant. Cependant, vous devez définir le schéma manuellement si vous sélectionnez Body dans la liste déroulante Returned content et JSON dans la liste déroulante Response body format. Dans ce cas, vous devez ajouter une colonne pour chaque attribut de premier niveau et configurer le type de la colonne à String pour les attributs ayant des objets JSON imbriqués.

{
    "id": 1,
    "name": "Talend",
    "address": {
       "city": "San Mateo",
       "state": "California",
       "zipcode": "94402"
    }
}

Vous devez ajouter ces colonnes dans le schéma : id (de type Int), name (de type String) et address (de type String). Le composant peut ensuite extraire zipcode de la colonne address à l'aide du langage Data Shaping Selector Language (par exemple, input.address.zipcode).

Par défaut, les colonnes du schéma dépendant de la configuration des options Response body format et Returned content, comme suit.

• Lorsque l'entrée Status, headers, and body est sélectionnée dans la liste déroulante Returned content, le schéma contient trois colonnes : body (de type String), headers (de type String) et status (de type Int).
• Lorsque l'entrée Body est sélectionnée dans la liste déroulante Returned content et que l'option TEXT est sélectionnée dans la liste déroulante Response body format, le schéma contient une colonne : body (de type String).

Lorsque vous récupérez des données d'un serveur HTTP, vous pouvez spécifier le formatet le contenu des données récupérées à l'aide du schéma, du bouton Guess schema, de l'option Response body format, de l'option Returned content, de l'option Extract a sub-part of the JSON et de l'option Output key/value pairs. Pour plus d'informations, consultez tHTTPClient : configuration et sortie.

Créez le schéma en cliquant sur le bouton Edit Schema. Si le schéma est en mode Repository, trois options sont disponibles :

• View schema : sélectionnez cette option afin de voir uniquement le schéma.

• Change to built-in property : sélectionnez cette option pour passer le schéma en mode Built-In et effectuer des modifications locales.

• Update repository connection : sélectionnez cette option afin de modifier le schéma stocké dans le référentiel et décider de propager ou non les modifications à tous les Jobs.

  Si vous souhaitez propager les modifications uniquement au Job courant, cliquez sur No et sélectionnez à nouveau la métadonnée du schéma dans la fenêtre Repository Content.

Vous pouvez définir une valeur factice à l'aide de la syntaxe Data Shaping Selector Language pour remplir certaines parties de manière dynamique avec la valeur extraite provenant de l'enregistrement entrant. Exemple :

Base URL (URL de base) = "https://{.input.job_url}" et Path (Chemin) = "{.input.job_url_path}"

Authentication type

• No authentication (Pas d'authentification) : aucune authentification n'est attendue pour accéder au serveur.
• Basic : un identifiant et un mot de passe sont attendus. Pour plus d'informations, consultez RFC 2617.
• Digest : un identifiant et un mot de passe sont attendus. Pour plus d'informations, consultez RFC 2617.
• Bearer token : un jeton d'accès brut est attendu. Il sera passé dans l'en-tête de la requête HTTP en tant que Authorization: Bearer <votre jeton>.
• NTLM : un identifiant (pouvant contenir un nom de domaine) et un mot de passe sont attendus. Pour plus d'informations, consultez NT LAN Manager (NTLM) Authentication Protocol (en anglais).
• API key : utilise une manière flexible de passer un jeton de clé d'API au serveur, avec la possibilité de sélectionner où le passer, avec quel nom et un préfixe :
  • Destination: sélectionnez où sera configuré le jeton : dans un en-tête HTTP avec le nom donné ou dans un paramètre de requête HTTP avec le nom donné (non recommandé car le jeton peut être visible dans les logs).
  • Name (Nom) : saisissez le nom de l'en-tête ou le paramètre de requête.
  • Prefix (Préfixe) (facultatif) : saisissez le préfixe à ajouter devant le jeton (uniquement si la Destination est Request header (En-tête de la requête)).
  • Token (Jeton) : saisissez le jeton d'authentification.
• OAuth 2.0 gère automatiquement la récupération et le renouvellement du jeton d'accès par rapport au serveur OAuth puis le passe à l'endpoint cible en tant que jeton Bearer :
  • Flow (Flux) : le flux OAuth que vous souhaitez exécuter. Atuellement, seul le flux Client Credentials est supporté.
  • Authentication mode : pour toutes les méthodes d'authentification supportées, les paramètres de flux et de périmètre (scope) sont configurés dans le corps, au format 'application/x-www-form-urlencoded' avec les clés 'grant_type=xxx&scope=xxxx'.
  • Token endpoint : saisissez le jeton d'authentification au format oauth2/mydomain.com/token.
  • Client ID (ID Client) et Client secret (Secret du client) : saisissez l'ID client et le secret du client.
  • Additional parameters (Paramètres supplémentaires) : saisissez les attributs supplémentaires à ajouter, par exemple l'attribut scope.

Pour sélectionner une méthode HTTP, cliquez sur le bouton [...] près de cette option et sélectionnez la méthode HTTP de votre choix dans la boîte de dialogue qui s'ouvre.

Consultez la description du champ Base URL pour plus d'informations.

Vous pouvez définir une valeur factice à l'aide de la syntaxe Data Shaping Selector Language pour remplir certaines parties de manière dynamique avec la valeur extraite provenant de l'enregistrement entrant. Exemple :

Base URL (URL de base) = "https://{.input.job_url}" et Path (Chemin) = "{.input.job_url_path}"

Si l'URL de base ou le chemin contient une valeur factice, vous pouvez ajouter des paramètres à la table et configurer le nom et la valeur du paramètre comme suit pour remplacer la valeur factice.

• Name (Nom) : saisissez le nom de la valeur factice à remplacer.

• Value (Valeur) : saisissez la valeur par laquelle remplacer la valeur factice. Cela peut être une valeur statique (par exemple contactEntity), une valeur extraite de l'enregistrement entrant (par exemple {.input.entity.id}), ou un mélange des deux (par exemple version{.input.api.version}).

Par exemple, avec l'URL de base https://www.example.com et le chemin /{api_version}, vous pouvez configurer le chemin en ajoutant un paramètre à la table, en configurant la colonne Name à api_version et la colonne Value à v1.0.

• Name (Nom) : saisissez le nom du paramètre.
• Value (Valeur) : saisissez la valeur du paramètre. Cela peut être une valeur statique (par exemple UUID-1234567), une valeur extraite de l'enregistrement entrant (par exemple {.input.user.id}), ou un mélange des deux (par exemple UUID-{.input.user.id}).

Exemple : Nom du paramètre de requête = entityId et valeur du paramètre de requête = UUID-1234567

• Name (Nom) : saisissez le nom de l'en-tête.
• Value : saisissez la valeur de l'en-tête. Elle peut être une valeur statique (par exemple text/html;charset=utf-8), une valeur extraite de l'enregistrement entrant (par exemple {.input.meta.content}) ou un mélange des deux (par exemple, text/{.input.document.format};charset={.input.document.charset}).

  Notez que les en-têtes ayant une valeur AUTHENT peuvent être envoyés uniquement avec les requêtes d'authentification OAuth 2.0.

• Query (Requête) : sélectionnez la requête sur laquelle appliquer cette configuration d'en-tête.

Exemple : Nom de l'en-tête = Content-Type et valeur de l'en-tête = text/html;charset=utf-8

• Text : saisissez le corps du message en plein texte dans la zone de texte située sous la liste déroulante. Vous pouvez définir une valeur factice à l'aide de la syntaxe Data Shaping Selector Language pour remplir certaines parties de manière dynamique avec la valeur extraite provenant de l'enregistrement entrant. Exemple :

  id={.input.user.id}
  name={.input.user.name}

• JSON : saisissez le corps du message au format JSON dans la zone de texte située sous la liste déroulante. Vous pouvez définir une valeur factice à l'aide de la syntaxe Data Shaping Selector Language pour remplir certaines parties de manière dynamique avec la valeur extraite provenant de l'enregistrement entrant. Exemple :

  {
   "id": "{.input.user.id}",
   "name": "{.input.user.name}",
   "age": "{.input.user.age}",
   }

• XML : saisissez le corps du message au format XML dans la zone de texte située sous la liste déroulante. Vous pouvez définir une valeur factice à l'aide de la syntaxe Data Shaping Selector Language pour remplir certaines parties de manière dynamique avec la valeur extraite provenant de l'enregistrement entrant. Exemple :

  <user>
   <id>{.input.user.id}</id>
   <name>{.input.user.name}</name>
   <age>{.input.user.age}</age>
  </user>

• Form data et x_www_urlencoded : créez le corps à l'aide d'un formulaire multipart avec des paires nom-valeur d'attributs ou à l'aide d'un formulaire URL-encoded avec des paires nom-valeur d'attributs. Saisissez le nom et la valeur des attributs dans les lignes de la table, sous la liste déroulante. Vous pouvez définir une valeur factice à l'aide de la syntaxe Data Shaping Selector Language pour remplir certaines parties de manière dynamique avec la valeur extraite provenant de l'enregistrement entrant.

La liste déroulante Body type est disponible lorsque vous sélectionnez l'option Request body.

• Text : sélectionnez ce format pour retourner un message plein texte. Dans ce cas, le payload de la réponse n'est pas parsé et il ne sera pas possible d'en extraire une sous-partie.
• JSON : sélectionnez ce format si la réponse reçue est au format JSON. Dans ce cas, le payload est traduit en différents enregistrements JSON correctement parsés.

Lorsque vous récupérez des données d'un serveur HTTP, vous pouvez spécifier le formatet le contenu des données récupérées à l'aide du schéma, du bouton Guess schema, de l'option Response body format, de l'option Returned content, de l'option Extract a sub-part of the JSON et de l'option Output key/value pairs. Pour plus d'informations, consultez tHTTPClient : configuration et sortie.

• Body : si l'option Text est sélectionnée dans la liste déroulante Response body format, un enregistrement avec un attribut de chaîne de caractères nommé body est généré et tout le payload y est copié. Si l'option JSON est sélectionnée dans la liste déroulante Response body format, un enregistrement représentant la structure hiérarchique du document parsé est généré.

• Status, headers, and body : un enregistrement est généré avec un attribut (de type INT) contenant le code de statut HTTP, un attribut headers qui est un enregistrement contenant tous les en-têtes de réponse en tant qu'attributs imbriqués et un attribut body qui est soit une chaîne de caractères simple contenant le payload complet en tant que texte (si l'option Text est sélectionnée dans la liste déroulante Response body format), soit un objet hiérarchique représentant le document parsé (si l'option JSON est sélectionnée dans la liste déroulante Response body format).

Lorsque vous récupérez des données d'un serveur HTTP, vous pouvez spécifier le formatet le contenu des données récupérées à l'aide du schéma, du bouton Guess schema, de l'option Response body format, de l'option Returned content, de l'option Extract a sub-part of the JSON et de l'option Output key/value pairs. Pour plus d'informations, consultez tHTTPClient : configuration et sortie.

Ce champ est facultatif et doit rester vide afin de récupérer la réponse JSON complète.

{
   "description": "List of some famous geologists",
   "content_length": 5,
   "author": "A. Smith",
   "content":[
      {
         "name":"Maurice Krafft",
         "age":35,
         "female":false,
         "address":{
            "city":"Mulhouse",
            "zipcode":68100
         }
      },
      {
         "name":"Katia Krafft",
         "age":49,
         "female":true,
         "address":{
            "city":"Soultz-Haut-Rhin",
            "zipcode":6860
         }
      },
      {
         "name":"Pline l'Ancien",
         "age":55,
         "female":false,
         "address":{
            "city":"Côme",
            "zipcode":22100
         }
      },
      {
         "name":"James Hutton",
         "age":70,
         "female":false,
         "address":{
            "city":"Édimbourg",
            "zipcode":0
         }
      },
      {
         "name":"Aline Peltier",
         "age":40,
         "female":false,
         "address":{
            "city":"Saint-Pierre",
            "zipcode":97410
         }
      }
   ]
}

{"name":"Katia Krafft","age":49.0,"female":true, ...
{"name":"Pline l'Ancien","age":55.0,"female":false, ...
{"name":"James Hutton","age":70.0,"female":false, ...

|=-----------------=|
|field              |
|=-----------------=|
|Soultz-Haut-Rhin   |
|Côme               |
|Édimbourg          |
'-------------------'

Lorsque vous récupérez des données d'un serveur HTTP, vous pouvez spécifier le formatet le contenu des données récupérées à l'aide du schéma, du bouton Guess schema, de l'option Response body format, de l'option Returned content, de l'option Extract a sub-part of the JSON et de l'option Output key/value pairs. Pour plus d'informations, consultez tHTTPClient : configuration et sortie.

Ce champ est disponible si vous sélectionnez JSON dans la liste déroulante Response body format.

La valeur peut provenir de l'entrée du composant ou de la réponse HTTP. Saisissez "{.input.<dssl_path>}" dans le champ Value si la valeur provient de l'entrée du composant ou saisissez "{.response.<dssl_path>}" si elle provient de la réponse HTTP.

Lorsque vous récupérez des données d'un serveur HTTP, vous pouvez spécifier le formatet le contenu des données récupérées à l'aide du schéma, du bouton Guess schema, de l'option Response body format, de l'option Returned content, de l'option Extract a sub-part of the JSON et de l'option Output key/value pairs. Pour plus d'informations, consultez tHTTPClient : configuration et sortie.

Cette option est disponible lorsque l'option Output key/value pairs est sélectionnée.

Pour une réponse MIME multipart avec des pièces jointes, la première part n'étant pas une pièce jointe dans le corps sera traitée comme le corps de l'enregistrement de sortie. La partie de la pièce jointe est indiquée avec l'en-tête Content-Disposition=attachment;... et le nom de fichier de la pièce jointe est pris depuis sa valeur `name=...`. Si le champ name n'est pas fourni dans les métadonnées de l'en-tête, le fichier sera nommé en fonction du nom du service (c'est-à-dire la valeur Path). Si aucune partie n'a l'en-tête Content-Disposition=attachment, la première partie du multipart est traitée comme le corps de l'enregistrement de sortie et les autres parts sont traitées comme des pièces jointes.

Pour les fichiers binaires, le composant tHTTPClient enregistre le corps de la réponse HTTP dans un fichier, sans le modifier. Si aucun nom n'est spécifié dans l'en-tête Content-Disposition, le fichier de résultats sera nommé d'après le nom de la ressource, ave un suffixe _0.

Il n'est pas recommandé d'utiliser cette option dans des environnements de production.

• Proxy type (Type de proxy) : sélectionnez le type de proxy à utiliser, HTTP ou SOCKS. Le proxy HTTP supporte l'authentification basique.
• Proxy host (Hôte du proxy) et Proxy port (Port du proxy) : saisissez l'adresse et le port du proxy.
• Proxy login (identifiant du proxy) et Proxy password (Mot de passe du proxy) : saisissez les identifiants nécessaires à l'authentification au proxy. Ces deux champs sont disponibles uniquement lorsque l'option HTTP est sélectionnée dans la liste déroulante Proxy type.

• Initial backoff (ms) (Backoff initial (ms)) : saisissez la durée d'attente, en millisecondes, avant la première nouvelle tentative d'appel HTTP.
• Backoff factor (Facteur de backoff) : lorsqu'une tentative échoue, la durée d'attente est multipliée par ce facteur, pour augmenter le délai entre chaque appel. Si le facteur est 1, tous les délais seront identiques.
• Maximum number of retries (Nombre maximal de tentatives) : saisissez le nombre maximal de tentatives pour une requête HTTP seule. L'appel initial ne doit pas être inclus dans ce nombre.

Exemple pour la configuration suivante :

Intial backoff (Backoff initial) : 300 ms, Backoff factor (Facteur de backoff) : 2 et Maximum number of retries (Nombre maximal de tentatives) : 4

Le connecteur HTTPClient (Client HTTP) effectue une première opération GET sur le serveur (premier appel). Une erreur d'expiration de la connexion est retournée. Le mécanisme de tentatives est activé et le composant attend 300 millisecondes. Une nouvelle tentative est effectuée (première tentative). Une réponse HTTP 503 est retournée. La durée d'attente est multipliée par 2, le composant attend donc 600 millisecondes. Une troisième tentative est effectuée (deuxième tentative). Une réponse HTTP 503 est retournée. La durée d'attente est multipliée par 2, le composant attend donc 1 200 millisecondes. Une quatrième tentative est effectuée (troisième tentative). Elle réussit. Aucune tentative supplémentaire n'est efffectuée et la réponse est retournée.

• Maximum number of redirects (Nombre maximal de redirections) : configurez le nombre maximal de redirections que doit suivre le connecteur. Si le nombre de redirections dépasse la valeur configurée, la dernière est retournée en tant que résultat de la requête.
• Redirect only on same host (Rediriger uniquement sur le même hôte) : activez cette option si vous souhaitez que les redirections soient effectuées uniquement lors de l'utilisation du même hôte.

Notez que le pagination est uniquement conforme aux payloads JSON et que les éléments souhaités doivent se trouver dans un tableau dans le payload JSON.

Vous devez configurer les options suivantes pour que la pagination fonctionne correctement.

• Preset : sélectionnez la configuration prédéfinie pour le service spécifique supportant la stratégie de pagination en sélectionnant le service correspondant. Pour sélectionner un service, cliquez sur le bouton [...] près de ce champ et sélectionnez le service. Vous pouvez sélectionner l'un des services suivants :
  • BOX : consultez Offset-based Pagination (en anglais) pour plus d'informations.
  • JIRA : consultez JIRA Server platform REST API reference (en anglais) pour plus d'informations.
  • OData : consultez OData Version 4.01. Part 1: Protocol (en anglais) pour plus d'informations.
• Load selected preset : cliquez sur ce bouton pour charger la configuration prédéfinie sélectionnée dans le champ Preset.
• Pagination strategy : sélectionnez la stratégie de pagination à utiliser. Actuellement, la seule stratégie disponible est Offset/limit. La stratégie offset/limit récupère les éléments commençant à une position spécifique dans les pages d'une taille spécifique. Le paramètre offset spécifie l'élément de début en termes d'offset du premier élément. Le paramètre limit spécifie la taille maximale d'une page en termes de nombre d'éléments. Une fois l'option Pagination strategy appliquée, une requête s'arrête lorsque le dernier appel retourne 0 élément.
• Location : spécifiez la manière dont configurer les paramètre d'offset et de limite. Elle peut être Query parameters ou In headers.
• Name of the offset : configurez le nom du paramètre à utiliser comme offset.
• Value of the offset : configurez la valeur de l'offset. Pour commencer du premier élément, configurez la valeur à 0. Vous pouvez obtenir l'offset d'une requête provenant des enregistrements entrants à l'aide de l'expression DSSL '{.input.last_page_info.offset}'.
• Name of the limit : configurez le nom du paramètre définissant le nombre maximal d'éléments autorisés dans une page.
• Value of the limit : configurez la limite, c'est-à-dire le nombre maximal d'éléments pouvant être retournés dans une page. La pagination s'arrête lorsqu'une page est retournée avec 0 élément.
• Path to elements : configurez le chemin d'accès au tableau JSON contenant les éléments souhaités. Il doit correspondre à un tableau JSON. Une fois la stratégie offset/limit appliquée, l'élément spécifié par ce paramètre devient la racine, quelle que soit la configuration de l'option Extract a sub-part of the response. Par exemple, avec l'option JIRA sélectionnée dans la liste déroulante Preset, configurer Path to elements à .issue permet de récupérer les tickets, même si l'option Extract a sub-part of the response est configurée à .key (et si key est un attribut des éléments présents dans les tickets).

• Normalize attributes (Normaliser les attributs) : vous permet de convertir une valeur dans le type de données attendu.
• Normalize arrays (Normaliser les tableaux) : vous permet de filtrer certains éléments d'un tableau JSON.

  Exemple :

  Si vous configurez le composant pour récupérer ce document JSON, ces incohérences JSON seront retournées dans la console d'exécution des Jobs :

  Some JSON inconsistencies has been identified:
  .users.*.addresses is not consistently present in all objects.
  .users.*.active is not consistently present in all objects.
  .users.*.email is not consistently present in all objects.
  .users.*.addresses is an array that contains items of several types: STRING, OBJECT.
  .users.*.addresses.*.country is not consistently present in all objects.
  .users.*.addresses.*.street is not consistently present in all objects.
  .users.*.addresses.*.zipcode is found with varying types: STRING, INT.
  Please, have a look to advanced settings JSON normalization to fix it.

  Pour éviter cela, vous pouvez par exemple utiliser l'option Normalize attributes (Normaliser les attributs) pour convertir l'attribut ayant le chemin .users.*.addresses en type ARRAY et l'attribut ayant le chemin users.*.addresses.*.zipcode en type INT, même si certaines valeurs retournées ont un type String. Vous pouvez également ajouter un attribut manquant, par exemple .users.*.active (vous pouvez ici le convertir en BOOLEAN car il retourne 'true' ou 'false').

  Vous pouvez également utiliser l'option Normalize arrays (Normaliser les tableaux) pour conserver uniquement les éléments OBJECT ayant le chemin .users.*.addresses, même si certaines adresses contiennent des types String.

Cette option est disponible lorsque l'option JSON est sélectionnée dans la liste Response body format de la vue Basic settings du composant.

• Content type : définissez le type de contenu du fichier défini par le protocole HTTP. Consultez https://www.w3.org/Protocols/rfc1341/4_Content-Type.html (en anglais) pour plus d'informations.
• Encoding : configurez l'encodage du fichier.
• Path to file : saisissez le chemin d'accès complet au fichier à charger.
• Attachment name : définissez l'ID de la pièce jointe formé par le protocole HTTP.

L'option Add attachments est disponible lorsque vous sélectionnez l'option Request body et que vous sélectionnez l'option Form data dans la liste déroulante Body type de la vue Basic settings.

Par exemple, un tableau de coordonnées géographiques devant contenir des types Double uniquement peut avoir un de ses éléments de type déduit comme Integer "[47, -1.567075]". Cela peut induire des erreurs, car le connecteur va tenter de générer un tableau de type Integer et d'y inclure un type Double. Forcer le passage de tous les nombres au type Double permet d'éviter ces erreurs.

Cette option est disponible uniquement lorsque vous sélectionnez JSON dans la liste déroulante Response body format de la vue Basic settings.

ERROR_MESSAGE : message d'erreur généré par le composant lorsqu'une erreur survient. Cette variable est une variable After et retourne une chaîne de caractères. Cette variable fonctionne uniquement si la case Die on error est décochée, lorsque le composant contient cette case.

NB_LINE : nombre de lignes lues par un composant d'entrée ou passées à un composant de sortie. Cette variable est une variable After et retourne un entier.