Discussion :

[H.Lionne]

Bonjour,

J'ai un update et un insert dans une table mais je veux faire passer l'update en premier (je veux mettre à jour un champ puis le réinsérer avec un autre code), hors informatica execute l'insert d'abord.
Dans le load plan, on ne peut changer l'ordre que pour les SQs.

I'm wating from a solution

[uraxyd]

fait deux mappings differents et ordonnance tes sessions

[KarLKoX]

Met deux Update Strategy, le premier DD_UPDATE et l'autre DD_INSERT avec éventuellement une expression qui change la valeur entre les deux

[galgal]

Bonjour,
avez-vous trouvé une solution ?

j'ai exactement la même problématique :
j'ai un routeur qui a en sortie :
un Update strategy en UPDATE
et
un Update strategy en INSERT.

Le Pb c'est qu'informatica semble suivre un ordre aléatoire en sortie,
alors que je souhaiterais faire l'UPDATE puis l'INSERT.

[Glutinus]

Sur un mapping donné, tu peux consulter et modifier l'ordre dans lequel les targets (même s'il s'agit de la même) sont insérés.

mappings -> target load plan.

[StéphanieB.]

Merci beaucoup de ton info Glutinus, je pense qu'elle pourrait bien m'aider pour certains mappings : demander la mise à jour d'abord, puis l'insertion en cas de non correspondance.
Cependant, dans mapping => target load plan, les flèches haut et bas sont en grisées ne me laissant pas la possibilité justement de demander l'exécution du dd_update et de la target qui va avec AVANT l'ordre existant c'est à dire dd_insert et target associée.
Comment faire pour que ces 2 boutons de flèches passent en noir et donc en actif ?

[Glutinus]

En fait ma réponse n'est pas complètement bonne...
Le target load plan permet de choisir dans quel ordre on charge depuis les source qualifiers... autrement dit, c'est une bonne méthode si on a plein de "petits mappings" à l'intérieur du mapping...

La solution, pour par exemple les cibles multiples pour une source unique, si jamais la cible est sur une base relationnelle (et pas du fichier), consisterait à vérifier les "constraint-based loading", pour ce point je n'ai pas trop le temps de regarder, il faudrait consulter l'aide Informatica.

[Glutinus]

Après relecture de l'aide, effectivement le gros conseil que donne informatica est de "spliter le mapping en deux si on veut absolument avoir un ordre particulier à faire"...

La logique pourrait consister donc à faire deux mappings, l'un par exemple de faire l'update, puis le second pour faire les insertions. Cela peut changer la logique et réduire le temps de traitement.

Pour ma part, j'utilise un système de tables temporaires (travaillant avec des cibles Oracle), mais bon cela peut varier selon le besoin de chacun.

On peut par exemple, avec une seule source, insérer des lignes dans une table "INSER_matable", insérer des lignes dans une table "UPD_matable". Un second mapping réinsère toutes les lignes dans la table finale (en la truncatant) depuis "INSER_matable", puis faire ensuite un update depuis la table "UPD_matable". Mais bon, cela peut être utile et plutôt efficace dans des cas de datamart par exemple, mais dans un datawarehouse où il ne faut surtout pas supprimer une seule ligne, ça peut être chaud...

Stéphanie (et autres) => il y a une option "update else insert" que tu peux cocher dans tes targets. Il faut par contre que ta source soit en "update". Je ne l'utilise jamais, mais tu pourrais essayer... Fais gaffe, parce que ta source sera alors en update, donc toutes tes cibles doivent être traitées en update... si ton mapping est complexe (plusieurs sources, plusieurs cibles), ce n'est peut-être pas la bonne solution.

[qqcvd]

je propose de mettre un port integer avec numerotation 1 ou 2 suivant que c est un update ou un insert.
puis de trier avant d envoyer ca dans la target.

[funckfot]

Bonjour,
Le Pb c'est qu'informatica semble suivre un ordre aléatoire en sortie,
alors que je souhaiterais faire l'UPDATE puis l'INSERT.

Ce n'est pas il semblerait mais c'est simplement sûr. Power center suit un ordre aléatoire sur les ordres SQL. On est obligé de "splitter" le mapping comme le dit Glutinus. on peut alors créer au sein du mapping des "pipelines" qui sont des flux de données distinct.

Pour info : le target load plan permet d'ordonnancer les "pipelines".

Le seul moyen d'obtenir l'UPDATE puis l'INSERT et de le découper ton mapping
en son sein tu peux :
1er pipeline : sélectionner les enregistrements et tu effectue l'UPDATE.
2eme pipeline : tu re-sélectionnes tes enregistrements misent en Update et tu finis par effectuer tes INSERT.

Mais la solution de qqcvd semble plus simple. A vérifier qu'il effectue toujours dans un ordre séquentiel (ce qui est en théorie le cas).

[alexisongagna]

Bonjour,

Effectivement, j'ai déjà rencontré ce problème également. La solution est de découper ton mapping en deux mapping différents. Un sera chargé de faire l'insertion et l'autre l'update. A chaque mapping une session et dans un workflow tu ordonnance les 2 sessions avec une condition de passage de l'une à l'autre si le code retour de l'exécution de la première est 0.

Avec ça ton problème est résolu

[funckfot]

Bonjour,

Effectivement, j'ai déjà rencontré ce problème également. La solution est de découper ton mapping en deux mapping différents. Un sera chargé de faire l'insertion et l'autre l'update. A chaque mapping une session et dans un workflow tu ordonnance les 2 sessions avec une condition de passage de l'une à l'autre si le code retour de l'exécution de la première est 0.

Avec ça ton problème est résolu

Mais pk faire 2 sessions? 2 pipelines dans le même mapping suffit amplement!

[alexisongagna]

Bonjour,
Pk 2 sessions ? Parce qu'une norme de développement me le contraint. Norme propre au client.

[funckfot]

Bonjour,
Pk 2 sessions ? Parce qu'une norme de développement me le contraint. Norme propre au client.

ok, je me demandais si vous connaissiez le terme de pipeline.
mais pk tu ne proposes pas directement l'autre solution, qui me semble bien plus pratique.
de toute façon, je pense qu'elle a sa réponse...