Problemes comuns de rendiment i resolucions d'aplicacions de llenç

Podeu crear aplicacions de llenç amb diverses fonts de dades. Trieu la font de dades i el connector en funció de les necessitats de negoci i dels escenaris per als quals dissenyeu l'aplicació. Per a les aplicacions empresarials, Microsoft Dataverse és el font de dades recomanat perquè proporciona diversos avantatges de rendiment. Per a les aplicacions amb poques transaccions, podeu anar amb qualsevol altre origen de dades disponible al vostre entorn.

Per tenir en compte el rendiment d'una aplicació, penseu en el nombre d'usuaris que utilitzaran l'aplicació quan s'hagi publicat; el volum de transaccions de creació, recuperació, actualització i supressió (CRUD); el tipus d'interaccions de dades, l'accés geogràfic i els tipus de dispositius que tenen els usuaris.

En aquest article us expliquem alguns dels problemes més habituals de rendiment que poden fer que les aplicacions del llenç s'executin lentament i com resoldre'ls. Aquesta informació us ajudarà a millorar el rendiment de l'aplicació amb el vostre pla de negoci i pensant en el creixement.

Començarem per alguns dels problemes habituals de rendiment que es poden produir independentment del connector que s'utilitzi. A les seccions posteriors, aprendreu sobre els problemes de rendiment i les resolucions específiques de diversos connectors.

Abans de començar, assegureu-vos que conegueu les fases d'execució de les aplicacions de llenç i del flux de trucada de dades. A més, llegiu Orígens habituals de rendiment lent per a una aplicació de llenç per conèixer els obstacles habituals que podeu evitar quan dissenyeu o actualitzeu les aplicacions del llenç.

Conjunts de dades grans que es carreguen lentament a diferents plataformes

El rendiment d'una aplicació pot variar quan es carreguen grans conjunts de dades en diferents plataformes, com ara iOS o Android. Aquesta variació es produeix a causa de diferents limitacions de sol·licitud de xarxa a cada plataforma. Per exemple, el nombre de sol·licituds de xarxa simultànies permeses pot ser diferent segons la plataforma. Aquesta diferència pot tenir un impacte important en el temps de càrrega de les dades per als conjunts de dades grans.

Us recomanem que carregueu només les dades que necessiteu visualitzar immediatament a la pantalla. Per a altres dades, pagineu i emmagatzemeu a la memòria cau les dades. Més informació: Consells i pràctiques recomanades per millorar el rendiment de l'aplicació de llenç

Massa columnes recuperades

Us recomanem que seleccioneu només les columnes que són necessàries per a l'aplicació. En afegir més columnes (o totes) de la font de dades, es baixen totes les dades de les columnes. Aquesta acció genera un gran nombre de trucades generals de xarxa i, per tant, un ús alt de memòria al dispositiu client. Aquest problema pot afectar encara més els usuarisis amb dispositius mòbils si l'amplada de banda de xarxa és limitada o si un dispositiu té una memòria limitada o un processador heretat.

Per exemple, si utilitzeu Dataverse com a font de dades de l'aplicació, assegureu-vos que heu habilitat la característica de selecció de columna explícita. Aquesta característica permet a Power Apps restringir la recuperació de dades només per a les columnes utilitzades a l'aplicació.

Per activar la característica de selecció de columna explícita a l'aplicació de llenç, aneu a Configuració > Pròximes característiques > Versió preliminar i activeu l'opció Selecció de columna explícita.

Navegadors incompatible o heretats

Els usuaris que utilitzen navegadors no compatibles o heretats poden experimentar problemes de rendiment. Assegureu-vos que els usuarisis només utilitzin navegadors compatibles per executar les aplicacions de llenç.

Rendiment lent a causa de la distància geogràfica

La ubicació geogràfica de l'entorn i la distància entre la font de dades i els usuaris finals pot afectar el rendiment.

Es recomana que l'entorn estigui ubicat a prop dels usuarisis. Tot i que el Power Apps utilitza la Xarxa de lliurament de contingut de l'Azure per al contingut, les trucades de dades continuen obtenint les dades de la font de dades. Una font de dades en una altra ubicació geogràfica pot afectar negativament el rendiment de l'aplicació.

