Información general de conectores de aplicciones de lienzo

Los datos son el núcleo de la mayoría de las aplicaciones, incluidos los creados en Power Apps. Los datos se almacenan en un origen de datos; debe llevar esos datos a su aplicación, para lo que es necesario crear una conexión. La conexión utiliza un conector específico para comunicarse con el origen de datos. Power Apps integra conectores para numerosos servicios populares y orígenes de datos locales, incluidos SharePoint, SQL Server, Office 365, Salesforce y Twitter. Para empezar a agregar datos a una aplicación de lienzo, vea Adición de una conexión de datos en Power Apps.

Un conector puede proporcionar tablas de datos o acciones. Algunos conectores solo proporcionan tablas, algunos solo proporcionan acciones y otros proporcionan ambos. Además, el conector puede ser un conector estándar o personalizado.

Nota

Se recomienda mantener el número de conectores en una aplicación de lienzo en un máximo de 10 y las referencias de conexión en no más de 20. Ir más allá de estos límites puede llevar a tiempos de carga más largos para los usuarios al iniciar la aplicación y podría causar problemas al guardar la aplicación.

Tablas

Si el conector ofrece tablas, agregue el origen de datos y luego seleccione la tabla en el origen de datos que quiere administrar. Power Apps recupera los datos de la tabla en la aplicación y actualiza automáticamente los datos en el origen de datos. Por ejemplo, puede agregar un origen de datos que contenga una tabla denominada Lecciones y luego establecer la propiedad Items de un control, como una galería o un formulario, en este valor en la barra de fórmulas:

Puede especificar los datos que la aplicación recupera personalizando la propiedad Items del control que muestra los datos. Retomando el ejemplo anterior, puede ordenar o filtrar los datos de la tabla Lecciones utilizando ese nombre como argumento para las funciones Search y SortByColumn. En este gráfico, la fórmula en la que se establece la propiedad Items especifica que los datos se ordenan y filtran según el texto de TextSearchBox1.

Para más información sobre cómo personalizar la fórmula con tablas, vea estos artículos:

Información acerca de los orígenes de datos en Power Apps
Creación de una aplicación a partir de datos de Excel
Crear una aplicación desde cero
Información sobre tablas y registros de Power Apps

Nota

Para conectarse a datos de un libro de Excel, este ha de estar hospedado en un servicio de almacenamiento en la nube como OneDrive. Para más información, consulte Conectar al almacenamiento en la nube desde Power Apps.

Acciones

Si el conector facilita acciones, tiene que seleccionar el origen de datos del mismo modo que antes. Sin embargo, en lugar de seleccionar una tabla como siguiente paso, conecte manualmente un control a una acción editando la propiedad Items del control que va a mostrar los datos. La fórmula en la que se establece la propiedad Items especifica la acción que recupera los datos. Por ejemplo, la aplicación no recuperará los datos si se conecta a Yammer y luego establece la propiedad Items en el nombre del origen de datos. Para rellenar un control con datos, especifique una acción como GetMessagesInGroup(5033622).messages.

Si tiene que controlar actualizaciones de datos personalizadas con conectores de acción, cree una fórmula que incluya la función Patch. En la fórmula, identifique la acción y los campos que quiere enlazar a la acción.

Nota

Para los conectores basados ​​en acciones, las galerías y otros controles no incluyen más datos automáticamente de la misma manera que lo hacen para los conectores tabulares. Por ejemplo, si vincula un origen de datos tabular a una galería, recuperará el primer conjunto o página de registros (por ejemplo, 100 registros). Y luego incluirá más datos a medida que el control lo solicite. Sin embargo, para un conector basado en acciones, recuperará una "página" de datos. Pero si los datos solicitados exceden el tamaño de una página de datos, el control no buscará automáticamente la siguiente página.

Para más información sobre cómo personalizar la fórmula con actualizaciones personalizadas, vea estos artículos:

Ruta
Collect
Actualización

El esquema dinámico es un tipo común de resultado para conectores basados ​​en acciones. El esquema dinámico de frase se refiere a la posibilidad de que la misma acción pueda devolver una tabla diferente con columnas diferentes en función de cómo se la llame. Las condiciones que pueden hacer que las columnas en la tabla difieran incluyen los parámetros de entrada de acción, el usuario o rol que ejecuta la acción y el grupo en el que trabaja el usuario, entre otros. Por ejemplo, los procedimientos almacenados de SQL Server pueden devolver columnas diferentes si se ejecutan con entradas diferentes, o una instancia de Azure DevOps puede usar campos personalizados que no están disponibles de forma predeterminada.

Nota

La documentación del conector muestra los resultados del esquema dinámico con este mensaje "Los resultados de esta operación son dinámicos" como valor de retorno.

Para obtener más información sobre cómo trabajar con esquemas dinámicos en Power Apps, consulte Trabajar con objetos sin tipo y dinámicos para información general y Conectar a Azure DevOps desde Power Apps para ver un ejemplo detallado.

Conectores populares

La tabla siguiente contiene vínculos a más información sobre nuestros conectores más utilizados. Para ver una lista completa de conectores, consulte el apartado Todos los conectores.

Microsoft Dataverse	Almacenamiento en la nube **
Dynamics AX	Excel
Microsoft Translator	Office 365 Outlook
Office 365 Users	Oracle
Power BI	SharePoint
SQL Server	Twitter

** Se aplica a Azure Blob, Box, Dropbox, Google Drive, OneDrive y OneDrive para la Empresa

Conectores estándar y personalizados

Power Apps proporciona conectores estándar para muchos orígenes de datos de uso común. Si Power Apps tiene un conector estándar para el tipo de origen de datos que quiere utilizar, ha de usar dicho conector. Si tiene que conectarse a otros tipos de orígenes de datos, como un servicio que haya creado, vea Registro y uso de conectores personalizados.

Todos los conectores estándar

Los conectores estándar no requieren licencias especiales. Para obtener más información, vea el tema sobre Planes de Power Apps.

Puede formular preguntas sobre un conector específico en los foros de Power Apps, así como sugerir que conectores que quiera agregar o se realicen otras mejoras en Power Apps Ideas.

Seguridad y tipos de autenticación

A medida que crea su aplicación y crea una conexión a un origen de datos, puede ver que su elección de conector le permite usar diferentes formas de autenticación. Por ejemplo, el conector de SQL Server le permite usar Microsoft Entra Integrado, la autenticación de SQL Server y la autenticación de Windows. Cada tipo de autenticación tiene diferentes niveles de seguridad asociados. Es importante comprender qué información y derechos comparte con los usuarios que usan su aplicación. El ejemplo principal en este artículo es SQL Server, sin embargo, los principios se aplican a todos los tipos de conexiones.

Nota

• Para obtener información detallada sobre las consideraciones de seguridad cuando se utiliza un servidor de base de datos relacional (como Microsoft SQL Server u Oracle) como origen de datos para una aplicación, consulte Utilizar Microsoft SQL Server de forma segura con Power Apps.
• Power Apps no admite identidades de miembro externo. Para obtener más información, consulte Propiedades de un usuario de colaboración B2B de Microsoft Entra.

Id. de Microsoft Entra

Esta autenticación es un tipo de conexión segura. Por ejemplo, SharePoint usa este tipo de autenticación. SQL Server también permite este tipo de autenticación. Cuando se conecta, el servicio de Microsoft Entra lo identifica por separado para SharePoint en su nombre. No tiene que proporcionar un nombre de usuario o contraseña. Como autor, puede crear y trabajar con el origen de datos con sus credenciales. Cuando publica su aplicación y su usuario inicia sesión, lo hace con sus credenciales. Si los datos están protegidos adecuadamente en un back-end, sus usuarios solo pueden ver lo que están autorizados a ver en función de sus credenciales. Este tipo de seguridad le permite cambiar los derechos para usuarios de aplicaciones específicas en el origen de datos del back-end después de que la aplicación haya sido publicada. Por ejemplo, puede otorgar acceso, denegar el acceso o refinar lo que un usuario o conjunto de usuarios puede ver, todo en el origen de datos de back-end.

