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.

il faudra une ligne pour chaque opérateurs à moins de basculer l'ensemble des opérateurs sur pour une configuration basique ce qui reviendrait a utiliser une adresse mail générique.

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.

Exemple Configuration SMTP pour GMAIL

Configuration Gmail -Sécurité de l'adresse mail utilisé

- Activer la vérification en deux étapes: Avant de pouvoir utiliser les mots de passe d’application, vous devez activer la vérification en deux étapes. Cela ajoute une couche de sécurité supplémentaire à votre compte en exigeant une deuxième forme de vérification lors de votre connexion.
- Générer un mots de passe d'application et le garder pour le saisir dans les paramétrage Helios

Configuration dans la codification Flux d'authentification pour une authentification Basique
- Configuration spécifique

- - Adresse du serveur SMTP: smtp.gmail.com
  - Port: 587 (pour TLS)
- Configuration commune

- adresse mail: Votre adresse Gmail complète (y compris @gmail.com).
- Mot de passe: Votre mot de passe Gmail généré par le mot de passe d’application.

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.

Dans le cas où le Token n’est pas valide (délai de validité dépassé), il faut redonner son accord. Nécessitera une configuration (installation de dll + répertoire dédié) sur les postes qui ne sont pas en Windows 11. Page de validation du token différente en fonction du fournisseur de mail.

Flux OAUTH 2.0

Aide Configuration en fonction du service de messagerie

En plus de configurer l'envoi d'e-mails dans Helios ERP il faudra également configurer votre service de messagerie à l'aide de votre prestataire ou service informatique.

Ci-dessous quelques liens pour vous aider dans la configuration.

Outlook

Dépréciation de l’authentification de base dans Exchange Online | Microsoft Learn

Authentifier une connexion IMAP, POP ou SMTP à l’aide d’OAuth | Microsoft Learn

API Outlook

GMAIL

Utiliser OAuth 2.0 pour accéder aux API Google | Authorization | Google for Developers

Utiliser OAuth 2.0 pour les applications de serveur Web | Authorization | Google for Developers

Connecter les comptes Gmail à l’aide d’OAuth 2.0 - Power Platform | Microsoft Learn

API GMAIL

https://console.cloud.google.com/

Cliquez sur Select a project en haut de l'écran, puis sur New Project.
1. . Donnez un nom à votre projet et cliquez sur Create.
Activer l'API Gmail
1. Une fois le projet créé, allez dans APIs & Services > Library.
2. Recherchez et sélectionnez l'API Gmail.
3. Cliquez sur Enable pour activer cette API dans votre projet.
Configurer les écrans de consentement OAuth
1. Allez dans APIs & Services > OAuth consent screen.
2. Choisissez External si vous prévoyez d’utiliser cette application pour des comptes externes à votre organisation, puis cliquez sur Create.
3. Renseignez les informations nécessaires, comme le nom de l’application, votre adresse email, etc., puis enregistrez.
4. Créer des informations d’identification OAuth 2.0
Allez dans APIs & Services > Credentials.
1. Cliquez sur Create Credentials et sélectionnez OAuth 2.0 Client IDs.
2. Sélectionnez Web application et renseignez le nom de l'application.
3. Pour les redirections, vous pouvez indiquer une URL factice si vous n'en avez pas. Par exemple : http://localhost.
4. Cliquez sur Create et notez les Client ID et Client Secret qu'il faudra saisir dans Helios ERP

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).

Ajout Opérateur

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.

Exemple de la configuration nécessaire pour Office disponible dans les écrans secondaires de configuration.

Exemple Création Configuration

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.
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
Mail	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
Mail	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

Exemple de la configuration nécessaire pour Gmail disponible dans les écrans secondaires de configuration.

Configuration Commune GMAIL

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	https://mail.google.com/
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://www.googleapis.com/oauth2/v4/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://accounts.google.com/o/oauth2/v2/auth
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).	http://localhost

Configuration Spécifique GMAIL

Service	Paramètre	Description	Valeur
Mail	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
Mail	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.gmail.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.

Par ex : [SOCIETE] : Envoi du BL : [ID_BL]
Deviendra : FORTERRO : Envoi du BL : 12345

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.

Liste des flux actuellement disponibles

Module	Abréviation	Libellé
S_CMD	ST_ENVOI	Passer une commande ST
S_CMD	ST_REL	Relance ST
S_CMD	ST_LST_REL	Liste relance ST
FACTURE	FACT_ENVOI	Envoi d'une facture
DEVIS_NEW	DEVIS_ENVOI	Envoi d'un devis
DEVIS_NEW	DEVIS_REL	Relance du devis
APPEL_OFFRE	OFFRE_ENVOI	Passer appel d'offre
DOC_TECH	GED_DIFF	Diffusion de la GED
C_CMD_NEW	C_CMD_ARC	Envoi d'un accusé de réception
F_CMD	FRS_REL	Relance FRS
F_CMD	FRS_LST_REL	Liste relance FRS
F_CMD	FRS_ENVOI	Passer une commande FRS
AVOIR	AVOIR_ENVOI	Envoi d'un avoir
BL	BL_ENVOI	Envoi d'un BL
NC_EVT	EVT_DIFF	Diffusion d'un évènement
NC_EVT	EVT_REL	Relance d'un évènement

Les flux non présents dans le tableau mais disponibles dans la codification sont prévus dans un second temps avec l'utilisation de Workflow.

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.

Module impacté...

BL
FACTURE CLIENT
AVOIR CLIENT
DEVIS CLIENT
DEVIS Relance
C_CMD_ARC
APPEL_OFFRE PASSER
F_CMD ENVOI
F_CMD Relance
F_CMD LST_REL
S_CMD ENVOI
S_CMD RELANCE
S_CMD LST_REL
GED Diffusion
Non conformité Diffusion
Non Conformité Relance
événement Diffusion
événement Relance
Création non conformité
Validation Revue de contrat
Création Client
Création Article
APPRO_PARTIEL
"TABLEAU";"ETAT_DIFF";"TXT_ETAT_DIFF"
"DEMA_ACHT";"DEM_HA_CREE";"TXT_DEM_HA_CREE"
"FAI";"FAI_CREE";"TXT_FAI_CREE"

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.

Solution : Ajouter l'opérateur connecté dans la liste des opérateurs affectés pour ce 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.

6.8. Erreur sur Authentification Basique (SMTP)

Lors de la validation du service du flux pour le basique si le port ou le mot de passe n'est pas correcte

Solution : Vérifier que le port correspond bien a 587 et que le mot de passe correspond au mot de passe des applications définie dans GMAIL

Browser not supported