Errores y ejecución condicional
SE APLICA A: 
Azure Data Factory Azure Synapse Analytics
Sugerencia
Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. Obtenga información sobre cómo iniciar una nueva evaluación gratuita.
Rutas de acceso condicional
La orquestación de Azure Data Factory y la canalización de Synapse permite la lógica condicional y permite al usuario tomar diferentes rutas de acceso en función de los resultados de una actividad anterior. El uso de rutas de acceso diferentes permite a los usuarios crear canalizaciones sólidas e incorpora el control de errores en la lógica de ETL/ELT. En total, se permiten cuatro rutas de acceso condicionales,
| Nombre | Explicación |
|---|---|
| Si es correcto | (Pase predeterminado) Ejecute esta ruta de acceso si la actividad actual se ha realizado correctamente |
| Tras error | Ejecute esta ruta de acceso si se produjo un error en la actividad actual. |
| Al finalizar | Ejecute esta ruta de acceso cuando se haya completado la actividad actual, independientemente de si se realizó correctamente o no. |
| Al omitir | Ejecute esta ruta de acceso si la propia actividad no se ha ejecutado |
Puede agregar varias ramas después de una actividad, con una excepción: la ruta de acceso de Tras finalización no puede coexistir con las rutas de acceso de Tras éxito o Tras error. Para cada ejecución de canalización, se activa como máximo una ruta de acceso, en función del resultado de ejecución de la actividad.
Tratamiento de errores
Mecanismo común de control de errores
Bloque Try/Catch
En este enfoque, el cliente define la lógica de negocios y solo define la ruta de acceso En caso de error para detectar cualquier error de la actividad anterior. Este enfoque representa que la canalización se realiza correctamente, si la ruta de acceso En caso de error se realiza correctamente.
Bloque Do If Else
En este enfoque, el cliente define la lógica de negocios y define las rutas En caso de errorySi es correcto. Este enfoque representa que la canalización se realiza con errores, incluso si la ruta de acceso En caso de error se realiza correctamente.
Bloque Do If Skip Else
En este enfoque, el cliente define la lógica de negocios y define las rutas En caso de error y Si es correcto, con la actividad ficticia Al omitir adjunta. Este enfoque representa que la canalización se realiza correctamente, si la ruta de acceso En caso de error se realiza correctamente.
Tabla de resumen
| Enfoque | Qué define | Cuando la actividad se realiza correctamente, se muestra la canalización general | Cuando la actividad se realiza con errores, se muestra la canalización general |
|---|---|---|---|
| Try-Catch | Solo la ruta En caso de error | Correcto | Correcto |
| Do-If-Else | Ruta En caso de error y rutas Si es correcto | Correcto | Error |
| Do-If-Skip-Else | Ruta En caso de error y ruta Si es correcto (con una omisión ficticia al final) | Correcto | Correcto |
Cómo se determina el error de canalización
Diferentes mecanismos de control de errores dan lugar a un estado diferente para la canalización: mientras que algunas canalizaciones producirán un error, otras se realizarán correctamente. Determinamos el éxito y los errores de la canalización de la manera siguiente:
- Se evalúa el resultado de todas las actividades del nivel de hoja. Si se omitió una actividad del nivel de hoja, se evalúa su actividad primaria en su lugar.
- El resultado de la canalización es correcto si y solo si todos los nodos se evaluaron correctamente.
Suponiendo que la actividad En caso de error y la actividad En caso de error ficticio se realizaron correctamente,
en el enfoque Try-Catch,
- Cuando la actividad anterior se realiza correctamente: se omite el nodo En caso de error y su nodo primario se realiza correctamente, la canalización general se realiza correctamente.
- Cuando se produce un error en la actividad anterior: se realiza el nodo En caso de error, la canalización general se realiza correctamente.
En el enfoque Do-If-Else,
- Cuando la actividad anterior se realiza correctamente: el nodo Si es correcto se realiza correctamente y se omite el nodo En caso de error (y su nodo primario se realiza correctamente), la canalización general se realiza correctamente.
- Cuando se produce un error en la actividad anterior: se omite el nodo Si es correcto y se produce un error en su nodo primario, se produce un error en la canalización general.
En el enfoque Do-If-Skip-Else,
- Cuando la actividad anterior se realiza correctamente: se omite el nodo Al omitir ficticio y su nodo primario Si es correcto se realiza correctamente, la otra actividad de nodo, En caso de error, se omite y su nodo primario se realiza correctamente, la canalización general se realiza correctamente
- Cuando se produce un error en la actividad anterior: el nodo En caso de error se realiza correctamente y Al omitir ficticio se realiza correctamente, la canalización general se realiza correctamente.
Ejecución condicional
A medida que desarrollamos canalizaciones más complicadas y resistentes, a veces es necesario introducir ejecuciones condicionales en nuestra lógica: ejecutar una determinada actividad solo si se cumplen ciertas condiciones. Los casos de uso son muchos, por ejemplo:
- ejecutar una actividad de seguimiento, como enviar una notificación por correo electrónico, si los trabajos de copia anteriores se realizaron correctamente
- ejecutar un trabajo de control de errores, si se produjo un error en alguna de las actividades anteriores
- continuar con el paso siguiente si la propia actividad o su actividad de control de errores correspondiente se realiza correctamente
- etc.
Mas abajo, explicaremos algunas lógicas comunes y cómo implementarlas en ADF.
Actividad única
Estos son algunos patrones comunes que siguen una sola actividad. Podemos usar estos patrones como bloques de creación para construir flujos de trabajo complicados.
Control de errores
El patrón es la lógica de condición más común en ADF. Se define una actividad de control de errores para la ruta de acceso "Tras un error" y se invocará si se produce un error en la actividad principal. Debe incorporarse como procedimiento recomendado para todos los pasos críticos que necesiten alternativas o registros de reserva.
Pasos del mejor esfuerzo
Algunos pasos, como el registro informativo, son menos críticos y sus errores no deben bloquear toda la canalización. En estos casos, debemos adoptar las estrategias del mejor esfuerzo: agregar los pasos siguientes a la ruta de acceso "Tras la finalización", para desbloquear el flujo de trabajo.
Y
En primer lugar y los escenarios más comunes son condiciones del tipo "y": continuar la canalización si y solo si las actividades anteriores se realizan correctamente. Por ejemplo, es posible que tenga varias actividades de copia que necesiten realizarse correctamente primero antes de pasar a la siguiente fase del procesamiento de datos. En ADF, el comportamiento se puede lograr fácilmente: declarar varias dependencias para el paso siguiente. Gráficamente, eso significa que varias líneas apuntan a la siguiente actividad. Puede elegir la ruta de acceso "Tras el éxito" para asegurarse de que la dependencia se ha realizado correctamente o "Tras la finalización" para permitir la ejecución del mejor esfuerzo.
Aquí, la actividad de espera de seguimiento solo se ejecutará cuando ambas actividades web se hayan realizado correctamente.
Y aquí, la actividad de espera de seguimiento se ejecuta cuando se completen ActivitySucceeded y ActivityFailed. Tenga en cuenta que con la ruta de acceso "Tras el éxito", ActivitySucceededed tiene que ejecutarse con éxito, mientras que ActivityFailed en la ruta de acceso "Tras la finalización" se ejecuta con el mejor esfuerzo, es decir, puede producir un error.
Or
Los segundos escenarios comunes son condiciones del tipo "o": ejecutar una actividad si alguna de las dependencias se realiza correctamente o produce un error. Aquí es necesario usar las rutas de acceso "Tras la finalización", actividad de la condición IF y lenguaje de expresión.
Antes de profundizar en el código, es necesario comprender una cosa más. Una vez ejecutada y completada una actividad, puede hacer referencia a su estado con @activity('ActivityName').Status. Es "Correcto" o "Con errores" Usaremos esta propiedad para crear lógica o condiciones.
Paso de registro de control de errores compartido
En algunos casos, quizá desee invocar un paso de registro o control de errores compartidos, si alguna de las actividades anteriores produjo un error. Puede compilar la canalización de la siguiente manera:
- ejecutar varias actividades en paralelo
- agregar una condición if para contener los pasos de control de errores, en la rama True
- conectar actividades a la actividad de condición mediante la ruta de acceso "Tras la finalización"
- expresión lógica para las lecturas de actividad de condición
@or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded').Status, 'Failed'))
- Nota: necesitas concatenar o si tienes más de dos actividades de dependencia, por ejemplo,
@or(or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded1').Status, 'Failed')),equals(activity('ActivitySucceeded1').Status, 'Failed'))
Dar luz verde si alguna actividad se realizó correctamente
Cuando todas las actividades sean del mejor esfuerzo, es posible que desee continuar con el paso siguiente si alguna de las actividades anteriores se realizó con éxito. Puede compilar la canalización de la siguiente manera:
- ejecutar varias actividades en paralelo
- agregar una condición if para que contenga los pasos siguientes, en la rama True
- conectar actividades a la actividad de condición mediante la ruta de acceso "Tras la finalización"
- expresión lógica para las lecturas de actividad de condición
@or(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
- Nota: El gráfico tiene un aspecto similar al escenario anterior. La única diferencia es el lenguaje de expresión usado
Escenarios complejos
Todas las actividades deben realizarse correctamente para continuar
El patrón es una combinación doble: condicional "y" + control de errores. La canalización continúa con los pasos siguientes si todas las actividades de procedimiento se realizan correctamente. De lo contrario, ejecuta un paso de registro de errores compartido. Puede compilar la canalización de la siguiente manera:
- ejecutar varias actividades en paralelo
- agregar una condición if. Agregue los pasos siguientes en la rama True y agregue código de control de errores en la rama False.
- conectar actividades a la actividad de condición mediante la ruta de acceso "Tras la finalización"
- expresión lógica para las lecturas de actividad de condición
@and(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
Patrones comunes
Try-Catch-Proceed
El patrón es equivalente al bloque "try" y "catch" en programación. Es posible que se produzca un error en una actividad en una canalización. Cuando se produce un error, el cliente debe ejecutar un trabajo de control de errores para tratarlo. Sin embargo, el error de actividad única no debe bloquear las actividades siguientes en la canalización. Por ejemplo, intento ejecutar un trabajo de copia y mover archivos al almacenamiento. Sin embargo, es posible que se produzca un error a mitad de camino. Y en ese caso, quiero eliminar los archivos parcialmente copiados y no confiables de la cuenta de almacenamiento (mi paso de control de errores). Pero estoy de acuerdo en continuar con otras actividades después.
Para configurar el patrón:
- Agregar primera actividad
- Agregar control de errores a la ruta de acceso UponFailure
- Agregar segunda actividad, pero no conectarse a la primera actividad
- Conecte las rutas de acceso UponFailure y UponSkip desde la actividad de control de errores a la segunda actividad
Nota:
Cada ruta de acceso (UponSuccess, UponFailure y UponSkip) puede apuntar a cualquier actividad. Varias rutas de acceso pueden apuntar a la misma actividad. Por ejemplo, UponSuccess y UponSkip pueden apuntar a una actividad, mientras que UponFailure apunta a otra.
El trabajo de control de errores solo se ejecuta cuando se produce un error en la primera actividad. La siguiente actividad se ejecutará independientemente de si la primera actividad se realiza correctamente o no.
Control de errores genérico
Normalmente, hay varias actividades que se ejecutan secuencialmente en la canalización. Si se produce un error, necesito ejecutar un trabajo de control de errores para borrar el estado o registrar el error. Por ejemplo, tengo actividades de copia secuenciales en la canalización. Si se produce un error en alguno de estos errores, es necesario ejecutar un trabajo de script para registrar el error de canalización.
Para configurar el patrón:
- Compilar una canalización de procesamiento de datos secuencial
- Agregar el paso de control de errores genérico al final de la canalización
- Conecta las rutas de UponFailure y UponSkip desde la última actividad hasta la actividad de manejo de errores
El último paso, el control de errores genéricos, solo se ejecutará si alguna de las actividades anteriores falla. No se ejecutará si todos se ejecutan correctamente.
Puedes agregar varias actividades para el control de errores.
