Comme vous le savez, EDN (Event Delivery Network) n’est pas encore intégré dans Oracle Service Bus. Impossible donc de propager/s’abonner à un évènement depuis un business/proxy service.
Chez Easyteam, on est têtu comme des mules et on ne souhaitait pas attendre cette merveilleuse fonctionnalité dans la prochaine release ….. feature extrêmement utile dans le contexte d’interactions asynchrones one-way entre Oracle Service Bus & SOA Suite.
Dans cet article, nous verrons ensemble « l’envers du décors » d’EDN.
Notre exemple consistera à propager un évènement dans EDN depuis OSB, puis à le catcher depuis une application composite dans SOA. Evidemment, une fois que vous aurez compris le principe, s’abonner à un évènement depuis OSB vous paraîtra tout aussi simple.
Si vous êtes déjà familier à EDN, vous pouvez passer le chapitre suivant et lire à partir d’ICI.
Rappel sur l’architecture EDN
Event Delivery Network est l’implémentation d’Oracle des architectures orientées évènements (EDA). EDN est l’alignement du modèle événementiel avec les applications SOA.
Le principe est assez simple. Il s’agit de déclencher des interactions asynchrones en publiant un « évènement ». Cet évènement peut être écouté par de multiples acteurs qui vont s’abonner.
EDN c’est quoi en fait ? Ce n’est ni plus ni moins qu’une surcouche Oracle qui empile et dépile des messages stockés dans une file Oracle Advanced Queuing unique dans la base de données de déshydratation. Ces messages représentent les évènements EDN, et ces évènements ne sont qu’une structure xml définie par Oracle pour décrire un évènement avec :
- Un nom d’évènement
- Un namespace pour cet évènement
- Un message XML à véhiculer
La beauté de la chose c’est la façon dont Oracle a intégré le concept dans sa suite de façon à ce que ce soit complètement transparent pour le développeur.
EDN & OSB: La recette de cuisine
Pour propager un évènement depuis OSB, voici mes ingrédients :
- Un adapteur JCA pour s’interfacer avec la file AQ EDN
- Un business service s’appuyant sur l’adapteur JCA fraîchement créé
- Une XQuery pour générer une structure XML « évènement » comme l’attend EDN
- Un proxy service OSB pour déclencher ma XQuery
- Un abonné côté SOA. Un processus BPEL fera très bien l’affaire.
Allez mettre votre tablier, c’est partit !
Etape 1. Création de l’adapteur JCA dans Jdeveloper
Dans votre IDE préféré (Jdeveloper, what else ?), créez un projet SOA en partant du template « empty composite ».
Glissez un AQ Adapter dans les external references et commençons ensemble la configuration de l’adapteur.
Spécifiez un nom:
Spécifiez le nom de votre connexion JDeveloper vers la base de déshydratation (POINT 1). Cette connexion est utilisée au design time uniquement. Le chemin JNDI vers la connexion SOA est également nécessaire (POINT 2). Cette connexion est, quand à elle, utilisée au runtime.
Ne spécifiez pas de contrat de service. Le WSDL sera généré automatiquement par JDeveloper après la finalisation de la configuration de notre adapter.
On souhaite bien évidemment empiler un message car dans notre exemple on lève un évènement.
Ici mon schéma base de données s’appelle « DEV_SOAINFRA ». Pour connaître le nom de la file AQ qu’on souhaite attaquer, on peut la consulter avec n’importe quel client SQL :
Il s’agit de « EDN_EVENT_QUEUE ».
Laissez les paramètres suivants vides
Cochez l’option pour prendre toute la structure de l’objet attendu « EDN_EVENT_DATA »
Finalisez la configuration de votre adapter.
Etape 2. Création du projet OSB & import dans Eclipse de l’adapteur JCA
Dans un premier temps, ouvrez Eclipse OEPE, créez un projet OSB et importez votre fichier de configuration JCA généré par JDeveloper
Pour générer le Business Service à partir de l’adapteur JCA <Attention, merveille d’ergonomie d’Eclipse>, une image vaut mieux qu’un beau discours :
Spécifiez ensuite un nom pour votre Business Service.
L’objet métier que notre évènement va véhiculer est le suivant :
Nous allons ensuite créer notre XQuery pour transformer cet objet en « structure EDN » véhiculant cet objet
L’objet de sortie est « EDN_EVENT_DATA »
Compléter votre XQuery en mode source de la façon suivante :
xquery version "1.0" encoding "Cp1252";
(:: pragma bea:global-element-parameter parameter="$ironMan" element="ns1:IronMan" location="../XSD/data.xsd" ::)
(:: pragma bea:global-element-return element="ns0:EDN_EVENT_DATA" location="../JCA/xsd/DEV_SOAINFRA_EDN_EVENT_DATA.xsd" ::)
declare namespace xf = "http://tempuri.org/Article_EDN_OSB/XQuery/TransformEDNFormat/";
declare namespace ns1 = "http://blog.easyteam.fr/article/marvell";
declare namespace ns0 = "http://xmlns.oracle.com/xdb/DEV_SOAINFRA";
declare namespace xmlns = "http://oracle.com/fabric/businessEvent";
declare function xf:TransformEDNFormat($ironMan as element(ns1:IronMan),
$namespace as xs:string,
$localname as xs:string)
as element(ns0:EDN_EVENT_DATA) {
<ns0:EDN_EVENT_DATA>
<EVENT>
<NAMESPACE>{ $namespace }</NAMESPACE>
<LOCAL_NAME>{ $localname }</LOCAL_NAME>
{
let $IronMan := $ironMan
return
<PAYLOAD>
{
fn-bea:serialize(
element {"business-event"} {
attribute {"xmlns:ns0"} {$namespace},
attribute xmlns {"http://oracle.com/fabric/businessEvent"},
element name{fn:concat("ns0:",$localname)},
element content{$IronMan}
}
)
}
</PAYLOAD>
}
</EVENT>
</ns0:EDN_EVENT_DATA>
};
declare variable $ironMan as element(ns1:IronMan) external;
declare variable $namespace as xs:string external;
declare variable $localname as xs:string external;
xf:TransformEDNFormat($ironMan, $namespace,$localname)
La fonction « fn-bea :serialize » permet de sérialiser le message XML véhiculé afin qu’il ne soit pas interprété par la file AQ à la réception.
Je crée ensuite un proxy service pour envoyer mon objet « IronMan ». Afin de simplifier cet exemple, je créerai un proxy service de type « Messaging Service », ce qui m’allège de l’écriture d’un WSDL.
Je commence à implémenter mon proxy service
Dans une variable « bodyTransformed » je récupère le résultat de ma XQuery à travers un ASSIGN sur le message d’entrée de la façon suivante :
J’ai décidé dans l’écran ci-dessus que le namespace de l’évènement serait « http://blog.easyteam.fr/article/edn » et que son nom serait « IronManEvent »
Je termine ensuite l’implémentation de mon proxy service :
Déployez votre projet sur l’OSB Server.
Avant de tester votre proxy service, il vous faut créer un abonné pour cet évènement. En effet, EDN ne gère pas la persistance de l’évènement s’il n’y a aucun abonné.
Création d’un abonné EDN
Pour cet exemple, nous irons à l’essentiel : un processus BPEL qui s’abonne à « IronManEvent ». Nous consulterons ce processus dans EM.
Créons d’abord notre fichier .edl de définition d’évènement dans notre nouveau projet SOA. Pour rappel dans mon proxy service, j’avais fait le choix en dur que le namespace de mon évènement serait « http://blog.easyteam.fr/article/edn » et que le nom de ce dernier serait « IronManEvent » :
Notre définition d’évènement étant local à notre projet SOA, la prochaine étape consiste à créer un processus BPEL abonné à cet évènement comme suit :
Ceci étant fait. Il ne nous reste plus qu’à tester !
Lancez la console service bus (/sbconsole) et testez votre proxy service :
Allons voir côté Enterprise Manager !
Mon processus BPEL a bien récupéré l’évènement avec la bonne payload !
Méthode alternative
Durant la rédaction de cet article, Edwin Biemond a publié un article présentant une méthode alternative se basant sur une file JMS faisant pont et un foreign server JMS. Je vous laisse apprécier son très bon article à cette adresse :
http://biemond.blogspot.com/2011/06/publish-to-edn-from-java-osb-with-jms.html
1 réflexion sur “Propager un évènement dans EDN depuis Oracle Service Bus”
Ping : Oracle Enterprise Pack for Eclipse (aka OEPE) « EASYTEAM LE BLOG
Les commentaires sont fermés.