Orquestar procesos y movimiento de datos

¿Qué te enseña este módulo?

Este módulo es sobre el orquestador maestro de Fabric: los Pipelines de Data Factory. Los objetivos oficiales:

1. Describir capabilities de pipelines en Microsoft Fabric.
2. Usar la actividad Copy Data en un pipeline.
3. Crear pipelines basados en templates predefinidos.
4. Ejecutar y monitorear pipelines.

Peso en el examen DP-700

Los pipelines aparecen transversalmente en los tres dominios, pero especialmente en Dominio 1 y 2:

🎯 Qué es CRÍTICO dominar

• Las actividades más usadas: Copy Data, Dataflow, Notebook, Lookup, Get Metadata, ForEach, If Condition
• Cuándo elegir Pipeline vs Dataflow vs Notebook (pregunta clásica de escenario)
• Triggers event-based con Activator (feature moderna, muy examinable)
• Parameters y dynamic content (para pipelines reutilizables)
• Retry logic y failure handling (para producción real)
• Copy Job (alternativa moderna a Copy activity)

2.1 · Definición

Un pipeline en Microsoft Fabric es un contenedor que encapsula una secuencia de actividades que realizan tareas de movimiento y procesamiento de datos.

Piénsalo como el director de orquesta 🎼: no toca ningún instrumento (no transforma datos por sí mismo), pero coordina todos los instrumentos (actividades) para que suenen en el momento correcto y en el orden correcto.

2.2 · Qué puede hacer un pipeline

Un pipeline puede:

• ✅ Mover datos entre sources y destinos.
• ✅ Ejecutar código de transformación (dataflows, notebooks, SQL, etc.).
• ✅ Orquestar múltiples actividades con dependencias (success/failure/completion).
• ✅ Aplicar lógica de control: condicionales, loops, ramificaciones.
• ✅ Ejecutarse por schedule o eventos.
• ✅ Parametrizarse para ser reutilizables.
• ✅ Notificar vía Teams, Outlook, webhooks.

2.3 · Interfaz: el pipeline canvas

En Fabric, los pipelines se diseñan en un canvas gráfico:

• Zona central: donde arrastras y conectas actividades.
• Barra de actividades (arriba): lista de actividades disponibles.
• Panel de propiedades (abajo al seleccionar actividad): configuración de la actividad activa.
• Ribbon: Home, Insert, Run, View, etc.

No requiere código. Todo se configura visualmente. Ideal para data engineers que quieren orquestación robusta sin escribir framework de scheduling desde cero.

Antes de meternos en el detalle, conviene entender los 3 conceptos base:

3.1 · Actividades (activities)

Las actividades son las tareas ejecutables dentro de un pipeline. Cada actividad:

• Hace una cosa específica (copiar datos, ejecutar un notebook, esperar, etc.).
• Puede tener un outcome: success, failure, completion, skipped.
• Se conectan entre sí con flechas que definen el flujo.

Las actividades siguientes se ejecutan según el outcome de la anterior. Ejemplos:

• Actividad B se ejecuta cuando A termina con success.
• Actividad C se ejecuta cuando A falla (para manejar errores).
• Actividad D se ejecuta siempre que A termine (success o failure).

3.2 · Parámetros y variables

Parámetros: valores que se pasan al pipeline al ejecutarlo. Hacen los pipelines reutilizables.

Pipeline "IngestData" con parámetro folder_name:
  - Llamada 1: folder_name = "sales"
  - Llamada 2: folder_name = "products"

Variables: valores internos que se calculan durante la ejecución. Se usan para pasar datos entre actividades.

Diferencia clave: parámetros son input externo, variables son estado interno.

3.3 · Pipeline runs

Cada vez que se ejecuta un pipeline → se inicia un pipeline run.

• Cada run tiene un ID único para tracking.
• Se puede iniciar de 3 formas:
  1. On-demand (botón Run manual).
  2. Scheduled (por horario).
  3. Event-based (por eventos como llegada de fichero).

Los runs pasados quedan en el historial para debugging y auditoría.

Fabric organiza las actividades en 3 grandes grupos:

4.1 · Data movement activities (mover datos)

Actividades cuyo propósito principal es transferir datos de A a B:

• Copy Data: la clásica para copiar entre cualquier source y destino soportado.
• Copy Job: método simplificado y moderno para movimiento rápido de datos.

4.2 · Data transformation activities (transformar datos)

Actividades que procesan y transforman datos:

• Copy Data (también cuenta aquí)
• Dataflow Gen2 activity
• Fabric Notebook activity
• Spark Job Definition activity
• Stored Procedure activity
• SQL Script activity
• HDInsight activity
• Delete Data activity

4.3 · Control flow activities (controlar el flujo)

