Conception pour la résilience

Conception à des fins de redémarrage

Certains processus d'intégration peuvent être très complexes et comporter des dépendances avec d'autres processus. Ils peuvent accéder à un certain nombre d'étapes avant que les données ne soient chargées dans le système cible final. Pour contribuer à l'arrêt et à l'ajout d'une colonne supplémentaire à vos tables intermédiaires, effectuez le suivi et l'identificateur de la charge en cours (load_id ou load_date, ou tout ce qui identifie de manière unique ce chargement). Cette option permet une meilleure traçabilité et facilitera la conception de vos procédures de nettoyage.

Que signifie Oracle Data Integrator ?

Utilisez des variables pour effectuer le suivi de l'identificateur du processus en cours de chargement et, si possible, ajouter ces valeurs aux étapes de données intermédiaires (colonnes supplémentaires dans vos tables intermédiaires).
Utilisez ces variables pour définir un nom de session différent (SESS_NAME) pour chaque exécution de scénario. Les opérateurs permettent immédiatement d'identifier les processus qui ne reconnaissent pas exactement l'emplacement de recherche. Reportez-vous à Utiliser des noms uniques et dynamiques pour les sessions de scénario.
En reprenant l'exemple précédent où le même processus est utilisé pour charger des centaines de fichiers, il est plus pratique de disposer d'un travail nommé après le fichier en cours de traitement qu'avec le même nom de travail générique pour tous les fichiers.

Conception pour limiter les impacts de coupure

L'exécution d'extractions volumineuses à des heures prédéfinies a un impact important sur l'ensemble de l'infrastructure.

Par exemple :

Le système source est affecté car il doit traiter la demande.
Le réseau est affecté, car la bande passante fonctionne normalement avec le service de la demande.
L'exécution des travaux d'intégration globaux est plus longue en raison du volume de données qui doit être traité.
Il est essentiel sur votre tâche d'intégration, en raison d'une taille réduite ou d'une interruption de service sur votre réseau.

Les jobs d'intégration ne doivent pas obligatoirement être en batch ou en temps réel. Souvent, ils peuvent être tous deux. Si le dernier chargement doit être une opération par lots (car les données sont consolidées ou agrégées pour l'instance), l'extraction et certains processus de pré-intégration peuvent être exécutés de façon plus en temps réel. Cela réduit la charge sur l'infrastructure globale et limite l'impact lors de la tentative d'accès au système source au moment de l'intégration. Si les données ont été extraites et préparées en mode de transmission en continu, vous n'avez pas besoin d'accéder au système source au moment où il est temps pour l'intégration finale.

Oracle Data Integrator fournit un certain nombre d'outils qui peuvent être utilisés lors de la construction de packages pour détecter la disponibilité de nouvelles données. Reportez-vous à Utiliser les outils orientés événement pour obtenir la liste correspondante.

Pour une intégration avec la réplication en temps réel réel réel, Oracle Data Integrator peut créer une infrastructure qui permettra la consommation des modifications, en exploitant les API mentionnées ci-dessus.

Choisir entre insérer et fusionner des données

Des compromis entre une approche INSERT et MERGE lors du chargement des données. En dehors de la stratégie d'intégration, il se peut que vous souhaitiez examiner ce qui se passe lorsqu'un chargement échoue partiellement.

Selon le mode de chargement des données dans le système cible, la différenciation des éléments chargés correctement par rapport aux échecs ou l'identification des éléments d'un chargement partiel peut être assez complexe. Même si, du point de vue de la conception, vous ajoutez toutes les données dans le système cible à l'aide d'une perspective de récupération, il peut être utile de fusionner les données entrantes avec celles déjà présentes dans le système cible.

Si vous choisissez cette approche, vous voudrez double vérifier l'impact de cette stratégie sur les performances de vos chargements. Mais n'oubliez pas qu'un chargement INSERT entièrement optimisé échoue pas plus rapidement que l'exécution de MERGE moins efficace.

D'une perspective Oracle Data Integrator, le passage d'une stratégie INSERT à une stratégie MERGE est une opération très simple : vous devez uniquement modifier votre stratégie d'intégration et sélectionner le module de connaissances approprié. Cela signifie que la modification des modules de connaissances pour un grand nombre de mappings peut être une tâche difficile. Vous pouvez automatiser une telle tâche à l'aide du kit SDK Oracle Data Integrator.

Conception pour limiter les coupures planifiées

Les interruptions de service planifiées sont généralement requises pour l'application de patches et les mises à niveau.

Dans un environnement cloud où l'application de patches et les mises à niveau sont plus simples et plus transparentes du point de vue de l'utilisateur final, les dernières choses à forcer dans une coupure car nous appliquons un patch au code des processus d'intégration. Cela signifie que l'application de patches doit faire partie de la stratégie de développement allant dans l'avenir afin de garantir que les coupures sont maintenues au minimum.

L'unité d'exécution pour Oracle Data Integrator est un scénario. Lorsqu'un scénario est généré, il est associé à un numéro de version (à partir de 001). Les scénarios peuvent être générés à nouveau (pour écraser la version en cours) ou une nouvelle version peut être générée (002, 003, etc.).

Lors de l'appel d'un scénario, Oracle recommande de toujours indiquer le numéro de version -1. Cet avantage aura deux :

Oracle Data Integrator utilisera toujours la dernière version de votre scénario. Vous n'avez pas besoin de modifier l'appel de ces scénarios lorsque vous générez de nouvelles versions.
Peu de temps après la création d'une nouvelle version du scénario, il s'agit de la version exécutée par Oracle Data Integrator. La section Configurer le délai d'expiration du cache de modèle de base d'agent décrit le contrôle des délais potentiels. Vous n'avez pas besoin d'arrêter ni de redémarrer Oracle Data Integrator, ni de tout outil d'orchestration externe que vous utilisez, pour qu'Oracle Data Integrator utilise la dernière version de vos scénarios d'intégration.

Remarque : cette approche n'est possible que si vous n'avez pas de boucles infinies dans Oracle Data Integrator. Les boucles infinies ne sont jamais recommandées dans Oracle Data Integrator (elles sont en fait admissibles comme anti-modèle) :

Ils ont créé les journaux Oracle Data Integrator : les purges des journaux n'affecteront jamais un travail en cours d'exécution. Une boucle sans fin est toujours en cours d'exécution, car les journaux correspondants ne peuvent donc pas être purgés.
Ils empêchent l'application de patches en direct à des scénarios : pour ODI de récupérer la nouvelle version d'un scénario, il doit avoir l'opportunité de démarrer ce scénario. Une boucle infinie ne se termine jamais… et, par exemple, ne peut jamais être redémarrée.
Au lieu d'une boucle infinie, vous pouvez terminer votre scénario en appelant ce même scénario de façon asynchrone : la dernière étape du scénario avant la fin consiste à démarrer une nouvelle copie de lui-même dans une nouvelle session.