Udostępnij za pośrednictwem

Używanie interfejsu API REST do rozszerzania funkcjonalności aplikacji kanwy

Microsoft Power Platform umożliwia rozszerzenie funkcjonalności aplikacji kanwy Power Apps używając REST API. Kiedy mamy do czynienia ze złożonymi algorytmami lub wieloma źródłami danych, funkcje Azure stają się idealnym wyborem, aby pomóc utrzymać proste formuły w Power Apps przy jednoczesnym przeniesieniu bardziej złożonej funkcjonalności po stronie serwera. Power Platform Łączniki niestandardowe umożliwiają aplikacjom kanwa korzystanie z interfejsu API REST tak samo jak innego źródła danych.

Wskazówka

Artykuł zawiera przykładowy scenariusz i wizualną reprezentację sposobu korzystania z interfejsów API REST w celu rozszerzenia funkcjonalności aplikacji kanwa. To rozwiązanie jest uogólnioną przykładową architekturą scenariusza, która może być używana dla wielu różnych scenariuszy i branż.

Wykres architektury

Diagram architektury ilustrujący przepływ pracy przy użyciu interfejsów API REST w celu rozszerzenia funkcjonalności aplikacji kanwa

Przepływ

  1. Aplikacja kanwy: # Power Apps aplikacja kanwy używa łącznika niestandardowego do uzyskiwania dostępu do operacji uwidocznionych przez funkcję Azure. Użytkownik uwierzytelnia się w aplikacji przy użyciu identyfikatora Entra, a dostęp do danych jest ograniczony do danych, do których użytkownik ma dostęp.
  2. Łącznik niestandardowy: łącznik niestandardowy opisuje, jakich operacji aplikacja może używać z interfejsu API REST, który w przykładzie jest implementowany przez funkcję Azure. Korzystając z łącznika niestandardowego, aplikacja # Power Apps kanwa może używać logiki jak każdego innego źródła danych.
  3. Microsoft Entra Aplikacje ID: Funkcja Azure jest zabezpieczona za pomocą Microsoft Entra aplikacji ID. Druga Microsoft Entra aplikacja identyfikatora jest zarejestrowana i skonfigurowana w łączniku niestandardowym, aby umożliwić Power Apps aplikacja kanwy dostęp do operacji funkcji Azure.
  4. Azure Funkcja: Funkcja Azure implementuje interfejs API RESTful oferujący co najmniej jedną operację, która jest uwidoczniona w Power Apps aplikacji kanwa przez wyeksportowanie łącznika niestandardowego z portalu Azure lub przez konfigurację ręczną. Funkcja Azure jest zabezpieczona rejestracją aplikacji Entra ID, aby zapewnić tylko autoryzowane wywołania.
  5. Azure Cosmos DB: Funkcja Azure może używać Azure Cosmos DB or Azure SQL lub dowolnego innego magazynu danych w chmurze, którego wymaga do zarządzania danymi. Właściwie funkcja może pracować z danymi w Microsoft Dataverse użyciu podejścia funkcyjnego ze względu na złożoność logiki.

Elementy

  • Power Platform environment: zawiera Power Platform zasoby, takie jak te, które implementują Power Apps środowisko użytkownika aplikacji w sklepie. Zasoby te są przenoszone z jednego środowiska do innego (np. od Dev do Test) przy użyciu Dataverse rozwiązań.
  • Power Apps: Power Apps służy do implementacji środowiska użytkownika rozwiązania. Twórcy mogą budować aplikację przy użyciu łącznika niestandardowego utworzonego przez dewelopera funkcji Azure jako źródła danych aplikacji.
  • Łącznik niestandardowy: Power Platform łączniki niestandardowe opisują operacje i struktury danych interfejsu API RESTful. Pozwalają one na łatwe korzystanie z interfejsu API z zasobów takich jak aplikacja Power Apps kanwa. Używane z Power Apps umożliwiają odwoływanie się do interfejsu API jak do każdego innego źródła danych.

Szczegóły scenariusza

Power Apps umożliwia organizacjom tworzenie niestandardowego środowiska użytkownika, a przy użyciu interfejsów API REST logika biznesowa jest scentralizowana i dostępna dla aplikacji przy użyciu łącznika niestandardowego. Takie podejście może również pozwolić Power Apps aplikacji działać jako integrator wielu usług zaplecza, zapewniając użytkownikowi pojedynczy widok danych i logiki ze wszystkich źródeł. Korzystając z podejścia REST API, możesz również przenieść złożoność interakcji z wieloma innymi systemami do komponentu implementującego REST API i uprościć implementację aplikacji kanwa, jednocześnie zapewniając to samo doświadczenie użytkownika.

W powyższym przykładzie aplikacja W sklepie jest tworzona przy użyciu Power Apps aplikacji kanwa. Aplikacja umożliwia sprzedawcy sklepowemu szybkie zapisanie żądania powiadomienia o zaległym zamówieniu dla klienta, gdy towar jest niedostępny. Aplikacja używa pojedynczej operacji RecordBackorder, która jest skonfigurowana w łączniku niestandardowym, który opisuje operację funkcji zaplecza Azure. W tym przykładzie funkcja Azure jest implementacją interfejsu API REST. Do zaimplementowania tego wzorca można użyć dowolnej technologii, która umożliwia utworzenie usługi RESTful.