Actividades que añaden lógica: loops, condicionales, esperas, invocación de otros pipelines. Estas son muchas, las vemos todas en la sección 7.

4.4 · 🎯 Novedades Fabric vs ADF

Fabric añade actividades nuevas que no existen en Azure Data Factory:

• Outlook (notificaciones por email)
• Teams (mensajes en Teams)
• Semantic model refresh (refrescar modelos Power BI)
• Dataflow Gen2 (obviamente, no existe en ADF)

5.1 · Copy Data activity (la clásica)

Copy Data es probablemente la actividad más usada de todo el examen.

Uso típico: mover datos de una fuente externa (BBDD, ficheros, APIs, otra cloud) a un destino en Fabric (Lakehouse, Warehouse, SQL DB).

Wizard visual: cuando la añades a un pipeline, un tool gráfico te guía por:

1. Elegir source (conectar, autenticar, seleccionar dataset).
2. Elegir destino.
3. Mapear columnas (opcional).
4. Configurar settings (batch size, parallel copies, etc.).

Cuándo usar Copy Data:

• ✅ Movimiento sin transformación (o transformación mínima).
• ✅ Ingesta raw para procesar después.
• ✅ Cuando otras herramientas de transformación no son necesarias.

Cuándo NO usar Copy Data:

• ❌ Si necesitas transformaciones complejas → usa Dataflow Gen2 o Notebook.
• ❌ Si necesitas merge/join de múltiples sources → usa Dataflow Gen2.

5.2 · Copy Job (la nueva alternativa)

Copy Job es un item independiente (no una actividad de pipeline, aunque puede usarse dentro de uno) diseñado para movimiento de datos simplificado.

Características:

• ⚡ Método simplificado para movimiento rápido.
• 🔁 Soporta CDC (Change Data Capture) en preview.
• 🔀 Soporta SCD Type 1 y SCD Type 2 como write methods.
• 📅 Ejecución por schedule o on-demand.
• 🎯 Optimizado para casos comunes de ingesta.

5.3 · Copy Data vs Copy Job

5.4 · Conectores de source

Copy Data soporta cientos de conectores. Categorías:

• Bases de datos (SQL Server, Oracle, PostgreSQL, MySQL, Cosmos DB, Snowflake, etc.)
• Ficheros (CSV, Parquet, JSON, XML, Excel)
• Storage (ADLS Gen2, Blob, S3, GCS)
• SaaS (Salesforce, Dynamics, SharePoint, ServiceNow)
• Web/API (REST, OData, HTTP)
• Fabric (Lakehouse, Warehouse, SQL DB)
• On-premises (con on-premises data gateway)

Actividades que transforman los datos, cada una con su motor de compute:

6.1 · Tabla completa

6.2 · Notebook activity (💻 la más flexible)

La actividad Notebook ejecuta un notebook de Fabric (Python, PySpark, Spark SQL, Scala, SparkR).

Configuración típica:

• Seleccionar el notebook a ejecutar.
• Pasar parámetros al notebook (variables base).
• Configurar timeout y retries.
• Especificar el Spark pool (opcional).

Cómo se pasan parámetros al notebook:

En el notebook, defines una celda con tag parameters:

# Celda con tag "parameters"
folder_name = "default"
process_date = "2026-01-01"

En el pipeline, en la actividad Notebook → tab Settings → Base parameters → añades:

• folder_name = "sales"
• process_date = @utcnow()

Los parámetros del pipeline sobrescriben los valores de la celda.

6.3 · Spark Job Definition activity

Ejecuta un Spark Job Definition (item de Fabric que empaqueta un script Python/JAR/Scala para ejecución batch).

Diferencia vs Notebook activity:

• Notebook: interactivo (celdas), ideal para desarrollo.
• SJD: no interactivo (script puro), ideal para producción.

Ambos usan Apache Spark clusters de Fabric.

6.4 · Stored Procedure activity

Ejecuta un stored procedure en:

• Azure SQL Database
• Azure SQL Managed Instance
• SQL Server
• Azure Synapse Analytics
• Fabric Warehouse (a través del connector T-SQL)

Puedes pasar parámetros al SP.

6.5 · SQL Script activity

Ejecuta T-SQL directo contra:

• Fabric Warehouse
• SQL analytics endpoint del Lakehouse
• Azure SQL, Synapse
• On-premises SQL Server

Útil para transformaciones SQL puras sin necesidad de SP.

6.6 · Delete Data activity

Borra ficheros o datos de:

• Lakehouse (folders o archivos)
• ADLS Gen2
• Blob Storage
• Otros storage

Uso típico: limpiar staging antes de una nueva carga.

6.7 · Dataflow Gen2 activity