Autorización de estándar abierto (OAuth)

Este tipo de conexión también es seguro. Por ejemplo, Twitter usa este tipo de autenticación. Cuando se conecte, deberá indicar su nombre de usuario y contraseña. Como autor, puede crear y trabajar con la fuente de datos con sus credenciales. Cuando publica su aplicación y su usuario inicia sesión, tiene que proporcionar también sus credenciales. Por lo tanto, este tipo de conexión es segura ya que sus usuarios deben usar sus propias credenciales para acceder al servicio de origen de datos.

Conexiones compartidas / Conexiones implícitas seguras

En una conexión compartida, el nombre de usuario y la contraseña para la conexión los proporciona el autor de Power Apps en el momento en que se crea el origen de datos en la aplicación. De este modo, la autenticación de conexión al origen de datos se comparte implícitamente con los usuarios finales. Tan pronto como se publique la aplicación, la conexión también se publicará y estará disponible para sus usuarios.

Antes de enero de 2024, los usuarios finales podían tomar la conexión que se comparte con ellos y crear nuevas aplicaciones independientes. Sus usuarios no podrán ver el nombre de usuario o la contraseña, pero sí que tendrán acceso a la conexión. Sin embargo, a partir de enero de 2024, todas las conexiones compartidas de nueva creación estarán aseguradas. Tenga en cuenta que las aplicaciones antiguas deben volver a publicarse para ser seguras. La conexión ya no se comparte con los usuarios finales. La Power App publicada se comunica con un proxy de conexión. El proxy de conexión solo se comunica con la Power App específica para la que está vinculado. El proxy de conexión limita las acciones que se envían a las conexiones de Power App {Get, Put/Patch, Delete} para un origen de datos determinado. Si tiene una aplicación que utiliza las conexiones publicadas antes de enero de 2024, debe volver a publicar su aplicación y anular la compartición de cualquier conexión con usuarios finales que no deberían tenerlas.

En SQL Server, un ejemplo de este tipo de conexión es la Autenticación de SQL Server. Muchas otros orígenes de datos de bases de datos ofrecen una capacidad similar. Cuando publica su aplicación, sus usuarios no necesitan proporcionar un nombre de usuario y una contraseña únicos.

Notificación para actualizar sus aplicaciones (conexiones implícitas seguras)

Si tiene aplicaciones que podrían actualizarse para usar esta característica, verá un mensaje en la página Aplicaciones. Indica la cantidad de aplicaciones que necesitan su atención.

Seleccione el enlace y se abrirá un panel lateral que enumera todas las aplicaciones que necesitan atención.

Seleccione el icono abrir a la derecha del nombre de la aplicación para abrirla y volver a publicarla. Continúe con las siguientes instrucciones.

Habilitar conexiones implícitas seguras para una aplicación existente

Abrir una app abierta para edición existente con conexiones implícitamente compartidas ya publicadas:

1. En la barra de comandos y después seleccione Configuración y busque "Segura".
2. Actualice el cambio de característica adecuadamente para habilitar conexiones implícitas seguras.
3. Guarde y publique la aplicación.

Anulación de uso compartido

Una vez publicada la aplicación, siga estos pasos para verificar que el uso compartido funciona correctamente:

• Compruebe si las conexiones se comparten con los copropietarios. Si no desea que un usuario final obtenga una conexión, desactive la casilla de verificación Copropietario .

  