Les distàncies geogràfiques excessives afecten el rendiment de diferents maneres, com ara per latència, menys rendiment, reducció de l'amplada de banda o pèrdua de paquets.

Llista permesa no configurada

Assegureu-vos que les URL de servei necessàries no s'hagin bloquejat o que s'hagin afegit a la llista permesa d'adreces del tallafoc. Per veure una llista completa de totes les adreces URL de servei que s'han de permetre al Power Apps, aneu a Serveis necessaris.

Ús de funcions que no es poden delegar i límit de files de dades inapropiat per a consultes no delegables

Les funcions delegables deleguen el processament de dades a la font de dades, i minimitzen la sobrecàrrega al client. Quan no és possible la delegació, podeu restringir el límit de la fila de dades de les consultes no delegables per tal que el nombre de files retornades d'una connexió basada en servidor sigui òptim.

L'ús de funcions no delegables i els límits de files de dades inapropiats per a les consultes no delegables afegeixen sobrecàrrega addicional a la transferència de dades. Aquesta sobrecàrrega resulta en la manipulació de les dades rebudes a la pila de JS al client. Assegureu-vos d'utilitzar funcions delegables per a l'aplicació sempre que estigui disponible i l'òptim límit de fila de dades per a consultes no delegables.

Més informació: Delegació de l'ús, Introducció a la delegació

Incidència OnStart ha d'ajustar-se

La incidència OnStart s'executa quan es carrega l'aplicació. Trucar a grans quantitats de dades mitjançant les funcions de la propietat OnStart de l'aplicació provocarà que l'aplicació es carregui lentament. Una pantalla amb gran dependència dels controls i els valors definits en una altra pantalla afectarà la navegació amb pantalla lenta.

Les seccions següents descriuen alguns dels problemes més habituals que s'experimenten en aquestes situacions.

Un nombre elevat de trucades a la incidència OnStart provoca que l'aplicació s'iniciï lentament

En una empresa, el volum de trucades de dades a una font de dades central por causar colls d'ampolla del servidor o la contenció de recursos.

Utilitzeu un mecanisme de la memòria cau per optimitzar les trucades de dades. Molts usuarisis poden utilitzar una única aplicació, cosa que fa que arribin múltiples trucades de dades per usuarisi als extrems del servidor. Aquestes trucades de dades poden ser un punt on es poden produir colls d'ampolla o limitacions.

Latència a la incidència OnStart a causa de seqüències d'ordres pesades

Les seqüències d'ordres des de la incidència OnStart són un dels errors més habituals en el disseny d'aplicacions de llenç. Només hauríeu d'obtenir les dades necessàries perquè l'aplicació s'iniciï.

Optimitzeu la fórmula en una incidència OnStart. Per exemple, podeu desplaçar algunes funcions a la propietat OnVisible. D'aquesta manera, podeu fer que l'aplicació s'iniciï ràpidament i els altres passos puguin continuar mentre s'obre l'aplicació.

Més informació: Optimitzar la propietat OnStart

Pressió de memòria al client

És important comprovar el consum de memòria d'una aplicació de llenç, perquè la majoria de les vegades l'aplicació s'executa en dispositius mòbils. Les excepcions de memòria a la pila són les causes més probables que hi ha darrere d'una aplicació del llenç que es bloqueja o congela en alguns dispositius.

Una pila de JavaScript (JS) pot arribar al límit perquè s'executen scripts pesats a la part del client per afegir, unir, filtrar, ordenar o agrupar columnes. En la majoria dels casos, una excepció de memòria esgotada a la pila del client pot fer que l'aplicació es bloquegi o pengi.

Quan utilitzeu dades dels orígens, com ara Dataverse o SQL Server, podeu utilitzar un objecte de Visualització per garantir que la integració, filtratge, agrupament o ordenació es produeix al servidor en comptes del client. Aquest mètode reduirà la sobrecàrrega del client a les seqüències d'ordres per a aquestes accions.

Si les operacions intensives del client, com ara JOIN o Agrupa per, s'han fet al client amb un conjunt de dades que té 2.000 registres o més, els objectes de la pila augmentaran i això farà que se superin els límits de la memòria.

