#DB2Kafka

L’export des données de l’as400 vers le bus applicatif se fait par polling via le job java db2kafka. Sur le model de la commande ‘oracle2kafka sync-query’, le job permet de produire dans un topic kafka le resultat d’une query faite sur une base de données. Oracle2kafka ne put pas être utilisé à cause d’un problème de driver C non fonctionnel.

Le job ne produit que les resultats qui ne sont pas déjà dans le topic.

#Déploiement hicksoncentral

Sur le namespace hicksoncentral-master le job est déployé une fois par table exportée. Il est déployé sous forme de job kubernetes, car le job java se termine. Au vu du besoin de plusieurs déploiement pour des tables simplement, et des changements possibles, le déploiement se fait plus simplement via helm. helm rep

il suffit de creer un fichier .yaml sur le modele des tables déjà crées et lancer

helm install --namespace hicksoncentral-master -f CHPROSE.yaml --set image.tag=a9f8725 ./hickson-db22kafka

Dans le cas de besoins plus particulier (query plus compliqué…) il faut creer le job a la main.

Au jour de l’ecriture de la documentation les tables suivantes sont exportées

| Notion | TABLE | clé | topic | | — | — | — | — |  | complexe | CHCOMPL | VBCTER , VBCCOM | as400.chf.CHCOMPL |  | film | CHFILM | VFNFIL | as400.chf.CHFILM | | prose | CHPROSE | V8CTER, V8CCOM, V8DFIL, V8HDF1, V8CSAL, V8NFI1 | as400.chf.CHPROSE |  | salle | CHSALLE | VGCTER, VGCCOM, VGCSAL | as400.chf.CHSALLE |  | territoire | CHTERIT | VICTER | as400.chf.VICTER | 

#Déploiement cible

Dans le cas d’un déploiement en production, ou simplement pour que l’export soit réactif aux changement dans l’as400, il faudrait déployer au sein d’un cronJob kubernetes. Il est a noté que les jobs créeront autant de connexions à la base de données que de jobs (qui sont indépendants) … l’orchestration devra peut etre tenir compte de cette contrainte. De plus, certaines tables sont plus ou moins “stables” … suivant le niveau de modification il faudra peut être tunner des niveaux de polling différents. example : table CHCOMPL ou CHTERIT ne doivent pas changer tous les jours, il est inutils de les requeter toutes les 10s.

Pour les tables importantes mais qui ne changent pas beaucoup, il faudra peut etre tuner la query pour que toutes les lignes de la table ne soient pas récupérées … cela nécessiterait un premier run avec toutes les lignes, avant de ne gérer qu’une “fenetre” de lignes suceptibles d’avoir changées.

#Amélioration de fonctionnalités

À chaque polling, tout le topic cible est relu … pour des tables/topics très gros, cela crée un nombre de lecture de kafka assez important … Pour cette raison il pourrait être interéssant de faire évoluer le job java pour gérer en interne le cron : ainsi le topic n’aurait pas besoin d’être relu entre les polls.

Pour mieux gérer le nombre de connexions, le job pourrait évoluer pour gérer plusieurs query ..; et ainsi gerer en interne les connexions en nombres réduits.