Vous pouvez avoir besoin un jour de créer un composant OSB (Oracle Service Bus) qui publie les messages qu’il reçoit vers une multitude de files JMS possibles. Une sorte de gouvernail à flux de messages.
D’une manière générale, lorsque l’on souhaite publier des messages vers une (ou plusieurs) file(s) JMS, le Proxy Service du composant OSB fait appel à un (ou plusieurs) Business Service(s) dont la seule fonction est de publier des messages vers une file JMS renseignée dans la partie « Transport » de chaque Business Service.
Or selon le besoin, le nombre de file JMS cibles peut être élevé. Et dans ce cas, on peut rencontrer les problèmes suivants :
- puisqu’il faut autant de Business Services créés que de files JMS cibles, le composant peut rapidement nécessiter d’avoir une quantité importante de Business Services ;
- cela peut engendrer des problèmes de maintenabilité : imaginons que l’on souhaite ajouter un préfixe à tous les noms de files JMS, il faudra répercuter cette modification sur chaque Business Service ;
- et surtout, chaque fois qu’une nouvelle file est ajoutée à la liste des files cibles, il faut ajouter un nouveau Business Service, et par conséquent redéployer le composant dans tous les environnements concernés.
Pour éviter cela, il est possible d’utiliser un « Dynamic Publish » au sein du Proxy Service, lequel fera appel à un seul et unique Business Service qui prendra en compte l’URI de destination de manière dynamique.
Comment procéder ?
Etape 1 : créer un Business Service « dynamique »
<BS.png>
La valeur renseignée dans l’Endpoint URI n’a pas d’importance puisqu’elle ne sera pas utilisée. C’est juste pour rendre le Business Service valide.
Etape 2 : ajouter un « Dynamic Publish » dans le Proxy Service
<DynamicEnqueue_PS.png>
<route.png>
<ctx:route isProxy= »false »>
<ctx:service>UtilDynamicJmsEnqueue_OSB/BusinessServices/DynamicJmsEnqueue_BS</ctx:service>
</ctx:route>
Cas d’utilisations
- Passage des paramètres de la file JMS via une variable<assign_JmsName2.png>
- Passage des paramètres de la file JMS via les « user-headers »<assign_JmsName.png>
Aller plus loin
Dans le cas où vous utilisez plusieurs fabriques de connexions (connection factory), il est envisageable de paramétrer aussi dynamiquement la fabrique de connexion associée à la file JMS dans l’URI Endpoint.
Périmètre d’application
Il faut considérer que l’utilisation de toutes les files JMS est censée être similaire au niveau du comportement à l’exécution du flux (QoS (Exactly Once ou Best-Effort), nouvelles tentatives en cas d’échec, etc.).
Exemples :
- Si certaines files JMS doivent être traitées avec une QoS (qualité de service) en « Exactly Once » et d’autres en « Best-Effort », il faudra créer deux Dynamic Publish : un configuré avec un Routing Options spécifiant une QoS en « Exactly Once », et un autre avec une QoS en « Best-Effort ».
- Si pour certaines files JMS plusieurs tentatives après échec doivent être programmées, dans ce cas il faudra prévoir deux Business Services : un configuré avec le paramètre Retry Application Errors = Yes et Retry Count > 0, et un autre configuré avec Retry Application Errors = No et Retry Count = 0.
