1 sur 45

EFORMASPX

Aperçu

L’application de workflow EFORMASPX vous permet d’afficher et de remplir les différents champs de votre formulaire électronique à travers un formulaire Web. Un formulaire Web est un équivalent ASP.NET à un formulaire Windows. Il possède des caractéristiques similaires à un formulaire Windows.

XMLTRANS

Aperçu

L’application de workflow XMLTRANS transforme n’importe quel document XML en n’importe quel autre format en utilisant une feuille XSLT.

Mode de fonctionnement

UPDATEPROCESSDATA

Aperçu

L'application de workflow UPDATEPROCESSDATA vous permet de modifier la valeur d’une donnée d’un processus pour une demande donnée. Elle fournit un moyen simple d’interagir entre différents processus, puisqu’une demande peut modifier une ou plusieurs données d’une autre demande.

Utilisation des paramètres par défaut

Numéro de la demande à modifier

Le paramètre REQUEST_ID de direction IN et de type numérique est obligatoire et doit contenir un numéro de demande valide.

Action

Les paramètres optionnels sont le ou les noms des données qui devront être modifiées.

Dans un processus, pour créer une action de type UPDATEPROCESSDATA, utilisez les paramètres suivantes :

REQUEST_ID envoie la valeur de la donnée :
- Donnée : REQUEST_ID_UPDATE
AMOUNT envoie la valeur de la donnée :

Vous devriez ajouter une gestion d’exception sur l’action de type UPDATEPROCESSDATA en cas d’erreur (par exemple, numéro de demande invalide).

📌 Exemple

Si vous souhaitez modifier la donnée AMOUNT (montant) avec la valeur de la donnée de processus AMOUNT_UPDATE, l’ID de demande à modifier est stocké dans une donnée de processus REQUEST_ID_UPDATE.

COMPLETEACTION

Aperçu

L'application de workflow COMPLETEACTION vous permet de compléter une action en cours avec les paramètres correspondant. Elle fournit une solution pour interagir et synchroniser des processus entre eux.

Paramètres

Demande

Action

Paramètres facultatifs

Les paramètres facultatifs sont les paramètres de l'action à compléter. Vous devrez définir ces paramètres dans les paramètres d'action correspondants. Vous pouvez ajouter autant de paramètres facultatifs qu'il y a de paramètres de l'action à compléter.

📌 Exemple

Si vous souhaitez compléter une action de type procédure Web asynchrone nommée MYASYNCACTION et qui possède le paramètre suivant :

AMOUNT reçoit la valeur de la donnée TOTAL (vous devez créer cette donnée dans votre processus)

Alors dans votre processus, ajoutez une action de type COMPLETEACTION avec les paramètres suivants :

Vous devriez ajouter une gestion d’exception sur l’action de type COMPLETEACTION en cas d’erreur (par exemple, numéro de demande invalide ou numéro d’action invalide, etc...).

GETPROCESSDATA

Aperçu

L'application de workflow GETPROCESSDATA vous permet de récupérer la valeur d’une ou de plusieurs données d’une demande. Elle fournit un moyen simple d’interagir entre différents processus.

Dans certains cas, cette application peut remplacer l’appel à un sous-processus et ainsi éviter la gestion parfois contraignante des versions entre les processus fils et parents.

GETFORMDATA

Aperçu

L'application de workflow GETFORMDATA vous permet de récupérer la valeur des champs d’une demande donnée. Cela peut être utile pour récupérer les données d’un formulaire qui ne sont pas mappées aux données du processus.

GETFORMDATA ne peut être utilisé qu'avec des champs et des données de type TEXT, NUMERIC et DATETIME.

Utilisation des paramètres par défaut

Numéro de demande

Le paramètre REQUEST_ID de direction IN et de type numérique est obligatoire et doit contenir un numéro de demande valide.

Action

Tout autre paramètre permet de récupérer les valeurs des champs dans les données du processus exécutant l’application GETFORMDATA.

Nom du paramètre : l’identifiant complet du champ dans le formulaire (ex. : REQUEST_COMPANY)
Récupérer la valeur dans : la donnée de processus à mettre à jour

📌 Exemple

Pour récupérer la valeur du champ REQUEST_COMPANY dans une donnée du processus nommée CUSTOMER_COMPANY, ajoutez une action de type GETFORMDATA avec comme paramètres :

Nom du paramètre : REQUEST_ID
Envoyer la valeur de : l’identifiant d’une demande valide
Nom du paramètre : REQUEST_COMPANY

La donnée du processus et le champ du formulaire doivent être du même type.
Vous devriez ajouter une gestion d’exception sur l’action de type GETFORMDATA en cas d’erreur (par exemple, numéro de demande invalide, etc.).

CANCELREQUEST

Aperçu

L’application de workflow CANCELREQUEST vous permet d’annuler une demande en cours.

Paramètres

Paramètre obligatoire

Paramètre facultatif

COPYDATA

Aperçu

L’application de workflow COPYDATA copie les données depuis un paramètre dans une autre donnée.

Mode de fonctionnement

Tous les paramètres sont facultatifs, et les noms des paramètres peuvent être réglés par le créateur du processus. Pour copier un ensemble de données dans un autre, la seule action requise est de définir la valeur par défaut avec les données à copier, puis de définir l’ensemble de données dans lequel les données seront copiées (pour autant que le type de données soit compatible). Les directions des paramètres doivent être INOUT. Il n’y a aucune limite au nombre de paramètres.

Paramètres facultatifs

Exemples de paramètres

DocuSign

Au travers des applications DOCUSIGNSEND et DOCUSIGNCHECK, vous avez la possibilité de faire signer électroniquement des documents au travers de DocuSign et de les récupérer dans WorkflowGen.

DOCUSIGNSEND

