Conception d'un flux de donnée afin de gérer les exceptions

Si vous détenez une licence du module Business Steward, vous pouvez inclure un processus de gestion des exceptions dans vos flux de données. Les principales composantes d'une procédure de gestion d'exception sont :
  • Un flux de donnée effectuant une procédure de qualité de donnée, tel que la déduplication d'enregistrement, la validation d'adresse ou le géocodage.
  • Un stage Exception Monitor qui identifie les enregistrements qui n'ont pas pu être traités.
  • Un stage Write Exceptions prend les enregistrements d'exceptions identifiés par le stage Exception Monitor et les écrit dans le référentiel d'exception afin qu'ils soient manuellement vérifiés.
  • Le Business Steward Portal, outil basé sur un navigateur, vous permet de vérifier et de modifier les enregistrements d'exceptions. Une fois modifiés, les enregistrements sont marqués comme « approuvés », ce qui les rend prêts au retraitement.
  • Un job de retraitement d'exceptions qui utilise le stage Read Exceptions pour lire les enregistrements approuvés du référentiel d'exception vers le job. Le job tente ensuite de retraiter les enregistrements corrigés, généralement à l'aide de la même logique que celle du flux de données initial. Le stage Exception Monitor recherche encore une fois les exceptions. Le stage Write Exceptions renvoie ensuite les exceptions au référentiel d'exception afin de procéder à une vérification supplémentaire.
Remarque : Ne placez pas d’autres stages entre les stages Exception Monitor et Write Exceptions dans un flux de données ; cela pourrait avoir un impact sur la configuration des exceptions dans Business Steward Portal.

Voici un scénario type permettant de mieux comprendre la mise en place de base de gestion d'exception :

Dans cet exemple, il existe deux flux de données : le flux de données initial, qui évalue les données de code postal des enregistrements d'entrée, et le job de retraitement des exceptions, qui prend les exceptions modifiées et vérifie que les enregistrements contiennent maintenant les données de code postal valides.

Dans les deux flux de données figure un stage Exception Monitor. Ce stage contient les conditions que vous souhaitez utiliser pour déterminer si un enregistrement doit être routé pour une révision manuelle. Ces conditions sont constituées d'une ou de plusieurs expressions, comme PostalCode is empty,, qui signifie que tout enregistrement ne contenant pas de code postal doit être considéré comme une exception, routé vers le stage Write Exceptions et écrit dans le référentiel d'exception. Pour plus d'informations, reportez-vous à la section Exception Monitor.

Tout enregistrement que l'Exception Monitor pourrait identifier comme étant une exception serait routé vers un dépositaire d'exception grâce à l'étape Écrire les exceptions. Les data stewards examinent les exceptions dans le dépositaire en utilisant le Business Steward Portal, un outil basé sur navigateur permettant de voir et de modifier des enregistrements d'exception. Dans notre exemple, le data steward peut utiliser Exception Editor dans le Business Steward Portal pour ajouter manuellement des codes postaux aux enregistrements d'exception et les marquer comme « approuvés ».

Une fois qu'un enregistrement est marqué comme « approuvé » dans le Business Steward Portal, l'enregistrement peut être relu dans un flux de données Spectrum™ Technology Platform. Le stage Read Exceptions réalise cette action. Si des enregistrements continuent à constituer des exceptions, ils seront à nouveau écrit dans le dépositaire d'exception afin d'être examinés par un data steward.

Pour définir la meilleure approche possible dans votre cas, considérez ces questions :
  • Comment voulez-vous identifier les enregistrements d'exception ? le stage Exception Monitor peut évaluer la valeur de n'importe quel champ ou n'importe quelle combinaison de champs afin de déterminer si un enregistrement est une exception. Vous pouvez analyser les résultats que vous obtenez actuellement avec votre flux de données afin de savoir comment vous souhaitez identifier les exceptions. Vous devriez peut être identifier les enregistrements dans la fourchette moyenne du continuum de qualité de données et non pas ceux qui ont été clairement validés ou qui ont clairement échoué.
  • Voulez-vous traiter à nouveau les enregistrements d'exception édités et approuvés grâce à la même logique utilisée dans le flux de données initial. Dans ce cas, vous devriez peut être utiliser un sous-flux afin de créer une logique métier réutilisable. Par exemple, le sous-flux peut être utilisé dans un flux de données initial effectuant une validation d'adresses et dans un job de retraitement des exceptions qui traite de nouveau les enregistrements corrigés afin de vérifier les corrections. Vous pouvez ensuite utiliser des sources et des étapes différentes entre les deux. Le flux de données initial peut contenir une étape Lire depuis la base de données qui récupère des données depuis votre base de données de clients afin qu'elles soient traitées. Le job de retraitement des exceptions contiendrait un stage Read Exceptions qui récupère les enregistrements d'exception modifiés et approuvés du le référentiel d'exception.
  • Voulez-vous traiter à nouveau les exceptions corrigées et approuvées selon un planning pré-définit ? Si c'est le cas, vous pouvez programmer votre job de retraitement via Planification dans Management Console.