Comme nous l’avions promis dans un précédent article, chaque version R comprend plus d’avancées liées à la fonctionnalité de messagerie, débloquant ainsi sa puissance cachée.
4D v17 R5 offre une nouvelle fonctionnalité intéressante pour les journaux d’emails. Parfois, pendant le développement, tout fonctionne bien, mais lorsque vous déployez chez le client, il y a un problème de livraison des e-mails. Il peut être difficile de découvrir où se situe l’échec, car la communication est cryptée et vous n’avez souvent pas accès aux fichiers journaux du serveur SMTP. Le problème est très probablement lié à votre serveur SMTP, mais comment en être sûr ? Il suffit de lancer le journal SMTP dans votre application ! Ce journal contient un enregistrement de toutes les actions effectuées, y compris celles qui interrompent la connexion. Mieux encore, ce journal montre les communications avec le serveur SMTP en texte clair, non crypté, ce qui en facilite l’analyse.
La commande SMTP New transporter crée une connexion avec un serveur SMTP (tel que exchange ou gmail) et enregistre toutes les communications entre celui-ci et le client.
Activer le journal des transactions SMTP
Pour activer le journal des communications SMTP dans votre base de données pour tous les e-mails envoyés, vous pouvez utiliser le code suivant :
SET DATABASE PARAMETER(SMTP Log, 1)
Pour exécuter facilement un journal SMTP sur le serveur, cliquez sur le bouton « Start Request and Debug Logs » dans la fenêtre d’administration de 4D Server :
Toutes les transactions SMTP en cours d’exécution sur 4D Server seront automatiquement enregistrées.
Enregistrer une transaction spécifique
Si vous devez consigner une transaction spécifique (pendant le débogage, par exemple), vous pouvez utiliser la propriété logFile de l’objet SMTP :
$server.host:="votremtpserver.com"
$server .user:="login"
$server .password:="psw"
// Enter the path of the log file you want to create
$server .logFile:="C:\tmp\SMTPLog.txt"
$transporter :=SMTP New transporter($server)
Exemple de fichier journal SMTP
Chaque ligne du journal contient cinq informations :
- Compteur
- Date et heure
- ID du processus
- ID unique du processus
- L’instruction d’envoi du client (« C > ») ou la réponse du serveur (« S <« ) avec le code de réponse et la description renvoyée.
Voici le résultat de la tentative de connexion avec un mot de passe incorrect :
1 2019-02-06T15:03:11.586 5 7 ### SMTP Connecté à 'smtp.gmail.com' sur le port 465. (sécurisé)
2 2019-02-06T15:03:12.142 5 7 S < "220 smtp.gmail.com ESMTP y139sm19463388wmd.22 - gsmtp"
3 2019-02-06T15:03:12.143 5 7 C > "EHLO [192.168.18.9]"
4 2019-02-06T15:03:12.154 5 7 S < "250-smtp.gmail.com à votre service, [195.68.52.79]"
5 2019-02-06T15:03:12.154 5 7 S < "250-SIZE 35882577"
6 2019-02-06T15:03:12.154 5 7 S < "250-8BITMIME"
7 2019-02-06T15:03:12.154 5 7 S < "250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH"
8 2019-02-06T15:03:12.154 5 7 S < "250-ENHANCEDSTATUSCODES"
9 2019-02-06T15:03:12.161 5 7 S < "250-PIPELINING"
10 2019-02-06T15:03:12.161 5 7 S < "250-CHUNKING"
11 2019-02-06T15:03:12.161 5 7 S < "250 SMTPUTF8"
12 2019-02-06T15:03:12.162 5 7 C > "AUTH PLAIN"
13 2019-02-06T15:03:12.168 5 7 S < "334 "
14 2019-02-06T15:03:12.168 5 7 C > "********************************"
15 2019-02-06T15:03:12.234 5 7 S < "535-5.7.8 Nom d'utilisateur et mot de passe non acceptés. En savoir plus à"
16 2019-02-06T15:03:12.234 5 7 S < "535 5.7.8 https://support.google.com/mail/?p=BadCredentials y139sm19463388wmd.22 - gsmtp"
17 2019-02-06T15:03:12.235 5 7 C > "QUIT"
18 2019-02-06T15:03:12.242 5 7 S < "221 2.0.0 closing connection y139sm19463388wmd.22 - gsmtp"
19 2019-02-06T15:03:12.242 5 7 ### Connexion SMTP fermée67 2019-01-10T11:00:08.653 -5 ### Connexion SMTP fermée
Regardons de plus près ce qui se passe dans le journal :
- Ligne 1: Ouverture d’un canal de communication avec le serveur SMTP sur le port 465. Le cryptage TLS est lancé automatiquement et la communication est sécurisée.
- Ligne 3: Le client envoie la commande EHLO pour initier la conversation SMTP.
- Lignes 4 à 11: le serveur renvoie certains éléments de configuration, notamment la liste des méthodes d’authentification prises en charge (ligne 7).
- Ligne 12: le client envoie le type d’authentification.
- Ligne 14: Le client envoie le login et le mot de passe. Ils n’apparaissent jamais en clair dans le journal, ils sont remplacés par des « * ».
- Lignes 15 et 16: le serveur renvoie l’erreur 535, l’authentification a échoué.
- Ligne 17: Le client envoie la commande « QUIT » pour fermer la connexion avec le serveur.
Comme vous pouvez le voir dans cet exemple, il est maintenant facile de résoudre les problèmes de communication.
Bonne journalisation !