BPEL et les files JMS, deuxième partie : Weblogic

Dans cette deuxième partie, je vais vous expliquer comment configurer le serveur Weblogic pour intégrer les files JMS dans vos flux BPEL.
La configuration de Weblogic se décompose en 3 parties :

  • Configuration des sources de données
  • Configuration de la partie messaging (Fabriques de connexion, Queues, etc.)
  • Configuration de l’adaptateur de ressources JMS

Le premier article et celui-ci sont complémentaires et permettent de configurer la base de données et le serveur d’applications pour l’interaction entre BPEL et les files JMS.

Configuration des sources de données

Pour bien différencier les 2 types d’actions possibles : empilement et « dépilement« , je préconise d’utiliser 2 sources de données.
Par ailleurs, la distinction en 2 sources de données va permettre de dimensionner les sources  en fonction de leur utilité. En effet, généralement il y a plus de consommateurs que de producteurs (mode publish / subscribe, nombre de threads parallèles élevés pour la consommation JMS, etc.).  Enfin, la distinction va également permettre d’obtenir des statistiques plus fines sur la nature des connexions à la base AQ (empilement, dépilement).
Pour créer une source de données, il faut aller dans ‘services / jdbc / Data Sources’ :

La création d’une nouvelle source de données se fait en cliquant sur ‘New’ et il reste à suivre les étapes proposées par l’interface Weblogic.
Les principales informations à renseigner sont :

  • Un nom JNDI qui va être utilisé pour désigner la source en question
  • Informations de connexion à la base (user, mot de passe, chaîne jdbc)
  • Type de transaction : XA dans notre cas.

Ecran « Général » de la source de données, une fois créée :

Ecran de résumé des informations sur le pool de connexions une fois la source de données créée :

Attention : la source de données doit être accessible par le serveur SOA. Pour cela, ajoutez le serveur SOA dans les ‘targets’.

Configuration de la partie « messaging »

Cette partie permet de configurer le fournisseur JMS et tout ce qu’il comporte :

  • fabriques de connexions
  • objets (queues et topics) auxquels les processus BPEL vont pouvoir se connecter
  • etc.

Dans un premier temps, il faut créer un module en se rendant dans ‘services / JMS / JMS Modules’ :

Cliquer sur ‘New’ pour créer un nouveau module et suivez les instructions.
Une fois le module créé, cliquez dessus pour le configurer en ajoutant un ‘foreign server’ pour l’empilement et un autre pour le dépilement :

Il reste à configurer les différentes parties du ‘foreign server’, cliquez dessus et rendez vous dans dans l’onglet général, deux informations sont à renseigner :

  • JNDI Initial Context Factory : oracle.jms.AQjmsInitialContextFactory
  • JNDI Properties : datasource=jdbc/AQEnqueueDataSource ou datasource=jdbc/AQDequeueDataSource (mettre le nom JNDI de la source de données préalablement créée)


Dans l’onglet ‘Destinations’, il faut ajouter les objets que vous souhaiter rendre accessibles aux processus BPEL. Pour cela, cliquez sur ‘New’ et renseignez les 3 champs suivants :

  • Name : nom que vous souhaitez donner à l’objet
  • Local JNDI Name : nom JNDI qui sera utilisé dans les processus BPEL pour pointer sur le bon objet
  • Remote JNDI Name : nom générique permettant d’identifier l’objet du côté de la base AQ. Ce nom doit être de la forme Queues/nom_schema.nom_queue pour les queues et Topics/nom_schema.nom_topic pour les topics.


Dans l’onglet ‘Connection factories’, il faut ajouter les fabriques de connexions utilisées par l’adaptateur de ressources JMS pour interagir avec le fournisseur JMS. On distingue deux types de fabriques de connexions, une pour les queues et l’autre pour les topics.
Pour chaque fabrique de connexions, les 3 champs suivants doivent être renseignés :

  • Name : nom de la fabrique de connexions
  • Local JNDI Name : nom JNDI qui sera utilisé dans l’adaptateur de ressources pour pointer sur la bonne fabrique de connexions.
  • Remote JNDI Name : nom générique permettant d’identifier le type d’objet instancier par cette fabrique (queue ou topic). Ce nom est XAQueueConnectionFactory pour les queues ou XATopicConnectionFactory pour les topics.

