Envoi en masse

La fonction d’envoi en bloc permet aux utilisateurs de créer et de distribuer plusieurs transactions avec un minimum d’effort en utilisant :

• Un modèle éligible, qui sera utilisé pour créer les transactions. Un modèle est « éligible » s’il comporte :

  • Au moins un document autre que le consentement

  • Au moins un rôle d’espace réservé

  • Au moins un champ de signature (pas nécessairement pour le rôle d’espace réservé)

• Un fichier CSV, qui contient des informations sur le signataire pour tous les rôles d’espace réservé

Le reste de cette section aborde les points suivants :

• Supported Languages

• Taille des fichiers et capacité de traitement

• Lancement d’un envoi groupé

• Format d’en-tête CSV

• Exemple de fichier CSV

• Fichiers CSV avec des caractères non ASCII

• Processus de validation

• Planification des envois en bloc

• Tutoriel vidéo

Langues prises en charge

Si la liste des supported languages has been limited noter ce qui suit :

• Les utilisateurs ne seront pas autorisés à générer de nouvelles transactions d’envoi en bloc pour les modèles dont la langue n’est pas prise en charge.

• L’option Envoi groupé sera masquée dans l’interface utilisateur de l’expéditeur (sur la page de liste des modèles ainsi que dans la page Modifier le modèle ).

• Toute tentative de déclenchement d’un envoi en bloc à partir de l’API pour un modèle dont la langue n’est pas prise en charge génère une erreur.

• Lors de la création d’une transaction ou d’un modèle à partir de l’interface utilisateur, si vous sélectionnez un modèle pouvant être envoyé en bloc dans la liste déroulante qui a maintenant une langue non prise en charge, l’option Envoi en bloc de téléchargement sera là car la nouvelle langue de transaction ou de modèle sera automatiquement réinitialisée à la langue de signature par défaut.