L'application de workflow DOCUSIGNSEND vous permet d'envoyer un ou plusieurs documents à DocuSign pour signature électronique.

L'application de workflow DOCUSIGNCHECK vous permet de vérifier le statut d'une enveloppe et de télécharger son fichier associé, qui est une concaténation de fichiers joints.

Adobe Sign

Au travers des applications ADOBESIGNSEND et ADOBESIGNCHECK, vous avez la possibilité de faire signer électroniquement des documents au travers de Adobe Sign et de les récupérer dans WorkflowGen.

ADOBESIGNSEND

L'application de workflow ADOBESIGNSEND vous permet d'envoyer un ou plusieurs documents à Adobe Sign pour signature électronique.

L'application de workflow ADOBESIGNCHECK vous permet de vérifier le statut d'un agrément et de télécharger son fichier associé, qui est une concaténation de fichiers joints.

Docaposte

Au travers des applications DOCAPOSTESEND et DOCAPOSTECHECK, vous avez la possibilité de faire signer électroniquement des documents au travers de Docaposte et de les récupérer dans WorkflowGen.

L'application de workflow DOCAPOSTESEND vous permet d'envoyer un ou plusieurs documents à Docaposte pour signature électronique.

Yousign

Au travers des applications YOUSIGNSEND et YOUSIGNCHECK, vous avez la possibilité de faire signer électroniquement des documents au travers de Yousign et de les récupérer dans WorkflowGen.

L'application de workflow YOUSIGNSEND vous permet d'envoyer un ou plusieurs documents à Yousign pour signature électronique.

Dropbox Sign

Les applications DROPBOXSIGNSEND et DROPBOXSIGNCHECK permettent de faire signer électroniquement des documents via Dropbox Sign et de les récupérer dans WorkflowGen.

L’application DROPBOXSIGNSEND facilite l’intégration des services Dropbox Sign dans les processus de workflow. Elle permet l’envoi de documents pour signature électronique, la gestion des signataires ainsi que la personnalisation de l’expérience de signature.

OpenAI

Avec l'intégration OpenAI, vous avez la possibilité d'interagir avec les modèles d'extraction audio via OPENAITRANSCRIPTION, ou avec les modèles de complétion via OPENAICHAT.

Avec l'application OPENAIADDMESSAGE, vous pourrez gérer facilement l'historique des messages.

L'application de workflow OPENAITRANSCRIPTION vous permet d'interagir avec un modèle audio OpenAI pour transcrire un fichier audio.

OPENAIADDMESSAGE

Aperçu

L'application de workflow OPENAIADDMESSAGE vous permet de mettre à jour l'historique des messages d'une conversation pour y ajouter des interactions utilisateurs ou d'outils. Il est aussi possible de mettre à jour l'historique directement depuis un sous-processus.

Paramètres requis

Paramètre

Type

Direction

Description

Paramètres facultatifs

Paramètre

Type

Direction

Description

GETAGENTTOOLDATA

Aperçu

L'application de workflow GETAGENTTOOLDATA permet d'extraire les informations d'un outil qui peut être fourni par une application comme OPENAICHAT.

Mode de fonctionnement

L'application permet d'extraire le nom, l'identifiant et les paramètres de l'outil en manipulation.
Il est aussi possible d'extraire les paramètres un par un en spécifiant le nom du paramètre directement dans le nom.

Paramètres

Paramètre

Type

Direction

Description

Exemple

Entrée

Paramètre

Valeur

Sortie

Paramètre

Valeur

GETAGENTTOOL

Aperçu

L'application de workflow GETAGENTTOOL permet d'extraire un outil et ses informations d'une liste d'outils qui peut être fourni par une application comme .

XMLTOJSON

L’application de workflow XMLTOJSON offre un moyen fiable de convertir du contenu XML structuré en contenu JSON équivalent. Elle est particulièrement utile lors du traitement de données de formulaire, de fichiers de configuration ou de réponses d’API initialement encodés en XML, mais qui doivent être utilisés dans des environnements ou des workflows où le format JSON est privilégié.

Paramètres

Nom

Type

Direction

Description

EXTRACTTEXT

Aperçu

L’application de workflow EXTRACTTEXT extrait le contenu texte d’un fichier en entrée (.pdf, .docx ou .txt) et retourne le texte extrait ainsi que sa longueur. Elle prend en charge des paramètres optionnels pour la taille maximale du fichier, le découpage et la normalisation du texte (sauts de ligne au format Unix).

Paramètres requis

Paramètre

Type

Direction

Description

Paramètres facultatifs

Paramètre

Type

Direction

Description

CHECKREQUESTEMBEDDINGS

L’application de workflow CHECKREQUESTEMBEDDINGS vérifie si les champs de données d’une demande ont été indexés avec des embeddings pour déclencher des branches conditionnelles dans un processus.

Paramètre requis

Paramètre

Type

Direction

Description

XMLTODATABASE

Aperçu

L’application de workflow XMLTODATABASE vous permet d’exporter les données depuis un document XML vers une ou plusieurs bases de données. C’est une application asynchrone qui ne nécessite pas d’action d’un utilisateur. La configuration des transactions SQL est effectuée via un fichier XML qui active les requêtes SQL sur des sources de données ODBC ou OLEDB.

Mode de fonctionnement

Le moteur WorkflowGen appelle l’application XMLTODATABASE avec le contexte et les paramètres afin d’obtenir les éléments suivants :

Le document XML contentant les données à exporter
Le fichier de transaction contenant :
- Les informations de connexion à la base de données
- Les informations de localisation des données dans le document XML contenant les données (en utilisant des XPath)

Après que XMLTODATABASE ait rassemblé toutes ces informations, elle est prête à exporter, et retourne ensuite le contexte à WorkflowGen afin que le workflow puisse continuer.

Description du fichier XML

Aperçu

Le document de transactions XML spécifie les commandes SQL qui seront exécutées sur les bases de données. Il est utilisé pour deux fonctions principales: la connexion à la base de données et le mappage des champs de la requête aux champs du document de données XML. N'oubliez pas que le document de données XML (généralement nommé FORM_DATA) peut être construit de plusieurs façons. Pour cette raison, les XPath sont utilisés pour mapper les champs de base de données aux champs XML.

Structure

Toute activité XMLTODATABASE peut avoir un nombre illimité de bases de données et un nombre illimité de commandes par base de données. Cela signifie que l'exportation peut être effectuée vers plusieurs bases de données et que chaque base de données peut avoir plusieurs commandes.

📌 Exemple de fichier de transactions XML

Attributs

Nœud `transaction`

Nœud `database`

Vous pouvez utiliser l'attribut connectionstringname ou l'attribut connectionstring, mais pas les deux.
Il est fortement recommandé d'utiliser un nom de connexion plutôt qu'une chaîne de connexion pour simplifier la gestion multi-environnement.

Nœud `command`

Exemple de nom de chaîne de connexion

Fichier de transactions XMLTODATABASE :

Fichier `web.config` :

Emplacement du fichier XML de transactions

Il y a quatre possibilités différentes pour stocker la définition de la transaction d’une action de type XMLTODATABASE. Dans tous ces cas, la transaction doit être définie ainsi :

Pour trouver la définition de sa transaction une action de type XMLTODATABASE va effectuer une recherche dans l’ordre suivant :

Dans un paramètre nommé TRANSACTIONS_TEXT.
Dans un fichier dont le chemin est dans un paramètre nommé TRANSACTIONS_FILE.
Dans un fichier nommé MyTransaction.xml placé dans le dossier ..\App_Data\Files\XmlToDatabase.

L’ordre de priorité est donc :

Le paramètre TRANSACTIONS_TEXT.
Le paramètre TRANSACTIONS_FILE.
Le fichier MyTransaction.xml.

Définition d’une transaction dans le fichier commun

Le fichier de transaction commun nommé Transactions.xml se trouve dans le répertoire \wfgen\App_Data\Files\XmlToDatabase. L’application XMLTODATABASE effectue une recherche dans ce fichier pour trouver votre transaction.

L’action de type XMLTODATABASE contient les paramètres suivants :

TRANSACTION : Direction IN, type texte
XML : Direction IN, type fichier

Définition d’une transaction dans un fichier spécifique

Si la transaction ne se trouve pas dans le fichier Transactions.xml, l’application XMLTODATABASE effectue une recherche pour un fichier XML du même nom que votre transaction. La transaction devrait être créée dans le fichier MyTransaction.xml.

L’action de type XMLTODATABASE a les mêmes paramètres que pour un fichier commun.

Vous pouvez déplacer la définition de transaction d’un fichier commun à un fichier spécifique sans avoir à modifier la définition de processus en supprimant la transaction du fichier Transactions.xml et ensuite le copier dans un fichier du même nom que votre transaction.

Dans une donnée de type fichier

Si vous ne pouvez pas accéder au dossier ..\App_Data du serveur Web, ou si vous souhaitez inclure votre transaction dans la définition de votre processus (pour pouvoir l’exporter et le partager par fichier XPDL), vous pouvez écrire votre transaction dans une donnée de type fichier de votre processus. Pour ce faire :

Créez une donnée de type fichier contenant votre transaction.
Éditez votre action de type XMLTODATABASE puis ajoutez un nouveau paramètre nommé TRANSACTIONS_FILE et liez-le à la donnée précédemment créée.

Dans une donnée de type texte

À partir de la version 7.15.0 de WorkflowGen, la transaction XML contenue dans les données de processus de type TEXT n'a plus de limite de 4 000 caractères pour la base de données MS SQL Server.

Pour ce faire :

Créez une donnée de type texte contenant votre transaction.
Éditez votre action de type XMLTODATABASE puis ajoutez un nouveau paramètre nommé TRANSACTIONS_TEXT et liez-le à la donnée précédemment créée.

Format des champs dates et numériques

Vous pouvez indiquer à l’application la liste des champs qui doivent avoir un format date ou numérique.

Les paramètres supplémentaires suivants peuvent être utilisés dans les actions qui utilisent XMLTODATABASE:

Format date généré dans les requêtes SQL

Les champs de type date sont formatés comme ci-après : yyyy-mm-dd hh:MM:ss

Format numérique généré dans les requêtes SQL

Les champs de type numérique sont formatés comme ci-après : XXXX.XX

📌 Exemple

Règle : Tous les nœuds trouvés dans le document XML avec le nom REQUEST_DATE et le nœud spécifique situé à /MyData/MonExemple/Champ_Date seront formatés comme des dates.
- Méthode : XML_FIELDS_DATE = //*/REQUEST_DATE, /MyData/MyExample/Date_Field

Détails de l’exécution de la transaction

Les commandes SQL peuvent être exécutées dans des transactions. Si des erreurs interviennent, un « rollback » est exécuté et l’état initial de la base de données est restauré. La valeur de l’attribut transaction du nœud database doit être réglée sur yes.

Si la transaction agit sur plusieurs bases de données, l’exécution des commandes sera multi-transactionnelle : si une erreur intervient dans une commande d’une des bases de données, une restauration générale sera exécutée sur la transaction en question.

Mode test

Les transactions peuvent être testées avant d’être lancées sur les bases de données. La valeur de la constante XmlToDatabaseTestMode dans le fichier de configuration doit être réglée sur Y.

Si cette constante est réglée sur yes et que vous avez spécifié l’usage des transactions sur les nœuds de la base de données, les transitions ne seront pas confirmées (committed) à la fin de l’exécution.

Description du fichier log

Si le paramètre XmlToDatabaseEnableTrace dans le fichier web.config du service Web est réglé sur Y, un fichier de log sera généré dans le répertoire \wfgen\App_Data\LogFiles\XmlToDatabase.

Les entrées du log sont au format suivant :

Date; [Database name;] Transaction name; SQL query; Execution result

Les valeurs execution result sont :

Si la requête a été exécutée avec succès : OK
Si une erreur est intervenue : ERROR : code erreur – description

📌 Exemples

Erreurs d’exécution possibles

Les erreurs suivantes peuvent intervenir lors de l’exécution des transactions :

Exemples d’export

📌 Exemple 1

Structure du fichier XML :

Le nœud command pourrait ressembler à ceci :

La balise XPATH: dans la requête sera remplacée par /data/ qui est la valeur de l’attribut XPath.

La balise PARAM: est utilisée pour identifier un paramètre WorkflowGen à la place d’utiliser un champ XML.

Les XPath ne retournant pas de nœuds utiliseront les valeurs null.
Il n’est pas possible d’utiliser le XPath factorisé en utilisant XPATH:: à la place de XPATH:.

📌 Exemple 2

Voici un exemple plus complexe utilisant la propriété loop.

Structure du fichier XML :

Le nœud command pourrait ressembler à ceci :

Vous devez utiliser deux caractères : (deux points) lorsque vous ne voulez pas utiliser le XPath factorisé dans le nœud command (voir l’exemple ci-dessus).

RAISEEXCEPTION

Aperçu

L'application de workflow RAISEEXCEPTION déclenche les exceptions d'annulation sur les actions spécifiées, contrôlées par l'exception de workflow d'annulation d'action dans le panneau de définition des conditions. Cette application de workflow peut ainsi être appelée par une action pour annuler une ou plusieurs autres actions dans une requête en cours. L'application est convertie en assembly de workflow pour simplifier la configuration et améliorer les performances.

Vous pouvez supprimer l’application dans la console IIS ainsi que le dossier physique sur le serveur (\wfgen\WfApps\WebServices\RaiseException). Par ailleurs, les paramètres d’authentification dans la déclaration de l’application de workflow ne sont pas nécessaires.

Ce dispositif est utile quand une ou plusieurs actions doivent être annulées après qu'un certain point dans le workflow ait été atteint, quoique ces actions aient été déjà activées. Comme exemple, si trois actions parallèles sont actives, mais une des actions parallèles est conclue avant les autres et vos règles de workflow déterminent que les deux autres actions ne sont plus exigées, vous pourriez activer le RAISEEXCEPTION pour annuler les deux autres actions et pour permettre le déroulement du workflow.

De plus, vous pouvez :

Utiliser les paramètres par défaut pour annuler toutes les actions d’une demande identifiée.
Utiliser les paramètres facultatifs pour annuler une liste d’actions instanciées dans une liste de demandes ou pour effectuer une annulation à la place d’un utilisateur défini.
Utiliser les paramètres supplémentaires pour définir plusieurs couples de références d’actions.

Paramètres par défaut

Les paramètres REQUEST_ID et ACTIVITY_NAME doivent être utilisés ensemble.

📌 Exemple

Dans cet exemple, l’application va annuler tous les instances de l’action PENDING_ACTION dans la demande 455 :

Paramètres facultatifs

Les paramètres REQUEST_ID_LIST et ACTIVITY_NAME_LIST doivent être utilisés ensemble.

📌 Exemples

Dans cet exemple l’application va annuler toutes les instances des actions PENDING_ACTION1 et PENDING_ACTION2 dans les demandes 445, 446 et 447 :

Dans cet exemple l’application va annuler toutes les instances des actions nommées PENDING_ACTION dans la demande 445 à la place de Jean Dupont (jdupont):

Paramètres supplémentaires

📌 Exemple

Dans cet exemple l’application va annuler toutes les instances de l’action PENDING_ACTION1 dans la demande 455 et toutes les instances de l’action PENDING_ACTION2 dans la demande 456. Si les actions 455 et 456 n’ont pas d’instance ouverte aucune erreur n’est remontée.

Erreurs d’exécution possibles

Les erreurs suivantes peuvent se produire lors de l’exécution de l’application :

GETUSERSFROMDIR

Aperçu

L’application de workflow GETUSERSFROMDIR permet la récupération d’une liste de noms d’utilisateurs, d’une liste d’emails ou d’une liste des IDs utilisateur. Ces listes s’obtiennent via une action automatique WorkflowGen qui exécute des requêtes SQL sur la base de données WorkflowGen. Elle peut être utilisée pour les notifications automatiques ou pour définir (filtrer) les utilisateurs d’une action d’un processus WorkflowGen.

Définitions

Le caractère x : Le caractère x dans certains noms de paramètres signifie qu’il peut exister plus d’une instance du paramètre. Par exemple, QUERYx_CMD signifie qu’il peut-y avoir QUERY1_CMD, QUERY2_CMD, QUERY3_CMD etc.
Action : Vous devez créer une action WorkflowGen de type GETUSERSFROMDIR pour utiliser cette application.

Liste des champs et macros disponibles pour les requêtes

Voici les champs et macros disponibles pour les requêtes créées dans les paramètres QUERYx_CMD. Ils peuvent être utilisés dans les conditions de ces requêtes afin de filtrer leurs résultats.

📌 Exemples

Cet exemple retourne une liste des noms d’utilisateur des utilisateurs de la province du Québec :

Cet exemple retourne une liste des noms d’utilisateur des utilisateurs dont l’adresse email termine par advantys.com :

Cet exemple retourne une liste des noms d’utilisateur des utilisateurs appartenant au groupe de développement :

Utilisation des paramètres supplémentaires

`QUERY1_CMD` : Exécution d’une requête SQL

Description

Pour lancer une requête SQL vous devez ajouter le paramètre (IN) QUERY1_CMD à l’action. Si le paramètre est vide ou inexistant l’opération ne sera pas exécutée.

📌 Exemple

Cet exemple retourne la liste des utilisateurs de la ville de Montréal dans le paramètre RESULT_LIST :

`RESULT_LIST` / `QUERYx_RESULT_LIST` : Capture du résultat des requêtes

Description

Pour récupérer le résultat de toutes les requêtes (liste des utilisateurs au format chaîne de caractères) vous devez ajouter le paramètre (OUT) RESULT_LIST à l’action. Pour récupérer le résultat individuel par requête vous devez ajouter le paramètre (OUT) QUERYx_RESULT_LIST pour chaque requête.

📌 Exemple

Cet exemple retourne la liste des utilisateurs de Montréal, Toronto et New York dans le paramètre RESULT_LIST. QUERY1_RESULT_LIST contient la liste des utilisateurs de Montréal, QUERY2_RESULT_LIST contient la liste des utilisateurs de Toronto et QUERY3_RESULT_LIST contient la liste des utilisateurs de New York :

À partir de la version 7.15.0 de WorkflowGen, le résultat d'une requête renvoyée dans des données de processus de type TEXT n'a plus de limite de 4 000 caractères pour la base de données MS SQL Server.

`QUERY1_DIR` : Définition de l’annuaire

Description

Vous pouvez définir l’annuaire des utilisateurs sur lequel vous voulez que porte la requête. Vous devez ajouter un paramètre (IN) QUERY1_DIR dans l’action. Si ce paramètre est NULL ou n’existe pas l’annuaire par défaut est WORKFLOWGEN (ou l’annuaire défini comme défaut par l’administrateur).

📌 Exemple

Cet exemple retourne la liste des noms d'utilisateur des utilisateurs de l’annuaire VotreSociété dans le paramètre RESULT_LIST :

`QUERYx_CMD` : Utilisation de plusieurs requêtes

Description

Vous pouvez ajouter plusieurs requêtes dans la même action WorkflowGen et récupérer les résultats dans une liste complète ou dans une liste par requête. Vous devez ajouter le paramètre (IN) QUERYx_CMD dont x est le numéro de la requête. Vous devez ajouter les paramètres (OUT) QUERYx_RESULT_LIST pour récupérer les résultats de chaque requête.

📌 Exemple

Cet exemple retourne la liste des noms d'utilisateur des utilisateurs de Montréal de l’annuaire WORKFLOWGEN dans le paramètre (IN) QUERY1_RESULT_LIST, la liste des noms d'utilisateur des utilisateurs de Montréal de l’annuaire INTRANET dans le paramètre (IN) QUERY2_RESULT_LIST et la liste complète des noms d'utilisateur des deux requêtes dans le paramètre (IN) RESULT_LIST :

`QUERYx_TOP` : Définition du nombre maximum d’enregistrements du résultat

Description

Vous pouvez spécifier le nombre maximum d’enregistrements retournés par les requêtes en ajoutant le paramètre (IN) QUERYx_TOP à l’action. Cette requête ne sera pas capable de retourner plus de résultats que le nombre défini dans ce paramètre.

📌 Exemples

Cet exemple retourne seulement les deux premiers noms d'utilisateur de cette requête :

Cet exemple retourne tous les noms d'utilisateur de cette requête :

`QUERYx_DEFAULT_VALUE` : Définition d’une valeur par défaut

Description

Vous pouvez définir une valeur par défaut à retourner pour les valeurs qui ne retournent pas de valeur. Vous devez ajouter un paramètre (IN) QUERYx_DEFAULT_VALUE à l’action.

📌 Exemple

Dans cet exemple, la requête ne retourne aucune valeur car la société définie n’existe pas. Ainsi le paramètre RESULT_LIST contiendra la valeur défaut1 :

`RESULT_SEPARATOR` : Définition d’un séparateur

Description

Vous pouvez définir un caractère de séparation des résultats dans la liste retournée en ajoutant un paramètre (IN) RESULT_SEPARATOR à l’action. Le séparateur par défaut est , (virgule).

📌 Exemple

Pour cet exemple, la valeur retournée dans le paramètre RESULT_LIST est nom1***nom2***nom3 :

Cet exemple retourne la valeur nom1,nom2,nom3 :

`RESULT_COUNT` / `QUERYx_RESULT_COUNT` : Compteur du nombre d’enregistrements retournés

Description

Vous pouvez récupérer le nombre d’enregistrements retournés par chaque requête ou par toutes les requêtes. Pour le nombre total d’enregistrements retournés par toutes les requêtes vous devez ajouter le paramètre (OUT) RESULT_COUNT à l’action. Pour le nombre d’enregistrements retournés par requête vous devez ajouter le paramètre (OUT) QUERYx_RESULT_COUNT à l’action.

📌 Exemple

L’exemple suivant retourne le nombre total d’enregistrements dans le paramètre RESULT_COUNT et le nombre d’enregistrements par requête (QUERY1 et QUERY2) dans les paramètres QUERY1_RESULT_COUNT et QUERY2_RESULT_COUNT :

Utilisation des paramètres dans les conditions des requêtes SQL

Description

Vous pouvez utiliser des paramètres dans les conditions SQL contenues dans le paramètre QUERYx_CMD. Vous devez ajouter des paramètres IN avec des noms différents des noms réservés suivants :

QUERYx_CMD
QUERYx_DIR
QUERYx_TOP

Vous pouvez alors appeler ces paramètres dans la condition en les préfixant par le caractère @ (arobase).

📌 Exemple

Cet exemple retourne la liste des noms d'utilisateur des utilisateurs de Montréal de l’annuaire WORKFLOWGEN :