Les eines per a desenvolupadors de la majoria dels navegadors us permeten definir la memòria. Us ajuda a visualitzar la mida de la pila, els documents, els nodes i els oients. Perfileu el rendiment de l'aplicació mitjançant un navegador, segons s'explica a Informació general de les eines per a desenvolupadors del Microsoft Edge. Comproveu els escenaris que excedeixin el llindar de memòria de la pila de JS. Més informació: Corregir problemes de memòria

Consideracions de rendiment per al connector de l'SQL Server

Podeu utilitzar el connector de l'SQL Server per al Power Apps per connectar-vos a un SQL Server local o a l'Azure SQL Database. Aquesta secció descriu els problemes comuns de rendiment i les resolucions per utilitzar aquest connector per a una aplicació de llenç. Més informació: Connectar amb l'SQL Server des del Power Apps, Crear una aplicació de llenç des de l'Azure SQL Database

Fem un cop d'ull als problemes i resolucions habituals del rendiment quan s'utilitza el connector de l'SQL Server per a les aplicacions de llenç.

Consulta N+1

Les galeries que generen massa sol·licituds als servidors causen problemes de consulta N+1. El problema de la consulta N+1 és un dels problemes més freqüents en utilitzar el control de Galeria.

Per evitar el problema, utilitzeu la visualització d'objectes a l'extrem de l'SQL o canvieu els escenaris de la interfície d'usuarisi.

Escanejat de taules en comptes de cerques d'índex

Una aplicació pot alentir si les funcions utilitzades per l'aplicació executen consultes a la base de dades que donen lloc a escanejos de taules en comptes de cerques d'índex. Més informació: Suggeriments, ANÀLISI de taules i cerca d'índex

Per resoldre aquests problemes, utilitzeu StartsWith en comptes d'IN a la fórmula. Amb una font de dades SQL, l'operador StartsWith genera una cerca d'índex, però l'operador IN genera un índex o un escaneig de taula.

Consultes lentes

Podeu perfilar i ajustar consultes i índexs lents a la base de dades SQL. Per exemple, si una fórmula obté certes dades en ordre descendent (DESC) en una columna determinada, aquesta columna d'ordenació hauria de tenir un índex amb ordre descendent. La clau d'índex crea un ordre ascendent (ASC) per defecte.

També podeu comprovar l'adreça URL de les sol·licituds de dades. Per exemple, el següent fragment de sol·licitud de dades (trucada d'OData parcial) demana a SQL que retorni 500 registres que coincideixin amb la columna Valor i l'ordre segons l'ID en ordre descendent.

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

Això ajuda a entendre els requisits de l'índex per cobrir condicions de sol·licitud similars. En aquest exemple, si la columna ID té un índex amb ordre descendent, la consulta es durà a terme més ràpidament.

Comproveu el pla d'execució de consultes lentes per veure si hi ha un escaneig de taula o índex. Superviseu tots els costos excessius de la consulta de clau al pla d'execució.

Més informació:

• Supervisar i ajustar per al rendiment
• Supervisar el rendiment mitjançant el magatzem de consultes
• Descripció general sobre les incidències ampliades

Contenció de recursos de base de dades

Assegureu-vos que la font de dades (la base de dades SQL) no té cap contenció de recursos, com ara colls d'ampolla del processador, contenció d'E/S, pressió de memòria o contenció tempDB. Comproveu també si hi ha bloquejos, esperes, interbloquejos i temps d'espera de la consulta.

Sol·licituds excessives o de clients gruixuts

Una aplicació que executa les operacions Agrupa per, Filtra per o JOIN al client utilitza el processador i els recursos de memòria dels dispositius client. Segons la mida de les dades, aquestes operacions poden tardar més temps en seqüències d'ordres al client, fet que fa que s'augmenti la mida de la pila JS al client. Aquest problema augmenta per a una font de dades local, perquè cada trucada de dades de cerca viatja a la font de dades per la passarel·la de dades.

En aquestes situacions, utilitzeu l'objecte Visualitza a la base de dades SQL per a les operacions GroupBy, Filter By o JOIN . Les visualitzacions poden utilitzar columnes selectives i eliminar columnes innecessàries amb tipus de dades grans, com ara NVARCHAR(MAX), VARCHAR(MAX) i VARBINAIRY(MAX).

Mida de les dades transferides al client

Per defecte, en una aplicació de llenç es mostren les dades amb les taules o les visualitzacions dels objectes de base de dades disponibles. Recuperar totes les columnes d'una taula pot tenir com a conseqüència una resposta lenta, especialment quan s'utilitzen tipus de dades grans, com ara NVARCHAR(MAX).