• Para verificar que la característica funciona correctamente, comparta la aplicación con otro usuario que no sea propietario. Una vez compartida la app, compruebe la lista Conexiones en la pestaña Dataverse en Power Apps para ese usuario. Verifique que el usuario no tenga una conexión disponible.

• Abra el panel Compartir para cambiar el derecho del usuario final a la conexión. Al elegir la X , se elimina el acceso del usuario a la conexión.

  

Usar aplicaciones con una nueva conexión implícita segura

Cuando la aplicación se vuelve a publicar y se comparte, los usuarios finales no tienen acceso a la conexión, pero trabajan con la conexión proxy oculta. Los usuarios no pueden crear una nueva aplicación basada en la conexión original.

Limitaciones

1. Todos los tipos de conexiones implícitamente compartidas funcionan como acción y tabular.
2. Los nombres de los servidores y las bases de datos están ocultos en los seguimientos de la red, pero son visibles en el cuadro de diálogo de consentimiento. Los nombres de las columnas no están ocultos.
3. Para los conectores tabulares, solo limitamos las acciones CRUD como Get, Post, Put o Delete. Si tiene permisos para Put, entonces tiene acceso a Post.
4. El límite de conectores basados en acciones se basa en la API específica que se utiliza en la aplicación.
5. Las advertencias siguen habilitadas en el uso compartido. La advertencia sobre las conexiones compartidas implícitamente sigue apareciendo en la vista previa. No obstante, su conexión con esta característica es segura, a pesar de la advertencia.
6. No se admite la publicación en un arrendatario completo, a diferencia de grupos o individuos específicos.
7. Existe un problema conocido al importar una conexión segura compartida implícitamente a través de una referencia de conexión. La seguridad no está configurada correctamente en el entorno de destino.
8. Hay un problema conocido al importar una solución mediante una entidad de servicio, lo que provoca un error de importación. Una solución consiste en compartir la conexión con la entidad de servicio.

Autenticación de Windows

Este tipo de conexión no es segura porque no depende de la autenticación del usuario final. Use la autenticación de Windows cuando necesite conectarse a un origen de datos que sea local. Un ejemplo de este tipo de conexión es con un servidor local que tenga un servidor SQL. La conexión debe pasar por una puerta de enlace. Como pasa a través de una puerta de enlace, el conector tiene acceso a todos los datos de ese origen de datos. Como resultado, cualquier información a la que pueda acceder con las credenciales de Windows que proporcione estará disponible para el conector. Y tan pronto como se publique la aplicación, la conexión también se publicará y estará disponible para sus usuarios. Este comportamiento significa que sus usuarios finales también pueden crear aplicaciones utilizando esta misma conexión y acceder a los datos de esa máquina. Las conexiones al origen de datos también se comparten implícitamente con usuarios con los que se comparte la aplicación. Este tipo de conexión puede ser válida cuando su origen de datos solo esté en un servidor local y los datos de ese origen se pueden compartir libremente.

Orígenes de datos en soluciones

Las soluciones se utilizan para administración del ciclo de vida de la aplicación y proporcionan otras capacidades para gestionar el ciclo de vida de orígenes de datos. Si una aplicación de lienzo está en una solución, pueden crearse referencias de conexión y variables de entorno para almacenar información sobre los orígenes de datos. Este proceso garantiza que los orígenes de datos se puedan cambiar o restablecer cuando las soluciones se migren a diferentes entornos.

Cambiar el nombre de orígenes de datos en aplicaciones

Para obtener información sobre cómo cambiar el nombre de los orígenes de datos en una aplicación y la diferencia entre los orígenes de datos tabulares y los basadas en acciones, vaya a Cambiar el nombre a orígenes de datos basados en acciones de Power Apps.

Cuadro de diálogo de consentimiento

Cuando los usuarios abren una aplicación que usa conectores por primera vez, verán un cuadro de diálogo de "consentimiento de conexión" para los siguientes propósitos.

1. Informar a los usuarios sobre los orígenes de datos a los que accede la aplicación.

