Discussion :

[fja34]

Bonjour, j'ai deux problématique similaires.

On m 'a donné les accès au schema d'informatica ou je peux normalement récupérer toutes les infos sur ce qui s'est exécuté en base de données.

Ma problématique est la suivante:
1) j'ai un mapping que je vais exécuter quotidiennement, correspondant à une mises à jour incrémentale de données. Par conséquent je dois récupérer la dernière date d'exécution sans erreur du job et partir utiliser cette date dans la session appliquant le mapping.
2) un peu plus complexe, j'ai un mapping que j'exécute plusieurs fois avec un paramètre issu d'une variable dans plusieurs sessions successivement. C'est aussi une mise à jour incrémentale, et par conséquent j'ai le meme problème qu'avant si ce n'est que c'est bien la date de la dernière session et pas du dernier mapping que je dois utiliser...

je suppose qu'a minima, je dois être capable de récupérer cette info avec une datasource sur le schema d'informatica en allant chercher l'info dans une table ou une vue. L'ideal serait même d'avoir des fonctions toutes faites dans informatica.

Pouvez-vous m'indiquer comment je peux faire cela dans informatica ?

il s'agit de la version: 9.1

Merci !

[Prjprj]

Bonjour,

Se baser sur la date d'exécution d'un job dans le référentiel Informatica pour décider d'un chargement en DELTA est une mauvaise idée.
Tu ne peux pas faire de traitement de reprise (sur une erreur fonctionnelle par exemple) en te basant sur une date technique puisque tu n'as pas le contrôle du chargement de ce champ et toute bidouille du référentiel Informatica risque de faire sauter le support éditeur.

Il est bien plus fiable et souple d'utiliser une date dans une table dédiée (2 colonnes suffisent, un code pour identifier la date que tu manipules et la date).
Cela peut-être utilisé dans les opérations SQL avant et après session ou via un script shell qui modifie ton fichier PRM puis lance ton workflow.

[fja34]

Bonjour,

Se baser sur la date d'exécution d'un job dans le référentiel Informatica pour décider d'un chargement en DELTA est une mauvaise idée.
Tu ne peux pas faire de traitement de reprise (sur une erreur fonctionnelle par exemple) en te basant sur une date technique puisque tu n'as pas le contrôle du chargement de ce champ et toute bidouille du référentiel Informatica risque de faire sauter le support éditeur.

Il est bien plus fiable et souple d'utiliser une date dans une table dédiée (2 colonnes suffisent, un code pour identifier la date que tu manipules et la date).
Cela peut-être utilisé dans les opérations SQL avant et après session ou via un script shell qui modifie ton fichier PRM puis lance ton workflow.

Bonjour,

je ne veux pas écrire dans cette base et par ailleurs je n'ai pas forcément les droit (en tout, je devrais avoir que du read en toute logique).

L'avantage de passer par une table alimentée est de m'éviter de faire des mapping et worklets juste pour insérer une "date ok" alors même qu'il y a des outils de monitoring. Par ailleurs, je comprends un peu ton idée de pas avoir la maitrise du contenu, mais je ne vois pas bien le danger d'utiliser une valeur qui indique que mon job s'est bien déroulé et qui reste alimentée par le moteur informatica

Merci pour ton aide.

[Prjprj]

L'idée, c'est qu'un mapping peut contenir des erreurs sans pour autant planter.

Admettons que ton workflow fonctionne mais que 2 mois après la mise en production de ton flux, un utilisateur final se rende compte que tu remplis mal une colonne, ton mapping a fonctionné, donc ta table cible s'est remplie, mais certains champs sont faux, il est donc nécessaire de corriger l'erreur.

Avec une table dans laquelle tu stockes une date que tu maitrise, il suffit de changer la date dans cette table et relancer ton workflow, il mettra à jour toutes les lignes qui le nécessitent et le problème sera réglé.
En te basant sur une table dont tu ne maitrises pas le contenu, te vas devoir passer par plusieurs étapes, d'abord livrer un workflow sans filtre pour corriger, puis livrer le bon workflow, ou passer un script SQL pour corriger, en admettant que tu puisses le faire.

Bref, c'est plus pratique d'utiliser une table que tu peux modifier

[fja34]

Ok, merci, je comprends mieux en effet.

Sur la façon de faire: si j'ai en PLSQL une procédure "simple" genre: log (startts, endts, jobname, status)
et une fonction simple genre : getLastOk (jobname) qui me retourne la dernière bonne exécution de ma table, quelle est la façon la plus simple / générique / réutilisable de de l'appliquer dans informatica:

dois-je passer par des mappings, worklets, variables et toute une usine à gaz, où y a-t-il des composants qui permettent de façon plus élégante de récupérer ma valeur dans une variable et de déclencher un log (aussi simplement que l'envoi d'un mail par exemple) ?

les systèmes pre-traitement post-traitement sont plutot pour des actions de type désactiver et reconstruire des index ou des contraintes non ?

as tu un "modèle" de bonne pratique à me montrer pour faire au plus simple et au plus propre ?

merci

[Waldar]

Le plus efficace d'un point de vue Oracle, c'est d'avoir les variables traduites au moment des appels SQL (surtout pas de jointure avec une table de paramétrage par exemple).

Pour ce faire, vous pouvez passer par des variables PowerCenter, mais je ne les trouve pas très bien gérées : c'est faisable, mais ce n'est pas trivial.
Le plus simple c'est de construire en début de traitement un fichier de paramètres et de l'utiliser dans les différents mapping.

[Prjprj]

Effectivement, du point de vue Informatica, c'est l'utilisation du fichier de paramètre qui est à privilégier, mais ce n'est pas très simple.
Côté Mapping/session, il suffit de définir un paramètre et s'en servir.

Côté serveur Informatica, il est nécessaire de modifier le fichier PRM sur le serveur avant de lancer le workflow, ce qui nécessite de créer un script shell ou un mapping qui permet de faire cela, vu que cela doit être fait en fonction d'une date qui change à chaque fois.

J'ai déjà vu sur un projet des scripts bash qui remplissaient certains champs des fichier PRM en se basant sur des suite de caractères identifiables (du genre ###DATE_MAJ###) avant de lancer les workflows associés.

A voir si c'est possible, créer le fichier PRM pour la prochaine exécution, à la fin de l'exécution de ton workflow (via script ou mapping) en fonction de la date de fin d'exécution de la session qui t'intéresse.