Compartir a través de


Usar el servidor SQL con aplicaciones de lienzo

SQL Server es una solución ampliamente utilizada para almacenar datos empresariales. Este artículo ofrece los mejores procedimientos recomendados para ayudarlo a crear y publicar una aplicación de lienzo de nivel empresarial con SQL Server.

Sugerencia

Este artículo proporciona un escenario de ejemplo y una representación visual de cómo usar SQL Server con una aplicación de lienzo. Esta solución es una arquitectura de ejemplo generalizada, que se puede utilizar para muchos escenarios y sectores diferentes. SQL Server y Power Apps admiten muchos enfoques de autenticación heredados. Este artículo se limita a los procedimientos recomendados.

Diagrama de arquitectura

Diagrama de arquitectura que muestra el flujo de trabajo para usar SQL Server con aplicaciones de lienzo.

Flujo de trabajo

Si bien muchas implementaciones anteriores de Power Apps con SQL Server usaban una puerta de enlace, esta arquitectura de ejemplo resalta la arquitectura de red privada virtual (VNET) con SQL Server. Una instancia de SQL Server puede ser Azure SQL o una base de datos SQL local expuesta a la nube mediante Azure Arc. En ambos casos, la comunicación es privada y segura.

  • Contoso VNET es una red privada virtual que el usuario crea en su inquilino.
  • Los recursos de Azure recursos de Contoso son recursos que usted pone a disposición en la red virtual desde dentro de su inquilino. Estos recursos incluyen servicios como una base de datos SQL de Azure o una base de datos SQL Server local disponible a través de Azure Arc.
  • La subred delegada se encuentra dentro de su red virtual y proporciona un contenedor para Power Platform para permitir que servicios como el conector SQL o un complemento de Dataverse funcionen con sus recursos.

Componentes

Esta sección describe los componentes que admiten la integración de SQL Server con aplicaciones de lienzo en esta arquitectura.

Aplicación de lienzo y tablas SQL

Las tablas y vistas de SQL Server aparecen en Power Apps como orígenes de datos tabulares. Puede vincular un origen de datos tabulares a la propiedad Items de tabla o galería mediante una expresión de Power Fx. Para los orígenes de datos tabulares, las expresiones Power Fx se traducen en expresiones OData, que luego se convierten en expresiones SQL. Sin embargo, OData y Power Fx no representan por completo todas las capacidades de una expresión SQL.

Sugerencia

Use Power Fx para consultas básicas y directas, y utilice procedimientos almacenados para expresiones SQL más complejas.

Aplicación de lienzo y procedimientos almacenados de SQL

Los procedimientos almacenados de SQL Server aparecen en Power Apps como orígenes de datos de acción. Normalmente, los orígenes de datos de acción no se pueden enlazar a una tabla o galería debido a sus posibles efectos secundarios. Sin embargo, puede marcar un select stored procedure como Safe for Tables and Galleries y usarlo con tabla o galería. Este enfoque recupera todos los datos que devuelve el procedimiento almacenado, pero tenga cuidado porque recuperar demasiados datos puede saturar la memoria del cliente. Para controlar la cantidad de datos recuperados, utilice los argumentos de paginación de parámetros que normalmente están presentes en este tipo de procedimientos almacenados.

Además, establezca los resultados en una variable Power Fx y use esta variable en la propiedad Items para completar la tabla o galería. Recuerde actualizar la variable de Power Fx en las operaciones de crear, actualizar y eliminar (CAE). Los procedimientos almacenados más complejos, como los que utilizan tablas temporales, podrían devolver un dynamic schema. Puede utilizar los resultados de estos procedimientos almacenados estableciendo los resultados esperados en un User defined type de Power Fx.

Conector de SQL Server de

Las aplicaciones Power Apps utilizan el conector de SQL Server para acceder a los datos en SQL Server. Si bien hay muchos tipos de autenticación SQL disponibles, Microsoft Entra ID y el SPN (nombre principal del servicio) compartible son dos de las mejores opciones.

Si desea utilizar Microsoft Entra ID, primero configure la base de datos de SQL Server para proporcionar seguridad a través de Microsoft Entra ID. El SPN compartible es un método de acceso habilitado por el administrador y debe concederse con cuidado, ya que todos los usuarios tienen los mismos derechos de acceso a la base de datos. Está protegido con conexiones implícitas seguras, que restringen el acceso a las tablas y acciones utilizadas en la aplicación (es decir, Get, Post, Put y Delete).

VNET (red privada virtual)

Hay varias formas de enrutar llamadas a SQL Server. La red virtual es una solución en la nube de Azure que hace que todos los puntos de conexión sean privados. Para implementarlo, aprovisione una red virtual dentro de su inquilino, configure la directiva empresarial y configure su entorno de Power Platform para respaldarla. Esta configuración garantiza que ningún tráfico SQL quede expuesto públicamente a través de la red.

