Discussion :

[Jinroh77]

Bonjour à tous,
J'ai un package qui charge un cube de manière particulière (mode push) or cela provoque, de temps en temps des erreurs. il suffit alors de relancer le traitement pour que cela fonctionne.

Je cherche donc à pouvoir relancer automatiquement ce package, qui est démarré depuis un package père, automatiquement en cas d'erreur.

J'ai pensé à placer mes tâches (3) dans une boucle For Loop et utiliser un jeu de variable mais je n'arrive pas à bien les manier pour obtenir ce que je souhaite

Avez-vous des idées ? déjà réalisé cela ?

Merci.

[Ptit_Dje]

Hello,

Quelle est la raison pour laquelle le package plante parfois ?
De mon avis, il serait plus interessant de se focaliser a resoudre ce soucis la au lieu de se servir d'un workaround qui risquerait lui meme d'etre sujet au meme probleme.

Sinon, (jamais teste...) au niveau du package pere, en cas d'echec du package appele, rediriger le flux en erreur vers le une autre tache executant le package en question (le relancer).
A partir de la, si le package reussit, rediriger le flux vers la tache suivante, sinon, rediriger le flux vers le package package precedent (execution du package).
Cela risque de creer une boucle infinie.

Schematiquement (Ou P et P' declenchent le meme package):
Execution du package P ---> (ERREUR) Execution du package P'
Execution du package P' ---> (ERREUR) Execution du package P
Execution du package P ---> (OK) Tache suivante
Execution du package P' ---> (OK) Tache suivante

Je ne sais pas si la solution est realisable.
En esperant vous avoir aide,

Bonne journee,
Dje

[Jinroh77]

Le problème est que l'erreur est visiblement sans raison.
Cela ne vient pas des données mais du moteur en lui même, en particulier de l'utilisation du composant de destination de partition SSAS qui est ancien, très peu utilisé et pas très pratique.
Les erreurs sont des :

Internal error: An unexpected exception occurred

SSIS Error Code DTS_E_PROCESSINPUTFAILED. The ProcessInput method on component "PP_DST Underlying" (233) failed with error code 0x80004005 while processing input "AnalysisServicesServerInput" (234). The identified component returned an error from the ProcessInput method. The error is specific to the component, but the error is fatal and will cause the Data Flow task to stop running. There may be error messages posted before this with more information about the failure.

L'idée de dupliquer la tâche risque en effet d'entrainer une boucle infinie en cas d'erreur venant d'autre chose
C'est pour cela que je souhaitais relancer cette partie 3 fois maximum par exemple.
De plus, je en suis pas sûr que l'ordonnanceur de tâche accepte de créer de telle boucle.

[Ptit_Dje]

Hello,

Hmmm, concernant l'erreur, je presuppose que tu as deja chercher sur google pour en trouver la cause. Personellement je ne l'ai pas fait et je n'ai jamais eu le cas de figure en live.

Pour en revenir a l'histoire de boucle, en effet, la solution proposee au dessus me semble pas tres clean voir impossible a implementer (je n'ai pas l'environnement adequat pour tester sous la main).

Concernant l'idee d'utiliser un container for loop:
Est ce que tes 3 taches sont a executer en chaine ?
Comment gerer le cas ou l'une d'entre elles echoue ? Rejouer que celle la ? Tout le package ?

L'idee pourrait etre d'utiliser une variable appelee retry, dont la valeur de depart serait 0.
Definir au niveau de ton container le nombre maximal de retry (pouvant etre une variable aussi, par soucis de flexibilite).
En cas de succes du contenu du container, executer un script assignant a la variable retry, une valeur permettant de sortir de la boucle (Inutile de relancer le package, et surtout pas voullu).
En cas d'echec, incrementer la valeur de retry de 1 via un script -> le container est rejouer.

Ensuite, etant donne la redirection de l'erreur vers un script, si celui-ci reussit, le container sera flaggue OK, ce qui, apres X essais echoues n'est pas le cas.
Donc je proposerais d'utiliser une variable flag permettant de controler le reel succes ou echec du container.
Au niveau du script incrementant la variable, ajouter un check pour verifier la condition de sortie de la boucle. Si cette condition est remplie, on sera donc dans un etat de X essais echoues et donc assigner a la variable flag une valeur specifique a cet etat.

En sortie de container, verifier la variable flag et, en fonction de son etat, poursuivre le flow ou rediriger vers un message d'erreur d'execution a l'operateur.

Encore une fois, ceci n'a pas ete teste, j'elabore juste des hypotheses de resolution en esperant que ca puisse t'aider a avancer



Derniere question:
Y a pas une propriete: OnFailureRetry a laquelle on puisse assigner une valeur X etant le nombre de retry ?


Voila voila,
Bonne chance,
Dje

[Jinroh77]

Merci pour toutes ces idées

Voici une méthode qui fonctionne que je propose à tout le monde.


Concernant la recherche de l'erreur, il n'y a pas grand chose si ce n'est que le comportement est étatique, d'un composant vieillissant et très peu utilisé ; Il n'y a qu'à voir le format de l'icône de la tâche

Pour ce qui est de la méthode, je n'ai pas trouvé de propriété OnFailureRetry. Par contre, je me suis inspiré de ton idée et de la manière du foor loop d'utiliser les variables.
L'expression d'évaluation doit être évaluée à false pour couper le recommencement de la boucle.
J'ai donc une variable Retry initialisée à 0 et une propriété EvalExpression comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

@[User::Retry] == 0

Ensuite, dans ce conteneur, j'ai un sequence container qui contient mes 3 tâches (qui doivent toutes les 3 être relancées en cas d'erreur).

