Introduction
La plupart des applications d’entreprise ont généralement des bases de données relationnelles comme magasin de données persistantes. Les opérations sur ces applications entraînent la création, la mise à jour et la suppression de données dans des tables au sein de bases de données relationnelles. Les applications en aval consultent les journaux des modifications pour découvrir les modifications qui se produisent dans les systèmes sources. Les données incrémentielles sont essentielles pour traiter des modifications très spécifiques des données d’entreprise, évitant ainsi le traitement complet de données entières dans des bases de données opérationnelles.
Une nouvelle ère d’applications fournit des services par abonnement pour publier les modifications des données commerciales pertinentes. Les chargements de données initiaux doivent être effectués avant d’envoyer les modifications capturées à partir des systèmes sources. Cependant, sur certaines bases de données d’applications héritées, les outils de réplication ne peuvent pas être utilisés sans nécessiter de modifications substantielles des applications héritées. Les systèmes en aval sont alors obligés de charger tout le contenu de la base de données opérationnelle pour traiter et générer des informations significatives incrémentielles dans le cadre de travaux par lots de nuit. Cette approche augmente le temps d’exécution global des lots et augmente la pression sur l’infrastructure en raison de la charge supplémentaire traitée sur une base périodique (quotidienne/hebdomadaire/mensuelle).
Énoncé du problème
Une solution personnalisée de capture de données de modification est nécessaire pour capturer les données via un journal des modifications pointant vers des événements de modification spécifiques générés par le système source sur z/OS en utilisant IMS comme base de données et transformer les données en temps quasi réel pour les consommateurs en aval. La latence a été réduite de quelques jours à un temps quasi réel avec la solution proposée.
But
L’objectif de ce livre blanc est de fournir une solution pour une application personnalisée de capture de données de modification (CDC) permettant d’identifier les modifications incrémentielles quotidiennes sur les systèmes hérités/mainframe. L’objectif principal de cette implémentation est de fournir une solution de réplication de données en temps réel pour rendre les données IMS sur z/OS disponibles pour les applications modernisées fonctionnant sur des plates-formes Web ou mobiles. Actuellement, les programmes COBOL sur z/OS sont utilisés pour extraire les données IMS et les transférer vers des bases de données exécutées sur des serveurs distants.
L’outil CDC capture les modifications de la base de données sur les segments de la base de données z/OS IMS, et ces données peuvent être publiées et transférées sur les tables de la base de données cible. Les données CDC sont très centrées sur les applications et de bas niveau. L’implémentation a créé une base pour migrer du traitement de données par lots vers des pipelines de données en temps quasi réel (PostgreSQL) et/ou des API, ce qui est l’une des principales caractéristiques de l’architecture de données moderne.
Vue d’ensemble de la solution
Une solution a été proposée pour obtenir les données en temps quasi réel de Mainframe z/OS à l’aide de la base de données relationnelle IMS. La configuration doit être effectuée via Classic Data Architect (CDA) et la console de gestion pour le chargement initial des données des systèmes source vers les systèmes cibles à l’aide de la méthode « d’actualisation » avec l’outil CDC. Capturez ensuite les données pour les modifications sur les systèmes sources en utilisant la « mise en miroir continue » et publiez les données aux consommateurs en aval de manière continue.
Le diagramme suivant donne un aperçu de la solution d’une implémentation réelle de Change Data Capture de z/OS vers la base de données PostgreSQL. La même approche de conception peut être utilisée pour toute autre application de base de données ; cependant, les pilotes peuvent devoir être installés selon les systèmes cible et source. Vous trouverez ci-dessous les composants de la solution.
- IBM Infosphere Classic CDC pour IMS
- IBM Infosphere CDC pour FlexRep
- Architecte de données IBM Infosphere Classic
Système source
Le système opérationnel source fournit des données commerciales aux systèmes en aval. Le système d’exploitation dispose d’une base de données relationnelle appelée systèmes source dans le schéma ci-dessus. L’application sur le système source est sur des mainframes avec plusieurs technologies comme IMS, COBOL, MQ, etc. Les données sur le mainframe (z/OS) sont principalement sur la relation parent-enfant IMS.
Système cible
Les consommateurs de données mainframe seraient publiés dans la base de données PostgreSQL, qui se trouve sur l’environnement cloud AWS.
Charge initiale
Les données initiales de l’ordinateur central seraient chargées à l’aide d’abonnements de capture de données modifiées pour les segments de données IMS respectifs vers PostgreSQL principal à l’aide d’une méthode appelée « rafraîchissement ».
Charge incrémentielle
Une fois le chargement initial terminé sur PostgreSQL, les modifications incrémentielles seront capturées via CDC et publiées dans les tables respectives de la base de données PostgreSQL principale.
Conception détaillée et flux de données
Le diagramme de flux suivant donne une vue approximative du flux d’activités qui sont menées dans le cadre de l’exécution de l’application CDC personnalisée. Les données relatives aux ADDS, INSERTS, UPDATES et DELETES ont été capturées, l’application CDC personnalisée valide toutes les modifications apportées à Change Database.
Flux de données
L’image ci-dessus représente le flux de données des systèmes sources sur z/OS Follow vers le système cible PostgreSQL sur l’environnement cloud AWS.
Techniques CDC
Il existe plusieurs méthodes/techniques disponibles pour gérer le processus Change Data Capture en fonction des données du système source.
La plupart des systèmes de base de données ont un fichier journal des transactions qui enregistre tous les changements et modifications pour chaque transaction sur les systèmes sources. La base de données transactionnelle opérationnelle n’obtiendra pas l’effet lorsque CDC utilise un journal transactionnel. La méthode « d’actualisation » serait utilisée pour obtenir la charge initiale des applications Mainframe IMS vers les systèmes en aval via une transformation intégrée. Ce processus est appelé « chargement initial ». Les modifications ultérieures pour les transactions seraient chargées en tant que charge incrémentielle sur les consommateurs en aval. Ce processus est appelé « mise en miroir ».
PostgreSQLName
PostgreSQL Primaire
Le chargement initial et les modifications ultérieures/incrémentielles sont chargés dans PostgreSQL sur le cloud AWS. PostgreSQL est la base de données principale à utiliser pour envoyer les données à divers consommateurs en aval. Cette base de données sera accompagnée d’une nouvelle copie de la base de données source dès que l’application de saisie des données modifiées aura terminé son traitement sur les systèmes mainframe/milieu de gamme.
Réplica secondaire/en lecture PostgreSQL
La base de données PostgreSQL (N+1) obtient la copie de synchronisation du système source en tant que réplica en lecture. Cette base de données répliquée en lecture servira de base de données secondaire et sera utilisée pour vérifier les freins et contrepoids de la base de données en termes de nombre d’enregistrements.
Abonnements
Le mappage des tables sera effectué à l’aide d’abonnements. Les mappages de table IMS sont effectués à l’aide de positions personnalisées ou ordinales avec des mappages de table cible et de colonne respectifs. Les utilisateurs existants sont ajoutés au fur et à mesure que certaines des données sont chargées telles qu’elles sont au format EBCDIC (Extended Binary Coded Decimal Interchange Code). La conversion du type de données doit être effectuée avant de publier les données dans les tables PostgreSQL cibles.
Surveillance et gestion des erreurs
Surveillance des abonnements
L’abonnement et la surveillance des données peuvent être effectués via l’onglet de surveillance dans Management Console. Management Console est une application d’administration qui vous permet de configurer et de surveiller la réplication. La console de gestion vous permet de gérer la réplication sur divers serveurs, de spécifier les paramètres de réplication et de lancer des opérations d’actualisation et de mise en miroir à partir d’un poste de travail client. Après avoir défini les données qui seront répliquées et démarré la réplication, vous pouvez fermer Management Console sur le poste de travail client sans affecter les activités de réplication de données entre les serveurs source et cible.
La solution CDC personnalisée interrompra son traitement et ne validera aucune modification de la base de données de modifications si une erreur est rencontrée soit lors de la comparaison des copies les plus récentes et antérieures du système source (base de données opérationnelle) ou lors de l’enregistrement des modifications dans la modification respective. bases de données.
La gestion des erreurs
Les échecs d’abonnement et d’événement sont notifiés à l’aide d’un mécanisme de gestion d’événement. Des notifications personnalisées peuvent être configurées en cas d’échec d’abonnement ou de défaillance du magasin de données. Un e-mail d’automatisation serait généré lors de la configuration des notifications.
Conclusion
CDC peut être utilisé comme un outil pour réduire le traitement des données dans les applications héritées et partager les modifications de données avec les systèmes cibles en temps réel. Cela peut être utilisé pour créer un pipeline de données dans les services de streaming.
Références
InfoSphere Data Replication d’IBM est la référence pour cette implémentation.
Remerciements
Je tiens à remercier les excellents relecteurs suivants qui m’ont aidé à réviser le contenu du document et pour leurs précieuses suggestions :
Prajyot Dhaygude, partenaire de livraison associé, IBM Consulting
Sandeep Sahu, responsable technique, IBM Consulting
A propos de l’auteur
Hemadri Lekkala travaille actuellement en tant que responsable de programme chez IBM Consulting depuis 2004. Il est un professionnel de la technologie accompli et axé sur l’intégrité offrant 20 ans d’expérience réussie en informatique. Il a travaillé dans la gestion de portefeuille de programmes et de projets pendant plus de dix ans. Il a de l’expérience dans les domaines de pratique de l’intégration numérique et des technologies émergentes et dans la construction de Test CoE. Il a développé et affiné les processus de gestion de programme en travaillant avec les bureaux PMO des clients. Il a de l’expérience dans la définition des KPI, des mesures commerciales et des SLA et a travaillé avec l’informatique et les affaires pour les feuilles de route informatiques et l’évaluation des produits. Il a géré de vastes portefeuilles pour les zones géographiques américaines pour les services cloud, le développement de l’intégration d’entreprise, le ressourcement, le support de livraison et les relations clients.