Gestion des erreurs dans BPEL 10.1.3x - Error Handling

La gestion centralisée des erreurs en 10.1.3.3 ( Fault Management Framework)


Il s'agit d'un sujet auquel nous avons tous été confrontés lors de la mise en place de projets SOA centrés sur BPEL: la gestion des erreurs. Pour ceux qui l'ont testée, la gestion des erreurs alourdit considérablement les processus en les rendant très complexes voire illisibles. En effet, pour gérer les erreurs, il faut non seulement intercepter les exceptions(catch), mais aussi les traiter(par notifications en général)


Pour rendre, plus lisibles les processus et pouvoir gérer les exceptions par niveau de gravité, il fallait jusqu'à présent imaginer un mécanisme central de gestion d'exceptions dit "Error Hospital". Ce dernier requérait l'écriture d'un Service Web de gestion des erreurs, et une définition(statique) de criticité pour l'exception ainsi interceptée. Toutefois, ce mécanisme, bien que flexible, requérait le redéploiement du processus pour tout changement de priorité et de criticité mais surtout rendait beaucoup moins lisible le processus par un FONCTIONNEL (à cause de la succession de try catch).


Heureusement, la 10.1.3.3 est arrivée!


De nombreuses fonctionnalités y sont intégrées, mais je me focaliserai sur le Fault Policy Framework ici


Qu'est ce que le Fault Policy Framework?
C'est un mécanisme de gestion centralisée des erreurs, essentiellement déclaratif et décoléré de l'implémentation du processus métier en lui-même. Il gère les cas de figure les plus courants i.e.: *Comment gérer des indisponibilités de Service Web? *Comment gérer de manière granulaire un certain type d'exception (type de Faute SOAP et/ou code de la faute) *Quelles actions déclencher le cas échéant i.e. combien de re-essais, comment escalader si la panne perdure, comment forcer la terminaison du processus, comment rejouer la séquence, comment déclencher une intervention humaine, exécuter un programme Java (en effet, c'est un Framework et il est extensible au travers d'une interface: IFaultRecoveryJavaClass ).
Quelle en est la valeur ajoutée?

Le 1er avantage est que ce mode opératoire permet de séparer les aléas opérationnels(coupure réseau, perte de BDD, indisponibilité de Service web etc.) du processus métier.
Le « Fault Policy Framework » permet également une meilleure lisibilité du processus BPEL. De ce fait, il permet de se concentrer sur la gestion des vraies erreurs fonctionnelles dans le design des processus.


Enfin, il permet de gérer à fortiori les erreurs.
On peut mixer la gestion des erreurs dans les processus, avec le Fault Policy Framework ; en effet, compte tenu de la granularité de ce dernier (par opération), on peut limiter son champ d’action et ainsi permettre l’activation de la gestion d’erreurs prévue dans les processus.
Sur le plan opérationnel, la console BPEL permet désormais de débloquer manuellement un processus en erreur : notamment en modifiant dynamiquement les données portant l’appel, en forçant la continuation du processus ou tout simplement en forçant son annulation.

Limitations

Attention, le « Fault Policy Management » ne gère pas les erreurs internes BPEL liées aux :
- mauvaise requêtes xpath
- types non valides dans les appels de fonctions xpath
- mauvais typage de données
etc.
En général, ces erreurs peuvent être décelées lors des tests unitaires ( utilisation de BPEL Tester)
Cas pratique chez un client
Client : XXXXXX
Temps de mise en place : 1J
Principe : Quels que soient les processus, une exception ( perte de réseau, perte de BDD ou Service Web en erreur etc.) devra effectuer au plus 5 essais par intervalles de (2, 4, 8, 16, 32S). Si au bout de ce nombre de tentatives, l’appel est toujours en échec, un mail est envoyé à l’administrateur par l’intermédiaire d’un programme java. A la réception du mail, l’administrateur se connecte sur la console Oracle BPEL et ouvre le processus en cause. Il a alors plusieurs choix possibles : il peut décider de forcer la suite du processus, de modifier les variables d’entrée de l’appel, forcer l’annulation du processus.