• Les transactions d’envoi en bloc déjà générées avec une langue désormais non prise en charge seront toujours traitées, mais généreront une erreur en raison de la langue désormais non prise en charge.

  Taille des fichiers et capacité de traitement

  Notez que l’envoi en bloc est soumis aux limitations suivantes :

  • La taille maximale du fichier est de 8 Mo.

  • Un maximum d’environ 3000 transactions sont traitées par heure.

  En tant que tel, pour un envoi en masse très important, nous vous recommandons de diviser votre demande en petits lots de 1000 lignes par heure. Cela permet d’éviter de bloquer la file d’attente des transactions pour d’autres utilisateurs.

  Si possible, lancez votre envoi groupé pendant le week-end. Cela réduira l’impact sur les autres utilisateurs et vous aidera à traiter vos transactions plus rapidement.

  Lancement d’un envoi groupé

  Conditions préalables

  • La fonctionnalité d’envoi groupé doit être activée sur votre compte.

  • Un modèle éligible et un fichier CSV approprié ont été créés.

    Le fichier CSV doit spécifier l’ID de la méthode de signature. Cet ID est sensible à la casse. Pour la méthode Signing with a Certificate, cet ID est « personalCertificateSigning ».

  Pour lancer un envoi en bloc :

  1. Cliquez sur l’option de menu Modèles . La page Modèles s’affiche.

  2. Cliquez sur le nom d’un modèle éligible. Sa page apparaît.

  3. Dans la section Détails du modèle de cette page, cliquez sur l’icône Envoyer des transactions en bloc .
     L’Explorateur de votre système s’ouvre.

  4. Utilisez l’Explorateur de votre système pour sélectionner un fichier CSV approprié. OneSpan Sign validera son format de fichier. Si le format est valide, le processus d’envoi en bloc commence.

     Lors de l’initiation d’un envoi groupé par SMS, les numéros de téléphone doivent suivre le format E.164 . Par exemple, +44 7923 123456 en Europe et +1 247 123 4567 en Amérique du Nord.

  Format d’en-tête CSV

  Cette section décrit le format d’en-tête CSV pour :

  • Un espace réservé

  • Plusieurs espaces réservés

  Un espace réservé

  Pour les transactions avec un rôle d’espace réservé, la ligne d’en-tête d’un fichier CSV doit avoir le format suivant :

  {PlaceholderRoleName},FIRST_NAME,LAST_NAME,EMAIL,AUTH_TYPE,AUTH_PROMPT,AUTH_CHALLENGE,SIGNER_VERIFICATION,FieldId1,FieldId2

  Notez que :

  • La chaîne {PlaceholderRoleName} n’apparaîtra pas dans le fichier. Au lieu de cela, il s’agira du nom d’un rôle d’espace réservé. De même, les chaînes de FieldId1 caractères et FieldId2 n’apparaîtront pas dans le fichier. Au lieu de cela, il s’agira de noms d’ID de champ.

  • {PlaceholderRoleName}, FIRST_NAME, LAST_NAMEet EMAIL sont des champs obligatoires. Tous les autres sont facultatifs.

  • Les AUTH_TYPEparamètres , AUTH_PROMPTet AUTH_CHALLENGE sont traités par OneSpan Sign comme un seul AUTH champ.

  • A FieldId est l’ID d’un champ qui appartient à un rôle d’espace réservé. Il peut être utilisé pour remplir automatiquement ce champ dans vos documents. La ligne d’en-tête peut comporter autant de ces champs que nécessaire.

  • Les lignes sous la ligne d’en-tête fournissent des valeurs pour les paramètres de la ligne d’en-tête. Il y a une ligne de ce type pour chaque transaction.

  • Si vous souhaitez spécifier une méthode de vérification du signataire externe (SIGNER_VERIFICATION) telle que PCC ou DIGIPASS, veuillez contacter notre équipe d’assistance.

  Plusieurs espaces réservés

  Si vos transactions contiennent plus d’un rôle d’espace réservé, vous devez ajouter un ensemble de champs d’en-tête pour chaque rôle supplémentaire. Tous les champs obligatoires doivent être présents pour chaque rôle d’espace réservé. Par exemple, un en-tête contenant uniquement les champs obligatoires pour deux rôles d’espace réservé peut ressembler à ceci :

  Placeholder1,FIRST_NAME,LAST_NAME,EMAIL,Placeholder2,FIRST_NAME,LAST_NAME,EMAIL

  Le {PlaceholderRoleName} champ définit toujours le début d’un bloc de rôle. Notez que :

  • Chaque bloc de rôle doit contenir tous les champs obligatoires.

  • Au sein d’un bloc de rôle donné, l’ordre des champs n’a pas d’importance. Portez une attention particulière au libellé de la phrase précédente car : (1) le AUTH champ comporte trois colonnes ; (2) Le FieldId champ peut avoir plusieurs paramètres et donc plusieurs colonnes.

  Ainsi, le format suivant est valide, même si l’ordre des champs diffère entre ses deux blocs de rôle :

  Placeholder1,EMAIL,LAST_NAME,FIRST_NAME,Placeholder2,FIRST_NAME,EMAIL,LAST_NAME

  Exemple de fichier CSV

  Voici un exemple de fichier CSV pour une transaction avec deux signataires :

  Signer1,FIRST_NAME,LAST_NAME,EMAIL,AUTH_TYPE,AUTH_PROMPT,AUTH_CHALLENGE,AUTH_PROMPT,AUTH_CHALLENGE,SIGNER_VERIFICATION,Signer2,FIRST_NAME,LAST_NAME,EMAIL,AUTH_TYPE,AUTH_PROMPT,AUTH_CHALLENGE,AUTH_PROMPT,AUTH_CHALLENGE,CUSTOMER_ID,SIGNER_VERIFICATION Signer1,David,Smith,dsmith@onespan.com,NONE,,,,,personalCertificateSigning,Signer2,Roger,Waters,rwaters@eSignLive.com,NONE,,,,133487, DIGIPASS

  (1) AUTH_TYPE se voit attribuer la valeur NONE pour les deux signataires ; (2) 133487 est le CUSTOMER_ID.

  Fichiers CSV avec des caractères non ASCII

  Si les données que vous devez mettre dans le fichier CSV contiennent des caractères non ASCII (par exemple, des caractères accentués, des caractères chinois), le fichier CSV doit être enregistré avec un codage UNICODE UTF-8.

  Par défaut, Microsoft Excel enregistre les fichiers au format CSV à l’aide du codage ANSI. La procédure suivante décrit comment enregistrer des fichiers Excel au format CSV à l’aide de l’encodage UNICODE.

  Pour enregistrer un fichier Excel au format CSV à l’aide de l’encodage UNICODE UTF-8 :

  1. Ouvrez le fichier dans Microsoft Excel.

  2. Dans le menu supérieur, cliquez sur Fichier > Enregistrer sous, puis accédez au répertoire de votre choix.

  3. Sélectionnez Enregistrer sous le type > CSV (délimité par des virgules) (*.csv).

  4. À côté du bouton Enregistrer , cliquez sur Outils > Options Web....

  5. Cliquez sur l’onglet Encodage .

  6. Cliquez sur Enregistrer ce document au format Unicode (UTF-8), >.

  7. Dans la fenêtre Options Web, cliquez sur OK.

  8. Enregistrez le fichier.

  Processus de validation

  OneSpan Sign valide la ligne d’en-tête avant de valider toute autre ligne d’un fichier CSV. Si quelque chose ne va pas avec la ligne d’en-tête, un message d’erreur est envoyé. Si la validité de la ligne d’en-tête est vérifiée, OneSpan Sign procède à la validation des autres rangées.

  Le reste de cette section traite de la validation des éléments suivants :

  • Ligne d’en-tête

  • Autres rangées

  • Champ AUTH

  Ligne d’en-tête

  OneSpan Sign vérifie que dans la ligne d’en-tête du fichier CSV :

  • Pour chaque rôle d’espace réservé dans le modèle, il existe un bloc de rôle qui contient {PlaceholderRoleName}des champs , FIRST_NAME, LAST_NAME, et EMAIL .

  • Chaque FieldId colonne correspond à un champ qui existe pour le rôle associé.

  Autres rangées

  OneSpan Sign vérifie que pour chaque bloc de rôle dans chaque ligne après la ligne d’en-tête :

  • Des valeurs ont été attribuées aux FIRST_NAMEcolonnes , LAST_NAMEet EMAIL .

  • La valeur de chacun FieldId est valide. La signification de « valide » dans ce contexte dépend de la façon dont vous avez configuré le champ (par exemple, vous avez peut-être attribué une longueur maximale à un champ de texte). Pour mieux comprendre les possibilités, consultez Ajout de champs à un document.

  Champ AUTH

  AUTH_TYPE, AUTH_PROMPTet AUTH_CHALLENGE constituent ensemble le «AUTH champ » d’un bloc de rôle donné.

  La valeur attribuée à AUTH_TYPE doit être NONE, CHALLENGE, SSOou SMS. Le processus de validation de AUTH_PROMPT et AUTH_CHALLENGE dépend de la valeur attribuée à AUTH_TYPE, comme expliqué dans le reste de cette section.

  S’il s’agit AUTH_TYPE = NONE d’un rôle particulier, OneSpan Sign n’essaie pas de valider AUTH_PROMPT ou AUTH_CHALLENGE pour ce rôle. C’est parce qu’ils ne sont pas utilisés (voir l’exemple de fichier CSV ci-dessus).

  Si AUTH_TYPE = CHALLENGE , pour un rôle particulier, OneSpan Sign le vérifie pour ce rôle :

  • Au moins une AUTH_PROMPT/AUTH_CHALLENGE paire a été spécifiée.

  • Il existe une correspondance 1:1 entre les invites et les défis (c’est-à-dire que pour chaque invite, il y a un défi - et vice versa).

  OneSpan Sign lit les colonnes d’invite et d’interrogation de gauche à droite, ce qui signifie que les deux éléments suivants sont des schémas de classement valides :

  AUTH_TYPE	AUTH_PROMPT	AUTH_CHALLENGE	AUTH_PROMPT	AUTH_CHALLENGE
  DÉFI	Question1	Réponse1	Question2	Réponse 2
  AUTH_TYPE	AUTH_PROMPT	AUTH_PROMPT	AUTH_CHALLENGE	AUTH_CHALLENGE
  DÉFI	Question1	Question2	Réponse1	Réponse2

  Les exemples ci-dessus illustrent que toutes les AUTH colonnes doivent apparaître dans l’ordre dans lequel elles sont censées être utilisées. Voici un autre exemple qui illustre ce concept : Answer2, Answer1, Question1, Question2 n’est pas un ordre valide.

  Si AUTH_TYPE = SMS , pour un rôle particulier, OneSpan Sign vérifie qu’il y a au moins une invite pour ce rôle . Le processus de vérification n’examinera que la première invite, qui doit être utilisée pour spécifier le numéro de téléphone auquel un message SMS sera envoyé. Le processus de vérification ignore tous les autres paramètres d’invite et de défi.

  Planification des envois en bloc

  Les transactions d’envoi en bloc sont placées dans une file d’attente. Toutes les 15 minutes, la file d’attente est vérifiée. Si de nouvelles tâches d’envoi en bloc sont arrivées, elles sont traitées dans l’ordre jusqu’à ce que la file d’attente soit vide.

  Tutoriel vidéo