mardi 22 juillet 2008

BAM : Récupération des données provenant de Bpel

Si vous n'arrivez pas à récupérer les données du processus Bpel afin de les postionner dans le DataSet du BAM, c'est peut être parce que vous avez ce type d'erreur dans votre log SOA suite :

ERROR default.collaxa.cube.sensor
No value for key: _cde in BAM payload:
(_cde correspond à mon champ dans le DataSet du BAM)

En fait, c'était mon cas mais ce n'est pas une erreur, c'est une mauvaise utilisation de Bpel avec le BAM.

Tout vient de la transformation xsl utilisée entre BPEL et BAM.
Les données du processus BPEL sont sous l'arborescence XSD suivante:


Comme on le visualise dans l'image ci-dessus, l'ensemble des données du processus Bpel (pour instance qui vient de fonctionner) est sous l'arborescence Xpath :

/tns:actionData/tns:payload/tns:variableData/tns:data

Vous devez donc mapper comme dans l'image ci-dessus, /tns:actionData/tns:payload/tns:variableData/tns:data vers la donnée du DataSet du BAM présente à droite dans l'image.


Une fois cette opération effectuée, si vous avez un XSD contenant plusieurs champs pour votre processus BPEL, il suffit de spécifier dans le processus Bpel quelle variable XML vous souhaitez pousser vers le BAM.

Cette action se fait dans Jdev sur l'action de votre choix :


Sélectionnez l'onglet "Sensor"



Spécifier votre variable qui sera poussée dans la transformation XSL du dessus




Ensuite vous retrouverez les données du processus BPEL dans le BAM :



Et voilou ....

mercredi 16 juillet 2008

populateXRefRow - MDM simple - Cross Referencing - Xref - Cross Reference - XrefTool


Cet article permet de mettre en oeuvre du cross referencing. Le cross referencing permet d'associer un id d'une application à une ou plusieurs autres applications. La correspondance des identifiants est alors centralisée dans la Soa Suite 10.1.3.3 (uniquement).


Exemple:

Une application Siebel gère les contacts par rapport à une application SAP. La concordance des identifiants des contacts entre Siebel et SAP, peut se faire via une table de référence croisée. Oracle Soa Suite et notamment l'ESB permet de mettre en oeuvre un référentiel croisé.


Pour mettre en oeuvre Xref, il faut utiliser dans un premier temps l'outil en ligne de commande Xreftool :


Cet outil permet de créer les tables dans le référentiel de la soa suite.


L'outil XrefTool est présent dans :

/integration/esb/bin

Votre Soa Suite doit être démarrée, et vous devez postionner les variables d'environnement comme suit:

set oc4j_username=oc4jadmin

set oc4j_password=XXXX


Lancer la commande: xreftool.bat -shell

un curseur apparait ">" et attend vos instructions.

la commande "help" permet d'avoir la liste des instructions disponibles.


Pour créer un objet de cross referencing, il faut tout d'abord utiliser:

!! Attention les instructions doivent respecter les minuscules et majuscules !!


createTable clients


ensuite nous allons ajouter des colonnes dans cet objet 'clients' pour associer l'id de Siebel avec l'id de SAP.


addColumns {tableName columnName1,columnName2...}

soit pour notre exemple : addColumns clients siebel,SAP


on peut bien évidemment rajouter des colonnes par la suite ou les supprimer si vos références croisées évoluent dans votre SI.


C'est terminé pour la création du référentiel .... c'est rapide ;)


Ensuite sous le répertoire :

/integration/esb/sql/oracle

Lancer le script SQL : xreftables.sql

en utilisant l'utilisateur oraesb

ce qui donne:

sqlplus oraesb/XXX

@xreftables.sql;


Ensuite vous pouvez utiliser l'ensemble des fonctions "XPath Extension Function" proposée dans l'ESB ou dans BPEL.



Pour renseigner votre référentiel croisé :

xref:populateXRefRow1M(xrefTableName as string,
xrefReferenceColumnName as string,
xrefReferenceValue as string,
xrefColumnName as string,
xrefValue as string,
mode as string) return xrefValue as string


mode = Add ou Update ou Link ou Any


xref:populateXRefRow(xrefTableName as string,
xrefReferenceColumnName as string,
xrefReferenceValue as string,
xrefColumnName as string,
xrefValue as string,
mode as string) return xrefValue as string


mode = Add ou Update ou Link ou Any


et voici les fonctions de recherche:


xref:lookupXRef(xrefTableName as string,
xrefReferenceColumnName as string,
xrefReferenceValue as string,
xrefColumnName as string,
needAnException as boolean) return as string



xref:lookupXRef1M(xrefTableName as string,
xrefReferenceColumnName as string,
xrefReferenceValue as string,
xrefColumnName as string) return as node-set


Je vous propose un exemple BPEL à télécharger ICI qui utilise la fonction xref:populateXRefRow
pour rappel, les functions sont aussi accéssibles dans Oracle ESB.

mercredi 9 juillet 2008

FOTY0001 dans SOA Suite 10.1.3.3

Pour visualiser en détail les exceptions XML il suffit de passer le patch suivant sur la soa suite 10.1.3.3.

C'est disponible sur metalink.oracle.com


# Interim Patch for bugs 6458663
#-------------------------------------------------------------------------##
DATE: 9th Oct 2007# -------------------------#
Platform Patch for : Generic#
Product Version # : 10.1.3.3.0#
Product Patched : Oracle BPEL Process Manager##
Bugs Fixed by this patch:# -------------------------#
Bug:6458663:MERGE LABEL REQUEST ON TOP OF 10.1.3.3

FOR BUGS 5473225 5926809# Bug:5473225:
PATCH01 GENESIS HOT UNABLE TO CATCH AN EXCEPTION DURING A TRANSFORM#
Bug:5926809:ORA PARSEESCAPEDXML XPATH EXPRESSION FAILED TO EXECUTE FOTY0001: TYPE ERROR#

mardi 8 juillet 2008

Envoyer un message depuis Siebel EAI vers Soa Suite avec AQ / JMS

Cet article permet de vous expliquer comment on peut à partir de Siebel EAI envoyer un message vers un fournisseur JMS/AQ. Autrement dit, envoyer un flux xml dans une queue Advanced Queuing. Celui-ci est ensuite récupéré par l'adapteur AQ de la Soa Suite.

Pour cela il suffit:

Paramétrer un queue JMS / AQ (Advanced Queuing) dans la base de donnée Oracle hébergeant Siebel.

Le message est alors poussé depuis Siebel directement dans la même base de données. Pour effectuer cette opération, Siebel EAI utilise le provider JMS décrit dans le fichier pdf (ici) en anglais.

Ce mécanisme permet d'assurer la persistance du message Siebel quelque soit l'état de la brique SOA.

Il ne nécessite pas d'avoir une SOA suite en mode cluster. Lorsque que la SOA suite est disponible à nouveau, un processus ou un flux ESB vient consommer le message SIEBEL dans la queue AQ/JMS (via l'adapteur proposé en standard dans SOA suite).

Cette dernière solution semble la plus proche des attentes des personnes ne voulant pas perdre un seul message Siebel.

Je vous propose également un ppt décrivant rapidement AQ (pour ceux qui ne connaissent pas): ici.

mercredi 2 juillet 2008

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