La détection des ajouts et des mises à jour des tables de base de données pour la réplication des données, l'ETL, le masquage des PII et d'autres activités de déplacement et de manipulation de données incrémentielles peuvent être automatisées dans les flux de travail IRI Voracity conçus et exécutés dans IRI Workbench (WB). Cet article explique comment vérifier régulièrement les modifications dans les tables source Oracle pour décider quand déplacer les données vers une cible MongoDB.
Les modifications peuvent être chargées dans différentes bases de données ou fichiers à l'aide d'un fichier batch planifié ou d'un script shell. Cela peut être fait en utilisant un horodatage et des champs spécifiques dans la table source. La vérification des erreurs est incluse et peut également être réagi.
Cet exemple sera créé et exécuté sur une machine Windows ; cependant, il peut être facilement modifié pour fonctionner sur une plate-forme de type Linux ou Unix.
La création du fichier de commandes est facile à l'aide d'un diagramme de flux de voracité dans WB. Dans cet exemple, la table source contient des colonnes nommées CREATION_DATE et UPDATE_DATE qui sont importants dans ce travail.
L'image ci-dessous montre les étapes contenues dans le fichier batch. Pour résumer :
- le travail est exécuté dans un répertoire spécifique
- une variable d'environnement est définie à l'aide de l'horodatage de la dernière exécution de la tâche
- l'horodatage actuel est enregistré
- les modifications actuelles sont capturées
- le niveau d'erreur est vérifié et traité en cas de succès ou non
- l'horodatage actuel écrase l'horodatage de la dernière exécution
- les données modifiées sont converties en CSV
- un blocage se produit pour attendre que le dernier fichier existe
- le fichier CSV est importé dans MongoDB
- le niveau d'erreur est vérifié, le fichier en cours est tronqué
- le fichier de modifications est supprimé
Chaque bloc de tâches du workflow est expliqué ci-dessous. Pour savoir comment créer des flux de travail Voracity à partir de la palette, consultez cet article.
Changer de répertoire
Ce bloc remplace le répertoire de travail actuel par celui spécifié.
Définir DERNIÈRE HEURE
Ce bloc de ligne de commande définit une variable d'environnement appelée LASTTIME . La valeur attribuée à la variable est le contenu du fichier LastTime.txt . L'horodatage de ce fichier est l'horodatage qui a été enregistré lors de la dernière exécution de cette tâche. S'il s'agit de la première exécution, ce fichier devra être créé manuellement avec un horodatage arbitraire daté avant l'exécution de cette tâche.
Horodatage.scl
Ce bloc de transformation utilise le programme CoSort SortCL dans Voracity pour interroger la base de données source pour l'heure actuelle. Cet horodatage est enregistré dans un fichier appelé LastTimeTemp.txt . La raison pour laquelle il est stocké dans un fichier temporaire est que l'horodatage actuel et le dernier peuvent être conservés jusqu'à ce que la vérification des erreurs se produise.
Il est important que l'horodatage provienne de la base de données et non de la machine locale. Cela évite les problèmes où la base de données et l'environnement d'exécution ne sont pas synchronisés.
Modifications.scl
Ce bloc de transformation fait quelques choses. Vous trouverez ci-dessous le diagramme de mappage de transformation pour ce bloc. L'entrée est la table source et la sortie est le fichier current.txt .
Dans l'entrée Section Options, une requête est soumise à la table source pour tous les enregistrements qui ont un CREATION_DATE ou UPDATE_DATE supérieur à la variable d'environnement LASTTIME .
Alors que la sortie semble avoir deux cibles , les données sont en fait ajoutées au même fichier en utilisant deux conditions différentes. Dans la première section de sortie, il y a un Inclure instruction qui trouve tous les enregistrements qui ont un CREATION_DATE supérieur à LASTTIME . Il existe également un champ de sortie supplémentaire appelé CDC_TYPE . La chaîne "CREATE" est enregistrée dans ce nouveau champ.
Dans la deuxième section de sortie, un Inclure recherche tous les enregistrements qui ont un UPDATE_DATE supérieur à LASTTIME et où CREATION_DATE n'est pas égal à UPDATE_DATE. Cela garantit que les fichiers nouvellement créés ne sont pas inclus dans cette passe. La chaîne "UPDATE" est enregistrée dans CDC_TYPE.
Erreur CoTri
Ce bloc de décision vérifie la variable ERRORLEVEL pour vous assurer qu'il a renvoyé 0 (ou succès) après avoir exécuté le travail CoSort ci-dessus. Si ce n'est pas le cas, le travail continue jusqu'à la EXIT bloc où le travail est terminé. S'il renvoie vrai, le travail continue jusqu'au bloc suivant.
Renommer LastTimeTemp
Ce bloc de commande copie le contenu de LastTimeTemp.txt dans LastTime.txt. Cela enregistre l'horodatage actuel capturé précédemment dans le fichier à utiliser pour la prochaine exécution de la tâche.
Convertir.scl
Ce bloc de transformation prend current.txt et le convertit en changes.csv . La conversion s'effectue du type de fichier délimité par défaut vers CSV. L'utilisation du type de processus CSV dans CoSort ajoute une ligne d'en-tête au fichier de sortie en utilisant les noms de champ. C'est le bloc de tâches où je pourrais appliquer d'autres manipulations (comme le masquage des données) aux données si je le souhaite.
Fichiers d'attente
Ce bloc d'attente bloque le fichier de commandes pendant 3 secondes, puis vérifie l'existence de changes.csv fichier avant de continuer.
MongoImport
Ce bloc de commande exécute la commande mongoimport en utilisant les paramètres spécifiés dans la vue des propriétés, comme indiqué ci-dessous.
Les paramètres indiquent que la base de données MongoDB appelée fnx est à charger avec le contenu du fichier changes.csv qui est du type csv et contient un titre qui définit les champs.
Notez que Voracity prend en charge d'autres méthodes de déplacement et de manipulation des données MongoDB. Voir cet exemple d'utilisation des pilotes Progress ODBC pour le masquage des données à l'aide des fonctions intégrées "FieldShield". Voracity peut également traiter les données BSON directement via l'API via le support /PROCESS=MongoDB dans CoSort v10, maintenant aussi.
Erreur de chargement
Ce bloc de décision vérifie la variable ERRORLEVEL pour s'assurer qu'il a renvoyé 0 (ou succès) après l'importation dans MongoDB. Si ce n'est pas le cas, le travail continue avec la Supprimer-Modifications et QUITTER blocs où le travail est terminé. S'il renvoie vrai, le travail continue jusqu'au bloc suivant.
Tronquer le courant
Ce bloc de commande tronque le fichier current.txt . Il s'agit d'effacer les enregistrements qui ont été chargés dans MongoDB. Si l'importation a échoué et que le bloc ci-dessus a quitté la tâche, ces enregistrements modifiés sont ajoutés lors de la prochaine passe. Ensuite, au fur et à mesure que le travail se répétait, ils seraient chargés dans MongoDB avec le groupe suivant d'enregistrements modifiés.
Supprimer les modifications
Ce bloc de commande supprime changes.csv afin que la passe suivante démarre avec un fichier nouvellement créé pour la passe.
Fichier de lot
Le fichier de commandes et les scripts de transformation sont créés lors de l'exportation du diagramme de flux. Une copie du fichier batch est ci-dessous. Chaque bloc ajoute des lignes exécutables au fichier batch.
Planificateur de tâches
À l'aide du planificateur de tâches Windows, ce fichier batch peut être exécuté à plusieurs reprises pour capturer les modifications dans la base de données source.
Conclusion
Avec un peu de planification et l'utilisation de blocs de commande, les modifications apportées à une table de base de données peuvent être détectées automatiquement à l'aide d'un fichier de commandes, puis programmées pour s'exécuter à des intervalles sélectionnés.
Contactez [email protected] ou votre représentant IRI pour plus d'informations ou de l'aide avec votre cas d'utilisation
- Cette approche diffère des solutions de capture de données modifiées basées sur les journaux, qui présentent généralement des goulots d'étranglement au niveau des performances, sont limitées à des bases de données spécifiques et ne permettent pas la transformation simultanée des données, le masquage des données PII, le nettoyage , et création de rapports.
