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.

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 paginan automáticamente más datos de la misma manera que lo hacen para las tablas. Por ejemplo, si vincula una acción a una galería, recuperará el primer conjunto o página de registros. 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. Debe gestionar esto directamente con las colecciones.

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

Patch
Collect
Update

Nota

Para trabajar con un esquema dinámico, puede utilizar una característica experimental llamada esquema dinámico. Esquema dinámico se refiere a la posibilidad de que la misma acción pueda devolver una tabla diferente con columnas diferentes. Las condiciones que pueden hacer que las columnas en las tablas 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. Para trabajar con un esquema dinámico, la documentación del conector muestra Las salidas de esta operación son dinámicas. como valor de devolución. Para obtener más información sobre cómo trabajar con un esquema dinámico en Power Apps, vea trabajar con esquemas dinámicos en Power Apps (experimental)

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 Azure AD 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 Azure Active Directory.

Azure Active Directory (AAD)

Este es un tipo de conexión seguro. 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 Azure AD 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.

Nota

Power Apps aún no admite formalmente los tipos de autenticación de Service Principal. Para obtener más información, consulte Métodos de autenticación que usan Azure Active Directory.

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, debe proporcionar su nombre de usuario y 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, 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.

Autenticación de la contraseña y el nombre de usuario de SQL.

Este tipo de conexión no es segura porque no depende de la autenticación del usuario final. Solo debe usarse en casos en los que pueda asumir con seguridad que todos los que tienen acceso a esta conexión pueden ver y usar todos los datos a los que la conexión proporciona acceso. No puede bloquear de manera confiable partes de los datos accesibles dentro de la conexión. Por ejemplo, si la conexión permite el acceso a una sola tabla, no puede confiar en un userID para filtrar y mostrar solo los datos de ese usuario específico dentro de esa tabla. Para una seguridad confiable, use una conexión más segura como integrado en Azure AD.

En SQL Server, este tipo de conexión se llama 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. Están utilizando el nombre de usuario y la contraseña que usted proporciona cuando crea la aplicación. La autenticación de conexión al origen de datos se comparte implícitamente con sus usuarios. Tan pronto como se publique la aplicación, la conexión también se publicará y estará disponible para sus usuarios. Sus usuarios finales también pueden crear aplicaciones utilizando cualquier conexión que use la autenticación de SQL Server que se comparte con ellos. Sus usuarios no pueden ver el nombre de usuario o la contraseña, pero la conexión estará disponible para ellos. Existen escenarios válidos para este tipo de conexión. Por ejemplo, si tiene una base de datos de solo lectura que está disponible para todos en la empresa. Los escenarios de datos de referencia (por ejemplo, un calendario corporativo) pueden ser útiles para este tipo de conexión. Más información: Usar Microsoft SQL Server de forma segura con Power Apps

Conexiones implícitas seguras (versión preliminar)

[Esta sección es documentación preliminar y está sujeta a modificaciones].

Power Apps ahora tiene soporte completo de vista previa para Conexiones implícitas seguras. La configuración predeterminada para esta característica es Activado. Las conexiones compartidas implícitas seguras son más seguras que las conexiones implícitas existentes. Las conexiones implícitamente compartidas de Power Apps son las que usan una credencial fija, como una cadena de conexión de SQL Server, en lugar de las credenciales específicas del usuario final, como AAD. Con esta función, las conexiones ya no se comparten directamente con los usuarios de Power Apps. En su lugar, se comparte un objeto de conexión de proxy que solo otorga acceso al recurso subyacente, como una tabla de servidor SQL específica. Los usuarios finales autores no pueden crear nuevas aplicaciones ni con la conexión ni con la conexión proxy. Esta función también limita al usuario final a acciones como get, put/patch y eliminar que están definidos en la aplicación correspondiente. El resultado es que los usuarios finales que también son autores no pueden crear nuevas aplicaciones ni con el objeto de conexión ni con el de conexión de proxy.

Nota

Conexiones implícitas seguras está ahora Activado de forma predeterminada para las nuevas aplicaciones.

Notificación para actualizar tus aplicaciones

Si tiene aplicaciones que pueden actualizarse para usar esta función, verá un mensaje en la página de aplicaciones. Indica la cantidad de aplicaciones que necesitan su atención.

Seleccione el enlace y se abre un panel lateral que enumerará 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. Vea las indicaciones a continuación.

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

Abra una aplicación existente abierta para editar con conexiones compartidas de forma implícita que se haya publicado anteriormente:

1. Seleccione Configuración > Próximas características en la barra de comandos.
2. En la pestaña Vista previa, cambie Conexiones implícitas seguras a Activado.
3. Guarde y publique la aplicación.

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 que haya compartido la aplicación, consulte 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 X se eliminará el acceso del usuario a la conexión.

  

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

Cuando su aplicación se vuelve a publicar y compartir, los usuarios finales no tendrán acceso a la conexión, pero trabajarán con la conexión de proxy oculta. No podrán crear una nueva aplicación basada en su 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 de forma implícita sigue presente mientras se encuentra en la versión preliminar privada. 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. Hay 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. Esto 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 aplicaciones que utilizan el conector Usuarios de Office 365, este podría ser el siguiente.

   • Esta aplicación puede:
     • Leer su perfil de usuario completo
     • Leer el perfil completo de todos los usuarios
   • No podrá:
     • 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)?

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 propios 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 terceros que no es de Microsoft, como Salesforce	No	No aplicable
Conectores personalizados que usan OAuth con Azure Active Directory como proveedor de identidad. 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 Azure AD 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.

Nota

¿Puede indicarnos sus preferencias de idioma de documentación? Realice una breve encuesta. (tenga en cuenta que esta encuesta está en inglés)

La encuesta durará unos siete minutos. No se recopilan datos personales (declaración de privacidad).