Ejecuta un Dataflow Gen2 desde el pipeline. Puedes pasar el dataflow como una step más de un flujo mayor.

Estas son muchas. Vamos a verlas todas porque cualquiera puede aparecer en preguntas de escenario. Las organizo por familias.

7.1 · Lógica condicional

If Condition activity 🎯 (muy examinable)

• Evalúa una expresión → si true ejecuta un set de actividades, si false ejecuta otro.
• Como un if/else de programación.

If Condition: @equals(pipeline().parameters.env, 'PROD')
  ├─ True: ejecutar validaciones estrictas
  └─ False: ejecutar solo warnings

Switch activity 🎯

• Evalúa una expresión → múltiples caminos según el valor.
• Como un switch/case de programación.

Switch: @pipeline().parameters.load_type
  ├─ 'FULL': ejecutar carga completa
  ├─ 'INCREMENTAL': ejecutar delta
  └─ default: enviar alerta

7.2 · Loops

ForEach activity 🎯 (MUY examinable)

• Itera sobre una colección y ejecuta actividades para cada item.
• Como un for each de programación.
• Puede ejecutar iteraciones en paralelo (más rápido) o secuencial (más controlado).

ForEach: sobre lista de tablas
  └─ Para cada tabla: ejecutar Copy Data + validación

Until activity

• Ejecuta un bloque de actividades hasta que una condición sea true.
• Como un do while de programación.
• Requiere timeout para evitar loops infinitos.

7.3 · Espera

Wait activity

• Pausa la ejecución un tiempo determinado (segundos).
• Útil para esperar procesos externos o simplemente escalonar cargas.

7.4 · Llamadas externas

Web activity 🎯

• Llama a un REST API externo.
• Puedes pasar headers, body, auth.
• Recibe respuesta que puedes procesar en actividades siguientes.

Webhook activity

• Llama a un endpoint y espera un callback.
• El pipeline se pausa hasta que el endpoint invoca el callback URL.

7.5 · Metadata y lookup

Lookup activity 🎯 (MUY examinable)

• Lee un record o tabla de un source externo.
• El output se puede referenciar en actividades siguientes.
• Ejemplo: leer una lista de tablas de una BBDD de config → pasar al ForEach.

Get Metadata activity 🎯

• Recupera metadata de un dataset (existencia, tamaño, timestamp, structure).
• Útil para checks previos: ¿existe el fichero? ¿es del tamaño esperado?

7.6 · Variables y filtros

Set Variable 🎯

• Asigna un valor a una variable existente.
• Útil para pasar estado entre actividades.

Append Variable

• Añade un valor a una variable de array.
• Útil dentro de ForEach para acumular resultados.

Filter activity

• Aplica una expresión de filtro a un array de input.
• Devuelve el subset que cumple la condición.

7.7 · Invocar otros pipelines

Invoke Pipeline activity 🎯

• Ejecuta otro pipeline desde el actual.
• Permite modularizar workflows complejos.

7.8 · Fallar controlado

Fail activity

• Causa fallo intencional del pipeline con mensaje custom.
• Útil para validaciones estrictas ("si no hay datos, falla").

Deactivate activity

• Desactiva otra actividad (útil para debugging).

7.9 · 🎯 Actividades específicas de Fabric

Refresh SQL Endpoint activity 🎯 (MUY examinable)

• Refresca el metadata del SQL analytics endpoint de un lakehouse.
• Resuelve el problema clásico: "el Dataflow lee datos viejos porque el sync no ha terminado".

Refresh Materialized Lake View activity

• Refresca una materialized lake view en un lakehouse.

Lakehouse Maintenance activity 🎯

• Ejecuta mantenimiento de rutina en tablas Delta de un Lakehouse.
• Incluye OPTIMIZE y V-Order.

7.10 · Workflow / decisiones humanas

Approval activity 🎯

• Pausa el pipeline y solicita aprobación humana.
• Reviewers designados aprueban/rechazan desde Teams o email.
• Basado en la decisión, el pipeline continúa por un camino u otro.

7.11 · Otras

Azure Batch, Azure Databricks, Azure Machine Learning activity

• Integraciones con servicios Azure específicos.

Functions activity

• Ejecuta una Azure Function.

KQL activity 🎯

• Ejecuta un KQL script contra una instancia de Kusto (Eventhouse).

Actividades nuevas de Fabric que NO existen en ADF originalmente.

8.1 · Teams activity

Publica un mensaje en un canal de Teams o en un chat de grupo.

Uso típico:

• Notificar éxito o fallo del pipeline.
• Alertar sobre umbrales de datos.
• Comunicar aprobaciones necesarias.

Configuración:

• Team + Channel destino.
• Mensaje (soporta markdown + variables dinámicas).
• Adjuntos opcionales.

8.2 · Outlook activity