2. Para describir las acciones que un conector puede realizar o no en una aplicación. Por ejemplo, para las apps que utilizan el conector Usuarios de Office 365:

   • Esta aplicación puede:
     • Leer su perfil de usuario completo
     • Leer el perfil completo de todos los usuarios
   • La aplicación no puede:
     • Modificar o eliminar cualquier información de perfil de usuario

3. Capturar el consentimiento del usuario final para conectarse a los orígenes de datos que utiliza la aplicación.

4. Facilitar la autenticación manual del usuario final, cuando sea necesario.

Para algunas conexiones, Power Platform puede autenticar automáticamente a un usuario para acceder a un origen de datos. Sin embargo, si el inicio de sesión automático falla, este cuadro de diálogo solicita a los usuarios que obtengan una conexión iniciando sesión manualmente. Power Platform solo puede intentar el inicio de sesión automático para una conexión cuando un origen de datos preautoriza la entidad de servicio de conexiones de la API de Azure de Microsoft, otorgándole permiso para realizar el inicio de sesión único para un usuario cuando se crea una conexión. Para obtener más información sobre el inicio de sesión único, consulte ¿Qué es el inicio de sesión único (SSO)?

Tenga en cuenta que, en el caso de las aplicaciones basadas en modelos que usan páginas personalizadas, cuando hay varias páginas personalizadas en una aplicación, el cuadro de diálogo de consentimiento solicita permisos de datos para todos los conectores de todas las páginas personalizadas, incluso si no se abren.

La siguiente imagen es un ejemplo del cuadro de diálogo de consentimiento de conexión para una aplicación que se conecta a un sitio de SharePoint.

Para conectores seleccionados, los administradores pueden suprimir este cuadro de diálogo y dar su consentimiento en nombre de los usuarios finales para conectarse a un origen de datos. En la siguiente tabla se explica qué tipos de conectores puede suprimir el diálogo de consentimiento en una aplicación.

Nota

Si un administrador suprime el cuadro de diálogo de consentimiento, pero la plataforma no puede realizar el inicio de sesión único para un usuario final, el cuadro de diálogo se presentará al usuario cuando inicie la aplicación.

Tipo de conector	¿El cuadro de diálogo de consentimiento se puede suprimir?	Referencia
Conectores de Microsoft que admiten el inicio de sesión único (como SharePoint, Usuarios de Office 365)	Sí	cmdlet de administrador de Power Apps
Conector que accede a un servicio de partner no de Microsoft, como Salesforce	No	No aplicable
Conectores personalizados que usan OAuth con como proveedor de identidad de Microsoft Entra. Estos son conectores personalizados creados por organizaciones y solo los usuarios de dentro de la organización pueden acceder a ellos (por ejemplo, creado por Contoso solo para usuarios de Contoso)	Sí	Administrar conexiones

Microsoft Power Platform solo puede suprimir el diálogo de consentimiento para conexiones a orígenes de datos donde:

1. El origen de datos no tiene la obligación de mostrar una IU de consentimiento explícito.
2. El origen de datos preautoriza la entidad de servicio de conexiones de la API de Azure de Microsoft para habilitar el inicio de sesión único.
3. Un administrador configura una aplicación para suprimir el consentimiento de las conexiones anteriores.

La preautorización de la entidad de servicios de conexiones de la API de Azure de Microsoft existe para los orígenes de datos propios de Microsoft y puede configurarse mediante aplicaciones personalizadas registradas en un inquilino de Microsoft Entra que utilizan los conectores personalizados. Un administrador gestiona la supresión del consentimiento por aplicación (a diferencia de los conectores), por lo que la supresión se gestiona en el nivel de experiencia de la aplicación más granular: este nivel de granularidad evita que la supresión del consentimiento para las "aplicaciones aprobadas" de una organización suprima inadvertidamente el consentimiento para las aplicaciones que no están aprobadas o revisadas.