Blog

le 07/11/2018
ygamba
Middleware, SOA & Urbanisation

Adaptateur Oracle JCA sur un environnement OSB clusterisé

« Le bus de service est une multiprise protocolaire… »

Il existe, en effet, différents types d’interconnexions systèmes qu’Oracle propose. Parmi lesquels, l’utilisation d’un adaptateur de ressources JCA dont :

Oracle JCA Adapter for AQ
Oracle JCA Adapter for Database
Oracle JCA Adapter for Files/FTP

Je vous propose ici, une procédure en 4 étapes de déploiement de l’adaptateur fichier sur un environnement OSB « clusterisé » qui peut être adaptée à tout autre adaptateur JCA Oracle.

1. Création du fichier de configuration JCA OSB

<adapter-config name="CR" adapter="File Adapter" wsdlLocation="../wsdl/CR.wsdl" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
  
  <connection-factory location="eis/HAFileAdapter" adapterRef=""/>
  <endpoint-interaction portType="Write_ptt" operation="Write">
    <interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">
      <property name="PhysicalDirectory" value="/OSB/CR/output"/>
      <property name="FileNamingConvention" value="%yyyyMMdd_HHmmSSss%_%SEQ%_CR.xml"/>
      <property name="Append" value="false"/>
      <property name="NumberMessages" value="1"/>
    </interaction-spec>
  </endpoint-interaction>
 
</adapter-config>

2. Liaison du JCA avec un Business Service

On peut constater le chargement des paramètres du fichier JCA dans l’espace « Advanced Settings » du Business Service :

C’est terminé côté développement OSB, notre Business Service est donc prêt à parler « fichier ».
Mais alors que tout semble ok, mon connecteur ne semble fonctionner qu’une fois sur 2, avec cette trace d’erreur dans les logs (dont j’ai sélectionné quelques lignes) :

####<15 déc. 2016 09 h 28 CET> <Error> <JCA_FRAMEWORK_AND_ADAPTER> <cluster002> <SERVEUROSB_002> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <11d1def534ea1be0:5e727d80:16059465e82:-8000-0000000000000007> <1513326511545> <BEA-000000> <Error while performing endpoint Activation: BINDING.JCA-12561
Erreur d'emplacement de l'adaptateur de ressources JCA (WebLogic).
Impossible de localiser ladaptateur de ressources JCA via lélément <connection-factory/> du fichier de liaison .jca
Le composant de liaison JCA ne parvient pas à démarrer l'adaptateur de ressources indiqué dans l'élément <connection-factory/> :  {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address: location='eis/HAFileAdapter'
Causes possibles : 
 1) Echec du déploiement du fichier RAR des adaptateurs de ressources vers le serveur d'applications J2EE WebLogic.
 2) Le paramètre d'emplacement JNDI <jndi-name> figurant dans le descripteur de déploiement JCA WebLogic n'a pas été défini sur eis/HAFileAdapter. Dans ce dernier cas, vous devrez peut-être ajouter une nouvelle entrée (connexion) 'connector-factory' au descripteur de déploiement. 
Corrigez cette erreur, puis redémarrez le serveur d'applications WebLogic
 [Caused by: Unable to resolve 'eis.HAFileAdapter'. Resolved 'eis']>

Traduction :

Suite à une surcharge d’activité du composant JCA sur le cluster, Weblogic ne sais pas quoi faire sur le 2ème serveur !

En effet, Weblogic a besoin qu’un plan de configuration soit déployé sur chacun des serveurs OSB, il nous reste donc 2 étapes.

3. Configuration Weblogic de l’adaptateur et génération du plan.xml (via la console d’administration Weblogic)

D’abord, recherchons la ressource FileAdapter :

Ensuite, la configuration de l’instance eis/HAFileAdapter :

Créer une session Weblogic puis modifier le répertoire cible « ControlDir » :

Et enfin générer le fichier « plan.xml » par enregistrement des modifications puis fermeture de la session Weblogic :

4. Distribution sur les serveurs

Vous trouverez alors le fichier plan.xml dans le répertoire cible « controlDir » que vous avez choisi.
Il faut maintenant via un terminal de commande, recréer la même arborescence sur l’ensemble de vos serveurs et y déposer le fichier que vous venez de générer « /OSB/FileAdpater/ControlDir/plan.xml« .

Il ne vous reste plus qu’à redémarrer votre serveur admin et vos serveurs managés afin que l’ensemble des modifications soit pris en compte.

N.B : Une autre solution pour éviter l’erreur de surcharge d’activité Weblogic est la mise en place d’une contrainte de gestionnaires de Thread.
Ci-dessous les étapes pour sa mise en place.

On commence par la création d’une contrainte sur le nombre maximal de threads :