Razumijevanje faza izvršavanja aplikacije od gotovih gradivnih elemenata, tijeka podatkovnih poziva i praćenja performansi
Kada korisnik otvori aplikaciju od gotovih gradivnih elemenata, ona prolazi kroz nekoliko faza izvršavanja prije prikazivanja bilo kojeg korisničkog sučelja. Dok se aplikacija učitava, povezuje se s različitim izvorima podataka—kao što su SharePoint, Microsoft Dataverse, SQL Server (lokalno), Azure SQL baza podataka (na mreži), Excel i Oracle.
U ovom ćete članku saznati više o tim različitim fazama izvršavanja i načinu na koji se aplikacija povezuje s izvorima podataka te o alatima koje možete koristiti za praćenje performansi.
Faze izvršavanja u aplikacijama od gotovih gradivnih elemenata
Aplikacija od gotovih gradivnih elemenata prolazi kroz sljedeće faze izvršavanja prije nego što korisniku pokaže sučelje:
Autentifikacija korisnika : Traži od korisnika koji se prvi put prijavljuje da se prijavi vjerodajnicama za sve veze koje aplikacija treba. Ako taj korisnik ponovo otvori aplikaciju, možda se od te osobe ponovo to zatraži, ovisno o sigurnosnim politikama tvrtke ili ustanove.
Dohvati metapodatke: Dohvaća metapodatke poput verzije platforme Power Apps na kojoj aplikacija radi i izvore iz kojih mora dohvatiti podatke.
Inicijaliziraj aplikaciju: Izvršava zadatke opisane u svojstvu OnStart.
Prikaz zaslona: prikazuje prvi zaslon kontrolama koje aplikacija popunjava podacima. Ako korisnik otvori druge zaslone, aplikacija ih prikazuje istim postupkom.
Tijek podatkovnih poziva u aplikacijama od gotovih gradivnih elemenata
Podatkovni pozivi iz aplikacija od gotovih gradivnih elemenata šalju podatke u tablične izvore podataka pomoću poveznika preko OData protokola. OData zahtijeva protok do pozadinskih slojeva kako bi kontaktirao ciljnu izvor podataka i dohvatio podatke za klijenta ili predao podatke izvor podataka. Konektori temeljeni na akcijama koji omogućuju API-je rade na isti način.
Razumijevanje načina na koji OData i API zahtjevi putuju u aplikacijama od gotovih gradivnih elemenata može vam pomoći da optimizirate performanse aplikacije od gotovih gradivnih elemenata i pozadinske izvore podataka.
U ovom ćete odjeljku saznati kako podatkovni poziv teče u aplikacijama od gotovih gradivnih elemenata s različitim vrstama izvora podataka.
Tijek podatkovnog poziva putem mrežnih izvora podataka
Sljedeći dijagram prikazuje kako uobičajeni zahtjev za podatke u aplikaciji od gotovih gradivnih elemenata (lijeva strana) putuje slojevima na strani poslužitelja i dopire do ciljnog izvora podataka (desna strana), a zatim vraća podatke klijentu.
Svaki sloj u gornjem dijagramu mogao bi se brzo izvoditi ili imati neke indirektne troškove tijekom obrade zahtjeva. U mnogim aplikacijama dva određena mjesta mogu često predstavljati primjetne indirektne troškove:
Pozadinski izvor podataka tijekom obrade zahtjeva.
Klijent tijekom slanja zahtjeva—ili tijekom manipuliranja primljenim podacima u memoriji hrpe i izvršavanja pridruženih JavaScript funkcija za obradu podataka za prikaz na zaslonima.
Tijek podatkovnih poziva s lokalnim pristupnikom za podatke
Ako se aplikacija od gotovih gradivnih elemenata poveže s lokalnim izvorom podataka poput SQL poslužitelja, trebate imati drugi sloj koji se naziva lokalni pristupnik za podatke. Ovaj je pristupnik obvezan za pristup lokalnim izvorima podataka. Preuzima pretvorbu zahtjeva OData protokola u SQL DML (Data Manipulation Language) izjavama.
Sljedeći dijagram prikazuje gdje i kako je lokalni pristupnik za podatke postavljen radi obrade zahtjeva za podacima.
Ako aplikacija koristi izvor podataka lokalno, mjesto i specifikacija pristupnika za podatke također će utjecati na izvedbu podatkovnih poziva.
Tijek podatkovnog poziva s Microsoft Dataverse
Kada koristite Microsoft Dataverse kao izvor podataka, zahtjevi za podacima idu izravno u instancu okruženja—bez prolaska kroz Upravljanje API-jevima servisa Azure. Zbog toga je izvedba podatkovnih poziva brža u usporedbi s ostalim izvorima podataka. Aplikacija je prema zadanim postavkama povezana s Microsoft Dataverse kada stvorite novu aplikaciju od gotovih gradivnih elemenata.
Razumijevanjem ovog koncepta na visokoj razini i načina na koji putuju podatkovni pozivi, možete ući u pojedinosti pregleda izvedbe vaše aplikacije. Ukratko, indirektni troškovi izvedbe mogu se dogoditi na bilo kojem od slojeva—od klijenta, APIM-a (Upravljanje API-jem), poveznika, lokalnog pristupnika za podatke i pozadinskih izvora podataka.
Mjerenje performansi
Power Apps Alat za nadzor
Iako možete koristiti alate za razvojne programere preglednika da biste vidjeli performanse, Power Apps postavlja skup poziva u alatu za praćenje samo na one koji jesu Power Apps.
Alat Power Apps za praćenje može vam pomoći u praćenju onoga što se zapravo šalje izvor podataka i vremenskim oznakama kada se zahtjevi šalju, a odgovori dolaze s poslužitelja.
Više o alatu za praćenje možete saznati u ovom članku: Ispravljanje pogrešaka aplikacija od gotovih gradivnih elemenata pomoću monitora .
Mjerenje memorijskog tlaka na klijentu
Da biste grafički vidjeli potrošnju memorije, možete koristiti alate za razvojne inženjere za preglednik za profiliranje memorije. Pomoći će vam vizualizirati veličinu snopa, dokumente, čvorove i osluškivače. Profilirajte izvedbu aplikacije pomoću preglednika, kao što je opisano u pregledu Microsoft Edge alata za razvojne programere (Chromium). Provjerite scenarije koji premašuju prag memorije JS snopa. Dodatne informacije: Rješavanje problema s memorijom
Sljedeći koraci
Pogledajte
Otklanjanje poteškoća za Power Apps
Napomena
Možete li nam reći više o željenim jezicima za dokumentaciju? Ispunite kratki upitnik. (imajte na umu da je upitnik na engleskom jeziku)
Ispunjavanje upitnika će trajati otprilike sedam minuta. Osobni podaci se ne prikupljaju (izjava o zaštiti privatnosti).