Pour aller plus loin…
Le Fault Policy management est l’une des bases de la 11G AS : http://bpel.us.oracle.com/11/index.jsp (site interne Oracle pour ceux qui sont de la maison)
Documentation de référence Oracle 10.1.3.3
http://www.oracle.com/technology/products/ias/bpel/pdf/10133technotes.pdf
Blog AMIS
http://www.it-eye.nl/weblog/2007/09/10/oracle-bpel-10133-fault-policy-management
http://technology.amis.nl/blog/?p=2485

XSL - créer ses propres fonctions XSL dans XML Mapper (user defined extension function)

Cet article vous permet de créer vos propres fonctions XSL à partir d'une classe java.

Tout d'abord il faut créer votre classe java effectuant une fonction non existante dans la palette du XML Mapper. Pour ma part j'utilise le super outil jdev .... ;)

Ma fonction d'exemple transforme des lettres 'aaa' en chaine 'bbb'.

package xsltfunctions;
public class XmlToHtml {
public XmlToHtml() { }
public static String getXmlConverted(String s)
{
s = s.replaceAll("aaa", "bbb");
s = s.replaceAll("zz", "RR");
return s;
}}


compiler cette classe, et rajouter un répertoire META-INF dans votre répertoire classes.


Le répertoire classes doit donc comprendre :

- 1 répertoire META-INF avec cet exemple de fichier XML conforme à la JSR 198 extension pour Jdev:





Télécharger ce fichier : ici
- 1 répertoire xsltfunctions contenant notre classe XmlToHtml compilée

Placer vous dans le répertoire classes pour exemple :

D:\dev_hugu\XmlManipulation\ClassXslFunction\classes

Faites un jar via la ligne de commande:

jar cvf xsltfunctions.1.0.jar *

Afin d'intégrer cette nouvelle fonction à jdev, vous devez modifier les préférences. Allez dans le menu Tools/Preferences, et sélectionner la dernière option XSL Maps.

Spécifier un fichier XML dans la zone:

Ce fichier XML décrit notre extension et comment retrouver la bonne classe, voici mon exemple:

Télécharger ce fichier extension.xml : ici

Ensuite quittez Jdev et re démarrer le.

Aller dans une transformation XSL et dans la palette des fonctions, votre nouvelle fonction apparait.

la fonction Test du XML mapper utilise bien notre fonction. Pour l'utiliser dans l'ESB / BPEL lors de l'éxecution sur votre serveur, il suffit de copier le fichier jar dans le répertoire de votre instance SOA suite:

ORACLE_HOME/j2ee/oc4j_soa/applib

Redémarrer votre Soa Suite et déployer votre processus bpel our ESB appelant cette transformation XSL et ca marche .....

Voici les liens vers la doc:

plus d'info sur XML Mapper en anglais : http://download.oracle.com/docs/cd/B31017_01/integrate.1013/b28981/xslt_mpr.htm#sthref1426

Bpel - Ecrire un fichier dans un répertoire dynamique - passer ou modifier des paramètres depuis la console

Voici un petit article sur BPEL et la possibilité au sein de ce super outil de passer ou modifier des paramètres à un processus déjà déployé c'est à dire en production.

L'exemple ci-dessous va illustrer le cas d'un processus Bpel qui doit écrire dans un répertoire un fichier xml. Le répertoire désigné est un paramètre. Il sera changé après avoir déployé ce processus.

Pour écrire un fichier dans un répertoire, on utilise l'adapteur fichier proposé en standard dans Bpel.

Il faut spécifier soit un nom logique, soit un chemin physque pour le répertoire de destination de ce fichier.

dans mon exemple nous allons créer la préférence "monrep", pour atteindre la liste des préférences il suffit de cliquez dans jdev sur l'icone:

puis la popup suivante apparait :

ainsi après le déploiement de ce processus on obtient une préfrence modifiable depuis la console Bpel.