N’oubliez pas que le nom du paramètre utilisé dans la condition doit être le même que celui défini dans l’action WorkflowGen.

`QUERYx_CMD` : Utilisation des macros dans les conditions des requêtes SQL

Description

Vous pouvez utiliser des macros dans les conditions SQL contenues dans les paramètres QUERYx_CMD. Vous devez simplement ajouter une macro disponible dans la condition.

📌 Exemple

L’exemple suivant retourne la liste des noms d'utilisateur des utilisateurs membres du groupe Dev venant de Montréal et associés à l’annuaire WORKFLOWGEN :

Il est important de respecter la syntaxe dans la liste des macros disponibles.

`RESULT_LIST_EMAIL` / `QUERYx_RESULT_LIST_EMAIL` : Capture des résultats des requêtes sous forme de liste d’emails

Description

Pour récupérer la liste des emails résultant de toutes les requêtes vous devez ajouter un paramètre (OUT) RESULT_LIST_EMAIL à l’action. Si vous voulez retrouver les emails par requête vous devez ajouter un paramètre (OUT) QUERYx_RESULT_LIST_EMAIL pour chaque requête.

📌 Exemple

Cet exemple retourne la liste des emails des utilisateurs de Montréal et Toronto dans le paramètre RESULT_LIST_EMAIL. Les paramètres QUERY1_RESULT_LIST_EMAIL et QUERY2_RESULT_LIST_EMAIL contiennent respectivement la liste des emails des utilisateurs de Montréal et de Toronto :

Gestion des erreurs dans WorkflowGen

Vous devez ajouter une action corrective liée à l’action GETUSERSFROMDIR afin de gérer les erreurs d’exécution. Cette action corrective est de type manuel et est lancée sur erreur d’exécution. Ainsi vous devez ajouter cette exception sur la transition entre les deux actions. Vous trouverez ci-dessous la liste des erreurs les plus fréquentes retournées par l’application.

Nombre maximum d’enregistrements retournés

Il existe une constante GetUsersFromDirMaxResultNb dans le fichier web.config contenant le nombre maximum d’enregistrements pouvant être retourné par une requête. Cette limite réduit le risque d’une erreur d’expiration d’un temps limite qui peut se produire lorsque les résultats des requêtes sont trop nombreux. Si le nombre d’enregistrements retournés est supérieur à la valeur de cette constante un message d’erreur indiquant que les requêtes retournent trop d’enregistrements (« The queries returned too many records ») sera affiché.

L'application ADOBESIGNSEND crée une enveloppe unique et l'envoie à un ou plusieurs signataires.

Vous pouvez spécifier un ou plusieurs fichiers par action ADOBESIGNSEND. Pour ce faire, utilisez le paramètre FILEx, où x correspond au numéro de fichier (p.ex. : FILE1). Au moins un fichier est requis.

Vous pouvez spécifier un ou plusieurs signataires. Pour ce faire, utilisez la combinaison de SIGNER_NAME_LIST et SIGNER_EMAIL_LIST. Vous pouvez également utiliser SIGNER_NAMEx et SIGNER_EMAILx, où x correspond au numéro du signataire.

Vous pouvez spécifier un rôle par destinataire. Pour ce faire, selon la méthode que vous utilisez pour spécifier les signataires (avec ou sans _LIST), vous pouvez utiliser SIGNER_ROLE_LIST ou SIGNER_ROLEx, où x correspond au numéro du signataire. Valeurs possibles : SIGNER (par défaut), APPROVER, ACCEPTOR, CERTIFIED_RECIPIENT, FORM_FILLER ou DELEGATE_TO_SIGNER, DELEGATE_TO_APPROVER

Des logs d'application sont disponibles. Ceux-ci peuvent être spécifiés en définissant la valeur du paramètre AdobeSignSendLogLevel dans le fichier web.config sur 0 pour désactiver la journalisation, 1 pour les logs d'erreur, 2 pour des logs d'informations ou 3 pour les logs de débogage; la valeur par défaut est 0.

YOUSIGNSEND

Aperçu

L'application de workflow YOUSIGNSEND vous permet d'envoyer un ou plusieurs documents à Yousign pour signature électronique.

Mode de fonctionnement

L'application YOUSIGNSEND crée une enveloppe unique et l'envoie à un ou plusieurs signataires.
Vous pouvez spécifier un ou plusieurs fichiers par action YOUSIGNSEND. Pour ce faire, utilisez le paramètre FILEx, où x correspond au numéro de fichier (p.ex. : FILE1). Au moins un fichier est requis.
Vous pouvez spécifier un ou plusieurs signataires. Pour ce faire, utilisez la combinaison de SIGNER_FIRSTNAME_LIST , SIGNER_LASTNAME_LIST et SIGNER_EMAIL_LIST. Vous pouvez également utiliser SIGNER_FIRSTNAMEx , SIGNER_LASTNAMEx et SIGNER_EMAILx, où x correspond au numéro du signataire.
Des logs d'application sont disponibles. Ceux-ci peuvent être spécifiés en définissant la valeur du paramètre YousignSendLogLevel dans le fichier web.config sur 0 pour désactiver la journalisation, 1 pour les logs d'erreur, 2 pour des logs d'informations ou 3 pour les logs de débogage; la valeur par défaut est 0.

Configuration de l'API Yousign

Création d'une application API Yousign

Dans l'interface d'administration Yousign, cliquez sur l'onglet Intégrations, puis sélectionnez le menu API.
Cliquez sur le bouton Créer une nouvelle clé.
Entrez une description dans le champ Description. Sélectionnez un environnement (qui dépend de votre utilisation), puis sélectionnez les permissions Full-Access.

Paramètres requis

Vous pouvez utiliser l'une des configurations suivantes : avec une liste de signataires ou avec des numéros de signataires.

Avec une liste de signataires

