11g et EMail : Consommer (avec modération) via UMS [1/2]

arkzoyd_featuredimage2

Souvent on souhaite permettre à nos services de notifier les utilisateurs… moins souvent, on souhaite pouvoir notifier nos services via emails… et forcément quand c’est une pratique moins fréquente, on trouve moins d’informations…

Cette problématique était prise en compte dans la version 10g via les « activation agents », cependant cette méthode n’est plus valable en 11g…

Aujourd’hui plus besoin de chercher ! Vous n’avez plus qu’à lire la suite !

L’exemple suivant a été réalisé en se connectant à une messagerie gmail, il détaillera donc à certains moment des points spécifiques à ce type de messagerie.

Dans cette première partie, on s’attardera sur le principe de la solution, ainsi que sur la première partie de la réalisation : la configuration des emails. Une seconde partie viendra compléter la réalisation, en s’attardant sur le client UMS.

Solution recherchée

Principe

Dans la version 11g, il semblerait que les « activation agents » aient disparus… cependant UMS vient avec une API Java qui va permettre de s’enregistrer sur une source pour recevoir des messages.

Vous trouverez les informations générales de ces  APIs UMS dans le guide du développeur SOA 11g. Ces APIs permettent au choix de réaliser un client EJB, POJO ou Web-Services.

La solution va donc consister à mettre en place un client qui permettra la consommation de nos messages. C’est ce client applicatif qui notifiera notre composite.

Quel que soit le format choisi, le principe restera :

  • Inscription auprès d’UMS pour un canal donné pour un consommateur de message
  • Consommation de message via un listener, ressemblant fortement à un MDB

Exemple mis en place

Voici un schéma présentant un modèle de consommation de mails basé sur ce principe, qui sera mis en place par la suite. Il permettra au final d’obtenir le résultat attendu : déclencher un composite à l’arrivée d’un email.

Le fonctionnement sera le suivant :

  • UMS interroge régulièrement la boîte mail
  • UMS notifie le listener inscrit d’un nouveau message
  • Le listener traite le message en le déposant dans une file JMS de type AQJMS (plus robuste/souple qu’un appel direct du composite)
  • Le composite initialise des instances par consommation de la file JMS.

Etape 1 : Configuration EMail d’UMS

Le premier point consiste à mettre en place la configuration permettant à UMS de se connecter à la boîte mail.

Cette configuration a été réalisée pour fonctionner avec un compte GMail, mais est tout à fait adaptable à un serveur Exchange ou autre.

Driver EMail

Configurer le driver email pour qu’il pointe sur les serveurs gmail, avec le bon utilisateur

  • Se connecter à l’Enterprise Manager
  • Se rendre sur les propriétés du driver email

  • Configurer les informations concernant les « incoming email »

Mise en place de certificats

Récupérer les certificats gmail sur votre machine (smtp pour information uniquement)

openssl s_client -connect imap.gmail.com:993 > imap.cert
openssl s_client -connect smtp.gmail.com:465 > smtp.cert

Créer un keystore avec ces certificats (utilisez bien l’outil keytool du jdk utilisé pour faire tourner le serveur SOA, au risque sinon de tomber sur des erreurs au démarrage)

keytool -import -alias imap.gmail.com -keystore trusted-gmail-ks.jks -storepass changeit -file imap.cert
keytool -import -alias smtp.gmail.com -keystore trusted-gmail-ks.jks -storepass changeit -file smtp.cert

Editer le fichier de l’environnement du domaine :

vim $FMW_HOME/user_projects/domains/soa/bin/setDomainEnv.sh

Remplacer (si vous n’avez jamais changé le truststore initial)

 -Djavax.net.ssl.trustStore=${WL_HOME}/server/lib/DemoTrust.jks

Par

 -Djavax.net.ssl.trustStore=${WL_HOME}/server/lib/trusted-gmail-ks.jks

Redémarrer le serveur pour prendre en compte les imports de certificats et que le tout se mette en place. Vous devez normalement voir à présent dans les logs au démarrage des choses du genre (notamment car dans les configurations du driver mis en place, on a choisi de mettre en Debug) :

A257 SELECT INBOX
* FLAGS (Answered Flagged Draft Deleted Seen)
* OK [PERMANENTFLAGS (Answered Flagged Draft Deleted Seen *)] Flags permitted.
* OK [UIDVALIDITY 653977782] UIDs valid.
* 3 EXISTS
* 0 RECENT
* OK [UIDNEXT 4] Predicted next UID.
A257 OK [READ-WRITE] INBOX selected. (Success)
A258 SEARCH UNFLAGGED ALL
* SEARCH
A258 OK SEARCH completed (Success)
IMAP DEBUG: IMAPProtocol noop
A259 NOOP
A259 OK Success
A260 CLOSE

Conclusion [1/2]

Dans cet article, nous avons pu voir les principes d’une solution de consommation d’EMail, ainsi que le début de sa mise en place (configuration EMail avec SSL).
A ce stade, UMS sera en capacité de récupérer les mails arrivant sur la boite mail, mais aucun consommateur n’est pour le moment inscrit. Le prochain article viendra compléter la partie réalisation, concernant ce consommateur UMS.
Sebastien Antony

About Sebastien Antony

Sebastien Antony has written 21 post in this blog.

Ingénieur études et développement J2EE

Poster un commentaire