Les timeouts sont un problème récurrent lors de la mise en place de processus BPEL.
Cet article présente comment et où modifier les plus important. Il s’attarde également sur un problème moins traditionnel, qui a suscité de nombreuses recherches … peut être ceci vous évitera-t-il les même galères … embarquons !

Avant tout…

Avant de commencer, il semble important de bien rappeler le point suivant :
Les timeouts sont présents pour éviter d’avoir de longues transactions, qui au final peuvent se révéler gourmandes, suivant la quantité des traitements à réaliser.
On peut les customiser pour les augmenter, et ainsi éviter certaines erreurs trop fréquentes, parfois à juste titre.
Cependant, on rencontre souvent l’effet pervers classique : un service répond lentement, provoquant des timeouts. Bien, augmentons alors les timeouts !
Eh bien non ! Cette béquille va au final masquer le problème, et surtout la cause initiale.
Commencez par :

• Vous demander si un tel temps de réponse est normal
• Si oui : avez-vous choisi le bon pattern pour un tel service ? Souvent on choisit des services synchrones pour la facilité, mais un service synchrone n’est pas « prévu » pour répondre en 1-2 minutes …
• Si non : commencez par analyser le problème de ce service avec la possibilité, si aucune solution ne se profile, de jouer sur les timeouts « temporairement ».

Enfin si vous pensez toujours avoir besoin d’adapter vos timeouts, continuons !

Les principales configurations

Présentation

La SOA-Suite 11g est bourrée de timeouts divers et variés à customiser. Généralement quelques ajustements sur les timeouts suivants sont suffisants pour résoudre les cas les plus courants :

• JTA Transaction Timeout : configuration globale des timeout des transactions JTA.
• Timeout des EJBs BPEL : configuration des timeouts des différents EJBs qui participent à l’exécution des processus BPEL.
• SyncMaxWaitTime : temps maximum d’attente d’un processus BPEL synchrone.

Une règle reste tout de même à respecter dès lors que l’on customise ces valeurs, sous peine de voir apparaitre des comportements suspects :

JTA Transaction Timeout > Timeout des EJBs > SyncMaxWaitTime BPEL

Comment configurer ces timeouts (11g) ?

Effectuez les configurations des timeout nécessaires et pensez à redémarrer le serveur pour que ces modifications soient prises en compte.

• JTA Transaction Timeout :

Sur la console d’administration, se rendre dans « Domain Structure => Services => JTA ».

La valeur par défaut est 30s

• Timeout des EJBs :

Sur la console d’administration, se rendre dans « Domain Structure => Deployments => soa-infra => EJBs ».

Les timeouts utiles sont principalement ceux de (timeout par défaut fourni)

BPELActivityManagerBean : 300s
BPELDeliveryBean : 300s
BPELDispatcherBean : 300s
BPELEngineBean : 300s
BPELFinderBean : 300s
BPELInstanceManagerBean : 300s
BPELProcessManagerBean : 300s
BPELSensorValuesBean : 120s
BPELServerManagerBean : 300s

• SyncMaxWaitTime :

Sur l’Enterprise Manager, se rendre sur « soa-infra », puis dans le menu choisir « SOA Administration => BPEL Properties => More »

Par défaut ce timeout est de 45s.

Et si mon problème persiste ?

Et bien là, vous tombez dans un cas particulier, qui doit être dû à une utilisation particulière dans votre processus…
Dans mon cas voici, malgré toutes les modifications, un extrait de l’erreur qui persistait dans les logs (extrait de l’audit) :

Concernant ce cas particulier, la solution finale était en fait assez simple, une fois que l’on sait quel est le problème…
Une transaction XA implique plusieurs sources de données. Pour chacune de ces sources, un « start » est réalisé pour impliquer la ressource dans la transaction, et un « end » à la fin.
Or la DataSource du domaine SOA est par défaut sans timeout XA précisé, et tente à priori toutes les 60s (valeur par défaut)  de faire une récupération sur cette ressource, et n’y arrivait pas, provoquant au final une impossibilité de maintenir la transaction et donc un « rollback » (une ressource de la transaction XA était inaccessible).
Ce mécanisme de récupération régulier semble être en place pour compenser l’absence de timeout défini.
La solution a donc consisté à définir que cette DataSource aurait une temporisation XA, afin d’éviter de passer par ce mécanisme de récupération. Pour cela, dans la console d’administration se rendre dans « Domain Structure => Data Sources => SOADataSource » (le nom peut varier pour vous repérer la bonne)

Ensuite effectuer la modification en cochant la case nécessaire dans l’onglet « Configuration / Transaction ». On note ici une valeur à 0 qui provoque un héritage du timeout global pour ce timeout particulier.

L’explication de ce dernier problème reste ma propre compréhension, et je vous invite, si vous souhaitez davantage de détails, à consulter cet article, qui m’a amené à cette solution.

Conclusion

Une bonne configuration des timeouts est importante pour mettre en place une solution stable, mais ils ne faut pas les augmenter à outrance. Il n’y a pas de règle précise sur la durée de ceux-ci, à vous de vous adapter et de tuner selon vos besoins.
En espérant que cet article vous aura évité des recherches fastidieuses dans le domaine parfois obscur des transactions…
Quelques sources (en partie, les recherches furent longues) et merci à leurs auteurs au passage !

• Article sur la configuration de timeout
• Autre article sur la configuration des timeouts
• Article concernant l’erreur XAER_NOTA