[BO Data Integrator] Rôle d'un Workflow en mode "Recover as a unit"

[Ryo_san]

Bonjour à tous,

J'ai remarqué l'option "Recover as a unit" dans les propriétés d'un Workflow sous BODI. Je sais que ça a un rapport avec l'intégrité des données lors d'une reprise, mais concrètement qqn pourrait m'expliquer comment ça marche ??

Il y a également l'option "Execute only once", je pense qu'il s'agit d'une option permettant de caractériser le Workflow en mode d'exécution unique, c'est à dire qu'en cas de reprise, il ne sera pas relancé, c'est bien ça ??

Merci de me confirmer tout cela !!!

[Bougeard]

L'interdépendance de certaines étapes d'un WorkFlow nécessitte qu'elles s'exécutent ensemble. dans une telle situation, le WorkFlow peut être déclaré en tant qu'unité de reprise (option Recover as a unit) de telle sorte que l'échec d'une seule de ses étapes suffise à le réexécuter totalement en mode de reprise automatique.

La déclaration explicite d'ecécution unique au niveau d'un WorkFlow ou d'un Data Flow (option Execute only once) autorise cependant que le WorkFlow terminé correctement ne soit pas réexécuté, quand bien même il appartient à un WorkFlow considéré comme unité de reprise.

[Prjprj]

Envoyé par Bougeard

L'interdépendance de certaines étapes d'un WorkFlow nécessitte qu'elles s'exécutent ensemble. dans une telle situation, le WorkFlow peut être déclaré en tant qu'unité de reprise (option Recover as a unit) de telle sorte que l'échec d'une seule de ses étapes suffise à le réexécuter totalement en mode de reprise automatique.

La déclaration explicite d'ecécution unique au niveau d'un WorkFlow ou d'un Data Flow (option Execute only once) autorise cependant que le WorkFlow terminé correctement ne soit pas réexécuté, quand bien même il appartient à un WorkFlow considéré comme unité de reprise.

En gros je n'ai pas grand chose à dire de plus, si ce n'est qu'un exemple est toujours plus parlant qu'une explication.

Pour Recover as a unit :
Supposons que tu gères un référentiel clients dans ton alimentation, tu gères des clients, leurs adresses, des entreprises et des tables pour dire quel client bosse pour quelle entreprise.

L'ensemble de ces alimentations est judicieusement rangé dans un workflow vu que ces traitements vont ensembles.

En activant l'option Recover as a unit au niveau du workflow qui regroupe le tout, l'ensemble du workflow sera ré-exécuté en cas de plantage sur un des sous-chargements, cela permet de maintenir la cohérence fonctionnelle de ton référentiel clients.

Imaginons donc qu'un utilisateur de ton beau logiciel de CRM dont tu gère le référentiel client s'est planté en saisissant le pays Canada et qu'il a écrit Canoda dans le champ Pays. Tes traitements étant bien faits, tu fais une transcodification sur la table des pays pour récupérer l'identifiant du pays, et, ton pays étant inconnu, tu te retrouves avec une valeur nulle dans un champ supposé not null
S'en suit un méga plantage qui fait que tout ce qui vient derrière n'est pas exécuté.
Deux possibilités :

• Tu n'as pas activé l'option :
  Lors de ton rechargement, BODI ré-exécute uniquement les parties du job qui n'ont pas été exécutés, entre temps les données ont évidement changé, plus d'intégrité des données, donc en clair, tu n'as plus qu'à tout vider et tout recharger, en supposant bien sur que tu puisses le faire, sinon, plus de vie de famille pendant 3 jours.
• Tu as activé l'option :
  Lors du rechargement, BODI ré-exécute tous les traitements de ton référentiel clients, ton intégrité est maintenue, tu pourras revoir ta famille ce soir.

Pour Execute only once :
Supposons maintenant que dans un autre traitement, tu as une interface entre 2 bases de données (pour maintenir à jour un logiciel de CRM suite à mise à jour d'une autre application par exemple), tu as ensuite d'autres traitements n'ayant rien à voir avec cette interface.
Ton interface devra avoir l'option Execute only once activée afin d'éviter de charger des doublons.
Imaginons que tu as un plantage sur un des traitements postérieur à ton interface, deux possibilités :

• Tu as activé l'option :
  Lors du rechargement BODI saute l'étape, ne recharge pas ton logiciel de CRM avec des données déjà intégrées dedans, pas de doublon, l'admin de ton logiciel de CRM est content
• Tu n'as pas activé l'option :
  Lors du rechargement, BODI rejoue l'étape d'interface et donc recharge les données dans ton logiciel de CRM, tu crées donc des doublons, l'admin de ton logiciel de CRM te maudis

Evidement tout dépend de tes traitements, donc cela doit être défini dès le début pour éviter de faire la correction après le gros bug (qui finis toujours par arriver).