Entender la vinculación de dependencias en el despliegue multiespacio de trabajo

Cuando despliegas elementos de Fabric en los espacios de trabajo (por ejemplo, desde Desarrollo, Pruebas y Producción), las dependencias entre los elementos pueden romperse. Algunos elementos almacenan referencias a sus dependencias como IDs de objetos (GUIDs específicos de cada espacio de trabajo), mientras que otros usan IDs lógicos (identificadores portátiles entre espacios de trabajo almacenados en el .platform archivo).

Los elementos que usan identificadores lógicos en sus definiciones se vinculan correctamente al elemento correspondiente en el espacio de trabajo destino. Los elementos que usan identificadores de objeto siguen apuntando al espacio de trabajo de origen, lo que hace que falle el despliegue.

Este artículo mapea qué tipos de elementos Fabric soportan la vinculación de dependencias mediante IDs lógicos cuando usas integración con Git, y cuáles no. Para saber más sobre los IDs lógicos y cómo se representan los elementos en el control de versiones, consulta Logical ID en Fabric.

Conceptos clave

  • ID lógico: Identificador generado automáticamente entre espacios de trabajo en el archivo .platform. Los elementos con el mismo ID lógico se tratan como el mismo elemento en todos los espacios de trabajo.
  • ID de objeto: Un GUID específico de espacio de trabajo que identifica una instancia concreta. Los ID de objetos no sobreviven a un despliegue entre espacios de trabajo sin intervención manual o parametrización.
  • Vinculación de dependencias (Git): Cuando sincronizas una rama de Git con un nuevo espacio de trabajo, Fabric resuelve referencias de dependencias usando IDs lógicos, apuntando automáticamente al elemento correcto en el espacio de trabajo de destino.
  • Por nombre o por URI: Algunos elementos hacen referencia a las dependencias por nombre de visualización o URI en lugar de por ID. Estas referencias pueden resolverse correctamente o no, en función de las convenciones de nomenclatura en los distintos espacios de trabajo.

Cómo funciona la vinculación de dependencias

Dentro de un espacio de trabajo, los elementos referencian sus dependencias usando IDs de objetos. Cuando Fabric exporta un elemento a Git, reemplaza algunos de estos IDs de objeto por IDs lógicos del .platform archivo. Cuando sincronizas la rama Git con otro espacio de trabajo, Fabric resuelve esos IDs lógicos de vuelta a los IDs de objeto correctos en el espacio de trabajo destino. Esto es lo que hace que la vinculación de dependencias funcione.

Sin embargo, no todas las referencias a dependencias se reemplazan por IDs lógicos durante la exportación. Los elementos que mantienen los ID de objetos en su representación Git siguen apuntando al espacio de trabajo original tras sincronizarse, y necesitas actualizarlos manualmente o mediante parametrización.

Importante

La vinculación de dependencias solo se aplica a referencias entre elementos de Fabric dentro del mismo espacio de trabajo. Si un elemento hace referencia a un elemento Fabric en otro espacio de trabajo, esa referencia usa un ID de objeto y no se vincula automáticamente. Las referencias a conexiones (conexiones de origen de datos, gateways) tampoco se vinculan automáticamente. Utiliza Bibliotecas de Variables con conjuntos de valores específicos del entorno para gestionar referencias de conexión entre entornos.

Compatibilidad del enlace de dependencias

Las siguientes tablas muestran si las dependencias de cada tipo de elemento Fabric se vinculan correctamente cuando se despliega entre espacios de trabajo. Actualmente, este artículo trata sobre el comportamiento de integración de Git . Como la vinculación está determinada por cómo cada elemento almacena sus referencias de dependencia en su definición, el mismo comportamiento se aplica a otros mecanismos de despliegue que reutilizan esas definiciones, como las pipelines de despliegue y las APIs de importación (en masa).

Estas tablas asumen que la dependencia es otro elemento en el mismo espacio de trabajo que el elemento fuente. Una referencia a un elemento en otro espacio de trabajo nunca se vincula automáticamente. Permanece fijado al ID del objeto fuente independientemente del valor mostrado en la tabla.

La columna Auto-bind en Git indica:

  • Sí: La definición de elemento en Git almacena la referencia de dependencia como un ID lógico. Cuando sincronizas la rama con un nuevo espacio de trabajo, la referencia se vincula automáticamente al elemento correspondiente en ese espacio de trabajo.
  • No: La definición de elemento en Git almacena la referencia de dependencia como un ID de objeto (GUID específico del espacio de trabajo). La referencia sigue apuntando al espacio de trabajo de origen tras la sincronización. Necesitas actualizarlo manualmente o parametrizarlo para el despliegue entre espacios de trabajo.
  • Parcial: El elemento resuelve la dependencia por nombre o URI, lo que podría funcionar si el nombre es consistente entre espacios de trabajo.

Notebooks

Dependencia Asociación automática en Git Notas
Lakehouse Sí Requiere activar "Lakehouse Auto-Binding in Git" en la configuración del cuaderno. Cuando está habilitado, el ID del objeto se reemplaza por un ID lógico en notebook-settings.json. Esta opción está desactivada de forma predeterminada. Para más información, consulta Lakehouse auto-binding en Git.
Environment Sí
Base de datos reflejada No

Nota:

La vinculación del cuaderno con Lakehouse no está habilitada de forma predeterminada. Tienes que activar la opción "Lakehouse Auto-Binding in Git" en la configuración de cada cuaderno. Para obtener más información, consulte Control de código fuente de Notebook e implementación.

Reports

Dependencia Asociación automática en Git Notas
Modelo Semántico (del informe de Power BI) Parcial El informe hace referencia al modelo a través de una referencia relativa byPath en definition.pbir, no a un ID lógico explícito. Se resuelve correctamente cuando el modelo se despliega en la misma ubicación relativa del espacio de trabajo objetivo, pero no se vincula mediante un ID lógico. Para más información, consulte la carpeta de informes de proyectos de Power BI Desktop.
Modelo Semántico (del informe paginado) No La cadena de conexión del informe hace referencia al modelo semántico mediante un identificador específico del espacio de trabajo que no se reescribe durante la implementación, por lo que sigue apuntando al modelo fuente. Necesitas actualizar esta referencia para el despliegue entre espacios de trabajo. (Los informes elaborados en Report Builder que hacen referencia al modelo por nombre pueden resolverse por nombre de visualización, que es Parcial.)

Pipeline

Dependencia Asociación automática en Git Notas
Pipeline Sí
Notebook Sí
Flujo de datos Gen2 Sí
SQL Database Sí
Definición de trabajo de Spark No La actividad SparkJobDefinition hace referencia a la Definición de Trabajo Spark por ID de objeto, no por ID lógico, por lo que se mantiene apuntando al elemento fuente tras el despliegue. Necesitas parametrizar este valor para el despliegue entre espacios de trabajo.
Lakehouse Sí
Modelo semántico No La actividad PBISemanticModelRefresh hace referencia al modelo semántico por el ID del ítem, no por el ID lógico. Necesitas parametrizar este valor para el despliegue entre espacios de trabajo.
Almacén No El almacén artifactId se resuelve mediante el ID lógico y se vuelve a vincular, pero el linkedService también almacena el SQL endpoint del espacio de trabajo de origen, que no se reescribe. Parametriza el endpoint para el despliegue entre espacios de trabajo.

Modelos semánticos

Dependencia Asociación automática en Git Notas
Modelo semántico Parcial Las referencias a modelos encadenados o compuestos utilizan cadenas de conexión identificadas por nombre.
SQL Analytics Endpoint (lakehouse) No La cadena de conexión de Direct Lake en TMDL expressions.tmdl contiene una URL de extremo específica del área de trabajo y un GUID de base de datos. Necesitas reemplazar estos parámetros para el despliegue entre espacios de trabajo.
Base de datos KQL No La cadena de conexión que incluye un URI de clúster en las expresiones TMDL contiene valores específicos del espacio de trabajo.
SQL database No La cadena de conexión en las expresiones TMDL contiene valores específicos del espacio de trabajo.
Almacén No La conexión al endpoint de SQL Analytics del almacén utiliza una URL específica para el espacio de trabajo.

Casas junto al lago

Dependencia Asociación automática en Git Notas
Casa del lago (atajo) Sí Los atajos internos de OneLake que apuntan a otro elemento Fabric, como una casa lacustre o un almacén, se almacenan como un ID lógico y se reasignan al elemento del espacio de trabajo de destino. Los accesos directos a fuentes externas, como Azure Data Lake Storage Gen2 o Amazon S3, apuntan fuera de Fabric e incluyen una referencia de conexión, por lo que no están sujetos a la vinculación al identificador lógico. Para obtener la lista completa de destinos de acceso directo, consulta accesos directos de OneLake. Para el comportamiento de implementación, consulta la integración de Git en Lakehouse y las canalizaciones de implementación.

Flujos de datos (Gen2)

Por defecto, Dataflow Gen2 crea referencias absolutas a los elementos Fabric: la consulta almacena el ID del espacio de trabajo de origen y el ID del objeto del elemento, que no se reescriben en el despliegue. Una referencia de origen puede usar en su lugar una referencia relativa: cuando seleccionas un elemento debajo del nodo !(Current Workspace) en un conector de Fabric, la consulta almacena el elemento por nombre (sin GUID), y se resuelve como el elemento correspondiente en el espacio de trabajo de destino durante la implementación. Los destinos de salida siempre usan referencias absolutas y no se reasocian. Para destinos y para cualquier referencia de fuente absoluta, parametriza los valores para el despliegue entre espacios de trabajo. Para más información, consulte Referencias relativas con conectores Fabric en Dataflow Gen2 y Dataflow Gen2 con integración CI/CD y Git.

Referencias fuente:

Dependencia Asociación automática en Git Notas
Lakehouse Parcial Se reasigna solo cuando se crea como referencia relativa (!( Espacio de trabajo actual)); La referencia absoluta por defecto no se vuelve a vincular.
Almacén Parcial Se reasigna solo cuando se crea como referencia relativa (!( Espacio de trabajo actual)); La referencia absoluta por defecto no se vuelve a vincular.

Referencias de destino:

Dependencia Asociación automática en Git Notas
Lakehouse No
Almacén No
SQL Database No

Definiciones de trabajos de Spark

Dependencia Asociación automática en Git Notas
Environment Sí
Lakehouse No El defaultLakehouseArtifactId utiliza un identificador de objeto.

Trabajos de copia

Dependencia Asociación automática en Git Notas
Lakehouse Sí
Almacén No El almacén artifactId se resuelve mediante el ID lógico y se vuelve a vincular, pero el linkedService también almacena el SQL endPoint del espacio de trabajo de origen, que no se reescribe. Parametriza el endPoint para el despliegue entre espacios de trabajo.
SQL Database Sí

API de GraphQL

Dependencia Asociación automática en Git Notas
Punto de conexión de SQL Sí
Almacén Sí
SQL Database Sí

Para todas las fuentes de datos de la API de GraphQL, puede que necesites reconfigurar la conexión y las credenciales tras el despliegue.

Secuencias de eventos

Dependencia Asociación automática en Git Notas
Lakehouse Sí
Eventhouse Sí Todos los destinos son totalmente compatibles con CI/CD cuando los elementos están en el mismo espacio de trabajo. Para Eventhouse con modo de Ingestión Directa, puede que necesites reconfigurar manualmente la conexión después del despliegue. Para más información, véase Eventstream CI/CD.
Activador (Reflex) Sí Todos los destinos son totalmente compatibles con CI/CD cuando los elementos están en el mismo espacio de trabajo. Para más información, véase Eventstream CI/CD.

Elementos de KQL

Dependencia Asociación automática en Git Notas
Base de datos KQL a casa de eventos Sí El parentEventhouseItemId in DatabaseProperties.json es un ID lógico y se vincula a la casa de eventos objetivo. Una base de datos KQL se implementa como elemento secundario de su eventhouse primario.
Conjunto de consultas KQL a una base de datos KQL Parcial Resuelve a través de clusterUri y databaseName, no del ID del objeto. La definición incluye un databaseItemId, pero es un ID de objeto que no se reasigna, así que la resolución depende del URI entre los entornos.
Panel de control en tiempo real para la base de datos KQL Parcial Utiliza un dataSources array con URIs de clúster. El mismo patrón que el conjunto de consultas KQL.

Almacenes

Dependencia Asociación automática en Git Notas
Almacén (referencia cruzada) No Las referencias a otros almacenes usan identificadores de objetos.
Punto de conexión de SQL No Las referencias de endpoints SQL utilizan identificadores específicos del espacio de trabajo.

Bibliotecas de variables

Dependencia Asociación automática en Git Notas
Elementos de Fabric (tipo ItemReference) No El tipo de variable ItemReference almacena workspaceId y itemId como GUID sin procesar. Debes actualizar o sobrescribir manualmente estos valores a través de conjuntos de valores por entorno.

Elementos sin dependencias

Los siguientes elementos no presentan preocupaciones sobre vinculación de dependencias entre espacios de trabajo:

  • Environment
  • SQL Database
  • Eventhouse (artículo contenedor; Las bases de datos KQL lo referencian)
  • Base de datos espejada (solo configuración de código fuente externo)

Resumen

Cuando despliegas elementos de Fabric entre espacios de trabajo, las dependencias entre elementos pueden romperse si las referencias se almacenan como IDs de objeto específicos del espacio de trabajo en lugar de IDs lógicos portátiles. No todos los tipos de elementos soportan la vinculación de dependencias mediante IDs lógicos. Antes de configurar el despliegue entre espacios de trabajo, revisa las tablas de compatibilidad de este artículo para identificar qué dependencias se vinculan automáticamente y cuáles requieren parametrización manual.

Contenido relacionado

  • Last updated on