L’envoi d'e-mail sur la version Helios ERP 2024 s'effectuera via le serveur d’application en utilisant le protocole SMTP" Simple Mail Transfer Protocol", qui est un protocole de communication utilisé pour transmettre des courriers électroniques ou e-mails à travers un réseau informatique. SMTP est un élément clé du processus de livraison des e-mails sur Internet.
Pour cela, il faudra configurer dans la codification du flux d’authentification différents paramètres afin de pouvoir utiliser l'envoi d’e-mail dans l’ ERP.
Il sera possible d'utiliser deux types d'envoi que nous définissons ci-dessous.
1. BASIQUE
L'utilisation basique utilisera l'envoi SMTP simple : Il faudra alors renseigner les valeurs des paramètres (server, port, email dans la fiche personnel, mot de passe) avec les informations appropriées pour votre serveur SMTP et votre compte e-mail.
Le mot de passe est stocké de manière sécurisée (crypté en BDD) mais il est recommandé d'utiliser des pratiques d'authentification plus robustes, comme l'utilisation de tokens d'accès OAuth pour l'authentification SMTP.
2. OAUTH 2.0
OAuth 2.0 (Open Authorization 2.0) est un protocole d'autorisation standard utilisé pour permettre à des applications tierces d'accéder aux données des utilisateurs sans divulguer leurs identifiants. Voici un aperçu du processus d'authentification OAuth 2.0 :
Redirection vers le Serveur d'Authentification : L'ERP redirige l'utilisateur vers le serveur d'authentification (également appelé serveur d'autorisation).
Émission du Code d'Autorisation : Si l'utilisateur donne son consentement, le serveur d'authentification émet un "code d'autorisation" qui est renvoyé à l'application tierce. Ce code est temporaire et ne donne pas directement accès aux données.
Échange du Code d'Autorisation contre un Jeton d'Accès : L'ERP utilisera le code d'autorisation pour faire une demande au serveur d'authentification en échange d'un "jeton d'accès". Ce jeton permettra de ne pas saisir les codes d'autorisation à chaque envoi.
Accès aux Ressources Protégées : L' ERP utilise le jeton d'accès pour envoyer les e-mails sur le serveur paramétré.
OAuth 2.0 propose différents types de flux d'authentification pour répondre aux besoins spécifiques des applications, notamment le flux d'authentification implicite, le flux d'autorisation du code d'autorisation, et d'autres. Il est important de noter que le processus exact peut varier en fonction de la mise en œuvre spécifique et des besoins de la messagerie utilisée.
|
|---|
3. Codification flux d’authentification
V2024
La codification flux d'authentification permet de définir le type de flux et son paramétrage d'authentification en fonction du fournisseur utilisé.
Ici nous allons voir la configuration d'une authentification OAuth2.0
Dans la codification il existe une partie configuration commune et une partie configuration spécifique propre au service utilisé (actuellement, il n'y a que les e-mails, mais on pourrait imaginer ajouter des services OneDrive.....) .
Il est également possible de lier les opérateurs ou groupes au type d'envoi d'e-mail souhaité ( L'opérateur doit être lié a un seul type d'envoi).
La case à cocher générique permet d'utiliser une adresse e-mail générale (d’un service par exemple Helios.forterro@gmail.com à partir de laquelle sera envoyé le mail → Pas d’identification par un opérateur mais par l’administrateur système de l’entreprise).
- Configuration du service Mail à Indiquer en plus de l’adresse mail générique
Par défaut, la configuration pour Office est disponible : il faudra juste initialiser le Client ID / Client Secret et Tenant propre à votre organisation dans l'écran de configuration commun.
- Configuration Commune Office
| Paramètre | Description | Valeur |
|---|---|---|
| Scope applicatif | Le champ "Scope" détermine les autorisations spécifiques accordées à l'application cliente pour accéder aux ressources protégées par le fournisseur de services. Dans le contexte de l'envoi de mails, les scopes applicatifs peuvent inclure des autorisations telles que la lecture des contacts, l'accès aux boîtes de réception, l'envoi de mails | offline_access https://outlook.office.com/SMTP.Send https://outlook.office.com/IMAP.AccessAsUser.All" |
| Url token | L'URL du token est l'adresse à laquelle votre application envoie une requête pour obtenir un jeton d'authentification OAuth 2.0. Ce jeton est ensuite utilisé pour autoriser l'application à accéder aux ressources protégées sur le serveur. L'URL du token varie en fonction du fournisseur de services OAuth que vous utilisez. Pour certains fournisseurs, comme Google ou Microsoft, l'URL du token est généralement bien documentée dans leur documentation OAuth. | https://login.microsoftonline.com/[tenant]/oauth2/v2.0/token |
| Url autorisation | L'URL d'autorisation est une partie essentielle du processus d'authentification et d'autorisation. Elle est utilisée pour rediriger les utilisateurs vers le fournisseur d'identité (comme Google, Facebook, etc.) où ils peuvent se connecter et consentir à l'accès demandé par une application tierce. L'URL d'autorisation est générée par votre application et envoyée à l'utilisateur lorsqu'il souhaite se connecter ou autoriser l'accès à ses données. Une fois que l'utilisateur a donné son consentement, il est redirigé vers l'URI de redirection avec un code d'autorisation ou un jeton d'accès, en fonction du flux OAuth utilisé. | https://login.microsoftonline.com/[tenant]/oauth2/v2.0/authorize |
| Client ID | Le client ID (identifiant client) est un identifiant unique attribué à une application cliente lors de son enregistrement auprès du fournisseur de services OAuth. Il est utilisé pour identifier de manière unique l'application cliente lors de l'interaction avec le serveur d'autorisation OAuth. En résumé, le client ID est une sorte de clé d'identification pour votre application cliente dans le système OAuth, et il est utilisé pour garantir que seules les applications autorisées peuvent accéder aux ressources protégées par le serveur d'autorisation. | |
| Client Secret | Mot de passe du client, une fois enregistrer le mot de passe est crypté | |
| Tenant | Tenant fait référence à une unité logique et isolée qui représente une organisation ou une entité distincte au sein d'un système ou d'une plateforme. Chaque tenant dispose généralement de ses propres ressources, utilisateurs, configurations et données, et est géré de manière indépendante des autres tenants. L'utilisation de tenants permet de garantir l'isolation des données et des configurations entre les différentes entités qui utilisent le système. Cela permet également aux fournisseurs de services de gérer efficacement de multiples clients ou organisations au sein d'une seule infrastructure, en fournissant une personnalisation et une sécurité adaptées aux besoins de chaque tenant. | |
| Url de redirection | URI de redirection, est une URL utilisée dans le processus d'authentification OAuth 2.0 pour rediriger l'utilisateur après qu'il a autorisé l'application tierce à accéder à ses données. Dans le flux d'autorisation OAuth 2.0, après que l'utilisateur a donné son consentement à l'application tierce, le fournisseur de services d'authentification redirige l'utilisateur vers l'URL de redirection spécifiée par l'application. Cette URL de redirection est généralement configurée lors de l'enregistrement de l'application auprès du fournisseur de services d'authentification. Une fois redirigé vers l'URL de redirection, l'application peut extraire le code d'autorisation ou le jeton d'accès de la requête de redirection, selon le flux d'autorisation OAuth utilisé. Ce code ou jeton est ensuite utilisé par l'application pour obtenir un jeton d'accès valide qui lui permettra d'interagir avec les ressources protégées au nom de l'utilisateur. Il est important que l'URL de redirection soit sécurisée et qu'elle soit contrôlée par l'application pour éviter les attaques de type redirection non sécurisée (open redirection). | https://login.live.com/oauth20_desktop.srf
|
- Configuration Spécifique Office
| Service | Paramètre | Description | Valeur |
|---|---|---|---|
| Port | Il est important de noter que le port exact utilisé dépend de la configuration du serveur OAuth 2.0 que vous utilisez, et qu'il peut varier d'une implémentation à l'autre. | 587 | |
| Serveur | Le serveur OAuth 2.0 est un serveur qui gère le processus d'authentification et d'autorisation pour les applications clients. Son rôle principal est de générer des jetons d'accès après avoir vérifié les informations d'identification de l'utilisateur et autorisé l'application cliente à accéder aux ressources protégées au nom de l'utilisateur. | smtp.office365.com |
Une fois la configuration effectuée, il sera possible de tester l'authentification via le bouton 
afin de rendre le service opérationnel (Le test s'effectue sur l'opérateur connecté et non sur les opérateurs basculés).
4. Codification Paramétrage des envois mail
V2024
Lorsqu’une fonctionnalité Helios ERP nécessitera un envoi de mail (exemple Envoi facture client ) le service Helios ERP d’envoi de mail existe et peut être appelé par le contexte.
Il est possible dans cette codification d'effectuer des paramétrages par Flux en définissant (Titre, Texte, Priorité, Accusé de réception). Il est également possible d’insérer des mots clés qui seront ensuite remplacés par la valeur en fonction du contexte.
Dans le flux d’envoi de BL possibilité d’utiliser les mots clés SOCIETE et ID_BL dans le titre ou le corps du mail.
|
|---|
La case à cocher "Copie mail" permet d'envoyer le mail également à l'émetteur du mail. Cette fonction est à utiliser dans le cas du SMTP pour avoir une trace de l'envoi.
Elle n'est pas nécessaire dans le cas de l'utilisation d'envoi de mail via OAuth 2.0, car le mail sera présent dans la boîte d'envoi.
4.1. Surcharge email Signature
4.1.1. Personnel
Dans le module Personnel sur l'onglet E-Mail il est possible de lier un texte propre à l'opérateur qui sera utilisé en pied d'e-mail après le Texte paramétré sur le flux et d'ajouter une signature : Propre à l’opérateur.
La signature prendra le pas sur le paramétrage des envois e-mails et le flux société si elle est définie. |
|---|
4.1.2. Société
Dans le module Société sur l'onglet E-Mail, il est possible de lier un Texte lié à la société qui sera utilisé en pied d’e-mail après le Texte paramétré sur l’opérateur.
Le logo lui sera attaché dans le mail.
| La signature prendra le pas sur le paramétrage des envois e-mails si elle est définie. |
|---|
4.2. Surcharge e-mail Nom du fichier
Version 2024
Lorsqu’une fonctionnalité Helios ERP nécessite un envoi (Courrier / Mail/ Exporter ) (Ne s'applique pas à Appliquer) il est possible de surcharger le nom du fichier généré par l'état via cette codification (exemple Envoi facture client).
On peut également utiliser une liste de mots clés définie par flux pour le nommage du fichier en fonction du flux.
Il est également possible via la casse à cocher Stockage GED de lier le document en fichier lié sur l'élément envoyé.
On pourra alors définir le Type de fichier du fichier lié que l'on souhaite par flux si on le souhaite.
5. Exemple : envoi d'e-mail dans Helios ERP .
Prérequis pour l'envoi d' e-mail :
- Mise en place de l’impression via Runtime Crystal Report
- Mise en place de l’architecture Helios ERP d’envoi de mail et son paramétrage
- Mise en place des écrans de diffusion
Action lors de l'envoi d'un mail :
- Récupération de la codification associée au flux d’envoi de mail :
- Titre à modifier en fonction du contexte.
- Texte à modifier en fonction du contexte.
- Récupération de la codification mail de l’opérateur :
- Texte à utiliser en pied de mail
- Signature.
- Récupération de la codification mail de la société :
- Texte / Logo.
- Recherche de l’état comme pour l’impression du BL :
- Génération d’un PDF.
- Mis en pièce jointe.
6. Gestion des erreurs
6.1 Erreur vérification d'authentification
Nous avons remarqué une erreur possible quand on vérifie l'authentification directement depuis le serveur/TSE
Il faudra alors installer le runtime suivant Microsoft Edge WebView2 | Microsoft Edge Developer sur le serveur.
6.2. Erreur dans les états
Dans le cas d'erreur lors de l'envoi d'un état, il faut dans un premier temps vérifier la compatibilité de l'état utilisé dans la personnalisation des états pour la diffusion utilisée.
Exemple
Erreur pendant la diffusion : Valeurs de paramètre manquantes
Personnalisation des états
6.3. Erreur Paramétrage d'envoi mail
L'erreur "Tra_Item_Introuvable Paramétrage d'envoi mail" ci dessous lors de l'envoi de mail est levée car il manque une ligne de paramétrage d'envoi mail pour la diffusion demandée (ici dans l'exemple commande fournisseur)
Solution : Créer la ligne de diffusion dans la codification Paramétrage d'envoi e-mail.
6.4. Erreur Flux d'authentification
L'erreur "Aucun flux trouvé pour l'utilisateur connecté" ci dessous lors de l'envoi d'e-mail est levée car l'opérateur connecté pour la diffusion demandée n'est pas lié à un flux d'authentification.
Solution : Dans le codification Flux d'authentification ajouter l'opérateur au Flux lui correspondant .
6.5. Erreur Taille pièce jointe
L'erreur "Attachements too big" est levée quand la limite de la taille de la pièce jointe (Mo) saisie dans le flux d'authentification est dépassée.
Solution : Réduire le nombre de fichier liée
6.6. Erreur Sans Flux
L'erreur "Com_Authentification_UserSansFlux" est levée quand l'opérateur connecté n'est pas dans la liste des opérateurs affectés lors du test Service du flux.
6.7. Erreur Donnée non valides
Lors de la validation du service du flux cette erreur peut arriver si un paramètre n'est pas correct.
Attention, le clientSecret n'est pas saisi par défaut malgré la présence 
, c'est pour cacher le mot de passe saisi.
