Problème :
Un adaptateur de la base de données (adaptateur de polling) lit un message en ‘LOGICAL DELETE’, c’est-à-dire qu’une fois que le message a été lu par l’adaptateur, il va être supprimé définitivement dans la base de données. Ensuite, le message va être reçu et traité par un processus BPEL.
Par défaut, l’adaptateur de la base de données et le processus BPEL ne sont pas dans une même transaction, donc, cela crée un problème : le message exécuté par le processus BPEL est en erreur, et la transaction ne peut pas être rollbacké jusqu’à l’adaptateur de la base de données, et le message est perdu définitivement.
 
Solution :
C’est simple, on va juste mettre l’adaptateur de polling et le processus BPEL dans une seule et même transaction : dans ce cas-là, la transaction peut être rollbackée jusqu’à l’adaptateur de polling, et le message va être gardé et va être pollé et traité par la prochaine transaction…
La configuration pour réaliser ce cas est aussi simple, il suffit juste à configurer les propriétés transactionnelles pour le processus BPEL dans composite.xml.
[sourcecode language=’xml’]
<component name=’TraiteDataminerFFournisseur’>
<implementation.bpel src=’TraiteDataminerFFournisseur.bpel’/>
<property name=’bpel.config.transaction’ many=’false’ type=’xs:string’>required</property>
<property name=’bpel.config.oneWayDeliveryPolicy’>sync</property>
</component>
[/sourcecode]