Connexion à un datasource Oracle pour récupérer des données

Support
1

Bonjour,

j’ai besoin de me connecter à une BDD Oracle pour récupérer des données.
pouvez vous me dire quelle est la syntaxe pour déclaré ce datasource dans les paramètres système ?
dans la doc, j’ai trouvé des exemples pour Mysql et Postgres mais pas pour oracle.

2

Rien de spécifique à Simplicité, ce sont le mêmes paramètres adaptés au driver JDBC d’oracle:

{
    "driver": "oracle.jdbc.driver.OracleDriver",
    "username": "<username>",
    "password": "<password>",
    "url": "jdbc:oracle:thin:@<host>:<port>:<database>"
}
  • Il faut que le port (en général 1521) soit accessible depuis le serveur
  • Il faut installer votre driver JDBC d’oracle dans le répertoire lib de tomcat.

Le driver doit correspondre exactement à celui de votre version Oracle installée sinon il peut y avoir des fonctionnements étranges, des erreurs de fetch…

3

Je confirme le exactement.

Par défaut le template d’instance utilisé sur le SIM embarque un driver Oracle à jour (version 19.3) ce qui n’est clairement pas adapté si votre Oracle est plus (très) ancien.

4

c’est ce que j’ai fait mais comme j’ai des erreurs, je préférais vérifier la syntaxe de déclaration de la datasource.

5

Oui

  • il faut commencer par mettre le bon driver Oracle dans tomcat/lib (retirer celui par défaut ojdbc8.jar) : si vous avez accès la base Oracle, le JAR est dans la distrib jdbc/lib.
  • vérifier le nom TNS et le port de votre base

En local, l’URL suivante fonctionne avec une base XE :

jdbc:oracle:thin:@localhost:1521:XE

Sinon il faut nous indiquer l’erreur ou voir avec votre DBA.

6

NB: Le remplacement du driver Oracle par défaut (19.3) par celui adapté à la version de votre serveur Oracle peut s’automatiser dans les hooks du SIM (ou plus globalement dans le hook git post-receive du repo Tomcat), Benjamin (@crb-admin) saura mettre ça en place.

7

Bonsoir,

Aaahhh, les drivers Oracle, toujours un plaisir…

à la lecture de vos échanges, je me pose des questions sur notre cible. En effet, l’application de Rosanne est censée être une application “gestion des données de référence”, qui se connecte à différentes sources de données, donc potentiellement différentes bases Oracle de différentes générations. Vous voyez où je veux en venir…

Même si l’on n’interroge qu’une seule base Oracle, on introduit une dépendance de bas niveau entre la version d’Oracle et l’application Simplicité. Pas top…

Bref je me demande s’il n’est pas préférable de stocker les données dans la base “locale” de l’application Simplicité, quitte à les verser dans le référentiel agents par ETL. Rien de choquant dans ce modèle puisque le référentiel agent consolide via ETL les informations issues de différentes sources.

8

Si on tape dans N serveurs Oracle de version différentes il faut trouver le driver qui marche avec toutes ces versions. S’il existe. Ce pb n’est pas spécifique à Simplicité.

NB: On a opté pour distribuer par défaut le plus récent (19.3) en espérant qu’il soit le plus largement compatible malheureusement @Francois et l’équipe a remonté des pbs avec ce driver et des versions express 11 et 18. Bref visiblement pas de progrès chez Oracle sur la compatibilité des drivers…

9

Bonjour,

Si vous avez une même version d’Oracle partout sur votre SI, ce n’est pas trop impactant d’avoir un seul driver JDBC en dépendance, surtout si le besoin est ponctuel d’accéder à Oracle à distance.

Si vous avez plusieurs versions d’Oracle ou que les accès sont nombreux, il faudra effectivement passer par une couche d’intégration logique et non physique :

  • type ETL en batch si la fraicheur de la donnée n’est pas critique
  • ou via objet web-service synchrone pour traiter l’information au fil de l’eau

Une réplication reviendrait à migrer vos référentiels Oracle pour tout mettre au final dans Simplicité.

Sinon de notre côté, il va falloir qu’on crée un classloader spécifique dans Simplicité pour ce genre de pool de connexion externe = isoler les classes de chaque driver ou lib tierces. Avec les nouveaux JDK qui n’embarquent plus certains javax, nous avons déjà des pb d’intégration de lib tierces, et ce sujet de R&D est au backlog (ex: dépendances de jCloud incompatibles avec celles de DocuSign).

10

Pour les drivers JDBC c’est chose faite en V5, on pourra avoir plusieurs drivers externes différents dans des classloader isolés :

  • donc sans modifier les drivers dans le tomcat/lib
  • permettant d’avoir différentes connexions avec des drivers dans différentes versions
  • en ajoutant juste une propriété jdbc pour spécifier le chemin du JAR à charger dans son connecteur dynamique, exemple :
{
    "driver": "org.postgresql.Driver",
    "username": "<user>",
    "password": "<pwd>",
    "url": "postgresql://<server>:<port>/<database>",
    "jdbc": "/usr/share/java/postgresql-42.2.9.jar"
}

En V4, il faudra encore mutualiser donc n’avoir qu’un seul driver par fournisseur de base de données dans tomcat/lib.