Envía un email vía Outlook.

Uso típico:

• Reportes de estado por email a stakeholders.
• Alertas críticas.
• Adjuntar resultados.

Configuración:

• Destinatarios (To, Cc, Bcc).
• Asunto.
• Body (HTML soportado).
• Attachments opcionales.

8.3 · Combinación con Approval

Muy común: Approval → notificar via Teams si aprobado, notificar via Outlook si rechazado.

9.1 · Anatomía de la actividad

Al añadir Copy Data al canvas, tienes varios tabs en el panel de propiedades:

Tab General (común a todas):

• Name, Description.
• Timeout (default: 12h, max: 7 días).
• Retry policy.
• Secure input/output.

Tab Source:

• Conexión al source.
• Query o table seleccionada.
• Query timeout, partitioning options.

Tab Destination:

• Conexión al destino.
• Table o folder destino.
• Update method (append, replace, upsert).

Tab Mapping:

• Mapeo columna a columna source → destino.
• Type conversions.

Tab Settings:

• Data integration units (DIU).
• Parallel copies.
• Retry on failures.
• Fault tolerance.
• Logging.

9.2 · Update methods según destino

Según el destino, tienes distintas opciones:

9.3 · Copy behavior for files

Al copiar ficheros:

• PreserveHierarchy: mantiene estructura de carpetas.
• FlattenHierarchy: aplana en una sola carpeta.
• MergeFiles: consolida en un solo fichero.

9.4 · Parallel copies y DIUs

Parallel copies: número de conexiones paralelas al source. Aumenta throughput pero puede saturar el source.

DIUs (Data Integration Units): unidad de compute para Copy Data. Más DIUs → más rápido pero más CU consumidas.

Para la mayoría de casos, dejar en Auto es suficiente.

9.5 · Fault tolerance

Puedes configurar cómo maneja errores:

• Abort activity on first incompatible row: falla al primer error.
• Skip incompatible rows (y opcionalmente logear a un fichero).

10.1 · Parámetros del pipeline

Cómo crearlos:

• Pipeline canvas → tab Parameters → New.
• Definir: Name, Type (String, Int, Float, Bool, Array, Object, SecureString), Default value.

Cómo referenciarlos:

@pipeline().parameters.folder_name
@pipeline().parameters.process_date

Cómo pasarles valor al ejecutar:

• On-demand run → dialog con inputs.
• Scheduled → definidos en el schedule.
• Event trigger → definidos en el trigger.
• Invoke pipeline → definidos en la llamada.

10.2 · Variables del pipeline

Cómo crearlas:

• Pipeline canvas → tab Variables → New.
• Definir: Name, Type, Default value.

Cómo asignarlas:

• Actividad Set Variable.

Cómo referenciarlas:

@variables('my_variable')

Diferencia clave vs parámetros:

• Parámetros: inmutables durante el run, definidos al inicio.
• Variables: mutables, se pueden cambiar durante el run.

10.3 · Expressions y functions

Fabric pipelines usan un expression language para valores dinámicos. Empiezan con @:

Referenciar valores:

@pipeline().parameters.env             -- parámetro
@pipeline().RunId                       -- ID del run actual
@pipeline().TriggerName                 -- nombre del trigger que lanzó
@pipeline().TriggerTime                 -- momento del trigger
@variables('x')                         -- variable
@activity('Lookup1').output.value       -- output de actividad

Funciones de fecha:

@utcnow()                               -- ahora en UTC
@formatDateTime(utcnow(), 'yyyy-MM-dd')
@addDays(utcnow(), -1)
@dayOfWeek(utcnow())

Funciones de string:

@concat('Files/', pipeline().parameters.folder, '/', formatDateTime(utcnow(), 'yyyyMMdd'), '.csv')
@toUpper('hello')
@substring('hello world', 0, 5)
@replace('hello', 'l', 'L')

Funciones lógicas:

@equals(x, y)
@and(condition1, condition2)
@or(condition1, condition2)
@not(condition)
@if(condition, valueIfTrue, valueIfFalse)

Funciones de colección:

@length(myArray)
@contains(myArray, item)
@first(myArray)
@last(myArray)
@indexOf(myArray, item)

10.4 · 🎯 Uso típico: nombres dinámicos de ficheros

Ejemplo común: guardar el output en una carpeta con fecha:

folder = @concat(
    'Files/ingested/',
    pipeline().parameters.source_name, '/',
    formatDateTime(utcnow(), 'yyyy/MM/dd'), '/'
)

10.5 · Dynamic content builder

Fabric ofrece un expression builder visual:

• Cualquier campo que soporte expressions muestra un icono fx o link Add dynamic content.
• Al hacer click, se abre un dialog con:
  • Funciones disponibles (categorizado).
  • Parámetros y variables del pipeline.
  • Output de actividades previas.
