Bien souvent lorsque vous venez du monde Java, vous avez été habitué à l’utilisation de frameworks ORM qui vous permettaient de faire les choses avec énormément de souplesse. La SOA Suite propose pour effectuer des demandes en base un DBAdapter. Celui-ci est relativement complet, mais ne permet pas forcément de tout réaliser.
Voici un petit tour d’horizon des possibilités de cet adapter, histoire de vous adapter à ce qu’il est capable de faire (et éviter des mauvaises surprises)…
Les différents modes du DBAdapter
Lors de la création d’un DBAdapter, il vous sera demandé rapidement de choisir le type d’opération que l’on souhaite voir l’adaptateur réaliser :
Call a stored procedure or function
Cette opération vous permettra de faire appel à une procédure PL/SQL définie dans la base. L’adaptateur se chargera de convertir les entrées / sorties de la procédure en une XSD.
Perform an operation on a table
Cette opération permettra de réaliser une opération sur une table (ou un ensemble de tables associées par des clefs) particulière :
- Insert ou Update
- Insert only
- Update only
- Delete
- Select
- Query by example
Ces opérations sont assez explicites par leur nom, sauf peut être le « Query by example » sur lequel nous allons nous attarder un peu.
En effet, le « Query by example » offre une fonctionnalité fortement appréciable : la possibilité de définir des critères dynamiques ! Bon ceci étant ne nous affolons pas, la dynamique reste sur une égalité sur des champs.
Imaginons que vous ayez une table « Client », contenant un nom, un prénom, un téléphone. Le « Query by example » vous permettra de fournir en entrée une combinaison de ces champs. L’adapter renverra une liste de Clients qui ont la combinaison correspondante.
Poll for New or Changed Records in a table
Cette opération permettra de déclencher un composite si des éléments correspondent à la requête effectuée.
C’est un moyen simple de traiter des nouvelles données saisies dans une table, par exemple avec une notion d’état mise à jour (à traiter, traité…). Selon l’intervalle configuré, l’adapter va interroger régulièrement la base et remonter les éléments correspondants. Le composite se verra fournir ces éléments et pourra effectuer le traitement nécessaire.
Execute Pure SQL
Il s’agit de l’opération la plus souple du point de vue requêtage : l’adaptateur proposera de fournir une requête personnalisée.
On pourra ainsi effectuer des requêtes plus complexes que dans les autres modes (jointures, conditions complexes…)
Paramètres
Les requêtes de certains modes (polling, select, pure sql) peuvent être en partie customisées (order by, conditions…) et permettent notamment le passage de paramètres.
Ainsi pour un select sur un Client, il sera possible de fournir un paramètre paramNom de la manière suivante :
select * from CLIENT where NOM like #paramNom
Ce paramètre pourra être par l’input d’appel de l’opération. Cela permet de dynamiser dans une certaine mesure les requêtes qui seront exécutées.
Les limites observées du DBAdapter
Lors de l’utilisation simple du DBAdapter, on n’observe pas de limites particulièrement gênantes. Cependant au fur à mesure, les demandes peuvent devenir de plus en plus complexes : il est bien cet adaptateur, simple, rapide à mettre en place, on va lui en demander davantage !
Le principal problème rencontré concerne la gestion des conditions. En effet, vous avez peut être eu l’habitude d’utiliser des mécanismes tels que les Criterias Hibernate ou d’autres méthodes permettant de dynamiser les critères. Ainsi vous pouviez facilement effectuer des interrogations en manipulant les différents critères.
- Le DBAdapter reste très limité dès lors que l’on souhaite faire des interrogations « dynamiques » :
- Le « Select » : permet de fournir des paramètres « fixes » qui devront être systématiquement fournis.
- Le « Query by example » : permet de fournir en paramètre n’importe quel champ, mais uniquement en égalité
- Le « Execute Pure SQL » : comme le « Select »
Ainsi, il est difficile de mettre en place des requêtages dynamiques sans multiplier des DBAdapters pour correspondre à tous les besoins, ou réfléchir à des solutions de contournement :
Par exemple, fournir une date de début et de fin, au lieu d’avoir une seule date et vouloir dans un cas les éléments ayant une date inférieure et dans l’autre une date supérieure.
Conclusion
Ces explications ne sont pas exhaustives concernant le DBAdapter. En effet elles reflètent une expérience personnelle de son utilisation, qui ne couvre pas l’ensemble de ce qui est proposé par celui-ci : ce n’est qu’un tour d’horizon.
La documentation reste votre meilleure amie pour déterminer s’il pourra répondre précisément à votre besoin. Si vous avez encore un doute, une simple preuve de concept vous permettra de vous assurer que la fonctionnalité à assurer est possible.
Il faut également garder à l’esprit que l’adapter n’est pas conçu pour être capable de tout faire : il aura toujours des limites, et c’est normal ! Des demandes trop complexes sont souvent associées au fait que l’on déporte du « métier » à son niveau : dans ce cas ne vaut-il mieux pas encapsuler dans un service ce besoin, qui saura gérer toute la complexité métier ?
Sources