Avec des numéros de signataires

Paramètres facultatifs

Configuration Yousign

Général

Paramètre de retour

Exemples

Avec liste de signataires

Avec numéros de signataire

EXECSQL

Aperçu

L'application de workflow EXECSQL vous permet d'exécuter une ou plusieurs requêtes SQL dans un processus.

Elle vous permet de récupérer des informations au travers de requêtes SELECT par exemple, afin de pouvoir utiliser le résultat dans des conditions du processus.

Mode de fonctionnement

L'application EXECSQL requiert les paramètres CONNECTION_NAME (qui correspond au nom de la connexion) et QUERY (qui correspond à la requête à exécuter).
Il est possible de spécifier une ou plusieurs commandes par action EXECSQL. Pour ceci, les paramètres doivent être préfixés par CMDx_, où x correspond au numéro de la commande (p.ex. : CMD1_).

Paramètres obligatoires

Paramètres facultatifs

Général

Si vous souhaitez alimenter un tableau à l'aide du paramètre FORM_DATA_GRIDVIEW, il est nécessaire que le contenu du FORM_DATA contiennent au moins le schéma XML.
Si la première action du processus est une action EXECSQL, vous devez mettre une valeur par défaut dans le FORM_DATA

Paramètres de requête

Il est possible de définir pour chaque requête des paramètres à utiliser lors de l'exécution. Les paramètres peuvent être définis de deux façons, soit en utilisant le préfixe QUERY_PARAM, soit en utilisant un arobase (@).

📌 Exemple

Vous pouvez utiliser QUERY_PARAM_MyParam ou @MyParam, où MyParam correspond au nom du paramètre défini dans la requête.

Paramètres de retour

Général

Requête `SELECT`

Requête `SCALAR`

Exemples

Requête `SELECT`

Stockage du retour dans des données

Alimentation d'un tableau

Dans le cas où EXECSQL est la première action du processus, vous devez définir une valeur par défaut pour la donnée FORM_DATA contenant le schéma du tableau comme dans l'exemple ci-dessous :

Requête `INSERT`

Voici une autre possibilité pour les paramètres de requête :

Requête `UPDATE`

Requête `DELETE`

Procédure stockée

Le type de requête PROCEDURE ne permet pas de retourner de valeur. Si vous souhaitez retourner une valeur, il faut utiliser le type SELECT.

Requête `SCALAR`

Lancement de plusieurs requêtes

Requêtes avec transactions et gestion des erreurs

RESTAPICLIENT

Aperçu

L'application de workflow RESTAPICLIENT vous permet d'appeler des points de terminaison de l'API REST pour échanger des informations avec d'autres applications via des requêtes HTTP. Elle peut également être utilisée pour créer des intégrations avec des applications extensibles (telles que les services Azure et Slack).

RESTAPICLIENT vous permet également d'appeler un point de terminaison de l'API REST à l'aide de charges utiles application/json ou application/x-www-form-urlencoded. RESTAPICLIENT recevra et traitera ensuite la réponse de l'API externe en mappant le contenu de la réponse avec les paramètres OUT définis.

Mode de fonctionnement

L'application RESTAPICLIENT requiert le paramètre APP_URL, qui correspond au point de terminaison de l'API REST.
Le type de contenu du charge utile de demande par défaut (APP_REQUEST_CONTENT_TYPE) est application/json. Le type de contenu application/x-www-form-urlencoded est également supporté.

Paramètre obligatoire

Paramètres facultatifs

Général

Paramètres `APP_URL` facultatifs

📌 Exemple

Les paramètres définis ci-dessus généreront l'URL suivante dans APP_URL :

Paramètres d'en-tête

📌 Exemple

Les paramètres définis ci-dessus généreront deux en-têtes dans la charge utile de la demande :

Paramètres d'autorisation

L'application supporte également certains paramètres d'en-tête d'autorisation prédéfinis afin d'éviter d'ajouter ces paramètres d'en-tête HTTP avec le nom de paramètre APP_HEADER_xxx.

Un seul en-tête d'autorisation peut être défini, sinon une exception est levée.
APP_AUTH_BEARER_TOKEN équivaut à définir le paramètre d'en-tête APP_HEADER_Authorization.

Charge utile de demande

Il existe deux manières différentes de préparer la charge utile de demande. La première consiste à accéder à la totalité de la charge de demande (voir Définir la charge utile de la demande entière via un paramètre ci-dessous); la seconde consiste à créer le JSON ou l'URL codée via les paramètres IN (voir les sections Charge utile de demande encodée en URL et la Charge utile de demande JSON ci-dessous.

Définir la charge utile de demande entière via un paramètre

Les paramètres suivants peuvent être utilisés lorsque vous avez accès à l'ensemble de la charge utile de demande ou que le type de contenu de la demande n'est pas application/json ni application/x-www-form-urlencoded. Vous pouvez définir la charge de cette demande dans une donnée de type File ou Text ou directement dans la valeur de texte.

APP_REQUEST_CONTENT_FILEa la priorité sur APP_REQUEST_CONTENT.
APP_REQUEST_CONTENT a la priorité sur les paramètres IN utilisés pour créer une charge utile JSON ou encodée en URL.

Charge utile de demande encodée en URL

Les exemples suivants montrent comment créer une charge utile de demande avec application/x-www-form-urlencoded comme type de contenu.

Charge utile de demande en URL standard

Les paramètres suivants sont utilisés pour créer une charge utile de demande encodée en URL standard :

Les paramètres définis ci-dessus généreront la charge utile de demande suivante :

Charge utile de demande JSON encodée dans un nom de clé

Les paramètres suivants permettent de générer une charge JSON encodée dans un nom de clé :

Les paramètres définis ci-dessus généreront la charge utile de demande suivante :