ALM (administración del ciclo de vida de la aplicación)

Power Platform admite la transición fluida de una aplicación Power Apps sobre SQL entre entornos de desarrollo, prueba y producción. Las referencias de conexión permiten cambiar las cadenas de conexión entre entornos, lo cual es importante para la autenticación SQL básica. Las variables de entorno facilitan el escenario de Microsoft Entra ID al cambiar el servidor y la base de datos entre entornos.

Casos de uso

Power Apps proporciona a las organizaciones una manera flexible e intuitiva de crear experiencias de usuario personalizadas.

  • Si está creando una nueva aplicación y almacenamiento, considere usar Dataverse. Sus características se han diseñado para facilitar la creación de aplicaciones de nivel empresarial.
  • Si tiene datos en SQL Server que no se pueden mover, o su organización requiere SQL Server, considere usar Power Apps en lugar de SQL Server.
  • Si no se pueden mover los datos, utilice Power Apps sobre SQL Server. Las aplicaciones existentes aún dependen de esos datos, por lo que es necesario trasladarlas a la nube para modernizarlas.

Consideraciones

Estas consideraciones implementan los pilares de Buena arquitectura de Power Platform, un conjunto de principios rectores que mejoran la calidad de una carga de trabajo. Obtenga más información en Buena arquitectura de Microsoft Power Platform.

Confiabilidad

Diseñe su carga de trabajo para evitar complejidad innecesaria: Power Apps funciona bien con consultas sencillas que puede delegar al servidor. Delegue tareas complejas a vistas y procedimientos almacenados. Luego, utilice esos procedimientos almacenados directamente para acciones sincrónicas. Use Power Automate para cualquier acción asincrónica, incluidas las llamadas a procedimientos almacenados de ejecución prolongada.

Seguridad

Utilice conexiones implícitas seguras: utilice conexiones implícitas seguras para todas las conexiones compartidas. Convierta cualquier aplicación más antigua para utilizar conexiones implícitas seguras según sea necesario. Con conexiones implícitas seguras, el conector permanece dentro del servicio de nube de Power Apps y no se encuentra en el cliente. La aplicación se conecta únicamente al conector proxy, que también está en el servicio en la nube de Power Apps. La aplicación y el conector proxy se conocen entre sí; sin embargo, la aplicación no conoce el conector. El conector proxy tiene una directiva que restringe los tipos de consultas a las consultas en la aplicación.

Diagrama de arquitectura que ilustra cómo los componentes de conexión compartidos implícitamente se relacionan entre sí.

Cree segmentación y perímetros intencionales: utilice entornos de Power Platform independientes para las etapas del ciclo de vida de la aplicación y asegúrese de que solo los usuarios adecuados tengan acceso a cada etapa para admitir las directivas de segmentación.

Excelencia operativa

Adopte prácticas de implementación seguras: estandarice la implementación de cualquier cambio en la aplicación Power Apps mediante procesos de implementación automatizados, como canalizaciones. Promocione la aplicación a producción solo después de probar esos cambios.

Eficiencia en el rendimiento

Diseño para cumplir con los requisitos de rendimiento: evalúe el rendimiento de su solución y los requisitos de volumen de datos para garantizar que el diseño de sus tablas, vistas y procedimientos almacenados de SQL Server sea adecuado. En su evaluación, incluya cómo se accede a los datos y cómo Power Apps delega operaciones a SQL Server. Tenga en cuenta las limitaciones al buscar y filtrar datos debido al soporte de delegación que ofrece SQL Server. Revise las limitaciones documentadas para las aplicaciones de lienzo en Comprender la delegación, en particular al elegir el origen de datos o el backend adecuados para su aplicación.

Optimizar la lógica: las aplicaciones de lienzo utilizan Power Fx para ejecutar el trabajo. Cada operación de Power Fx es independiente y no se gestione como una transacción atómica. Por ejemplo, si una aplicación crea una fila de detalles de pedido de venta, pero no crea un registro de encabezado de pedido de venta, la fila de detalles de pedido de venta permanece. No salga de estos pasos de procedimiento obligatorios en Power Fx. Utilice procedimientos almacenados de SQL Server con soporte para transacciones.

Optimización de la experiencia

Diseño para la eficiencia: las aplicaciones que permiten a los usuarios acceder a otros orígenes de datos junto con las tablas de SQL Server desde una única aplicación Power Apps, sin necesidad de interactuar con varias aplicaciones individuales, mejoran la eficiencia y proporcionan una mejor experiencia visual personalizada. Evite crear una aplicación para crear una aplicación: la aplicación debe ofrecer cierta eficiencia al usuario u otro beneficio de arquitectura en comparación con el uso de una experiencia de Power Apps basada en modelos.

Power Apps:

Conectores:

Administración del ciclo de vida de la aplicación (ALM):