• Puedes componer la expression visualmente sin recordar sintaxis exacta.

11.1 · On-demand runs

Cómo: en el pipeline editor → botón Run en el Home ribbon.

Cuándo: desarrollo, testing, ejecuciones puntuales, re-ejecutar después de fix.

11.2 · Scheduled runs

Cómo: pipeline editor → botón Schedule.

Configuración:

• Start date.
• End date (opcional).
• Time zone.
• Frequency: Minute, Hour, Day, Week, Month.
• Interval: cada cuántas unidades (cada 15 min, cada 2h, etc.).

Ejemplo: "Every day at 06:00 AM Central European Time, starting 2026-01-01".

11.3 · Event-based runs (los MÁS interesantes)

Estos los vemos a fondo en la siguiente sección porque son bastante complejos y muy examinables.

Base: eventos como llegada de fichero → Activator capta el evento → dispara el pipeline.

12.1 · ¿Qué son los event-based triggers?

Triggers que ejecutan un pipeline automáticamente cuando ocurre un evento en:

• OneLake (fichero creado/borrado/modificado)
• Azure Blob Storage (fichero creado/borrado/modificado)
• Jobs de Fabric (pipeline succeeded/failed)
• Workspace events

12.2 · Arquitectura

Fichero llega a OneLake/Blob
  ↓
Evento emitido (Microsoft.Fabric.OneLake.FileCreated)
  ↓
Eventstream capta el evento
  ↓
Activator evalúa la condición
  ↓
Pipeline se ejecuta con parámetros dinámicos

Los componentes clave:

• Eventstream: capa de captura de eventos.
• Activator (antes "Reflex"): capa de decisión y acción.

12.3 · 🎯 Por qué son tan poderosos

• ⚡ Real-time processing: no esperas al próximo schedule.
• 💰 Coste bajo: solo ejecutas cuando hay datos nuevos.
• 🤖 Automation total: sin intervención manual.
• 🔄 Data freshness: analytics siempre actualizadas.

12.4 · Cómo configurar un trigger de storage event

Paso 1: en el pipeline canvas → botón Trigger en Home ribbon.

Paso 2: se abre el panel Set alert (usa Activator).

Paso 3: seleccionar tipo de eventos:

• OneLake events (para ficheros en OneLake)
• Azure Blob Storage events

Paso 4: seleccionar el source:

• Para OneLake: workspace + lakehouse + folder.
• Para Blob: Azure subscription + storage account.

Paso 5: elegir tipos de eventos:

• Microsoft.Fabric.OneLake.FileCreated
• Microsoft.Fabric.OneLake.FileDeleted
• Microsoft.Storage.BlobCreated
• Microsoft.Storage.BlobDeleted
• Y muchos más.

Paso 6: filtros (opcional):

• Filtrar por folder path.
• Filtrar por file name pattern.
• Filtrar por file type.
• Se hace vía el campo Subject.

Paso 7: configurar la acción del trigger:

• Workspace destino.
• Pipeline a ejecutar.
• Nombre del Activator item (Reflex).

Paso 8: Create → trigger activo.

12.5 · Ejemplo completo (tutorial oficial)

Escenario: cuando se sube un CSV a Files/Source/ en un Lakehouse, procesar y cargar a una tabla.

Setup:

1. Crear Lakehouse TutorialLakehouse con subfolder Source.
2. Crear pipeline TutorialPipeline que procesa el CSV.
3. En Real-Time hub → Fabric Events → OneLake events → Set alert.
4. Configurar source como TutorialLakehouse/Files/Source.
5. Eventos: FileCreated y FileDeleted.
6. Action: Run a Fabric item → seleccionar TutorialPipeline.
7. Guardar activator como TutorialActivator.

Test:

• Subir un CSV a Files/Source/.
• Automáticamente se dispara el FileCreated event.
• Activator llama al pipeline.
• Pipeline procesa y carga a Sales table.
• Sin refresh manual, sin esperar schedule.

12.6 · 🎯 Casos de uso comunes

• 📊 Data lake ingestion: nuevos ficheros → pipeline auto-procesa.
• 🧪 Trigger a Notebook para preprocessing ML.
• 🔔 Alertas cuando datasets críticos se modifican.
• 🔗 Forward events a webhooks para compliance.
• 📧 Notificaciones vía Teams/Email con el evento.

Cuando un pipeline se ejecuta por un trigger de storage event, Fabric expone información del evento al pipeline vía parámetros built-in.

13.1 · Parámetros disponibles

@pipeline()?.TriggerEvent?.FileName        -- nombre del fichero
@pipeline()?.TriggerEvent?.FolderPath      -- ruta de la carpeta