La transferència de grans quantitats de dades als clients trigarà una estona. Aquesta transferència també resulta en més temps d'escriptura de seqüències d'ordres quan hi ha grans quantitats de dades a la pila JS al client, tal com s'ha descrit anteriorment en aquest article.

Per reduir la mida de les dades que es transfereixen al client, utilitzeu les visualitzacions amb les columnes específiques necessàries per a l'aplicació i assegureu-vos que la selecció explícita de columnes s'ha habilitat, tal com s'ha descrit abans en aquest article.

Consideracions específiques de l'SQL Server local

El rendiment de les aplicacions de llenç que utilitzen el connector de l'SQL Server amb passarel·la de dades local pot veure's afectat de diverses maneres. En aquesta secció es detallen els problemes i les resolucions de rendiment habituals específics per utilitzar un origen local base de dades.

Passarel·la de dades local incorrecta

Les organitzacions poden definir diversos nodes per a passarel·les de dades local. Encara que un dels nodes no estigui disponible, les sol·licituds de dades al node incorrecte no tornaran el resultat dins d'un període de temps acceptable o causaran missatges d'error d'"inaccessible" després d'esperar una estona.

Assegureu-vos que tots els nodes de passarel·la de dades local estiguin bé i configurats amb una latència de xarxa mínima entre els nodes i la instància SQL.

Ubicació de la passarel·la de dades local

Una passarel·la de dades local crida les fonts de dades locals per interpretar les sol·licituds OData. Per exemple, la passarel·la de dades ha d'entendre l'esquema de la taula de dades per traduir les sol·licituds d'OData a instruccions de llenguatge de manipulació de dades (DML) SQL. S'afegeix una sobrecàrrega addicional quan la passarel·la de dades està configurada en una ubicació separada amb alta latència de xarxa entre la passarel·la de dades i la instància SQL.

En un entorn empresarial, es recomana tenir un clúster de passarel·la de dades escalable quan s'esperen sol·licituds de dades intensives. Comproveu el nombre de connexions que s'estableixen entre els nodes de comprovació de la passarel·la de dades i la instància SQL.

Mitjançant la comprovació de les connexions concurrents en una passarel·la de dades local o en una instància d'SQL Server, la vostra organització pot identificar el punt en què s'ha d'escalar la passarel·la de dades i amb quants nodes.

Escalabilitat de la passarel·la de dades

Si espereu accedir a un gran volum de dades de la passarel·la de dades local,, un sol node de la passarel·la de dades local pot convertir-se en un coll d'ampolla al tractar aquest volum de sol·licituds tan gran.

Un sol node de la passarel·la de dades local pot ser suficient per tractar 200 connexions concurrents o menys. Això no obstant, si totes aquestes connexions concurrents estan executant activament consultes, les altres sol·licituds acaben esperant una connexió disponible.

Per obtenir informació sobre com assegurar-vos que la vostra passarel·la de dades local s'escala d'acord amb el volum de dades i sol·licituds, aneu a Supervisar i optimitzar el rendiment de la passarel·la de dades local.

Consideracions específiques d'Azure SQL Database

Les aplicacions de llenç poden connectar-se a l'Azure SQL Database utilitzant el connector de l'SQL Server. La causa més habitual de problemes de rendiment quan s'utilitza l'Azure SQL Database és seleccionar el nivell erroni per a les vostres necessitats empresarials.

Azure SQL Database està disponible en diferents nivells de servei i ofereix capacitats d'emmagatzematge per complir amb diferents requisits empresarials. Per obtenir més informació sobre els nivells, aneu a la documentació d'Azure SQL Database.

Amb les sol·licituds de dades intensives, els recursos del nivell que seleccioneu poden limitar-se en arribar al valor llindar. Aquesta limitació compromet el rendiment del següent conjunt de consultes.

Comproveu el nivell de servei d'Azure SQL Database. Un nivell inferior tindrà algunes limitacions i restriccions. Des d'una perspectiva de rendiment, CPU, rendiment d'E/S i latència són importants. Per tant, us recomanem que comproveu el rendiment de la base de dades SQL periòdicament i comproveu si l'ús dels recursos supera el llindar. Per exemple, l'SQL Server local defineix normalment el llindar d'ús de CPU en un 75 per cent aproximadament.