Pour que cette préférence soit dynamique dans le processus, il faut utiliser une variable bpel basée sur le schéma :

et la spécifier dans l'onglet (comme ci-dessus) adapter de l'action invoke. Si le schéma ne fait pas apparaitre le champ xml directory, il faut éditer à la main le WSDL pour qu'il est la structure suivante: ici

Ensuite dans une action ASSIGN avant votre INVOKE de votre adapteur fichier, il suffit d'attribuer le nom du répertoire désiré:

Vous déployer votre processus, et vous pouvez dynamiquement changer le répertoire en modifiant la préférence depuis la console d'administration:

et voilou ....

Oracle Adapter for Siebel - Could not open a session in 4 attempts. {1}(SBL-JCA-00200)

Si vous avez mis en place l'adapteur siebel d'Oracle et que lors de la tentative de connexion vous avez ce superbe message d'erreur:

20080616-17:39:12 ERROR com.ibi.bse.TargetWorker:java.lang.IllegalStateException: Problem activating adapter. (Could not open a session in 4 attempts. {1}(SBL-JCA-00200)). Check logs for more information

N'hésitez pas à vérifier vos paramètres de connexion, si vous êtes certains, consultez alors la log de l'adapteur présente dans ORACLE_HOME\adapters\application\config\jca_sample\log

où jca_sample correspond à votre configuration depuis l'application explorer.

Si cette log ne vous donne pas plus d'information sur le problème consultez alors la log du serveur siebel:

présente dans ce répertoire D:\sea\siebsrvr\log dans mon cas. Listez les derniers fichiers Log et vous trouverez l'erreur :

2021 2008-06-16 11:03:27 0000-00-00 00:00:00 -0500 00000000 001 003f 0001 09 siebdev 1500 2872 D:\sea\siebsrvr\log\siebdev.log 8.0 SIA [20405] ENUObjMgrLicense Error 1 00000002485605dc:0 2008-06-16 11:03:27 (dmlicmgr.cpp (133)) SBL-DAT-00171: A license key for this software has expired.
Please enter a new key to proceed, or contact your system administrator.

Si maintenant on ouvre SiebelTool (outil de dev et d'administration des objets siebel)

en allant dans Help puis Technical support puis le bouton licence key on a :

Modifiez vos licences et cela devrait le faire .....

Oracle WLP (weblogic portal)

Certes c'est en anglais cette superbe vidéo, mais cela vous donnera une étendue du la puissance de WLP ....

http://www.youtube.com/watch?v=tn2DjGoBkMQ

OWSM - Web Service Manager deployer une nouvelle gateway

Vous pouvez configurer depuis la console web de WebService Manager une nouvelle gateway afin de sécuriser vos Web Services.

Pour que cette gateway soit opérationnelle, il faut la déployer sur votre SOA suite.

Pour faire cela, il suffit d'utiliser le script :

ORACLE_HOME\owsm\bin>wsmadmin deploy gateway

PS: Il faut bien entendu que votre SOA suite soit démarrée ...

plus de renseignements en anglais sur :

http://forums.oracle.com/forums/thread.jspa?messageID=2571910&tstart=0

WebApp Ipico avec Tolk Framework pour Oracle

Je vous avais déjà proposé un article sur Tolk le framework permettant d'interpréter les trames IPX des lecteurs RFID IPICO, je vous propose maintenant de découvrir la webapplication à déployer dans le serveur d'application Oracle.

Cette webapplication comprend une servlet qui peut démarrer automatiquement vos communications avec vos lecteurs RFID ipico.

Cette application web comprend une servlet qui autorise le démarrage et l'arrêt (bug en cours de correction) manuellement. Une fois la trame récupérée avec le protocole IPX dans la webapp, celle-ci est poussé soit sur un fichier, une base de donnée, ou encore une queue JMS.

C'est le dernier cas que j'ai utilisé dans ce lien vers mon projet Jdev: ici

Bon RFID à tous .........