Ojo con el ?: es sintaxis de "null-safe access". Necesario porque:

• Cuando el pipeline se dispara por evento → los valores están presentes.
• Cuando el pipeline se ejecuta manualmente (test) → los valores son NULL.
• El ? evita que el pipeline falle en test manual.

13.2 · Uso en actividades

Ejemplo: usar el nombre del fichero recibido para construir la ruta:

input_file = @pipeline()?.TriggerEvent?.FileName
target_table = @concat('processed_', formatDateTime(utcnow(), 'yyyyMMdd'))

13.3 · Estructura completa del evento

Los eventos tienen esta estructura:

13.4 · Expression builder para trigger parameters

En el expression builder del pipeline hay una tab específica para trigger parameters:

• Data Factory parsea automáticamente el fichero y la carpeta.
• Puedes añadirlos a expressions dinámicamente.

Fabric incluye templates predefinidos para escenarios comunes. Te ahorran mucho tiempo si tu caso encaja.

14.1 · Cómo usar un template

1. Crear nuevo pipeline.
2. En la pantalla inicial → tile Templates.
3. Explorar la biblioteca.
4. Seleccionar template → se crea un pipeline pre-configurado.
5. Editar y personalizar según necesidad.

14.2 · Categorías de templates

Templates comunes:

• Copy multiple files/tables desde un source.
• Incremental copy desde una BBDD.
• Ingest data from REST API con paginación.
• Consolidate multiple sources en un destino.
• Simple ETL de un flat file a una tabla.

14.3 · Beneficios

• ⚡ Setup rápido (patrones probados).
• 📚 Buena forma de aprender best practices.
• 🎯 Cubren la mayoría de escenarios comunes.

Todas las actividades tienen configuración General común.

15.1 · Tabla completa

15.2 · 🎯 Timeout

• Formato: D.HH:MM:SS (Days.Hours:Minutes:Seconds).
• Default: 12 horas.
• Máximo: 7 días (7.00:00:00).
• Si se excede → la actividad falla con timeout error.

15.3 · 🎯 Retry logic

Configurar retries es crítico para producción. Escenarios típicos que se benefician:

• Errores transitorios de red.
• Servicios temporalmente no disponibles.
• Rate limiting en APIs externas.
• Timeouts intermitentes.

Consideraciones:

• No demasiados retries (3-5 suele bastar).
• Retry interval razonable (30-60 seg típico).
• Combinar con retry conditions para retry solo en errores específicos.

15.4 · 🎯 Secure input/output

Cuando activas:

• Secure output: el output de la actividad no se logea.
• Secure input: el input no se logea.

Uso típico: cuando la actividad maneja credenciales, tokens, o datos sensibles (LGPD, GDPR, HIPAA).

Ejemplo: si la actividad hace un Web call con un token de auth, activa Secure input para que el token no aparezca en logs.

15.5 · ⚠️ Límite de actividades por pipeline

Máximo 120 actividades por pipeline, incluyendo actividades anidadas en containers (ForEach, If, Switch, Until).

Si necesitas más → modulariza con Invoke Pipeline.

16.1 · ¿Para qué?

La actividad Invoke Pipeline permite que un pipeline ejecute otro pipeline.

Beneficios:

• 🧩 Modularizar workflows complejos.
• ♻️ Reutilizar lógica común entre múltiples pipelines.
• 📂 Organizar proyectos grandes.
• 🎯 Escapar del límite de 120 actividades por pipeline.

16.2 · Cómo funciona

Pipeline padre:

Actividad A → Invoke Pipeline "SubPipeline_A" → Actividad B

Al llegar a Invoke:

1. Ejecuta SubPipeline_A.
2. Puede pasarle parámetros.
3. Espera a que termine (o continúa en async si se configura).
4. El output del subpipeline se puede referenciar.
5. Continúa con Actividad B.

16.3 · Configuración

• Invoked pipeline: pipeline a ejecutar.
• Parameters: valores pasados al subpipeline.
• Wait on completion: esperar a que termine (default) o async.

16.4 · Uso típico

Patrón master + workers:

Master pipeline:
  ├─ Lookup: obtener lista de sources
  └─ ForEach source:
       └─ Invoke Pipeline "ProcessSource" (para cada source)

Cada ProcessSource es un pipeline independiente que hace su ETL específico.

17.1 · ¿Qué es?

Approval activity pausa el pipeline y solicita una decisión humana (aprobar/rechazar) a personas designadas.

17.2 · Cuándo usarla

• ✅ Workflows que requieren sign-off manual.
• ✅ Compliance y auditoría.
• ✅ Decisiones que deben ser traceable y auditables.
• ✅ Data publishing a producción.

17.3 · Cómo funciona