Consideracions de rendiment per al connector del SharePoint

Podeu utilitzar el connector del SharePoint per crear aplicacions mitjançant les dades de les llistes de les llistes de Microsoft. També podeu crear aplicacions de llenç directament des de la visualització de llista. Fem un cop d'ull als problemes de rendiment i les resolucions habituals per utilitzar una font de dades del SharePoint amb aplicacions de llenç.

Massa columnes de cerca dinàmiques

El SharePoint admet diversos tipus de dades, incloses les consultes dinàmiques com Persona, Grup i Calculat. Si una llista defineix massa columnes dinàmiques, trigarà més temps a manipular aquestes columnes dinàmiques a SharePoint abans de tornar les dades al client que executa l'aplicació del llenç.

No abuseu de les columnes de cerca dinàmiques a SharePoint. Aquest abús pot tenir com a conseqüència una sobrecàrrega evitable addicional al SharePoint per a la manipulació de dades. En lloc d'això, podeu utilitzar columnes estàtiques per mantenir els àlies de correu electrònic o els noms dels usuarisis, per exemple.

Columna i fitxer adjunt d'imatge

La mida d'una imatge i un fitxer adjunt poden contribuir a una resposta lenta mentre es recuperen al client.

Reviseu la llista i assegureu-vos que només s'han definit les columnes necessàries. El nombre de columnes de la llista afecta el rendiment de les sol·licituds de dades. Això és perquè els registres coincidents o els registres fins als límits de fila de dades definits es recuperen i es tornen a transmetre al client amb totes les columnes definides a la llista (tant si l'aplicació les utilitza totes com si no).

Per consultar només les columnes utilitzades per l'aplicació, habiliteu la característica de selecció explícita de columnes, tal com s'ha descrit més amunt en aquest article.

Llistes grans

Si teniu una llista gran amb centenars de milers de registres, valoreu la possibilitat de particionar la llista o dividir-la en diverses llistes basant-vos en paràmetres com ara les categories o la data i l'hora.

Per exemple, les dades es poden emmagatzemar en llistes diferents d'una manera anual o mensual. En aquest cas, podeu dissenyar l'aplicació perquè un usuarisi pugui seleccionar un interval de temps i recuperar les dades d'aquest interval.

Dins d'un entorn controlat, la referència de rendiment ha demostrat que el rendiment de les sol·licituds d'OData en llistes de Microsoft o SharePoint està molt relacionat amb el nombre de columnes de la llista i el nombre de files que s'estan recuperant (limitat pel límit de files de dades per a les consultes no delegables). Tenir un menor nombre de columnes i establir el límit de files de dades en un valor més baix pot millorar el rendiment de l'aplicació de llenç.

Tanmateix, al món real, les aplicacions estan dissenyades per complir certs requisits empresarials. Pot ser que no sigui ràpid o senzill reduir el límit de files de dades o el nombre de columnes d'una llista. Tanmateix, es recomana supervisar les sol·licituds OData al client i ajustar el límit de files de dades per a les consultes no delegables i el nombre de columnes de la llista.

Consideracions del rendiment per utilitzar el Dataverse com a font de dades

Quan utilitzeu el Microsoft Dataverse com a font de dades, les sol·licituds de dades van directament a la instància de l'entorn, sense passar per la gestió de l'API de l'Azure. Més informació: Flux de trucades de dades en connectar-se al Microsoft Dataverse

Una aplicació de llenç connectada al Dataverse pot executar-se lentament si executa seqüències d'ordres intensives del client, com ara Filtra per o JOIN al client en comptes del servidor.

Utilitzeu visualitzacions de Dataverse quan sigui possible. Una visualització amb els criteris d'adhesió o de filtre necessaris ajuda a reduir la sobrecàrrega de l'ús d'una taula sencera. Per exemple, si heu d'unir taules i filtrar-ne les dades, podeu definir una visualització unint-les i definint només les columnes que necessiteu. A continuació, podeu utilitzar aquesta visualització a l'aplicació, que crea aquesta sobrecàrrega al servidor per a l'operació d'unió o filtre en lloc del client.Aquest mètode redueix no només les operacions addicionals, sinó també la transmissió de dades. Per obtenir informació sobre l'edició dels criteris de filtratge i d'ordenació, aneu a Edita els criteris de filtre.

