Modifier la console Bpel

La console Bpel est une simple WebApplication qui utilise les API java-bpel.

On peut donc la modifier. Elle est présente dans votre répertoire ORACLE_HOME/j2ee/mon_instance/applications/orabpel/console

Ainsi, dans mon exemple que je vous propose de rajouter le temps d'éxecution d'un proccessus en ms, dans la console comme le montre l'image ci-dessus.

Pour cela il faut éditer la page jsp :

ngInstanceList.jsp

et modifier la ligne 651, en rajoutant le temps en (<%= ( iH.getModifyDate().getTime() - iH.getCreationDate().getTime() ) / divisor %> ms) :

La jsp en téléchargement sur ce lien ICI

Comment faire une Correlation dans Bpel pour réveiller un processus

Ce mémo explique rapidement comment créer un processus Bpel (dit père) qui s'initialise et attend qu'un autre processus (dit fils) lui permet de se finir en fonction du contenu du message xml qu'il porte.

Pour être plus clair, le processus père démarre et attend. Ensuite, le fils poste un message au père avec un contenu approprié au père pour qu'il se termine.


Ce point technique sur la correlation démontre la simplicité de mise en oeuvre dans Bpel Process Manager D'Oracle (forcement)

La premiere étape consiste à créer un processus Bpel de type asynchrone dans Jdev:




puis de rajouter une méthode d'accès à ce même processus afin qu'il est 2 méthodes d'entrée et 1 de sortie. Cette étape se fait en modifiant le WSDL du processus que l'on vient de créer.

La méthode "suite" prend en entrée le même schéma et en sortie le schéma "output" par défaut.

Nous avons donc maintenant un processus BPEL avec 2 méthodes d'accès, auquel nous rajouter une action ASSIGN pour renseigner le résultat :

On rajoute une action "RECEIVE" afin d'arrêter le processus père tant que les conditions fonctionnelles ne sont pas remplies par le fils :

puis on effectue un "deploy" du processus père.

Maintenant on va créer le fiston (dit le processus fils), celui-ci va faire une action " INVOKE" pour prévenir le père sur la méthode "suite" qu'il peut continuer et se terminer si l'input du père correspond à l'input du fils.

Attention : Pour faire l'invoke du père il faut avant tout déployer le père.

Détail du fils :

L'action "invoke" appelle la méthode "suite" du père :

Puis il faut créer un correlationSet comme cela :


Puis définir un property alias, qui n'est autre qu'une propriété avec un type (ici String) qui permet de relier le père et le fils. Cette propriété est remplie par un Xpath :



Ensuite sur le père, vous devez spécifier une action "Receive" sur la méthode "suite" appelée par le fils.



Dans cette même action, sur l'onglet correlation, ajouter votre correlationSet :

La première action Receive du client doit comporter également le même correlationSet, mais il aura un 'initiate' à 'true'.

Dans le fils, sur l'action 'invoke' qui poussera le mesage XML vers le père le correlationSet (identique au père) doit avoir le paramètre 'out' (onglet correlation).

Le détail de ces 2 processus sur ce lien : (ICI)

Passer des variables BPEL vers une transformation XSL

Par défaut BPEL process Manager propose d'effectuer des transformations XSL avec XSLMapper (outil graphique de mapping dans Jdev).

Lors de l'ajout d'une tâche "transformation", Bpel process manager génère la ligne suivante :

ora:processXSLT('Transformation_1.xsl',bpws:getVariableData('inputVariable','payload')) vers votre variable de destination.

Mais dans beaucoup de cas de format pivot ou de boucle sur un tableau XML il parait necessaire de passer à la transformation XSLT des données du processus BPEL. Ainsi, dynamiquement on peut re utiliser la même transformation XSL avec des paramètres non fixe.

Pour faire cela, il faut utiliser la même ligne, mais en rajoutant des 'properties' :

ora:processXSLT('Transformation_1.xsl',bpws:getVariableData('inputVariable','payload'),bpws:getVariableData('BPELxslparameters'))

où 'BPELxslparameters' est une variable de ce type XSD (ICI)

qu'il faut créer dans votre processus Bpel. Ensuite, il faut renseigner les propriétés "name" et "value". Le champ "name" correspond à votre "parameter" XSL que vous déclarer graphiquement dans XSLMapper:



"cpt" correspond à un parameter en XSL sur la source. Ce paramètre peut être utilisé dans votre transformation XSL. Pour mon exemple, je m'en sert en tant que compteur, pour boucler sur ma structure de départ (à gauche dans la copie d'écran de mapper xsl).

Je vous propose mon exemple XSL : ICI

Ensuite il faut créer 2 "assign" dans Bpel :

- 1 pour initialiser la structure XML (remplir la propriété "name")

- 1 pour initialiser la valeur (remplir la propriété "value")

Mon code Bpel, afin de voir la création de la variable 'BPELxslparameters' et le reste des infos en détail (ici)

Ainsi, comme cela on peut facilement passer des paramètres entre l'instance BPEL et le moteur de transformation XSL.

Un projet Jdev Bpel/XSL qui démontre tout cela sur ce lien (ICI)

