cURL Import and design time testing This section helps you configure the activity via the cURL code snippets, and perform design time testing of the request. |
- cURL Command Text—Multiline design-time text field where a full cURL command can be pasted. Supports both `cm and bash styles.
- cURL import button—Action button that immediately triggers parsing/import of the current cURL Command Text into the activity (method, URL, headers, body, auth, files).
- Test request button—Action button that executes the configured request at design time. While running, it toggles to Cancel. On completion or cancellation it reverts to Test and updates Report field with formatted response or error.
- Report—Multiline text area used to display the outcome of the last cURL import or design-time test execution (success summary, mapping details, warnings, or errors).
|
Cette section vous aide à définir les paramètres liés à la connexion. |
|
Cette section vous aide à définir comment l'activité s'authentifie auprès du serveur. | Authentification : sélectionnez la méthode d'authentification. Les options disponibles sont les suivantes :
- Aucune authentification (No authentication ) : le serveur ne nécessite pas de validation de l'utilisateur pour accepter votre requête.
-
Authentification de base : fournit la validation de l'utilisateur au serveur de réception via le nom d'utilisateur et le mot de passe sécurisé.
Basculez entre les mots de passe simples et sécurisés en sélectionnant l'icône plus et en choisissant l'option souhaitée : Utiliser la chaîne simple (Use simples string) et Utiliser la chaîne sécurisée (Use secure string).
- Jeton du porteur (Bearer token ) : fournit la validation de l'utilisateur au serveur de réception via un jeton de porteur unique généré après la connexion.
- Negotiated authentication—Use the HTTP Negotiate scheme for the runtime to select Kerberos or NTLM (and optionally Digest) based on server challenges. When Authentication is set to Negotiated authentication and Use operating system credentials = True, the current OS user context is used (Windows logon token; on Linux/macOS an existing Kerberos ticket, e.g. from kinit). Set Use operating system credentials = False to enable the Custom credentials field; supply a NetworkCredential (domain / username / password or secure password).
|
Cette section vous aide à définir le comportement de la requête. |
- Cookies supplémentaires : spécifiez manuellement les cookies supplémentaires sous forme de paires clé-valeur.
- Délai d’expiration de la demande : spécifiez le temps d’attente maximal, en millisecondes, avant l’abandon de la demande. La valeur par défaut est de 10 000 millisecondes (10 secondes).
- Continuer en cas d'erreur (Continue On Error) : décidez si l'automatisation doit se poursuivre même lorsque l'activité génère une erreur (Vrai(True), option par défaut). Pour arrêter l'automatisation lorsqu'une erreur se produit, utilisez Faux (False).
- Suivre les redirections (Follow redirects) : décidez si votre demande doit automatiquement suivre les redirections d'URL fournies par le serveur (Vrai(True), option par défaut). Pour ignorer les redirections et utiliser la réponse initiale, utilisez Faux (False).
- Nombre maximal de redirections : spécifiez le nombre de redirections automatiques que vous souhaitez suivre avant de vous arrêter. La valeur par défaut est 3.
|
Stratégie de nouvelle tentative Cette section vous aide à définir le mécanisme de nouvelle tentative en cas d'échec de la demande. | Retenter le type de stratégie (Retry policy type) : spécifiez la méthode de nouvelle tentative des demandes. Les options disponibles sont les suivantes :
- Aucune nouvelle tentative (No retry ) : votre demande n'appelle le serveur qu'une seule fois. En cas d'échec, aucune autre tentative n'a lieu.
- Nouvelle tentative de base (Basic retry ) : réessaye la requête après des échecs en utilisant un délai fixe.
- Nombre de nouvelles tentatives (Retry count) : spécifiez le nombre de nouvelles tentatives. La valeur par défaut est 3.
- Délai : spécifiez le temps fixe entre les nouvelles tentatives en millisecondes. La valeur par défaut est de 500 millisecondes (0,5 seconde).
- Utiliser l'en-tête Réessayer-Après : décidez si la requête doit utiliser l'en-tête Réessayer-Après recommandé par le serveur (Vrai, option par défaut). Pour ignorer la valeur de l'en-tête Réessayer - Après (Retry-After) , utilisez Faux (False).
- Limite de délai : spécifiez le délai maximal autorisé entre les nouvelles tentatives de nouvelle tentative , en millisecondes. La valeur par défaut est de 30 000 millisecondes (30 secondes).
- Codes de nouvelle tentative (Retry status codes) : spécifiez les codes de statut qui doivent déclencher de nouvelles tentatives.
- Retour exponentiel (Exponential backoff ) : Nouvelles tentatives avec des délais croissants entre chaque tentative.
- Nombre de nouvelles tentatives (Retry count) : spécifiez le nombre de nouvelles tentatives. La valeur par défaut est 3.
- Délai initial (Inital Delay ) : spécifiez le délai avant la première nouvelle tentative, en millisecondes. La valeur par défaut est de 500 millisecondes (0,5 seconde).
- Multiplicateur : spécifiez le nombre utilisé pour augmenter le délai après l'échec de chaque demande. La valeur par défaut est 2, ce qui double le délai à chaque fois.
- Utiliser jitter (Use jitter) — Pour les délais, décidez si vous souhaitez ajouter un décalage aléatoire entre 0 et 100 millisecondes pour éviter les nouvelles tentatives synchronisées (Vrai(True), par défaut).
- Utiliser l'en-tête Réessayer-Après : décidez si la requête doit utiliser l'en-tête Réessayer-Après recommandé par le serveur (Vrai, option par défaut). Pour ignorer la valeur de l'en-tête Réessayer - Après (Retry-After) , utilisez Faux (False).
- Limite de délai : spécifiez le délai maximal autorisé entre les nouvelles tentatives de nouvelle tentative , en millisecondes. La valeur par défaut est de 30 000 millisecondes (30 secondes).
- Codes de nouvelle tentative (Retry status codes) : spécifiez les codes de statut qui doivent déclencher de nouvelles tentatives.
|
This section helps you customize how the response will be returned by the server. |
- Always save tesponse as file—Force writing the response body to disk even when an attachment filename is not inferred.
- Enable debugging info—Enable extended debug capture (raw request/response metadata, headers snapshot, timing, retry details) and output to the response object or during design time testing.
- Output file name—Override the server-provided filename (e.g. from Content-Disposition).
- Output file target folder—Control destination folder for the saved response files.
- If the file already exists—Define collision strategy when a file with the resolved name already exists in the target folder. Options:
- Auto rename—Append incremental suffix (_1, _2, …) to produce a unique filename.
- Replace—Overwrite existing file.
- Stop and discard—
- Abort the save operation (and workflow if the exception is not handled) leaving existing file intact.
|
Cette section vous aide à capturer et à stocker la réponse renvoyée par le serveur. | Contenu de la réponse : Capture la réponse du serveur et la stocke dans une variable, pour un traitement futur. Il comprend :
- CodeStatut ( StatusCode ) : code de statut de la réponse HTTP.
- ContenuTexte : la réponse sous forme de texte brut (si disponible).
- ContenuBinaire : Données de réponse brutes pour le contenu non textuel.
- Fichier— Réponse enregistrée sous forme de fichier (ILocalResource) dans votre dossier Téléchargements. Le nom de fichier provient des en-têtes de réponse ou est généré automatiquement pour éviter d'écraser des fichiers.
- En-têtes— Tous les en-têtes de réponse HTTP.
- En-têtes de contenu (ContentHeaders ) - En-têtes spécifiquement liés au contenu de la réponse. Par exemple, Content-Type et Content-Length.
- RawRequestDebuggingInfo—Optional string containing captured low-level request/response details (e.g. constructed request line, headers, retries, timing) populated only when debugging is enabled; empty string otherwise.
|