Consideracions de rendiment per al connector de l'Excel

El connector de l'Excel proporciona connectivitat des d'una aplicació de llenç a les dades d'una taula d'un fitxer de l'Excel. Aquest connector té limitacions en comparació amb altres fonts de dades, com per exemple funcions delegables limitades, que permeten a l'aplicació de llenç carregar dades de la taula només fins a 2.000 registres. Per carregar més de 2.000 registres, particioneu les dades en diferents taules de dades com a altres orígens de dades.

Fem un cop d'ull als problemes i resolucions habituals del rendiment quan s'utilitza una font de dades de l'Excel amb aplicacions de llenç.

Massa taules de dades i mides de dades grans

La lentitud d'una aplicació es pot experimentar quan utilitza un fitxer de l'Excel amb massa taules de dades, o taules de dades que tenen una quantitat de dades immensa en diverses columnes. Un fitxer de l'Excel no és una base de dades relacional ni una font de dades que proporcioni funcions delegables. El Power Apps ha de carregar primer les dades de les taules de dades definides i, a continuació, utilitza funcions com ara Filtra, Ordena, JOIN, Agrupa per i Cerca.

Tenir massa taules de dades amb moltes files i columnes afecta el rendiment de l'aplicació i la sobrecàrrega del client, ja que cada taula de dades s'ha de manipular dins de la pila JS. Aquest efecte també fa que l'aplicació consumeixi més memòria de client.

Per garantir que l'aplicació no es veu afectada per aquest problema, definiu només les columnes que necessiteu a la taula de dades d'un fitxer de l'Excel.

Transaccions intensives

L'Excel no és un sistema de base de dades relacional. L'Excel gestiona els canvis des d'una aplicació de la mateixa manera que quan un usuarisi canvia les dades d'un fitxer de l'Excel. Si l'aplicació té un nombre elevat de lectures, però menys operacions CRUD, pot tenir un bon rendiment. No obstant això, si l'aplicació fa transaccions intensives, pot afectar adversament el rendiment de l'aplicació.

No hi ha cap valor llindar específic per al nombre de transaccions, ja que també depèn de les dades que es manipulen. Diversos aspectes més també afecten el rendiment de l'aplicació, com ara la sobrecàrrega de la xarxa o el dispositiu de l'usuarisi.

Si teniu dades només de lectura, podeu importar aquestes dades a l'aplicació localment en comptes de carregar-les des del font de dades. Per a les aplicacions empresarials, utilitzeu orígens de dades de Dataverse, com ara SQL Server o SharePoint.

Mida del fitxer

Podeu triar entre moltes opcions d'emmagatzematge al núvol que tenen diverses capacitats d'emmagatzematge configurables per al fitxer de l'Excel. Tanmateix, tenir un únic fitxer d'Excel gran amb totes les taules definides afegeix una sobrecàrrega addicional per a l'aplicació mentre es baixa el fitxer i es llegeixen les dades per carregar-les al client.

En lloc d'utilitzar un fitxer gran, dividiu les dades en diversos fitxers d'Excel amb les taules de dades mínimes. Connecteu-vos a cadascun dels fitxers quan el necessiteu. D'aquesta manera, la càrrega de les dades de la taula de dades es produeix en fragments, i es redueix la sobrecàrrega de tenir moltes taules o un conjunt de dades gran.

Ubicació del fitxer

La ubicació geogràfica de la font de dades i la seva distància de les ubicacions del client poden donar lloc a un coll d'ampolla de rendiment per a l'aplicació i induir la latència de xarxa. Aquest efecte es pot amplificar quan un client mòbil té un amplada de banda limitada per a la connectivitat.

És millor conservar el fitxer a prop dels usuarisis (o de la majoria d'usuarisis, en cas de públic global) per tal que el fitxer es pugui baixar ràpidament.

Passos següents

Consells i pràctiques recomanades per millorar el rendiment de les aplicacions de llenç

Consulteu també

Informació sobre les fases d’execució i el flux de trucades de dades de les aplicacions de llenç
Orígens habituals de rendiment lent per a una aplicació de llenç
Problemes comuns i solucions per al Power Apps
Solució de problemes d'inici del Power Apps