1. El pipeline llega a la Approval activity.
2. Se pausa la ejecución.
3. Notificación a los aprobadores (por email, Teams).
4. Aprobadores revisan → aprobar o rechazar.
5. Según la decisión:
   • Approved → sigue el camino success.
   • Rejected → sigue el camino failure.
6. La decisión queda auditable para siempre.

17.4 · Ejemplo: publicación con aprobación

Pipeline "PublishData":
  ├─ Prepare + Validate data
  ├─ Approval activity (business owner reviews)
  ├─ If approved:
  │    ├─ Publish results to production
  │    └─ Teams notification "Published"
  └─ If rejected:
       ├─ Outlook notification "Feedback and rejection reason"
       └─ Fail activity (stop pipeline)

17.5 · Auditoría

Todos los pipelines con approvals son fully observable en Fabric Monitoring:

• Ver estado de aprobación pendiente.
• Ver quién aprobó/rechazó y cuándo.
• Ver comentarios de la decisión.
• Diagnóstico de workflows con approvals pendientes.

18.1 · Dónde monitorizar

Hay varios sitios desde donde monitorizar:

A) Pipeline canvas → tab Runs

• Historial de runs del pipeline actual.
• Detalles por run: duración, status, activity outputs.

B) Monitor Hub

• Vista centralizada de todos los runs de todos los pipelines.
• Filtros por workspace, tipo de item, status.

C) Workspace list

• El pipeline item en la lista muestra el último estado.

18.2 · Real-time monitoring

Mientras el pipeline corre:

• Indicadores visuales de status por actividad.
• Verde ✅ = success, Rojo ❌ = failure, Amarillo ⏸️ = in progress, Gris = skipped.
• Puedes ver el output/input de cada actividad al pinchar.

18.3 · Run history

Para cada run pasado:

• Timestamp de inicio y fin.
• Duración total.
• Status general.
• Detalles por actividad: input, output, error messages.
• Trigger que lo lanzó.
• Parámetros con los que se ejecutó.

18.4 · Métricas de performance

• Tiempo por actividad.
• Rows copiadas (para Copy Data).
• Throughput.
• CU consumidas.

Útil para identificar bottlenecks.

18.5 · 🎯 Audit trail

• Quién ejecutó qué pipeline y cuándo.
• Logs detallados con timestamps.
• Data lineage (rastreo desde origen hasta destino).
• Error messages con contexto.

Esencial para debugging y compliance.

19.1 · Notificaciones básicas por schedule

Para pipelines programados, puedes configurar failure notifications:

1. Pipeline canvas → Schedule button.
2. Sección Failure notifications.
3. Añadir usuarios o grupos.
4. Cuando el pipeline falla → email automático.

19.2 · Notificaciones avanzadas con Teams/Outlook activities

Para casos más complejos:

Pipeline principal
  ├─ Actividades de ETL
  └─ Si falla cualquier actividad (rama on failure):
       ├─ Set variable: error_message = detalles
       ├─ Teams activity: post to #data-alerts
       ├─ Outlook activity: email to data-team@company.com
       └─ Fail activity (opcional, marca fail explícito)

19.3 · Con Activator

Para eventos más avanzados:

• Activator detecta cuando pipeline falla.
• Puede activar múltiples acciones:
  • Reenviar a Power Automate.
  • Escribir a un log centralizado.
  • Notificar a múltiples canales.

Muchos vienen de Azure Data Factory (ADF) o Azure Synapse Pipelines y les interesa saber qué cambia.

20.1 · Similitudes

• Concepto de pipeline y actividades: casi idéntico.
• Mayoría de actividades de ADF están en Fabric.
• Expression language es el mismo.
• Copy Data y conectores: muy similares.

20.2 · Diferencias clave

Fabric añade (no en ADF originalmente):

• ✅ Outlook activity (email notifications).
• ✅ Teams activity (notifications en Teams).
• ✅ Semantic model refresh (para Power BI).
• ✅ Dataflow Gen2 activity.
• ✅ Refresh SQL Endpoint activity.
• ✅ Lakehouse Maintenance activity.
• ✅ Copy Job (item independiente).

Fabric quita (o cambia nombre):

• ⚠️ Wrangling Data Flow → reemplazado por Dataflow Gen2.
• ⚠️ Some legacy connectors deprecated.

Fabric mejora:

• ✅ Integración nativa con OneLake, Lakehouses, Warehouses.
• ✅ Trigger events con Activator.
• ✅ UI más moderna y coherente con el resto de Fabric.

20.3 · Migración ADF → Fabric

Microsoft ofrece:

• Compatibilidad de actividades (la mayoría se traduce directamente).
• Fabric Lakehouse/Warehouse connectors disponibles en ADF (para hybrid).
• Guía de migración de Mapping Data Flows a Dataflow Gen2.
• Roadmap: mount ADF resources en Fabric (para transición gradual).

20.4 · ⚠️ Featues NO backported

Los features nuevos de Fabric NO se traen a ADF (dos roadmaps separados).

De la documentación oficial:

21.1 · Diseño

1. Start simple: empieza con data movement básico y añade complejidad gradualmente.
2. Use parameters: parametriza connections y file paths para hacer pipelines reutilizables.
3. Handle errors: plan de retry logic y paths alternativos.
4. Monitor performance: revisa execution times y optimiza actividades lentas.
5. Test thoroughly: valida con sample data antes de producción.

21.2 · Naming conventions

• Usa nombres descriptivos y consistentes.
• Convenciones: pl_[dominio]_[accion] (ej: pl_sales_daily_ingest).
• Para actividades: [verbo]_[objeto] (ej: Copy_Sales_Data, Validate_Row_Count).

21.3 · Modularización

• Pipelines grandes → dividir con Invoke Pipeline.
• Lógica común → subpipelines reutilizables.
• Un pipeline una responsabilidad clara (no "hace de todo").

21.4 · Error handling

• Retry logic en actividades propensas a errores transitorios (Web, Copy remote).
• Failure paths para notificaciones.
• Approval activities para gates críticos.
• Fail activity para validaciones estrictas.

21.5 · Performance

• Parallelize con ForEach cuando aplique.
• Copy activity con DIUs adecuados.
• Batching en Copy para reducir overhead.
• Incremental loads en vez de full cuando posible.

21.6 · Governance

• Usa workspace folders para organizar.
• Git integration para versionado.
• Deployment pipelines para dev → test → prod.
• Secure input/output en actividades sensibles.

Trampa 1: "Un pipeline es lo mismo que un dataflow"

❌ NO. Un pipeline orquesta actividades. Un dataflow transforma datos. Un pipeline puede ejecutar un dataflow como una de sus actividades.

Trampa 2: "Copy Data es la única forma de mover datos"

❌ También hay Copy Job, Dataflow Gen2, Notebook, Shortcuts, Mirroring. Cada uno para su caso.

Trampa 3: "Los eventos de OneLake son instantáneos"

✅ Casi. Hay una latencia mínima de segundos entre el evento y la ejecución del pipeline. No es exactamente 0ms.

Trampa 4: "Puedo tener 500 actividades en un pipeline"

❌ Máximo 120 actividades por pipeline (incluyendo anidadas). Para más → usa Invoke Pipeline.

Trampa 5: "Retries se aplican automáticamente"

❌ Están desactivados por defecto. Hay que activarlos explícitamente en cada actividad.

Trampa 6: "Los parámetros son iguales que las variables"

❌ Parámetros: input externo, inmutables durante el run. Variables: estado interno, mutables.

Trampa 7: "Trigger parameters funcionan en run manual"

❌ NO. En run manual, @pipeline()?.TriggerEvent?.FileName es NULL. Por eso se usa el ? de null-safe access.

Trampa 8: "Approval activity bloquea todo el workspace"

❌ Solo bloquea ese pipeline específico. Otros pipelines corren normal.

Trampa 9: "El timeout máximo es 24 horas"

❌ Máximo 7 días (7.00:00:00). Default: 12 horas.

Trampa 10: "Fabric Data Factory = Azure Data Factory"

❌ Son distintos. Fabric tiene features nuevas (Teams, Outlook, Semantic Model Refresh, Dataflow Gen2, Refresh SQL Endpoint, Lakehouse Maintenance). ADF no las tiene.

Trampa 11: "Refresh SQL Endpoint activity refresca datos"

❌ NO refresca los datos. Refresca el metadata sync del SQL analytics endpoint del lakehouse (para que las nuevas tablas/columnas aparezcan).

Trampa 12: "Puedo usar Refresh SQL Endpoint sobre un Warehouse"

❌ Es específico para SQL analytics endpoint de Lakehouse. Los Warehouses tienen su propia sincronización.

Trampa 13: "ForEach siempre ejecuta en paralelo"

❌ Puede ser paralelo o secuencial. Tú lo configuras. Batch count controla el paralelismo (default 20).

Trampa 14: "Event triggers solo funcionan con OneLake"

❌ También con Azure Blob Storage y otros sources.

Trampa 15: "Secure input/output oculta los datos en el destino"

❌ Solo los oculta en los logs. Los datos siguen viajando y llegando al destino normalmente.

Pipeline vs Dataflow vs Notebook (LA gran pregunta)

Copy Data vs Copy Job

3 tipos de trigger

Actividades más usadas (chuleta rápida)

Parámetros vs Variables

General settings críticos