Le problème trouvé était qu'en, cas d'erreur du sequence container, la boucle passait en rouge et ne pouvait se relancer.
L'idée est donc de jouer avec la propriétée MaximumErrorCount du Foor Loop. C'est cette valeur qui va définir le nombre de retraitement du contenu. Je la passe donc à 3 (via une variable).

Le dataflow est donc le suivant :
Dans un Foor Loop

Dans une séquence, traite les 3 tâches

En cas d'erreur un script qui fixe ma variable Retry à 0

En cas de réussite script qui fixe ma variable Retry à 1

Fermeture du Foor Loop.

Une petite capture pour expliquer

[Jinroh77]

Humm petite nouveauté dont je suis en train de me rendre compte...
Le MaximumnErrorCount ne compte pas le nombre de fois où la tâche est en erreur, mais le nombre d'erreurs retournées...
Donc quand une erreur survient et qu'il retourne 15 lignes d'erreurs, ma variable à 5 n'est d'aucune utilité
De manière très temporaire, je passe celle-ci à 50, mais je suis à la recherche d'une véritable solution

[Ptit_Dje]

Hello,

Si tu incrémentes ta variable de retry en tant que redirection d'une (ou plusieures) tâches en erreur, via un script par exemple, ca devrait jouer je pense.

D'un point de vue logique:
Initialisation de la variable à 0

Boucle : While Variable >= 0 and variable <= MaxRetry

Execute tasks

On success: Variable = -1 (-> on force la sortie de la boucle)
On error : Variable = Variable + 1 (-> nouveau retry ou sortie en erreur)

Fin de boucle

Par la suite, il devrait toujours être possible de tester la valeur de Variable pour savoir si:
Elle est égale à -1, les taches se sont bien déroulées
Elle est > que maxRetry, les taches ont echoué après le nombre déterminé de retry.

J'espère que cette solution pourra t'aider.

Bonne journée,
Dje

[Jinroh77]

Merci pour la boucle.
je suis en train de tester depuis quelques jours dès que j'ai un moment mais pour le moment je ne parviens pas à boucler comme il faut.
J'ai l'impression que tout se met en erreur sans autoriser le relancement de la tâche puisque considérée en erreur.

EDIT :
Finalement j'ai réussi à rendre le processus fonctionnel.
Il faut pour cela passer le MaxErrorCount du conteneur de séquence à 1 et celui du FoorLoop et du package avec la variable MaxRetry.
Dans ce cas tout est bon

Merci.