La réplication incrémentielle des données, le masquage, l'intégration (ETL) et d'autres opérations d'actualisation des données sont courantes dans les environnements de base de données fréquemment mis à jour. Ces travaux nécessitent la détection d'ajouts et de mises à jour de tables. Ces opérations dynamiques sont faciles à automatiser dans les workflows IRI Voracity conçus et exécutés dans IRI Workbench (WB).
Cet article contient un exemple de flux de travail que les utilisateurs de l'édition de SGBD Voracity, FieldShield, CoSort ou NextForm peuvent implémenter pour vérifier régulièrement les modifications dans une table source (Oracle dans ce cas) afin de décider quand déplacer les données vers une nouvelle cible (MySQL). Il montre également comment les données peuvent être masquées de manière conditionnelle dans le cadre de ce processus. Notez qu'IRI travaille également sur une approche basée sur les journaux pour incrémenter les données en temps réel sans avoir besoin de valeurs de colonne delta.
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 également incluse et peut également être appliquée.
Cet exemple a été créé et exécuté sur une machine Windows. Il peut être facilement modifié pour fonctionner sur une plate-forme 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 CREATED_DATE et UPDATED_DATE qui sont importants dans ce travail.
L'image ci-dessous montre les étapes contenues dans le fichier batch. Pour résumer :
- la tâche est exécutée 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 réussite ou d'échec
- l'horodatage actuel écrase l'horodatage de la dernière exécution
- une règle pour expurger les e-mails se terminant par "edu" est utilisée dans la cible
- une règle pour masquer partiellement le champ SSN est utilisée dans la cible
- les données modifiées sont chargées dans MySQL
- le niveau d'erreur est vérifié, le fichier d'horodatage temporaire est renommé
Chaque bloc de tâches du workflow est expliqué ci-dessous. Les deux blocs mauves sont des blocs de mappage de transformation et représentent des scripts de tâche CoSort SortCL. Les diagrammes de mappage et les scripts de travail représentés par chacun des blocs sont présentés ci-dessous pour plus de clarté. 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.
Ce fichier contient une ligne :"2008-09-10 09:39:23.5"
Horodatage.scl
Cette tâche utilise le programme SortCL 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.
Le diagramme de mappage et le script sérialisé pour cette tâche sont les suivants :
Modifications.scl
Ce travail fait l'extrait principal, la transformation, le chargement. L'entrée est la table source dans Oracle et la sortie est une table au format similaire dans MySQL :
Dans la section d'entrée, une requête est soumise à la table source pour tous les enregistrements qui ont un CREATED_DATE ou UPDATED_DATE supérieur à la variable d'environnement LASTTIME . La requête est "SELECT * FROM SCOTT.CLIENT WHERE CREATED> TO_TIMESTAMP(\'$LASTTIME\', \'YYYY-MM-DD HH24:MI:SS.FF1\') OR (UPDATED> TO_TIMESTAMP(\'$LASTTIME\ ', \'AAAA-MM-JJ HH24:MI:SS.FF1\'))".
De plus, une condition est ajoutée pour vérifier le EMAIL colonne pour les données se terminant par "edu". Cela sera utilisé dans une fonction de masquage conditionnel des données en sortie. Dans la sortie, un If-Then-Else déclaration est ajoutée au EMAIL colonne. Il utilise la condition précédemment créée pour tester les données. Si les données se terminent par "edu", l'adresse e-mail est supprimée. Sinon, l'adresse e-mail est copiée depuis l'entrée.
Une deuxième fonction de rédaction est utilisée dans le SSN colonne. Il supprime les trois premiers caractères, laisse le tiret, supprime les deux caractères suivants, laisse le tiret et laisse les quatre derniers caractères. Par exemple ***-**-6789.
Vous trouverez ci-dessous le script de travail sérialisé SortCL décrit ci-dessus afin que vous puissiez examiner la requête et la syntaxe conditionnelle impliquées dans les deltas incrémentiels :
Erreur CoTri
Le bloc de décision vérifie la variable ERRORLEVEL pour vous assurer qu'il a renvoyé 0 (en cas de succès) après avoir exécuté le travail SortCL ci-dessus. Si ce n'est pas le cas, la tâche se poursuit jusqu'à la FIN 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 vers LastTime.txt . Cela enregistre l'horodatage actuel capturé précédemment dans le fichier à utiliser pour la prochaine exécution de la tâche.
Fichier de lot
Le fichier de commandes et les scripts de transformation sont créés lorsque le diagramme de flux (illustré ci-dessus) est exporté. 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 batch, puis programmées pour s'exécuter à des intervalles sélectionnés afin que vous puissiez déplacer, mapper, masquer et autrement manipuler les données modifiées sur un fichier. base incrémentale.
Contactez [email protected] ou votre représentant IRI pour plus d'informations ou de l'aide avec votre cas d'utilisation.