Ta architektura oferuje elastyczność, ale oznacza również, że potrzeba więcej pracy programisty, aby rozwinąć i utrzymać usługi sieciowe i warstwę danych. Ogólnie rzecz biorąc, wraz ze wzrostem złożoności aplikacji, powinieneś mocno rozważyć ten typ architektury. Na przykład, gdy wiele źródeł danych jest potrzebnych do zbudowania pojedynczego widoku, zalecamy użycie warstwy API, aby dostarczyć wydajne doświadczenie, ponieważ odpowiedź danych może być kształtowana po stronie serwera i dostarczana do klienta bardziej efektywnie. Użycie tej warstwy pośredniej oznacza, że możesz dodać warstwę cache'owania po stronie serwera i zaimplementować bogatszą telemetrię dla aplikacji.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary Power Platform dobrze zaprojektowanego środowiska, czyli zestaw założeń przewodnich, które poprawiają jakość zadania. Dowiedz się więcej w Microsoft Power Platform artykule Dobrze zaprojektowane środowisko.

Niezawodność

Zaprojektuj swoją pracę, aby uniknąć niepotrzebnej złożoności– Korzystanie z podejścia REST API z Power Apps aplikacji za pośrednictwem niestandardowego łącznika pozwala uniknąć niepotrzebnej złożoności, a także centralizowanie logiki, w której może być używana przez inne aplikacje w organizacji. Łącznik niestandardowy umożliwia Power Apps Maker korzystanie z operacji z interfejsu API RESTFul jak każdej innej operacji źródła danych.

Przetestuj odporność i dostępność – Przenosząc logikę z aplikacja canvas do interfejsu API REST, powinieneś być w stanie niezależnie przetestować interfejs API niezależnie od aplikacji, która go używa.

Mierz i publikuj wskaźniki kondycji — dane telemetryczne powinny być przechwytywane ze składnika interfejsu API REST, aby śledzić jego kondycję. Na przykład użycie Azure Monitor – rejestrowanie zapewni Application Insights odpowiednie śledzenie komponentu.

Zabezpieczenia

Stwórz celową segmentację i granice: Używaj oddzielnych środowisk Power Platform dla poszczególnych etapów cyklu życia aplikacji i upewnij się, że tylko odpowiedni użytkownicy mają dostęp do każdego etapu, aby wspierać zasady segmentacji. Ważne jest również, aby zarejestrowane aplikacje Entra ID były oddzielone między środowiskami, aby zachować ochronę każdego etapu danych i nie mieszać się między środowiskami.

Doskonałość operacyjna

Zastosuj bezpieczne rozwiązania wdrażania: Standaryzuj wdrażanie wszelkich zmian w aplikacji Power Apps przy użyciu zautomatyzowanych procesów wdrażania, takich jak potoki. Podwyższ poziom aplikacji do wersji produkcyjnej dopiero po przetestowaniu zmian.

Zaimplementuj strategię ograniczania niepowodzeń wdrażania– W przypadku zależności między aplikacją a interfejsem API REST należy upewnić się, że masz przetestowaną strategię ograniczania wdrażania któregokolwiek z nich, które powoduje błędy po zaktualizowaniu jednego ze składników.

Efektywność wydajności

Projektuj, aby spełnić wymagania dotyczące wydajności: Oceń wymagania dotyczące wydajności rozwiązania i ilości danych, aby upewnić się, że projekt tabeli jest odpowiedni. Ocena powinna obejmować sposób uzyskiwania dostępu do danych oraz ocenę, w jaki sposób Power Apps bezpośrednie korzystanie z różnych źródeł danych może być zbyt często komunikujące się ze źródłami danych. Może to spowodować spowolnienie wydajności z powodu opóźnienia pojedynczego żądania wysyłanego do każdego magazynu danych. Jeśli na przykład aplikacja miała logikę, która działała w dużej liczbie wierszy w źródle danych, możesz być w stanie przesunąć cały ten ruch sieciowy do funkcji zaplecza Azure. Ograniczenie do pojedynczej interakcji z interfejsem API REST, który z kolei zarządzałby interakcją z wieloma innymi źródłami danych, w których można to zrobić bardziej efektywnie.

Zoptymalizuj logikę – W miarę jak logika staje się coraz bardziej złożona w usłudze aplikacja kanwy, funkcje Azure lub podobnych implementacjach interfejsu API RESTful zaplecza może odciążyć tę logikę do centralnej, wielokrotnie używanej usługi. Użycie funkcji łącznika niestandardowego do opisania tych interfejsów API RESTful umożliwia aplikacjom kanwa używanie skonfigurowanych operacji jak każdego innego źródła danych.

Wydajność testowa– Wraz z testowaniem funkcjonalności i niepowodzeń ważne jest, aby przetestować i opracować punkt odniesienia dla wydajności oraz ocenić go w ramach cyklu wydania, jeśli interfejs API jest wrażliwy na zmiany w czasach ukończenia pracy.

Optymalizacja środowiska

Projektuj pod kątem wydajności – Aplikacje, które umożliwiają użytkownikom dostęp do wielu źródeł danych z jednej Power Apps aplikacji bez konieczności interakcji z wieloma indywidualnymi aplikacjami, sprawiają, że użytkownik jest bardziej wydajny i dobrze wykorzystują bardziej niestandardowe wrażenia wizualne.

Współautorzy

Microsoft utrzymuje ten artykuł. Artykuł został napisany przez następujących autorów.

Główni autorzy: