Diseño de un flujo de datos para procesar excepciones

Si posee la licencia para el módulo Business Steward, puede incluir el proceso de gestión de excepciones en sus flujos de datos. Los factores básicos del proceso de gestión de una excepción son los siguientes:
  • Un flujo de datos inicial que lleva a cabo un proceso de calidad de datos, por ejemplo, desduplicación de registros, validación de direcciones o geocodificación.
  • Una etapa Exception Monitor que identifica registros que no se pudieron procesar.
  • La etapa Write Exceptions toma los registros de excepción identificados por la etapa Exception Monitor y los escribe en el repositorio de excepciones para su revisión manual.
  • Business Steward Portal, una herramienta basada en navegador, permite revisar y editar los registros de excepciones. Cuando está editado, los registros se marcan como "Aprobados", lo que permite que estén disponibles para volver a ser procesados.
  • Un trabajo de reprocesamiento de excepciones que usa la etapa Read Exceptions para leer registros aprobados desde el repositorio de excepciones en trabajo. Entonces el trabajo intenta volver a procesar los registros corregidos, normalmente mediante la misma lógica que el flujo de datos original. La etapa Exception Monitor una vez más verifica la presencia de excepciones. La etapa Write Exceptions envía excepciones de vuelta al repositorio de excepciones para una revisión adicional.
Nota: Do not place other stages between Exception Monitor and Write Exceptions stages in a dataflow; doing so could impact the configuration of exceptions in the Business Steward Portal.
A continuación, se muestra un caso hipotético de ejemplo que ayuda a ilustrar una implementación básica de gestión de excepciones:

En este ejemplo, hay dos flujos de datos: el flujo de datos inicial que evalúa los datos de código postal de los registros de entrada y el trabajo de reprocesamiento de excepciones, el que toma las excepciones editadas y verifica que los registros ahora contengan datos de código postal válidos.

En ambos flujos de datos, hay una etapa Exception Monitor. Esta etapa contiene las condiciones que desea utilizar para determinar si un registro se debe enrutar para revisión manual. Estas condiciones constan de una o más expresiones, tales como PostalCode is empty, lo que significa que cualquier registro que no contenga un código postal se considerará como excepción y se enrutará a la etapa Write Exceptions y se escribirá en el repositorio de excepciones. Para obtener más información, consulteException Monitor.

Todos los registros que Exception Monitor identifica como excepciones son enviados a un repositorio de excepciones utilizando la etapa Write Exceptions. Los administradores de datos revisan las excepciones del repositorio utilizando Business Steward Portal, una herramienta de exploración para ver y modificar registros de excepción. Si utilizamos nuestro ejemplo, el administrador de datos podría usar el editor de excepciones del portal Business Steward Portal para agregar manualmente códigos postales a los registros de excepción y marcarlos como "Aprobados".

Cuando se marca un registro como "Aprobado" en Business Steward Portal, ese registro está disponible para que se lo vuelva a leer en un flujo de datos de Spectrum™ Technology Platform. Este proceso se realiza mediante el uso de una etapa Read Exceptions. Si todavía algún registro genera una excepción, se lo escribe nuevamente en el repositorio de excepciones para que un administrador de datos la revise.

Para determinar cuál es la mejor opción para su situación, tenga en cuenta estas preguntas:
  • ¿Cómo quiere identificar los registros de excepción? La etapa Exception Monitor puede evaluar cualquier valor de un campo o cualquier combinación de campos para determinar si un registro es una excepción. Es recomendable analizar los resultados que está obteniendo actualmente con su flujo de datos para determinar cómo quiere identificar las excepciones. También se recomienda identificar registros en el rango medio de la secuencia de calidad de datos y no entre aquellos que claramente están validados o han fallado.
  • ¿Quiere que los registros de excepción editados y aprobados vuelvan a ser procesados utilizando la misma lógica que se utilizó en el flujo de datos original? Si es así, es recomendable utilizar un subflujo para crear una lógica de negocio reutilizable. Por ejemplo, el subflujo puede utilizarse en un flujo de datos inicial que lleva a cabo la validación de direcciones y en un trabajo de reprocesamiento de excepciones que reprocesa los registros corregidos para verificar las correcciones. Luego, puede utilizar diferentes etapas de origen y recepción entre los dos. El flujo de datos inicial puede contener una etapa Read from DB que toma datos desde la base de datos de sus clientes para ser procesados. El trabajo de reprocesamiento de excepciones contiene una etapa Read Exceptions que toma los registros de excepción editados y aprobados desde el repositorio de excepciones.
  • ¿Quiere volver a procesar correctamente y aprobar las excepciones siguiendo una programación predeterminada? Si es así, puede programar su trabajo de reprocesamiento utilizando Programación en la Consola de administración.