Le paramètre APP_REQUEST_CONTENT_PAYLOAD_NAME est seulement supporté avec le type de contenu de demande application/x-www-form-urlencoded.

Charge utile de demande JSON

Les exemples suivants montrent comment créer une charge utile de demande avec application/json comme type de contenu.

Charge utile de demande JSON standard

Les paramètres suivants sont utilisés pour créer une charge utile de demande JSON simple :

Les paramètres définis ci-dessus généreront la charge utile de demande suivante :

Si vous souhaitez convertir ce JSON en tableau, vous devez définir la valeur du paramètre APP_REQUEST_CONTENT_IS_ARRAY sur Y.

Le paramètre APP_REQUEST_CONTENT_IS_ARRAY défini sur Y générera la charge utile de demande suivante :

Pour savoir comment créer un JSON plus complexe, voir les sections Définition d'un tableau JSON dans une propriété JSON et Définition d'un objet ou d'un tableau JSON dans une propriété JSON avec le paramètre de suffixe __JSON ci-dessous.

Définition d'un tableau JSON dans une propriété JSON

Pour définir un tableau dans une propriété JSON, vous devez définir le chemin de la propriété (par exemple, person.spokenlanguages) suivi du suffixe __X, où X est le numéro d'index du tableau.

Les paramètres suivants permettent de définir un tableau JSON dans une propriété JSON :

Les paramètres définis ci-dessus généreront la charge utile de demande suivante :

Si vous souhaitez définir un tableau JSON d'objets JSON (p.ex. "spokenlanguages": [{"spokenlanguage":"french"}, {"spokenlanguage":"english"}]) dans une propriété JSON, voir la section suivante.

Les paramètres du tableau seront ordonnés en fonction de leur numéro d'index.
Les numéros index n'ont pas de limite (p.ex. person.spokenlanguages__9999).

Définition d'un objet ou d'un tableau JSON dans une propriété JSON avec le paramètre de suffixe __JSON

Pour définir un objet / un tableau JSON dans une propriété JSON, vous devez définir le chemin de la propriété (p.ex. person.children) suivi du suffixe __JSON avec l'objet ou le tableau JSON comme valeur de paramètre.

Les paramètres suivants permettent de définir un objet ou un tableau JSON dans une propriété JSON:

Les paramètres définis ci-dessus généreront la charge utile de demande suivante :

Une exception sera levée si plusieurs propriétés JSON sont spécifiées dans les paramètres IN (p.ex. person.childrenetperson.children__JSON).
Le suffixe __JSON utilise

Charge utile de réponse

L'application supporte le mappage des paramètres OUT avec la réponse HTTP :

Mappage d'une charge utile de réponse JSON avec des paramètres OUT

L'application supporte également des paramètres OUT personnalisés supplémentaires pour mapper la charge utile d'une réponse JSON simple.

📌 Exemple

Charge utile de réponse JSON :

Les paramètres suivants permettront de mapper la charge utile de la réponse dans différentes données de processus :

Pour mapper des JSON complexes, voir la section suivante.

Mappage d'une charge utile de réponse JSON avec des paramètres OUT à l'aide du langage de requête JSONPath

L'application supporte le langage de requête JSONPath (similaire aux expressions XPath en XML). Ce langage vous permet d'extraire des données spécifiques d'un fichier JSON. Pour plus de détails sur la syntaxe JSONPath, voir .

📌 Exemple

Charge utile de réponse JSON :

Par exemple, nous voulons ici obtenir les noms des petits-enfants de Charles âgés de plus de sept ans, et nous voulons également que ces noms soient séparés par un | (en utilisant le paramètre IN APP_JSONPATH_DELIMITER). En même temps, nous allons récupérer l'âge et la date de naissance d'Elizabeth. Pour obtenir ces informations, les paramètres suivants doivent être définis :

Dans le nom du paramètre PARAM1__JSONPATH, le nom de PARAM1 n'est pas pertinent, mais il doit être suivi du suffixe __JSONPATH (deux traits de soulignement sont utilisés dans le suffixe).

Exemple d'utilisation avec l'API Azure REST pour obtenir un jeton d'accès OAuth 2.0 et créer une rubrique Event Grid

Cet exemple montre comment obtenir un jeton d'accès et l'utiliser pour créer une rubrique Event Grid. Cela peut être fait en créant un processus avec deux actions ayant RESTAPICLIENT comme application. Le workflow ci-dessous illustre cet exemple :

Les sections suivantes décrivent les paramètres à déclarer pour chaque action.

Action `GET_TOKEN` : Obtention d'un jeton d'accès OAuth 2.0

Les paramètres suivants sont nécessaires pour obtenir un jeton d'accès afin d'utiliser l'API de gestion Azure Resource. Ce jeton sera stocké dans le paramètre OUT access_token et sera utilisé lors de la création d'une rubrique Event Grid dans la section suivante.

Les paramètres définis ci-dessus généreront la charge utile de demande suivante :

Voici la réponse de l'API Azure :

Le paramètre OUT access_token est mappé avec la propriété JSON access_token.

Pour plus d'informations sur l'obtention d'un jeton d'accès pour utiliser l'API de ressource Azure, voir .

Action `CREATE_TOPIC` : création d'une rubrique Event Grid

Les paramètres suivants sont nécessaires pour créer une rubrique Event Grid à l'aide de l'API de gestion des ressources Azure.

Les paramètres définis ci-dessus généreront la charge utile de demande suivante :

Voici la réponse de l'API Azure:

Pour plus d'informations sur la création d'une rubrique Event Grid et sur l'API Azure REST, voir .

Activation de SSL / TLS

En cas d'erreur Impossible de créer le canal sécurisé SSL / TLS, le chiffrement renforcé doit être activé en exécutant le code suivant dans PowerShell :

Redémarrez votre serveur IIS après avoir exécuté les commandes.