Attention : le module de ‘messaging’ doit être accessible par le serveur SOA. Pour cela, ajoutez le serveur SOA dans les ‘targets’.

Configuration de l’adaptateur de ressources

L’adaptateur de ressources JMS et un des adaptateurs JCA mis à disposition par la SOA Suite pour dialoguer avec des applications tierces.
Pour la configuration de l’adaptateur JMS, il faut se rendre dans la section ‘deployments’ :

Sélectionnez l’adaptateur JMS : ‘JmsAdapter’ et rendez vous dans l’onglet ‘configuration’ puis ‘Outbound Connection Pools’ :

Ajoutez deux pools de connexions par objets (topic et queue), un pool pour l’empilement et un pour le dépilement. On se retrouve donc avec 4 pools de connexion à créer :

  • eis/ajms/TopicEnqueueCP
  • eis/ajms/TopicDequeueCP
  • eis/aqjms/QueueEnqueueCP
  • eis/aqjms/QueueDequeueCP

Pour chaque pool de connexions, donnez les informations suivantes :

  • ConnectionFactoryLocation : nom JNDI de la fabrique de connexions configurée dans la partie messaging. Il faut choisir le nom JNDI correspondant à la fabrique de connexions liée au bon objet et à la bonne action.
  • IsTopic : booléen prenant ‘true’ comme valeur si le pool de connexions est utilisé pour les topics.

Attention : Appuyez sur ‘Entrée’ après avoir entré la valeur pour la valider et cliquez sur ‘Save’, une fois les propriétés renseignées.

Une fois tous les pools de connexions configurés, retournez sur la page ‘deployments’ pour redéployer l’adaptateur de ressources JMS. Cochez la case ‘JmsAdapter’ et cliquez sur ‘Update’ :

Créez le plan de déploiement s’il n’existe pas encore :

Choisissez le plan de déploiement pour le redéploiement de l’adaptateur de ressources JMS :

L’adaptateur de ressources est à présent à jour …

Conclusion

A l’issue de cette configuration et après avoir suivi le premier article, vous êtes au point au niveau de la configuration des ressources JMS. Il reste à présent à développer vos flux BPEL pour les faire interagir avec les files JMS, objet de l’article suivant …

4 réflexions sur “BPEL et les files JMS, deuxième partie : Weblogic”

  1. Bonjour,
    Très bon article trouvé par hasard en cherchant des infos sur le tuning du load balancing weblogic – MySQL.
    by de way auriez vous des informations ou des liens à me proposer, pour l’instant je trouve rien sur la doc officielle BEA-Oracle concernant le load balancing vers des BD MySQL sous weblo ?
    Merci

  2. Adrien,
    La série d’articles en cours est un tutorial permettant d’intégrer des files JMS au sein d’une architecture SOA basée sur BPEL, le fournisseur JMS choisi est Oracle AQ.
    Chaque fournisseur JMS a ses avantages et ses inconvénients, le choix ici s’est porté sur Oracle AQ car c’est celui que j’utilisais en 10g et il est directement intégré à BPEL via les adaptateurs de ressources : AQAdapter et JMSAdapter.
    En ce qui concerne la haute disponibilité, la solution Oracle AQ te fait bénéficier de tous les avantages de la base de données, notamment en termes de haute disponibilité. Il faut voir maintenant côté Weblogic s’il y a des modifications à faire sur la configuration pour autoriser la haute disponibilité au niveau des files JMS …
    En tout cas, le but de ce tutorial n’était pas de traiter les aspects haute disponibilité 😉

    1. La haute disponibilité n’est qu’un des avantages parmi d’autres. Je voulais rappeler qu’il est préférable (dans la mesure du possible) d’utiliser un maximum les fonctionnalités natives de Weblogic afin de bénéficier de toutes les fonctionnalités d’intégration et pouvoir centraliser l’exploitation au maximum.
      Bon article btw 😉

  3. Pourquoi utiliser des foreign Server et non déclarer les files JMS directment sur WebLogic avec des JDBCPersistantStore (pointant sur la base de ton choix) ? Cela te permet de gérer de la haute disponibilité gràce aux DistributedQueue !

Les commentaires sont fermés.