La même utilisation en anglais : http://blogs.oracle.com/rammenon/2007/05/07

Paramètres JDEV 10.1.3x

Afin de récupérer d'un poste à un autre poste, vous pouvez copier les fichiers suivants pour retrouver votre configuration Jdev.

Vous pourrez également dans le cadre d'un développement en équipe positionner ces fichiers dans votre gestionnaire de source (Exemple : http://downloads.open.collab.net/collabnet-subversion.html)

Les fichiers de configuration sont sous :

D:\productORACLE\10.1.3.1\jdevinstance\system\oracle.j2ee.10.1.3.41.57

où D:\productORACLE\10.1.3.1\jdevinstance\system correspond à mon répertoire d'éxecution de Jdev 10.1.3x

La liste des fichiers est la suivante:

- IDEConnections.xml
- preferences.xml
- uddiconnections.xml
- webdavcon.xml

Faire du IE dans FireFox

voici un plugin trés pratique pour FireFox, notamment pour les WebApp non compatible FireFox :

http://ietab.mozdev.org/installation.html


sinon j'aime beaucoup :

- TAB Effect
https://addons.mozilla.org/fr/firefox/addon/4258


- et Lens Pic
https://addons.mozilla.org/da/firefox/addon/5579

ODI Suite

Je vous propose une petite explication de la suite ODI:

A la suite des rachats d'éditeurs comme Sunopsis (ETL), BEA (logiciels d'infrastructure) et Hyperion (décisionnel, gestion des performances), Oracle lance sa nouvelle plate-forme d'intégration de données : Data Integration Suite. Basée sur des standards ouverts, la solution cible les problématiques d'ETL (extraction, chargement, transformation de données), de qualité des données et de gestion des processus métiers.

Intégrée à la gamme Oracle Fusion Middleware (intergiciels), Data Integration Suite a été conçue pour trouver sa place dans une architecture orientée services (SOA). Ainsi, Data Integration Suite doit permettre à l'entreprise utilisatrice de connecter sources de données et applications hétérogènes (différents progiciels, différentes bases : Oracle Database, IBM DB2, MySQL, Microsoft SQL Server, etc.), et de diffuser l'information souhaitée à travers ses départements. D'autres acteurs sont présents sur ce créneau, parmi eux les spécialistes de l'ETL Informatica et Talend, l'alternative française open source.

Oracle Data Integration Suite (Data Integrator, BPEL Process Manager, Enterprise Service Bus, Application Server, Data Relationship Manager, B2B Engine et Business Rule Engine) est facturée à partir de 60.000 dollars par processeur (CPU). Il est également possible d'intégrer une option qui permet d'adapter la solution au grid computing (regroupement de serveurs Unix, Linux, Windows...)

Tutorial ODI

Pour commencer avec ODI (Oracle Data Integrator) .......

Aller sur ce lien ICI

Oracle Business Rules V11

Voici un petit mémo sur OBR v11 :

L'interface graphique sera intégrée totalement à Jdev11 et permettra d'effectuer des tableaux de correspondance et de déclenchement de règles metiers.

Toujours basé sur
RETE Rules “Engine”
(based on JESS)

Oracle Business Rules - Règles & Structure XML Fact

OBR permet de positionner une règle métier qui peut être executée depuis Bpel, ESB, java, WebService ...

Dans le cas présent, je vais vous détailler comment on créé une règle dans l'application Web "Rule Author" présent dans la SOA suite.

Le principe est le suivant :

- Mettre en place WebDav (cf autre article de mon blog) sur Oracle HttpServer

- Aller sur votre webapplication RuleAuthor (http://monserveur:monport/ruleauthor) et spécifier une connexion WebDav comme cela:
Ensuite il faut créer un repository :

Le charger (action load dans le menu):


RuleAuthor vous répond alors : Dictionary 'Monhugu (INITIAL)' has been loaded

La prémière étape est terminée, maintenant, nous allons importer une structure XML à partir du XSD suivant ICI

Cette structure XML vous permet d'envoyer des faits au moteur de règle et de récuperer les résultats.

L'import de la structure XML se fait dans le menu, "definitions" puis cliquez sur XMLFact. Un bouton "create" est présent dans la partie droite de la page. Cliquez dessus et spécifier les paramètres suivants:

XML Schema = D:\dev_hugu\BlogDemo\SchemaProject\BlogComm.xsd

JAXB Class Directory = d:\temp (Permet de construir les classes java correspondant à votre structure XML, c'est à dire les Getter & Setter sur chaque élément)

Puis cliquez sur "Add Schéma", pour avoir l'écran suivant :

Sélectionner les 2 lignes comme proposé et cliquez sur "Import".

La structure est intégrée à OBR (Oracle Business Rule).
Vous devez maintenant créer vos règles métiers, comme par exemple le calcul d'une commission :

Ensuite vous sauvez le tout ....

et depuis BPEL on utilise alors une étape DECIDE comme cela:


Voici le projet Jdev correpondant à cette copie d'écran à télécharger ICI

sinon pour une documentation en English plus précise : http://download.oracle.com/docs/cd/B32110_01/web.1013/b28965/toc.htm