Cet article débute une suite d’articles concernant les logs/audits SOA. De manière générale, la console Enterprise Manager de la SOA-Suite permet d’obtenir des informations sur les instances, notamment grâce aux informations déshydratées en base de données.
Cependant un problème récurrent est la réactivité de cette console : ralentissement, difficulté à accéder au détail d’une instance. Rien de plus rageant que savoir que l’information est juste là, mais si longue parfois à obtenir…
Cet article présente les alternatives possibles à la console, ainsi que la manière de les mettre en place.
Via l’API SOA
La première orientation estd’utiliser l’API de management à disposition pour obtenir les informations d’audit d’une instance. Ce choix semble le plus logique : les APIs sont là pour s’abstraire en grande partie de toute la partie technique associée aux instances SOA. Elles devraient permettre en cas de montée de version d’avoir un minimum de modification à appliquer aux batch l’utilisant.
Cette API a été présenté dans un précédent article, et permet notamment de récupérer grâce à ses filtres (CompositeInstanceFilter et ComponentInstanceFilter par exemple) des instances de processus. On pourra alors obtenir des objets représentant nos instances (CompositeInstance et ComponentInstance par exemple).
Une fois ces instances à disposition, il suffira pour obtenir l’audit d’appeler leur méthode getAuditTrail.
Cependant à l’utilisation, il semblerait que l’on puisse obtenir les audits associés à des processus BPEL, mais pas pour des Mediator par exemple. Apparemment l’audit des autres types de composants semblent toujours retourné vide.
De plus lorsque l’on souhaite traiter un certain nombre d’instances, les délais paraissent important (on ne peut faire qu’instance par instance la récupération de l’audit).
Enfin, il est nécessaire que le serveur soit « up and running » pour pouvoir obtenir des informations.
Cette méthode pourrait être la meilleure, mais ces dernières observations nous limite dans son usage. Ce sera celle à privélégier si les limitations ne compromettent pas votre objectif.
Exemple rapide de code java associé :
// Propriétés de connexion
Hashtable jndiProps = new Hashtable();
jndiProps.put(Context.PROVIDER_URL, "t3://soa-vm:8001/soa-infra");
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
jndiProps.put(Context.SECURITY_PRINCIPAL, "weblogic");
jndiProps.put(Context.SECURITY_CREDENTIALS, "welcome1");
// création du locator à partir des propriétés de connexion
Locator locator = LocatorFactory.createLocator(jndiProps);
// préparation de filters pour la récupération d'instances
CompositeInstanceFilter filter = new CompositeInstanceFilter();
filter.setId("290003");
ComponentInstanceFilter componentFilterMed = new ComponentInstanceFilter();
componentFilterMed.setEngineType("mediator");
ComponentInstanceFilter componentFilterBpel = new ComponentInstanceFilter();
componentFilterBpel.setEngineType("bpel");
// récupération d'une instance et de ses composants enfants
List<CompositeInstance> composites = locator.getCompositeInstances(filter);
for (CompositeInstance composite : composites) {
System.out.println("Composite Audit Trail : " + composite.getAuditTrail());
List<ComponentInstance> mediators =
composite.getChildComponentInstances(componentFilterMed);
for (ComponentInstance mediator : mediators) {
System.out.println("Mediator Audit Trail : " + mediator.getAuditTrail());
}
List<ComponentInstance> bpels =
composite.getChildComponentInstances(componentFilterBpel);
for (ComponentInstance bpel : bpels) {
System.out.println("BPEL Audit Trail : " + bpel.getAuditTrail());
}
}
Via SQL/Java
Devant ce constat concernant l’API, la seule alternative semble de mettre en place des interrogations de la base de l’infrastructure de la SOA. Cependant il existe peu de documentation précise et rien ne nous assure que le stockage ne sera pas différent dans une prochaine version. Une solution certainement plus complexe à mettre en place, mais qui devrait offrir davantage de résultats.
Les tables intéressantes
Voici une liste, non exhaustive, des tables et champs utilisés lors de la déshydratation des instances. Les informations sont stockées par composant (BPEL, Mediator, Reference, Business Rule…). Ici nous ne présenterons qu’une partie des tables, concernant les composants BPEL et Mediator.
BPEL
|
TABLE |
DESCRIPTIF |
| CUBE_INSTANCE | table contenant les instances BPEL |
| AUDIT_TRAIL | table contenant les audits trail des instances BPEL |
| AUDIT_DETAILS | table contenant les éléments audits de taille intermédiaire (auditDetailThreshold) |
| XML_DOCUMENT | table contenant les éléments XML de taille importante (largeDocumentThreshold) |
Il est à noter que les tables AUDIT_DETAILS et XML_DOCUMENT ne sont pas systématiquement utilisées. Des données peuvent y être stockés pour des causes de volume important (et permettre de manière générale de meilleures performances pour les accès aux métadonnées du BPEL). Elles seront utilisés selon les paramétrages auditDetailThreshold et largeDocumentThreshold, comme précisé dans la documentation Oracle (points 13.2.5 et 13.2.6) :
Mediator
|
TABLE |
DESCRIPTIF |
| MEDIATOR_INSTANCE | table contenant les instances de mediator |
| MEDIATOR_CASE | table contenant les case de chaque mediator |
| MEDIATOR_CASE_DETAIL | table contenant les audit des cases d’un mediator |
| MEDIATOR_AUDIT_DOCUMENT | table contenant les audits d’un mediator (payload, headers, properties…) |
Format des informations : pourquoi du java ?
Le principal problème que l’on rencontrera, lorsque l’on souhaite accéder à ces audits/logs, sera leur lecture proprement dite.
En effet les informations ne sont pas lisibles en l’état, suivant les tables, les champs nous intéressant contiennent des données :
- Compressées
- Binaires
- De Type Raw
- Sous forme d’objets java sérialisés
L’hétérogénéité des données, fait qu’il sera difficile d’obtenir les informations par SQL pur (du moins à mon niveau de SQL). L’utilisation de Java permettra la transition de données illisibles pour lutilisateur à des données compréhensibles.
Conclusion
La SOA-Suite présente une manière simple d’accéder aux logs/audits des instances de composites au travers de l’Enterprise Mananger. Cependant cette console a ses limites, qui peuvent être parfois contraignantes.
Vous avez pu découvrir ici 2 méthodes alternatives pour y accéder :
- API SOA : méthode simple et pérenne, permettant la récupération des audits BPEL principalement. Peu performante lors de recherches sur de multiples instances
- SQL/Java : méthode plus complexe et certainement moins pérenne. Beaucoup plus performante et adapté à des recherches sur multiples instances.
Dans d’autres articles, nous verrons le détail de récupération par type de composants (BPEL et Mediator, valide de 11.1.1.4 à 11.1.1.7) par SQL/Java, ainsi qu’un use case d’utilisation : définir les performances des différentes étapes d’un composite !
Restez connecté !
