vendredi 21 décembre 2007

Utilisation de AQ (Advanced Queueing) avec SOA

Cet article va vous expliquer comment utiliser AQ d'Oracle (MOM interne de la base de données) avec Bpel ou ESB. AQ peut être comparé à MQSerie de IBM.

Tous les messages sont stockés dans la base Oracle et vous assure de les retrouver quoiqu'il se passe, notamment en mettant en oeuvre l'option Oracle RAC (Cluster de la base de donnée).

La première étape consiste à créer une queue dans votre base de donnée (9i jusqu'à 11g). Pour ma part j'utilise 10g. On peut bien sure scripter la création d'une queue ou alors utiliser l'interface graphique d'administration de votre base de donnée.

Aller sur le "Database Control" qui est une webapp livrée avec votre base de donnée. Si elle ne démarre pas vérifier que le service Windows associé est bien démarré.
Pour ma part, il s'agit de l'URL : http://hsimonne-fr.fr.oracle.com:1158
(où hsimonne-fr.fr.oracle.com est le nom de mon serveur)

Connectez-vous en tant que SYSDBA puis cliquer sur l'onglet "maintenance". Dans cette rubrique, vous avez "Stream", cliquez sur "setup", puis "messaging". Vous devez arriver à ce type d'écran:




Cliquez ensuite sur "CREATE" puis sélectionner "Normal Queue, Fixed Datatype".

Saisir un nom pour votre "queue de message" et une table associé pour y stocker les informations.
Vous devez ensuite créer une table qui stockera l'ensemble de vos messages :

Le nom de table doit être précédé du schema comme "EDGE" .
Exemple :

Cliquez ensuite sur "Finish". Pour rendre actif votre queue AQ, il faut lui associer un "Subscriber". Cet objet va gérer la réception des messages et la consommation de ceux-ci.

Sélectionnez alors :

puis "GO" et dans l'écran suivant "CREATE" pour arriver sur cela :



Entrez un nom de "subcriber" et le nom de la queue précédemment créer avec son schéma devant comme dans l'image ci-dessus. Voila c'est terminée pour la partie DataBase.

Ensuite dans votre Jdev préféré, soit vous pousser un message depuis l'ESB ou depuis BPEL en utilisant l'adapteur proposé en standard pour AQ adapter:


puis suivre les étapes suivantes:

Attention ! Spécifier bien une connexion database avec l'utilisateur ayant accès au schéma dans lequel réside votre queue.


Spécifier comme ci-dessus si vous consommer ou envoyer un message, puis sélectionner ensuite votre queue depuis cet écran :


Spécifier ensuite si vous voulez corréler les messages, c'est à dire dépiler ou envoyer un message contenant un certain identifiant (sinon ne rien mettre):




Spécifier le format du message stocké, en utilisant par exemple un XSD:



Et voila c'est fini pour envoyer un message AQ !

Si vous souhaitez maintenant le consommer, il suffit de prendre le même adpateur AQ et de spécifier que vous consommer. Attention ! Dans ce cas il faut spécifier le "Subscriber" configuré dans la Base de donnée, exemple:




Ainsi, votre ESB Oracle ou Bpel Manager peut envoyer / consommer des messages avec AQ.

3 commentaires:

Gregory a dit…

Merci pour tes articles interessants ! 2 choses pourtant :
a- Merci de ne pas mettre des liens non disponibles sur internet dedans, ca fait plusieurs fois que je finis decu par ca (Le pire c'etait pour l'article sur le BAM)
b- Regarde ce que sont des "buffered queues" et tu verras qu'Oracle peut ne pas garantir que les messages sont stockes en base de donnees avec AQ.

Mon profil sous linkedin a dit…

je viens de modifier les URL qui menaient vers mes serveurs.

Pour "buffered queues", je connais pas trop, pour faire des messages non stockés dans la base j'utilise plus simplement ce qui est présent dans le serveur d'application Oracle : JMS en mémoire ou en mode fichier.

J'avais aussi l'envie de faire un article sur JMS provider vers une database afin de persister mes messages JMS dedans ...

Gregory a dit…

Awesome ! Et merci pour ton blog ! Je suis un lecteur avide...

;-) A propos des buffered queues, tu dis ça parce que tu raisonnes java... Pour avoir traîné dans un monde parallèle, MQ est au cœur de Websphere justement pour faire le lien entre tous les legacy sans faire de java ! AQ, c'est la même chose mais qui s'adresse aux gorilles de la base. Imagine que tu doives propager des données pour constituer un Data Mart ou simplement pour migrer vers Oracle 11g : (1) Pas besoin de persister tes messages, tu pourras les reconstituer si ta base explose et (2) pas la peine de passer par une infrastructure qui permette de propager des messages en dehors de la base... Ce sont les buffered queues. Pour la petite histoire, c'est l'infrastructure qui supporte Oracle Streams depuis Oracle 9iR2 et qu'Oracle a rendu accessible au commun des mortels en 10g !

J'attends la suite avec impatience...