Modernizacja aplikacji przy użyciu Power Platform

W dzisiejszym szybko zmieniającym się krajobrazie cyfrowym organizacje stoją przed ciągłym wyzwaniem modernizacji starszych aplikacji, aby nadążyć za zmieniającymi się potrzebami biznesowymi. Modernizacja aplikacji ma kluczowe znaczenie dla poprawy wydajności operacyjnej, poprawy jakości obsługi klienta i wyprzedzenia konkurencji. Microsoft Power Platform oferuje kompleksowy zestaw narzędzi i technologii, które umożliwiają firmom szybkie i skuteczne przekształcanie i modernizowanie aplikacji.

Ten oficjalny dokument analizuje korzyści, strategie i najlepsze praktyki modernizacji aplikacji za pomocą Microsoft Power Platform. Zawiera szczegółowe informacje i wskazówki dotyczące sposobu, w jaki platforma niskokodowa Microsoft może pomóc w zapewnieniu powodzenia działań związanych z modernizacją aplikacji w ramach transformacji cyfrowej organizacji.

Wskazówka

Możesz zapisać lub wydrukować ten oficjalny dokument przez wybranie pozycji Drukuj w przeglądarce, a następnie wybranie pozycji Zapisz jako plik PDF.

Wprowadzenie

Starsze aplikacje stawiają wiele wyzwań przed organizacjami. Aplikacje te są często zbudowane na przestarzałych stosach technologicznych i frameworkach, co utrudnia ich integrację z nowoczesnymi systemami i narzędziami. Często mają one ograniczenia skalowalności i wydajności, które utrudniają organizacji obsługę rosnących obciążeń i wymagań klientów. Starszym aplikacjom brakuje elastyczności i zwinności, co ogranicza ich zdolność do szybkiego dostosowywania się do zmieniających się potrzeb biznesowych i dynamiki rynku. Luki w zabezpieczeniach, wysokie koszty utrzymania, ograniczone możliwości integracji i ryzyko uzależnienia od dostawcy dodatkowo potęgują wyzwania związane ze starszymi aplikacjami. Aby im sprostać, organizacje muszą zmodernizować swoją infrastrukturę aplikacji, aby korzystać z nowych technologii.

Funkcje projektowania niiskokodowego na platformie Microsoft Power Platform umożliwiają tworzenie i wdrażanie nowoczesnych aplikacji szybciej i efektywniej niż kiedykolwiek wcześniej. Łatwo integruj istniejące systemy i źródła danych, aby zapewnić bezproblemową wymianę danych i współpracę. Dodaj sztuczną inteligencję, aby poprawić wrażenia użytkowników, zautomatyzować procesy i uzyskać cenny wgląd w dane. Niezależnie od tego, czy jesteś deweloperem obywatelskim majstrującym przy brzegach sieci, czy profesjonalnym deweloperem pracującym nad złożonym dostosowaniem, możesz przeprowadzić transformację cyfrową intuicyjnie, szybko i przy niższych kosztach niż w przypadku tradycyjnych podejść.

Dlaczego Power Platform?

Kompleksowe narzędzia i technologie wchodzące w skład Power Platform znacznie skracają czas trwania, obniżają koszty i zmniejszają wymagania rozwojowe projektów modernizacji i transformacji cyfrowej. Podejście niskokodowe zmniejsza — a nawet może wyeliminować — potrzebę kosztownego kodowania, nauki o danych i zasobów inżynieryjnych AI. Korzystają na tym zarówno deweloperzy obywatelscy, jak i profesjonalni programiści. Deweloperzy obywatelscy mogą odgrywać aktywną rolę w procesie modernizacji, tworząc aplikacje bezpośrednio w oparciu o swoją wiedzę specjalistyczną i zmniejszając zależność od zespołów IT. Profesjonalni programiści mogą dostarczać nawet złożone rozwiązania w znacznie krótszym czasie, dzięki czemu mogą szybciej przejść do następnego projektu.

Power Platform – produkty i koncepcje

Każdy produkt z rodziny Power Platform ma unikalny obszar zainteresowania. Organizacje mogą wdrażać produkty pojedynczo lub w połączeniu, aby spełnić swoje specyficzne wymagania. Produkty są ze sobą połączone, tworząc spójną całość, niezależnie od tego, jak są połączone.

Poniższa tabela zawiera ogólny przegląd każdego produktu Power Platform.

Product	Podpis
Power Apps	Twórz niestandardowe aplikacje na intuicyjnej kanwie typu "przeciągnij i upuść". Dzięki ponad tysiącowi konektorów wewnętrzne i zewnętrzne źródła danych i usługi są dostępne za pomocą zaledwie kilku kliknięć. Twoje aplikacje mogą działać w przeglądarce, na komputerze lub na urządzeniach mobilnych.
Power Automate	Twórz przepływy pracy, aby zautomatyzować nawet złożone procesy. Włączanie wewnętrznych i zewnętrznych źródeł danych oraz usług przy użyciu wbudowanych i niestandardowych łączników. Cyfrowej automatyzacji procesów (DPA) należy używać, gdy aplikacje mają interfejs programowania aplikacji (API). Użyj robotyzacji procesów biznesowych (RPA), aby zautomatyzować powtarzalne zadania wykonywane w przeglądarce lub aplikacji desktopowej. Przepływy pracy można wyzwalać w przypadku zdarzeń występujących w innych systemach i usługach lub zaplanowanych do pracy o określonej godzinie.
Copilot Studio	Tworzenie agentów konwersacyjnych przy użyciu niekodowanego interfejsu graficznego. Możesz wdrażać agentów w wielu kanałach, w tym w witrynach internetowych, aplikacjach mobilnych i platformach do przesyłania wiadomości, takich jak Microsoft Teams. Tworzenie treści wspomagane przez AI może przyspieszyć tworzenie tematów. Odpowiedzi generatywne mogą znajdować i prezentować informacje z wielu źródeł bez konieczności tworzenia tematów.
Power BI	Przeciągnij wykresy, tabele i inne wizualizacje na kanwę, aby łatwo tworzyć zaawansowane raporty, które odkrywają wglądy ukryte w twoich danych. Uwzględnij zautomatyzowane uczenie maszynowe na potrzeby modelowania predykcyjnego i wizualizacji AI z drzewami dekompozycji, aby uzyskać szczegółowe analizy głównych przyczyn. Eksploruj dane, zadając pytania w języku naturalnym w prostym formacie pytań i odpowiedzi.
Power Pages	Szybko twórz atrakcyjne, oparte na danych witryny internetowe na bezpiecznej, niskokodowej platformie SaaS (Software as a Service) klasy korporacyjnej. Dzięki bogatym, konfigurowalnym szablonom i płynnemu środowisku wizualnemu tworzenie, hostowanie i administrowanie nowoczesnymi, zewnętrznymi witrynami biznesowymi jest łatwiejsze.

Rodzina produktów Power Platform opiera się na kilku pomocniczych możliwościach i koncepcjach. W poniższej tabeli opisano najważniejsze z nich, które należy zrozumieć.

Pojęcie	Podpis
Power Fx	Power Fx to niskokodowy język typu open source inspirowany formułami programu Excel. Silnie typowany, deklaratywny i funkcjonalny, z imperatywną logiką i zarządzaniem stanem, a wszystko to wyrażone w przyjaznym dla człowieka tekście, Power Fx sprawia, że typowe zadania programistyczne są łatwe zarówno dla programistów obywatelskich, jak i profesjonalnych. Umożliwia pełnej wersji projektowania z bez konieczności wykorzystywania kodu dla osób, które nigdy wcześniej nie zostały zaznajomione z pracą w środowisku koderskim, co umożliwia zespołom współpracę oraz pozwala zaoszczędzić czas i koszty.
Łączniki	Łączniki są niezbędne, aby umożliwić współpracę kodowania niskokodowego i tradycyjnego w celu dostarczania nowoczesnych aplikacji. Konektory to otoczka wokół interfejsu API, która umożliwia Power Apps i Power Automate korzystanie z wewnętrznych i zewnętrznych źródeł danych i usług. Dostępnych jest ponad tysiąc gotowych konektorów i można tworzyć własne dla dowolnego interfejsu API RESTful. Definicja łącznika zawiera niezbędne metadane, aby ułatwić korzystanie z interfejsu API aplikacjom z małą ilością kodu.
Dataverse	Dataverse to hybrydowy magazyn danych w skali chmury zbudowany na usługach zarządzania danymi Azure, ale to coś więcej niż baza danych. Jest to podstawowa platforma danych zarówno dla Dynamics 365, jak i Power Platform, z logiką po stronie serwera w postaci przepływów pracy i wtyczek, reguł biznesowych i przepływów procesów, wysoce wyrafinowanym modelem bezpieczeństwa oraz rozszerzalną platformą programistyczną z wbudowaną obsługą aplikacji wielojęzycznych i wielowalutowych. Aplikacje można szybko konstruować na podstawie modelu danych, co sprawia, że jest to jeden z najszybszych sposobów wdrażania rozwiązania oparte na formularzach i danych.
AI Builder	AI Builder ułatwia korzystanie ze sztucznej inteligencji w usługach Power Apps i Power Automate w celu znajdowania szczegółowych informacji w danych, automatyzacji procesów i zwiększania produktywności aplikacji. Dzięki AI Builder nie potrzebujesz umiejętności kodowania ani nauki o danych, aby uzyskać dostęp do mocy AI. Wstępnie utworzone modele, które można dostosowywać, są gotowe do użycia w wielu typowych scenariuszach biznesowych, a ponadto można tworzyć własne modele, aby spełnić określone potrzeby biznesowe.
Copilot	Pomoc sztucznej inteligencji Copilot sprawia, że użytkownicy i programiści Power Platform, zarówno obywatele, jak i profesjonaliści, są bardziej produktywni, dzięki czemu mogą poświęcić więcej czasu na najlepsze części swojej pracy, a mniej na przyziemne zadania. Opisz swój scenariusz biznesowy Copilotowi w Power Automate, a on przekształci Twój opis w zautomatyzowany przepływ pracy. Powiedz Copilot w Power Apps, co chcesz zrobić lub jakie informacje chcesz zobaczyć, a on może zbudować dla Ciebie aplikację. Copilot konfiguruje połączenia, tworzy i wypełnia tabele, generuje ekrany, a nawet oferuje sugestie dotyczące ulepszenia przepływu lub aplikacji. Aplikacje będą miały wbudowane środowiska oparte na usłudze Copilot od pierwszego ekranu, dzięki czemu użytkownicy będą mogli odkrywać szczegółowe informacje podczas konwersacji.
Rozwiązania i środowiska	Środowiska to granice, które zawierają i ułatwiają zarządzanie i zabezpieczanie zasobów Power Platform. Są one również używane w zarządzaniu cyklem życia aplikacji (ALM), w którym rozwiązania są opracowywane i testowane w oddzielnych środowiskach przed wdrożeniem w środowisku produkcyjnym. Rozwiązania są pakietami dostosowań i rozszerzeń Power Platform. Rozwiązanie może zawierać aplikacje, przepływy, tabele, wykresy, pulpity nawigacyjne, łączniki i inne składniki wymagane przez dostosowanie lub rozszerzenie. Rozwiązania mogą być opracowywane, testowane i wdrażane do produkcji w oddzielnych środowiskach w ramach polityki ALM organizacji. Możesz eksportować rozwiązania, aby udostępniać je innym użytkownikom lub organizacjom, a także importować rozwiązania od innych osób. Rozwiązania są zarządzane lub niezarządzane. Rozwiązania niezarządzane są używane do rozwoju i testowania. Rozwiązania zarządzane są używane do wdrażania i dystrybucji produkcyjnej.

Najważniejsze korzyści Power Platform dot. modernizacji aplikacji

Korzyści płynące z modernizacji aplikacji przy użyciu Microsoft Power Platform wykraczają poza początkową wartość biznesową posiadania rozwiązania wykorzystującego nowoczesne technologie.

• Niższe koszty. Organizacje mogą zaoszczędzić pieniądze na tworzeniu i utrzymaniu aplikacji. Badanie przeprowadzone na zlecenie przez Forrester Consulting wykazało, że organizacje korzystające z Power Platform mogą odnotować 45-procentowy spadek kosztów rozwoju aplikacji i uzyskać 140-procentowy zwrot z inwestycji.

• Rozszerz pulę zasobów i wyeliminuj wąskie gardła. Profesjonalni programiści, analitycy danych i inżynierowie AI są wysoko opłacani i bardzo poszukiwani. Małe i średnie organizacje często nie mogą sobie pozwolić na luksus posiadania własnej wiedzy w zakresie kodowania, a outsourcing jest kosztowny. Niskokodowa platforma Power Platform jest bardziej dostępna dla większej puli zasobów. Eksperci merytoryczni i pracownicy posiadający wiedzę na temat procesów biznesowych mogą przyspieszyć modernizację, nawet jeśli nigdy nie napisali ani jednego wiersza kodu.

• Zbuduj wózek, a nie koło. Tradycyjne tworzenie oprogramowania zaczyna się za każdym razem od nowa, odkrywając koło na nowo z każdym nowym projektem. Dzięki niskokodowym, intuicyjnym i przyjaznym dla twórców produktom Power Platform możesz skupić się na budowaniu lepszego wózka - usprawniając procesy biznesowe - i szybciej cieszyć się korzyściami płynącymi z wysiłków modernizacyjnych.

• Zmniejsz dług technologiczny. Koszty – zarówno finansowe, jak i związane z utraconymi możliwościami – związane z modernizacją "szybkich i brudnych" rozwiązań programowych oraz utrzymaniem starszej infrastruktury są wysokie. Power Platform zmniejsza ten dług techniczny, ułatwiając i obniżając koszty tworzenia rozwiązań już za pierwszym razem, upraszczając integrację danych i zarządzanie nimi za pomocą wspólnego modelu danych i łączników, zapewniając scentralizowaną platformę do zarządzania rozwiązaniami oraz wspierając ciągłe doskonalenie dzięki analityce i sztucznej inteligencji.

• Zwiększ bezpieczeństwo i zapewnij zgodność. Wszystkie produkty Power Platform zawierają w pełni zintegrowane zabezpieczenia, zgodność i zarządzanie klasy korporacyjnej, począwszy od środowisk, w których działają. Managed Environments to zestaw narzędzi, które pozwalają administratorom zarządzać Power Platform na dużą skalę, z większą kontrolą i mniejszym nakładem pracy. Między innymi możesz ograniczyć, kto może udostępniać przepływy i aplikacje oraz komu, a także używać zasad, aby ograniczyć łączniki, których mogą używać twórcy. Natywne, elastyczne modele zabezpieczeń danych oznaczają, że każda aplikacja nie musi tworzyć własnych.

• Modernizuj na bieżąco. Im ważniejsze są aplikacje, które chcesz zmodernizować, tym mniej prawdopodobne jest, że chcesz je wszystkie zastąpić jednocześnie. Podejście niskokodowe dobrze nadaje się do tworzenia rozwiązań w zarządzalnych etapach.

• Integracja starszych aplikacji. Starsze aplikacje często nie mają interfejsów API. Możliwości RPA Power Platform mogą zautomatyzować klasyczne aplikacje i uwzględnić je w nowych, nowoczesnych procesach biznesowych. RPA może być również pomocna w przyrostowym modernizowaniu dużych i złożonych aplikacji.

• Wprowadzaj innowacje, nie wydając więcej. Możliwości Power Platform stale się poprawiają. Aplikacje zbudowane na platformie korzystają z innowacji Microsoft bez dodatkowych kosztów.

• Zwiększ produktywność pracowników w nowoczesnym miejscu pracy. Power Platform jest częścią nowoczesnego miejsca pracy Microsoft. Aplikacje zmodernizowane na platformie mogą wykorzystywać możliwości Microsoft 365, w tym angażujące środowiska mobilne i łatwą, intuicyjną współpracę. Najnowocześniejsza sztuczna inteligencja, taka jak Copilot, AI Builder i funkcje, które wkrótce zostaną ogłoszone, sprawiają, że użytkownicy i programiści są bardziej produktywni przy mniejszej frustracji i płytszej krzywej uczenia się.

Innowacje dla pracowników pierwszej linii

Pracownicy pierwszej linii potrzebują nowoczesnych aplikacji, z których mogą korzystać na dowolnym urządzeniu i w dowolnym miejscu, w którym pracują. Potrzebują dostępu do szczegółowych informacji w czasie rzeczywistym, aby szybciej podejmować lepsze decyzje. Muszą współpracować ze współpracownikami i kierownictwem, aby wszystko działało sprawnie. Kiedy American Airlines zdecydowały się zmodernizować aspekty swojej działalności, dostały to wszystko i jeszcze więcej.

We współpracy z Microsoft, American Airlines stworzyły ConnectMe, aplikację Microsoft Teams stworzoną na bazie Power Apps oraz Azure. Korzystając z aplikacji na dowolnym urządzeniu mobilnym, zespoły pierwszej linii mają kluczowe informacje o przylocie, wejściu na pokład, bagażu i bramkach na wyciągnięcie ręki w czasie rzeczywistym, usprawniając operacje naziemne, przyspieszając czas zwrotów samolotów i sprawiając, że podróż jest przyjemniejsza dla klientów. Dowiedz się więcej o transformacji linii lotniczej.

Możliwości AI dla pracowników umysłowych

Pracownicy umysłowi pływają w oceanie danych i zbyt często mają wrażenie, że toną. Prawie wszystkie aplikacje zbierają dane. Niewiele z nich pomaga użytkownikom zrozumieć gromadzone dane, nie mówiąc już o wyciąganiu wniosków, które mogą pomóc pracownikom lepiej wykonywać swoją pracę. W ramach modernizacji można dodać do aplikacji funkcje sztucznej inteligencji, które nie tylko automatyzują zbieranie i analizę danych, ale także ułatwiają pracownikom wiedzy dostrzeganie wzorców i trendów. Analiza predykcyjna może wykorzystywać modele sztucznej inteligencji do prognozowania przyszłych wyników na podstawie danych historycznych z dużą dokładnością, umożliwiając liderom planowanie z pewnością. Zmodernizowane aplikacje mogą obejmować pomocnik AI, działając jako partner do generowania treści w kontekście — podsumowując wywiady, przygotowując ukierunkowane komunikaty marketingowe i sprzedażowe, a nawet oferując przydatne informacje w czasie rzeczywistym, gdy przedstawiciel obsługi klienta lub sprzedawca rozmawia przez telefon z klientem.

Stopniowa podróż do modernizacji starszych aplikacji

Jeśli Twoja organizacja jest podobna do większości, masz rosnące zaległości przestarzałych aplikacji, które skorzystałyby na modernizacji. Starsze aplikacje zazwyczaj korzystają z przestarzałej technologii i są zbudowane na infrastrukturze — sprzęcie i oprogramowaniu — która nie jest już obsługiwana. Często tylko nieliczni pracownicy, zwykle ci zbliżający się do emerytury, wiedzą, jak one działają. Nowi pracownicy nie chcą mieć z nimi nic wspólnego, ponieważ nie mogą korzystać z nowoczesnych narzędzi, do których są przyzwyczajeni lub z którymi chcą pracować. Ich utrzymanie, nie mówiąc już o ich aktualizacji, wymaga zdobycia góry technicznego długu, który rośnie tym wyżej, im bardziej się wspinasz. Lata, a może dekady patchworkowej konserwacji skutkują bazą kodu, której nikt nie ośmiela się dotknąć — zwłaszcza gdy polega na niej znaczna część firmy.

Organizacje często nie są w stanie łatwo zastąpić wszystkich tych aplikacji jednocześnie. Zamiast tego rozpoczynają proces stopniowej modernizacji. Podejście przyrostowe maksymalizuje korzyści płynące z modernizacji, jednocześnie łagodząc niektóre zagrożenia związane z jednorazową modernizacją.

Opcje modernizowania aplikacji

Modernizacja nie zawsze oznacza odbudowę starszej aplikacji od podstaw. Inne opcje to wycofanie go, zastąpienie, ponowne hostowanie, refaktoryzacja i zmiana architektury.

W poniższej tabeli opisano każdą opcję, etap zarządzania cyklem życia aplikacji (ALM), kiedy jest najbardziej odpowiedni, oraz czynniki, które mogą mieć wpływ na jego wybór.

Koniec wykorzystania

Migracja

Modernizacja

Wycofaj

Replace

Ponownie hostuj

Refaktoryzuj

Ponownie strukturyzuj

Ponownie skompiluj

Podpis

Usuń aplikację

Zastąp inną aplikacją lub aplikacją SaaS

Ponowne wdrażanie w chmurze w takiej postaci, w jakiej się znajduje

Optymalizowanie istniejącego kodu

Przenoszenie kodu do nowej architektury aplikacji lub dzielenie go na mikrousługi

Przepisywanie aplikacji od podstaw z oryginalnym zakresem i specyfikacjami

Sterowniki

Nie jest już potrzebny

Zmniejsz wydatki

Zmniejsz wydatki kapitałowe

Korzystaj z nowszych technologii

Zmniejsz wydatki kapitałowe

Odzyskiwanie miejsca do przechowywanych danych

Szybki zwrot z inwestycji w chmurę

Szybsze, krótsze aktualizacje

Bardziej przenośny kod

Większa wydajność chmury pod względem zasobów, szybkości i kosztów

Popraw wydajność

Zmniejszenie długu technologicznego

Poprawa skalowalności, niezawodności i łatwości konserwacji

Łatwiejsze wdrażanie nowych możliwości chmury

Mieszanie stosów technologicznych

Przyspieszenie innowacji

Przyspieszenie rozwoju

Zmniejszenie kosztów operacyjnych

Technologie Microsoft

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

Kontenery

Azure PaaS

Power Platform

Azure PaaS

Mikrousługi bezserwerowe

Power Platform

Azure PaaS

Mikrousługi bezserwerowe

W poniższej tabeli zasugerowano sposoby, w jakie podejście niskokodowe może być stosowane do każdej z opcji modernizacji aplikacji.

Opcja	Podpis
Ponownie hostuj	Ponowne hostowanie przenosi aplikację w niezmienionej postaci ze starszego środowiska do nowszego. Podejście niskokodowe nie ma zastosowania bezpośrednio, ale ponowne hostowanie może być pierwszym krokiem przed zastosowaniem innych strategii, które obejmowałyby rozwiązania niskokodowe.
Refaktoryzacja lub zmiana architektury	Refaktoryzacja dostosowuje kod, aby aplikacje mogły jak najlepiej korzystać ze środowiska opartego na chmurze. Zmiana architektury znacząco modyfikuje kod. Może to obejmować hermetyzację istniejącej logiki przez przeniesienie jej do interfejsu API, który można uwidocznić w rozwiązaniach niskokodowych za pośrednictwem łącznika.
Wymiana lub przebudowa	Zamiana polega na wymianie jednej aplikacji na inną. Ponowne kompilowanie powoduje ponowne utworzenie aplikacji od podstaw. Ta opcja jest często stosowana w sytuacji, gdy podejście niskokodowe pozwala osiągnąć najlepsze wyniki biznesowe. Rozpoczęcie od aplikacji z Dynamics 365 lub Microsoft AppSource może pomóc w szybkim rozpoczęciu modernizacji, gdy przypadek użycia pasuje do wstępnie zbudowanej funkcji. Organizacje mogą następnie korzystać z komponentów Power Platform, aby dostosować aplikację do swoich unikalnych potrzeb.

Niskokodowe podejście Power Platform może zaoferować znacznie więcej niż tylko kolejne narzędzie programistyczne. Włączenie małej ilości kodu do strategii nowoczesnych aplikacji może również stanowić podstawę do umożliwienia osobom niebędącym deweloperami, takim jak eksperci w danej dziedzinie, udziału w pracach modernizacyjnych. Organizacje odkryły, że ustanowienie Centrum Doskonałości (CoE) wokół Power Platform i korzystanie z narzędzi takich jak CoE Starter Kit do tworzenia wytycznych i zarządzania pomaga użytkownikom skutecznie tworzyć aplikacje i automatyzacje o niskim kodzie oraz zapewnia ponowne wykorzystanie zasobów, takich jak interfejsy API i komponenty. Niskokodowe oprogramowanie może przyspieszyć tworzenie aplikacji i pomóc organizacjom w szybszym wydobywaniu wartości z danych, niezależnie od tego, gdzie się znajdują. W rzeczywistości wiele organizacji decyduje się na zintegrowanie niskokodowego sposobu myślenia ze swoją kulturą.

Przewodnik po twojej ścieżce modernizacji

Łatwo jest poczuć się przytłoczonym, gdy zaczniesz myśleć o modernizacji starszych aplikacji. Przewodnik może pomóc Ci zaplanować podróż i utrzymać Cię na właściwej ścieżce po drodze. Dobrym miejscem do rozpoczęcia jest wykonanie tych trzech kroków, biorąc pod uwagę każdy z nich z nastawieniem na niskopoziomowe kodowanie.

1. Planowanie. Zastanów się dokładnie nad celami modernizacji starszej aplikacji i zdefiniuj strategię ich osiągnięcia. Miej jasne określenie problemu, który chcesz rozwiązać modernizacją. Jest to czas na ocenę aplikacji i środowisk pod kątem tego, co nie działa, co działa, ale można je ulepszyć, oraz — co najważniejsze — jaka wartość dla firmy lub użytkowników wynika z wszelkich zmian. Oceń każdą możliwość modernizacji pod kątem jej potencjału do skorzystania z podejścia niskokodowego. Określaj priorytety możliwości, które zawierają rozwiązania niskokodowe. Użyj narzędzia Cloud Adoption Strategy Evaluator, aby opracować uzasadnienie biznesowe modernizacji aplikacji.

2. Implementacja. Modernizuj swoje aplikacje nie tylko przyrostowo, ale iteracyjnie. Podejście iteracyjne daje organizacjom elastyczność w zakresie zmiany zakresu lub strategii projektu w zależności od potrzeb. Rozwiązania niskokodowe Power Platform można opracowywać i testować szybciej niż tradycyjnie tworzone aplikacje, a wdrożenie w środowiskach zarządzanych wymaga zaledwie kilku kroków. Chociaż niskokodowe wymaga mniej umiejętności niż tradycyjne kodowanie, upewnij się, że Twoi pracownicy są odpowiednio przeszkoleni w zakresie pracy w zespołach fuzyjnych, które łączą zasoby niskokodowe i tradycyjne.

3. Operacje. Modernizacja aplikacji nie kończy się na wdrożeniu. Dzięki niskokodowemu podejściu opartemu na chmurze możesz używać usług i narzędzi platformy w chmurze do zabezpieczania aplikacji, nadzorowania ich, zarządzania nimi i optymalizowania ich.

Ocena możliwości dla rozwiązań niskokodowych

Organizacje używają różnych metod, od nieformalnego przeglądu po szczegółowe drzewa decyzyjne, aby określić, czy podejście niskokodowe jest właściwym sposobem modernizacji starszej aplikacji. Najważniejszą rzeczą do rozważenia jest to, że low-code nie jest decyzją typu "wszystko albo nic". Powszechne jest budowanie części aplikacji z komponentów Power Platform, a części z komponentów opracowanych przy użyciu tradycyjnych technik kodowania.

Aby ocenić aplikację, zalecamy najpierw ustalenie, czy jest ona nadal potrzebna i przydatna, czy też powinna zostać wycofana. Jeśli zdecydujesz, że jest ona nadal potrzebna, oceń, czy rozwiązanie niskokodowe może zastąpić aplikację jako całość. Jeśli cała aplikacja nie nadaje się do zastąpienia małą ilością kodu, oceń, czy co najmniej jedno obciążenie lub składnik aplikacji może być. Może się okazać, że rozwiązanie niskokodowe rozszerzone o tradycyjnie opracowany kod zapewnia to, co najlepsze z obu światów.

Na przykład, jeśli stwierdzisz, że aplikacja nie jest dobrze dopasowana, ponieważ w Power Apps brakuje wymaganej kontrolki, możesz użyć Power Apps component framework (PCF) i tradycyjnego kodu do zbudowania niestandardowej kontrolki. Innym przykładem jest aplikacja, która ma złożoną logikę. Logikę można scentralizować w interfejsie API, do którego Power Apps może uzyskać dostęp za pomocą niestandardowego łącznika. W obu tych przykładach rozszerzalność Power Platform pozwoliła na zbudowanie większości aplikacji z komponentów o niskim kodzie, wypełniając luki w tradycyjnie opracowanym kodzie.

NSure.com, zastrzeżona internetowa platforma zakupów ubezpieczeń, oferuje przykład ze świata rzeczywistego. Początkowe uruchomienie firmy opierało się na tradycyjnie opracowanych usługach Angular, Xamarin i Azure. Dodając Power Platform i Dynamics 365, NSure.com stworzył rozwiązanie nowej generacji, wykorzystując zarówno niskokodowe, jak i tradycyjne techniki kodowania, co ilustruje poniższy diagram. Dowiedz się więcej o ścieżce firmy.

Równie ważne jak identyfikacja możliwości niskokodowych jest rozpoznanie, kiedy podejście niskokodowe nie jest właściwe. W poniższych tabelach opisano przypadki użycia, które często nie pasują do rozwiązań niskokodowych. Organizacje stoją przed różnymi wyzwaniami na froncie i zapleczu, więc rozważmy je osobno.

Scenariusze frontonu, które nie pasują do podejścia niskokodowego

Scenariusz	Wyzwanie
Urządzenie użytkownika nie jest zgodne	Power Platform rozpoznaje urządzenia mobilne i urządzenia specjalistyczne, takie jak skanery kodów kreskowych. Urządzenia, które zależą od określonych interfejsów API lub sterowników, mogą nie być obsługiwane i wymagają bardziej tradycyjnego podejścia.
Duża ilość danych po stronie klienta	Doświadczenie użytkownika w niektórych aplikacjach wymaga dużych ilości danych, co jest wyzwaniem dla każdej technologii, nie tylko niskokodowej. Pobieranie i przetwarzanie tak dużej ilości danych może obciążać systemy zaplecza i obniżać wydajność zarówno aplikacji, jak i urządzenia, na którym działa. Użytkownicy nie są tak produktywni, gdy są zmuszeni do poruszania się po morzu danych. Zanim przejdziesz do tradycyjnych metod kodowania, aby poradzić sobie z obciążeniem, sprawdź, czy odpowiednie filtrowanie i nawigacja mogą zapewnić lepsze wrażenia użytkownika.
Złożone wymagania dotyczące trybu offline	Aplikacje, które muszą działać w miejscach, w których łączność jest słaba lub nie istnieje, mogą być trudne do zaimplementowania i obsługi, niezależnie od tego, czy używają kodu niskokodowego, czy tradycyjnego. Power Apps oferuje podstawowe możliwości dla prostych scenariuszy offline. Na przykład aplikacja, która przechwytuje potencjalnych klientów podczas wydarzenia i przesyła ich do marketingowej bazy danych po wydarzeniu, będzie działać dobrze. W przypadku aplikacji, które wymagają plików i obrazów, łącznikami nie-Dataverse lub złożonego rozwiązywania konfliktów, należy zapoznać się z tradycyjnymi technikami kodowania.

Scenariusze zaplecza, które nie pasują do podejścia niskokodowego

Scenariusz	Wyzwanie
Dane o dużej prędkości przepływu	Importowanie milionów wierszy danych w ramach migracji i podobnych zdarzeń jest często obsługiwane. Jednak obciążenia, które obejmują przetwarzanie milionów wierszy danych co godzinę lub codziennie, powinny podlegać większej ocenie. Na przykład gromadzenie dużych ilości danych telemetrycznych Internetu rzeczy (IoT) w Dataverse nie miałoby sensu. Zamiast tego usługi w chmurze Azure mogłyby być wykorzystywane do gromadzenia i analizowania danych oraz odpowiednich sygnałów dodawanych do Dataverse w celu wyzwalania akcji w aplikacji. Aplikacje, które wymagają dużej ilości aktualizacji danych Dataverse regularnie mogą wymagać pomocy tradycyjnego kodu do skalowania aktualizacji.
Obciążenia w tle ze złożoną logiką	Obciążenia w tle, które obejmują złożoną logikę lub dużą liczbę wywołań interfejsu API, mogą nie być odpowiednie dla rozwiązania z małą ilością kodu. Zamiast tego logikę można scentralizować w interfejsie API, który może wywołać rozwiązanie z małą ilością kodu.
Interfejsy API korzystające z protokołów innych niż RESTful	Łączniki Power Platform obsługują tylko interfejsy API REST. Jeśli musisz nawiązać połączenie z innym stylem interfejsu API, takim jak SOAP lub gRPC, podaj własny interfejs API REST, który komunikuje się z niezgodnym.

Zalecamy nadążanie za falami wydań Power Platform, ponieważ nadal wypełniają luki w tym, co można zrobić za pomocą rozwiązań niskokodowych. Utworzenie prototypu z małą ilością kodu to dobry sposób na określenie, czy scenariusz jest odpowiedni.

Priorytetyzacja możliwości niskokodowych

Oceniając portfolio aplikacji, nie wystarczy zidentyfikować dobrych kandydatów do przekształcenia niskokodowego. Twój zespół musi nadać im priorytety, aby zmaksymalizować powodzenie działań modernizacyjnych.

Ustalanie priorytetów powinno uwzględniać następujące czynniki:

• Dojrzałość organizacji w zakresie niskokodowych platform
• Złożoność możliwości
• Zwrot z inwestycji dla organizacji, użytkowników i działu IT
• Czas do ustalenia wartości

Realistyczne podejście do niskokodowych możliwości organizacji może pomóc w wyborze okazji, która stawia przed Twoim zespołem wyzwanie, ale go nie przytłacza. Nie musisz wybierać najprostszej aplikacji bez żadnych wyzwań. Idealny oferowałby kilka możliwości zbadania, jak połączyć tradycyjny kod z rozwiązaniami low-code.

Aplikacje ze złożoną integracją z innymi systemami często nie są najlepszym miejscem do rozpoczęcia. Próba radzenia sobie z aplikacjami, które są zbyt duże lub zbyt złożone, może prowadzić do frustracji i niepowodzenia. Unikaj tych, które są wątpliwymi kandydatami na platformy niskokodowej. Zachowaj je na czas, gdy Twój zespół ukończy kilka udanych modernizacji.

Podczas modernizowania dużej, monolitycznej aplikacji należy zastanowić się, czy można stopniowo modernizować jej małe części. Zastosowania monolityczne były kiedyś powszechne. Teraz bardziej powszechne są mniejsze aplikacje skoncentrowane na rolach lub zadaniach. Pozwalają one na stopniowy rozwój oraz ulepszanie i skalowanie tworzących je zespołów.

Kilka pierwszych modernizacji jest ważnych, ponieważ pozwala organizacji dostrzec wpływ rozwiązań niskokodowych. Ocena korzyści i zagrożeń dla interesariuszy aplikacji jest ważna podczas ustalania priorytetów możliwości. Wybór aplikacji, która nikogo nie obchodzi lub ma niewielki wpływ na organizację, nie będzie najlepszą demonstracją zalet rozwiązania low-code.

Akceptacja zmodernizowanej aplikacji przez użytkownika jest ważna. Użytkownicy muszą czuć, że ich nowa niskokodowa aplikacja pasuje do reszty aplikacji, z których korzystają. Innym ryzykiem związanym z adopcją jest stopień dostosowania, do którego są przyzwyczajeni. Jeśli oczekują wysoce niestandardowego środowiska, mogą być mniej skłonni do przyjęcia rozwiązania niskokodowego, które wydaje się mniej osobiste.

Organizuj i podnoś kwalifikacje swoich zespołów

Organizacje, które z powodzeniem modernizują swoje starsze aplikacje, nie tylko przypisują projekt modernizacji do zespołu tradycyjnych programistów kodu i mają nadzieję, że im się powiedzie. Ważne jest, aby zapewnić zespołowi wiedzę i pewność siebie w zakresie programowania niskokodowego, które są potrzebne do pomyślnego ukończenia prac modernizacyjnych.

Zespół niskokodowych zasobów współpracujących z tradycyjnymi zasobami kodu jest określany jako zespół fuzyjny. Zespoły fuzyjne zostały zaprojektowane tak, aby zachęcać do współpracy przez szkolenie obu typów zasobów w zakresie integracji rozwiązań niskokodowych z tradycyjnym kodem. Architekt rozwiązań określa, w jaki sposób rozwiązanie jest zaprojektowane między kodem niskokodowym a tradycyjnym.

Chociaż łatwo jest domyślnie przypisać całą pracę tradycyjnym programistom, wysiłki związane z modernizacją z małą ilością kodu są dobrą okazją do rozszerzenia zespołu projektowego. Wielu użytkowników biznesowych tworzy doskonałe zasoby niskokodowe. Mogą przyspieszyć pracę zespołu, ponieważ rozumieją już problem biznesowy. Muszą tylko nauczyć się, jak wykonywać rodzaje niskokodowej pracy, którą podejmuje się zespół, i być zaznajomieni z procedurami testowania i ALM. Może to oznaczać naukę tworzenia aplikacji w Power Apps lub przepływów pracy w Power Automate. Powinni również zrozumieć, co tradycyjni programiści mogą opracować, aby ułatwić sobie wysiłki związane z małą ilością kodu. Nie oznacza to, że muszą wiedzieć, jak pisać tradycyjny kod.

Tradycyjne zasoby kodu muszą mieć podstawową wiedzę na temat podejść niskokodowych i tego, czym różnią się one od kodu, który zwykle piszą. Co najważniejsze, muszą poznać opcje rozszerzalności rozwiązań niskokodowych. Powinni czuć się komfortowo, tworząc aplikację testową lub przepływ, który używa napisanego przez nich kodu, aby upewnić się, że działa i być gotowym do obsługi zasobów niskokodowych w korzystaniu z ich zasobów rozszerzalności.

Zarówno zasoby niskokodowe, jak i tradycyjne muszą rozumieć, gdzie zaczynają się i kończą rozwiązania niskokodowe i tradycyjne oraz gdzie się przecinają.

Zbieranie wymagań

Może się okazać, że masz aplikacje, które mają dekadę lub więcej i nie są udokumentowane. Do odtworzenia mogą wymagać inżynierii wstecznej lub wiedzy użytkownika biznesowego. Należy pamiętać, że chociaż podejście niskokodowe jest wydajne, nie przyspiesza gromadzenia wymagań i wiedzy o procesach biznesowych ani nie sprawia, że złożone wymagania są mniej złożone. Często istnieje nierealistyczne oczekiwanie, że zespół, który modernizuje aplikację, osiąga tyle samo, co zespół, który tworzy nową aplikację z małą ilością kodu. Ustal oczekiwania swojej organizacji, mając na uwadze te wyzwania.

Dwa podejścia mogą pomóc przyspieszyć wysiłek związany ze zdobyciem wiedzy na temat starszej aplikacji. Najpierw poszerz zespół o użytkowników biznesowych posiadających wiedzę na temat domeny. Po drugie, skup się na zrozumieniu procesu biznesowego i jego pożądanego rezultatu, a nie na dokumentowaniu, w jaki sposób został on zaimplementowany w starszym systemie. Wyjątkiem jest sytuacja, gdy starsza aplikacja wymaga wyspecjalizowanej logiki wykonującej reguły biznesowe, których należy przestrzegać.

Unikanie pracy wbrew podejściu niskokodowemu

Organizacje, które dopiero zaczynają modernizować aplikacje za pomocą rozwiązań niskokodowych, często popełniają błąd polegający na opracowywaniu kodu niskokodowego w taki sam sposób, w jaki opracowują kod tradycyjny. Na przykład organizacja może zastosować standardy UX napisane dla aplikacji Angular do swojej pierwszej implementacji Power Apps. Zespół projektowy spędzałby niepotrzebny czas próbując spełnić standardy, które zostały zaprojektowane z myślą o możliwościach frameworka Angular, a nie o potrzebach biznesowych.

Zespoły, które są przyzwyczajone do pracy z tradycyjnym kodem, mogą próbować zminimalizować low-code. Na przykład, zamiast używać kontrolek Power Apps, zespół może zbudować aplikację z kontrolek Power Apps Component Framework, aby uniknąć używania niskiego kodu w jak największym stopniu. Najlepiej, aby zespoły zaszły jak najdalej dzięki low-code, dopóki nie trafią na blokery, których nie można obejść. Zespoły, które uczą się, jak korzystać z możliwości platformy, odnoszą większe sukcesy w osiąganiu maksymalnych korzyści z low-code. Low-code staje się coraz bardziej zdolny do przejmowania tego, co kiedyś było możliwe tylko w przypadku tradycyjnego kodu. Częstym wyzwaniem w przeszłości było utknięcie, ponieważ low-code nie był w stanie odtworzyć niektórych potrzebnych funkcji. Power Platform radzi sobie z tym wyzwaniem dzięki opcjom rozszerzalności, które pozwalają głównie aplikacjom o niskim kodzie na włączenie wyspecjalizowanych komponentów napisanych w tradycyjnym kodzie, gdy jest to konieczne.

Podejścia niskokodowe mogą odgrywać ważną rolę w strategiach modernizacji. Najlepsze wyniki wymagają jasnego określenia problemu, który ma rozwiązać wysiłek modernizacyjny, planowania, obsadzania stanowisk wykraczających poza domyślne role, szkoleń i ustalania priorytetów. Wprowadzenie odpowiednich zmian w standardach i procesach, jeśli zajdzie taka potrzeba, również pomaga organizacjom w pełni wykorzystać potencjał low-code. Prawidłowo przeprowadzona modernizacja powinna poprawić ogólną wartość biznesową zmodernizowanych aplikacji.

Platformy low-code szybko ewoluowały w ostatnich latach. Chociaż zawsze dobrze radziły sobie z obsługą indywidualnych scenariuszy produktywności, ostatnio skupiono się na możliwościach przedsiębiorstwa. Organizacje budują niskokodowe aplikacje, które wspierają nowoczesne miejsce pracy, w tym pracę hybrydową (zdalną i stacjonarną) oraz towarzyszącą jej potrzebę sposobów zachęcania do współpracy. Platformy niskokodowe, takie jak Power Platform, mogą teraz być skalowane w celu obsługi aplikacji, na których mogą polegać wszyscy użytkownicy w organizacji i które można zintegrować z modelami zabezpieczeń przedsiębiorstwa. Łącząc możliwości niskokodowe z infrastrukturą przedsiębiorstwa, można używać technik niskokodowych równolegle z tradycyjnymi metodami. Low-code abstrahuje od dużej części złożoności i umożliwia szerszemu gronu osób udział w tworzeniu rozwiązań.

Zrozum strukturę kosztów podejścia niskokodowego

Częstym pytaniem, które zadają organizacje, gdy rozważają modernizację, jest to, ile to będzie kosztować? Chociaż pełne omówienie licencjonowania i analizy kosztów wykracza poza zakres tego artykułu, możemy zgłębić te tematy na wysokim poziomie.

Produkty Power Platform są produktami licencjonowanymi. Możesz licencjonować je indywidualnie, aby dopasować je do swoich wymagań. Rozliczenia na platformie Azure można skonfigurować w trybie płatności zgodnie z rzeczywistym użyciem, co umożliwia korzystanie z usługi bez konieczności zakupu licencji z góry i obejmuje pewne użycie usługi Power Automate w aplikacji. Power Automate ma również licencje na użytkownika i na przepływ dla pracy autonomicznej. Licencjonowanie na przepływ działa dobrze, gdy masz automatyzację, która przynosi korzyści całej organizacji. Licencje Power Apps mogą być na użytkownika lub na aplikację. Witryny Power Pages są licencjonowane na użytkownika, witrynę lub miesiąc. W przypadku witryn uwierzytelnionych potrzebna jest dodatkowa licencja. Wszystkie licencje obejmują korzystanie z konektorów i Dataverse, z opcją licencjonowania większej ilości pamięci masowej i żądań API dla scenariuszy o dużej objętości.

Wszystkie produkty Power Platform mają ceny ilościowe, które zwykle mają zastosowanie do modernizacji aplikacji i muszą być oceniane pod kątem unikalnej strategii każdej organizacji.

Oceniając koszt rozwiázan niskokodowych w porównaniu z tradycyjnym kodem, należy zdać sobie sprawę, że porównanie to nie jest jak 1 do 1. W przypadku low-code płacisz za robociznę potrzebną do zaimplementowania unikatowego procesu biznesowego w produkcie low-code oraz za licencję produktu na korzystanie z niego. Ogólnie rzecz biorąc, licencja obejmuje wiele aplikacji i automatyzacji, z których każda nie wymaga większych kosztów.

W przypadku tradycyjnych podejść do kodowania płacisz za robociznę potrzebną do zaimplementowania unikatowego procesu biznesowego w kodzie, robociznę związaną z utworzeniem infrastruktury aplikacji oraz usługi w chmurze potrzebne do obsługi aplikacji.

Wszystkie rozwiązania, zarówno niskokodowe, jak i tradycyjne, wymagają bieżącej konserwacji i utrzymania. Jednak rozwiązania niskokodowe wymagają do tego mniej zasobów. Ponoszą również mniejszy dług techniczny, ponieważ infrastruktura aplikacji jest dostarczana przez platformę.

W porównaniu z w pełni niestandardową aplikacją, która nie jest oparta na platformie niskokodowej, rozwiązanie niskokodowe ma bardziej przewidywalny koszt. Nie wpadnij w pułapkę porównywania licencjonowania niskokodowego z początkowym kosztem tradycyjnego wdrożenia kodu.

Zajrzyj do środka Power Platform

Komponenty Power Platform są tworzone w oparciu o te same usługi chmurowe Microsoft Azure, które są dostępne w przypadku korzystania z tradycyjnych metod kodowania. Integracja tych komponentów ze sobą oraz z funkcjami zabezpieczeń, skalowalności i odzyskiwania po awarii została wykonana za Ciebie.

Wewnątrz Dataverse

Dataverse jest obsługiwane przez ponad 25 w pełni zarządzanych usług Azure, takich jak Functions, Load Balancer, Cognitive Services, Synapse, DevOps, Active Directory i Microsoft Purview. Wbudowane funkcje obejmują kompleksowe zabezpieczenia, zaawansowaną analitykę, sztuczną inteligencję, zaawansowaną logikę biznesową i obsługę zdarzeń, modelowanie danych oraz integrację z Dynamics 365, Microsoft 365, Azure i nie tylko. Wszystkie te możliwości są zbudowane na poliglotycznej warstwie magazynu Dataverse, która jest oparta na Azure SQL DB (dla danych relacyjnych), Azure Cosmos DB (dla NoSQL), Azure Blob Storage (dla plików) i Azure Data Lake Storage Gen 2 (dla analityki na dużą skalę i długoterminowego przechowywania danych). Są one dostępne do przejrzystego użytku w niskokodowych komponentach Power Platform i za pośrednictwem interfejsu API REST Dataverse.

Wysoka dostępność i ciągłość działania oraz odzyskiwanie po awarii (BCDR) są ważne dla aplikacji o znaczeniu krytycznym dla firmy. Dataverse maksymalizuje dostępność dzięki usługom niezawodności platformy Azure. Replikacja serwerów podstawowych i pomocniczych jest synchroniczna, a pod spodem znajduje się sieć szkieletowa, która może wykrywać awarie i wybierać nowy serwer podstawowy zgodnie z protokołami poprawności. Przełączenia awaryjne o wysokiej dostępności, które występują w obrębie regionu Azure, są płynne i rzadko zauważane przez użytkowników, zwykle w ciągu kilku sekund. Gwarantują zerową utratę danych niezależnie od tego, czy awaria jest planowana, czy nieplanowana.

Odzyskiwanie po awarii w trybie przełączania awaryjnego odbywa się między dwoma regionami Azure. Aby zapewnić szybsze przełączanie awaryjne przy minimalnej utracie danych, przy użyciu replikacji asynchronicznej jest utrzymywana ciągła kopia odzyskiwania po awarii. Planowane przejścia w tryb failover nie powodują utraty danych, a w przypadku środowisk produkcyjnych zwykle można je ukończyć w ciągu kilku sekund lub kilku minut.

Poza techniczną implementacją high availability i BCDR, zespół operacyjny regularnie testuje swoją gotowość do reagowania na różnego rodzaju zdarzenia.

Wewnątrz Power Automate

Przepływy w chmurze Power Automate są tworzone na podstawie Azure Logic Apps. Power Automate zapewnia abstrakcje i integrację z innymi składnikami niskokodowymi, takimi jak Power Apps Azure Logic Apps i używa silnika czasu wykonywania. Programiści zaznajomieni z Logic Apps przekonają się, że Power Automate wykorzystuje podobne koncepcje, w tym język wyrażeń.

Wewnątrz Power Apps

Silnik Power Apps wykonawczy jest zbudowany na frameworku React. Aplikacje są tworzone w projektancie Power Apps, który wykorzystuje interfejs przeciągania i upuszczania do tworzenia ekranów. Formuły Power Fx implementują logikę. Łączniki rozszerzają dostęp aplikacji do innych usług oraz logiki i składników, które umożliwiają rozszerzenia wizualne wielokrotnego użytku. Deweloperzy mogą używać Power Apps Component framework (PCF) do tworzenia kontrolek niestandardowych. Podczas gdy wiele frameworków UI może być używanych razem z PCF, Power Apps posiada wbudowaną obsługę React.

Wewnątrz łączników

Łączniki używają usługi Azure API Management do zarządzania poświadczeniami i połączeniami od każdego użytkownika.

Ta sama architektura jest używana dla wszystkich łączników, w tym łączników niestandardowych tworzonych dla własnych interfejsów API. Korzystanie z Azure API Management zapewnia spójny interfejs dla produktów Power Platform, takich jak Power Apps i Power Automate ze wszystkimi łącznikami.

Wyjątkiem jest łącznik Dataverse. Jest on wyświetlany na liście łączników dla aplikacji i przepływów, ale jest zaimplementowany w inny sposób. Gdy aplikacja lub przepływ korzysta z danych lub akcji Dataverse, interakcja odbywa się bezpośrednio za pośrednictwem interfejsu API OData Dataverse.

Opcje rozszerzalności Power Platform

Rozszerzalność jest kluczową cechą, która odróżnia Microsoft Power Platform od innych platform niskokodowych. Naczelną zasadą platformy jest „brak klifów” - nie należy blokować możliwości osiągnięcia czegoś za pomocą niskiego kodu, nawet jeśli wymaga to tradycyjnego kodu. W razie potrzeby możesz skompilować całe obciążenie jako część większej aplikacji przy użyciu tradycyjnego kodu. Jednak platforma oferuje wiele opcji rozszerzalności, które umożliwiają używanie kodu niskokodowego i tradycyjnego razem w tym samym obciążeniu.

W poniższej tabeli przedstawiono ogólne omówienie niektórych typowych opcji rozszerzalności. Do niektórych z nich odniesiemy się ponownie później, gdy omówimy, jak podejść do modernizacji i wzorców, które można zastosować.

Opcja	Podpis
Interfejsy API i niestandardowe złącza	Łączniki niestandardowe dla interfejsów API REST centralizują logikę aplikacji i umożliwiają jej uwidocznienie składników niskokodowych w bezpieczny i nadzorowany sposób. Tego podejścia można użyć w strategii opartej na interfejsie API na potrzeby modernizacji aplikacji. Niestandardowy łącznik wykorzystuje dokument OpenAPI do zdefiniowania sposobu, w jaki komponent niskokodowy może wchodzić w interakcje z interfejsem API REST. Na przykład możesz utworzyć interfejs API przy użyciu usługi Azure Functions i opublikować go w usłudze Azure API Management. Azure API Management może wyeksportować definicję OpenAPI, aby automatycznie utworzyć niestandardowy łącznik do użycia w rozwiązaniu niskokodowym. Takie podejście oddziela aplikacje klienckie od interfejsów API, umożliwiając ich niezależną ewolucję. Interfejsy API są zarządzane centralnie, dodając warstwę zabezpieczeń, nie uwidaczniając interfejsu API bezpośrednio i używając technik uwierzytelniania, takich jak klucze subskrypcji, tokeny, certyfikaty klienta i nagłówki niestandardowe.
Power Apps Component framework	Power Apps Component Framework to struktura rozszerzalności do tworzenia niestandardowych wizualizacji dla Power Apps i Power Pages. Składniki kodu są tworzone przy użyciu języka HTML, JavaScript lub TypeScript. Pomyśl o składnikach kodu jako o blokach konstrukcyjnych interfejsu użytkownika, które można ponownie wykorzystać do skompilowania jednej lub większej liczby aplikacji. Składniki zawierają manifest, który definiuje, w jaki sposób składnik niskokodowy może wchodzić w interakcje ze składnikiem kodu. Interfejs składnika umożliwia aparatowi środowiska uruchomieniowego hostingu komunikowanie zdarzeń cyklu życia kontenera hostingu. Dzięki temu składnik kodu może renderować wizualizacje przy użyciu informacji kontekstowych dostarczanych przez kontener hostingu. Pomysły można znaleźć w galerii społeczności na stronie https://pcf.gallery.
Tabele wirtualne	Tabele wirtualne ułatwiają integrację danych znajdujących się w systemach zewnętrznych. Płynnie reprezentują dane zewnętrzne jako tabele w Microsoft Dataverse, bez replikacji danych i często bez potrzeby niestandardowego kodowania. Dataverse jest przekazwyane z dostawcami danych dla OData v4 i Azure Cosmos DB. Wirtualny dostawca konektorów, obecnie w wersji zapoznawczej, rozszerza dostępnych dostawców danych o podzbiór konektorów Power Platform, w tym SharePoint i SQL Server. W przypadku bardziej zaawansowanych scenariuszy deweloperzy mogą tworzyć niestandardowych dostawców danych. Tworzenie niestandardowych dostawców danych wymaga dogłębnej znajomości zarówno danych zewnętrznych, jak i Dataverse. Możliwość tworzenia wtyczek Dataverse przy użyciu Power Fx dla logiki jest w wersji zapoznawczej.
Pluginy Dataverse	Wtyczka Dataverse to niestandardowa obsługa zdarzeń, która jest wykonywana w odpowiedzi na określone zdarzenie. Pomyśl o wtyczkach jak o procedurach składowanych w aparacie bazy danych, ale napisanych na platformie .NET. Na przykład zdarzenia są zgłaszane podczas przetwarzania operacji danych Microsoft Dataverse lub na żądanie w przypadku niestandardowych zdarzeń API. Wtyczka jest zaimplementowana jako niestandardowa klasa skompilowana do zespołu .NET Framework, który można przesłać i zarejestrować za pomocą Dataverse. Korzystając ze zdefiniowanego interfejsu, wtyczka może uzyskać informacje kontekstowe o przetwarzanym zdarzeniu. Wtyczki mogą działać jako część transakcji Dataverse i mogą wykonywać inne operacje na danych, które są częścią bieżącej transakcji. Wtyczki są przeznaczone do małych jednostek pracy. Ich wydajność musi być zoptymalizowana, aby nie wpływały negatywnie na ogólną wydajność. Wtyczki są zawsze wykonywane, niezależnie od operacji z poziomu interfejsu użytkownika lub interfejsu API, co czyni je zaawansowanym sposobem spójnego wymuszania logiki biznesowej.

Eksplorowanie scenariuszy architektury modernizacji z małą ilością kodu

Podobnie jak w przypadku większości platform, można tworzyć nieskończoną liczbę scenariuszy architektury przy użyciu komponentów Power Platform i innych usług chmurowych firmy Microsoft. W tej części dokumentu przyjrzymy się niektórym z bardziej typowych scenariuszy i omówimy kilka kwestii, o których należy pamiętać podczas ich używania.

Doświadczenia związane z aplikacjami

Modernizacja doświadczenia użytkownika może mieć duże znaczenie dla użytkowników. Power Apps to podstawowy sposób tworzenia doświadczeń z aplikacją wewnętrzną Power Platform. Możesz używać Power Pages do wewnętrznych aplikacji internetowych, ale jest to bardziej powszechne w przypadku aplikacji zewnętrznych.

Power Apps

Obciążenia powinny być zaprojektowane w taki sposób, aby użytkownicy mogli wykonywać większość swojej pracy bez przełączania aplikacji. Podczas modernizowania dużej, monolitycznej aplikacji można podzielić jej funkcjonalność na wiele aplikacji. Z drugiej strony, jeśli użytkownicy muszą pracować z wieloma aplikacjami, możesz skonsolidować ich w jednej aplikacji, która przedstawia ujednolicony widok wielu źródeł danych.

W poniższej tabeli opisano dwa typy aplikacji, które można tworzyć za pomocą Power Apps, aplikacje kanwy i aplikacje oparte na modelu.

Typ aplikacji	Podpis
Aplikacje kanwy	Aplikacje kanwy można w dużym stopniu dostosowywać. Składają się z jednego lub więcej ekranów, z którymi użytkownicy wchodzą w interakcję. To Ty decydujesz o układzie każdego ekranu i nawigacji między ekranami. Aplikacje oparte na kanwie współpracują z danymi za pomocą łączników. Pojedyncza aplikacja może współpracować z wieloma łącznikami, dzięki czemu nadaje się do integracji z wieloma źródłami danych jako aplikacja złożona.
Aplikacje oparte na modelu	Aplikacje oparte na modelach wykorzystują Dataverse jako podstawowe źródło danych. Składają się one z jednej lub więcej stron, które mogą być tabelami Dataverse lub stronami niestandardowymi. Stronę tabeli Dataverse można przenieść do strony szczegółów w celu przeglądania i edycji. Strony niestandardowe mogą zawierać ekran aplikacji opartej na kanwie i dane z łączników. Aplikacje oparte na modelu mają dostosowywalną wbudowaną strukturę nawigacji. Jest ona spójna we wszystkich aplikacjach opartych na modelu, co ułatwia adaptację użytkowników.

Na poniższym diagramie przedstawiono podstawową architekturę aplikacji kanwy lub aplikacji opartej na modelu, w której aplikacja łączy się bezpośrednio ze źródłami danych.

Aby zminimalizować bezpośrednie połączenia ze źródłem danych, aplikacja może używać łącznika niestandardowego z interfejsem API, który wykonuje wszelkie niezbędne prace w źródle danych. Takie podejście pozwala kontrolować, jakie operacje są uwidocznione dla składników z małą ilością kodu i może abstrahować złożoność podstawowej logiki. Na poniższym diagramie przedstawiono to podejście oparte na interfejsie API.

Power Apps może również bezpośrednio uruchamiać przepływy w chmurze Power Automate, które mogą zwracać wyniki do aplikacji lub działać asynchronicznie.

Korzystanie z Power Apps z repozytoriami danych lub interfejsami API pozwala zmodernizować środowisko użytkownika, jednocześnie minimalizując zakłócenia w innych częściach starszego rozwiązania. Takie podejście może również umożliwić połączenie wielu starszych systemów w jedną aplikację, dając użytkownikom jedno miejsce do wykonania pracy.

Power Pages

Podstawowym źródłem danych dla Power Pages jest Dataverse. Podczas dodawania stron do witryny definicje stron są przechowywane w Dataverse. Strony mogą zarówno prezentować dane Dataverse, jak i zbierać dane od użytkowników w celu przechowywania ich w tabeli Dataverse.

Strony można skonfigurować dla dostępu anonimowego lub uwierzytelnionego przy użyciu tożsamości zewnętrznej Microsoft Entra ID dla użytkowników wewnętrznych lub dostawców tożsamości dla użytkowników zewnętrznych. Gdy uwierzytelnieni użytkownicy uzyskują dostęp do danych, dostępne są tylko te dane, do których mają uprawnienie dostępu.

Powszechnym zastosowaniem witryny Power Pages jest zapewnienie użytkownikom zewnętrznym samoobsługowego dostępu do procesu biznesowego organizacji. Użytkownicy wewnętrzni mogą korzystać z aplikacji Power Apps. Na poniższym diagramie przedstawiono taką architekturę.

Zarządzanie danymi

Modernizacja aplikacji wymaga oceny danych, które są używane w całym rozwiązaniu. Zmodernizowane aplikacje mają wiele opcji obsługi danych. W wielu przypadkach wiele aplikacji korzysta z tego samego repozytorium danych. Migracja danych do nowego repozytorium w ramach modernizacji jednej z aplikacji staje się trudna. Podstawowym założeniem Power Platform jest to, że dane mogą być wykorzystywane tam, gdzie się znajdują lub wprowadzane do platformy w Dataverse lub data lake.

Dostępne są następujące opcje architektury danych zmodernizowanej aplikacji:

• Pozostaw dane na miejscu: Użyj łączników lub interfejsów API z łącznikami niestandardowymi, aby uzyskać dostęp do danych w miejscu, w którym się znajdują. Gdy dane znajdują się lokalnie, brama danych może ułatwić bezpieczną łączność. Użyj tabel wirtualnych, aby zintegrować zgodne dane zewnętrzne jako tabelę Dataverse.

• Migracja do Dataverse: Dataverse jest dobrym rozwiązaniem w przypadku danych transakcyjnych i konsolidacji wielu źródeł w jeden system rekordów. Dane mogą być mapowane i migrowane z wielu źródeł przy użyciu Power Query oraz automatycznych przepływów. Dataverse obsługuje również elastyczne tabele przeznaczone do pozyskiwania dużych ilości danych przechowywanych w formatach bez struktury lub częściowo ustrukturyzowanych.

• Migracja do data lake: W przypadku danych historycznych, analitycznych lub telemetrycznych użyj usługi data lake. Dane w jeziorze mogą być wykorzystywane do generowania analiz Power BI lub przetwarzane w celu generowania wniosków opartych na sztucznej inteligencji.

Oceniając opcje architektury danych zmodernizowanej aplikacji, należy pamiętać o następujących kwestiach:

• Wpływ na inne aplikacje: Chociaż migracja do bardziej wydajnego magazynu danych może być idealna dla jednej aplikacji, początkowy wpływ na inne aplikacje korzystające z danych może być zbyt duży. Niektóre organizacje rozważają pozostawienie danych w starych magazynach danych i tworzenie nowych danych w Dataverse, migrację ze starego magazynu w miarę modernizacji większej liczby aplikacji.

• Wpływ na nowe aplikacje: Pozostawienie danych w starym magazynie danych, choć łatwe, może negatywnie wpłynąć na to, jak łatwo zmodernizowane aplikacje mogą z nich korzystać. Starsze magazyny danych mogą nie mieć dobrej integracji z innymi usługami w chmurze, co utrudnia włączenie danych do nowej ogólnej architektury.

• Konsolidacja danych: W ramach modernizacji aplikacji często identyfikuje się dane, które nie mają jasnego właściciela lub odpowiedzialności za zapewnienie ich prawidłowego wykorzystania. Konsolidując swoje dane Dataverse, organizacje mogą usprawnić zarządzanie nimi i lepiej upewnić się, że są one właściwie wykorzystywane.

• Prywatność i bezpieczeństwo danych: Prywatność i bezpieczeństwo należy ocenić na podstawie bieżących potrzeb i docelowej architektury modernizacji, a nie tylko sposobu, w jaki starsza aplikacja je obsługiwała. Rozwiązania chmurowe mają więcej opcji wdrażania kontroli prywatności i bezpieczeństwa. Często pojedynczy magazyn danych może je uprościć. Należy również zastanowić się, jak zaimplementować ujednolicone zabezpieczenia danych w aplikacjach hybrydowych, które dzielą dane na wiele repozytoriów.

• Kwestie integracji. W starszych magazynach danych może brakować interfejsów API niezbędnych do umożliwienia dostępu bez migrowania danych lub tworzenia interfejsu API, którego aplikacje mogą używać z łącznikiem niestandardowym. Łączność ze starego magazynu danych do aplikacji, które z niego korzystają, powinna zostać oceniona w celu określenia, czy wydajność byłaby akceptowalna.

Należy określić architekturę danych dla każdej aplikacji, która zostanie zmodernizowana. Pierwszym krokiem jest ustalenie ogólnej wizji sposobu, w jaki Twoje architektury danych włączają Dataverse. Jeśli celem jest maksymalizacja wartości platformy niskiego kodowania, należy używać Dataverse, gdy tylko jest to możliwe. Posiadanie wizji na początku może pomóc w uniknięciu rozprzestrzeniania się większej liczby silosów danych.

Dane zewnętrzne a Dataverse

Starsze aplikacje często opierają się na danych, które znajdują się poza organizacją i istniały długo przed Dataverse. Modernizacja tych aplikacji nie musi wiązać się z duplikowaniem danych w Dataverse. Zamiast tego można przedstawić wirtualną tabelę Dataverse. Tabele wirtualne mogą uczestniczyć w relacjach z innymi tabelami wirtualnymi oraz z tabelami lokalnymi. Zmodernizowane aplikacje widzą ujednolicony zestaw tabel, który istnieje w całości w Dataverse.

Tabele wirtualne są implementowane przy użyciu architektury dostawcy danych. Dataverse zawiera dostawcę OData, którego można użyć z usługami sieci Web v4 OData. Dostawca danych wirtualnych łączników, obecnie w wersji zapoznawczej, umożliwia korzystanie z tabelarycznych łączników Power Platform jako tabel wirtualnych.

Na poniższym diagramie przedstawiono użycie łącznika wirtualnego.

Deweloperzy mogą również tworzyć niestandardowych dostawców dla innych zewnętrznych źródeł danych. Muszą jednak zrozumieć i wdrożyć wszystkie mapowania Dataverse i obsługę operacji.

Poniższe zagadnienia mogą pomóc w ocenie użycia tabel wirtualnych w projektach modernizacji:

• Wszystkie zewnętrzne źródła danych muszą mieć klucz podstawowy, a dostawca danych musi przedstawić go jako identyfikator GUID Dataverse. Klucze inne niż identyfikatory GUID można uwzględnić z dopełnieniem, jeśli wartość dopełniona jest stabilna i unikatowa.
• Zabezpieczenia danych są konfigurowane na poziomie tabeli wirtualnej. Zabezpieczenia na poziomie wierszy i kolumn są niedostępne.
• Wydajność tabel wirtualnych zależy od dostawcy danych, interfejsu API zewnętrznego źródła danych i łączności ze źródłem danych. W większości przypadków dostęp do tabel wirtualnych jest wolniejszy niż w przypadku tabel Dataverse w lokalizacji lokalnej.
• Niektóre funkcje Dataverse, takie jak wyszukiwanie, audyt, wykresy i pulpity nawigacyjne oraz dostęp offline nie są dostępne dla tabel wirtualnych.
• Używanie tabel wirtualnych jako danych referencyjnych może spowodować zmniejszenie synchronizacji.

Pliki i obrazy

Podczas modernizowania aplikacji korzystających z plików i obrazów należy wziąć pod uwagę, gdzie nowe rozwiązanie będzie je przechowywać. Dataverse posiada specjalistyczne możliwości przechowywania plików i obrazów. Oba mogą być dodawane do tabel jako kolumny i są przechowywane w usłudze Azure Blob Storage, która jest zarządzana przez Dataverse. Aplikacje mogą z nimi współpracować za pomocą łącznika Dataverse, bez konieczności oddzielnego uwierzytelniania lub interfejsu API.

Korzystanie z Dataverse dla plików i obrazów jest odpowiednie, gdy mają one bezpośrednie połączenie z danymi i wielu użytkowników nie musi nad nimi współpracować; na przykład zdjęcie produktu lub lokalizacji lub ostateczna kopia umowy prawnej. Jeśli jednak wielu użytkowników musi jednocześnie zmodyfikować umowę prawną, użycie SharePoint zapewni większe możliwości współpracy. Rozważ użycie Azure usługi Blob Storage bezpośrednio, jeśli musisz zarządzać zabezpieczeniami oddzielnie od Dataverse lub jeśli musisz użyć pewnych funkcji specyficznych dla plików.

Integracje

Modernizacja aplikacji często wiąże się z integracjami z systemami wewnętrznymi lub zewnętrznymi. Integracje można ogólnie podzielić na dane, aplikacje lub procesy.

• Integracja danych łączy dane z różnych źródeł, aby zapewnić użytkownikowi ujednolicony widok. Oferuje podejście oddzielone, ale nie pozwala na budowę logiki lub procesów w czasie rzeczywistym. Wydajność może być lepsza, ponieważ wszystkie dane są lokalne.

• Integracja aplikacji łączy się w warstwie aplikacji i zwykle odbywa się za pośrednictwem interfejsów API lub, w przypadku rozwiązań niskokodowych, łączników. Integracja na poziomie aplikacji zapewnia zdefiniowaną granicę między dwoma rozwiązaniami, ale w wielu przypadkach tworzy również zależność w czasie rzeczywistym. Ten typ integracji tworzy również granicę zabezpieczeń, do której dostęp może być kontrolowany przez system udostępniający interfejs API.

• Integracja procesów łączy wiele różnych systemów, z których każdy jest częścią ogólnego procesu biznesowego. Ten typ integracji jest najbardziej rozłączny, dzięki czemu uczestniczące w nim systemy mogą obsługiwać każdą część procesu biznesowego. W scenariuszach modernizacji pomocne może być podzielenie części procesu na potrzeby modernizacji za pomocą platformy low-code, zintegrowanego z innymi częściami, które nadal są obsługiwane przez starszy system.

Oceniając sposób implementowania integracji, ważne jest, aby nie zakładać, że stare podejście jest najlepsze dla modernizowanej aplikacji. Jeśli na przykład proces jest synchroniczny i działa w czasie rzeczywistym, zastanów się, czy można to zrobić asynchronicznie. Integracja synchroniczna może być bardziej krucha w rozwiązaniu chmurowym. Na przykład przepływ z małą ilością kodu Power Automate z odpowiednią obsługą błędów może zorganizować integrację. Takie podejście nie tylko poprawiłoby niezawodność, ale także zwiększyłoby produktywność użytkowników, ponieważ nie musieliby już czekać na zakończenie integracji.

Poniższe zagadnienia mogą pomóc w ocenie, jak przenieść istniejące integracje:

• Czy integracja jest nadal potrzebna? Nierzadko zdarza się, że okazuje się, że nikt już nie korzysta z wyników integracji i można ją wycofać.

• Czy istnieją problemy z łącznością, jeśli zmodernizowana aplikacja znajduje się w chmurze? Wyzwania mogą obejmować opóźnienia i dostęp do lokalnego interfejsu API lub magazynu danych. W niektórych przypadkach lokalna brama danych może pomóc w uzyskiwaniu dostępu do usługi lub danych z chmury. Jeśli dostęp do danych lub usługi jest zbyt wolny, zastanów się, czy możesz ustawić dane lokalnie w zmodernizowanej aplikacji, czy przeprowadzić integrację w tle.

Integracja może również pomóc w doborze odpowiedniego rozmiaru zmodernizowanej aplikacji. Możesz podzielić co najmniej jedną część starszej aplikacji, aby ją pozostawić lub zaimplementować w osobnej aplikacji. Takie podejście będzie działać dobrze, gdy użytkownicy o różnych rolach używają różnych części starszej aplikacji. Możesz zaimplementować co najmniej jedną rolę przy użyciu niskopoziomowego kodowania i użyć integracji procesów, aby umożliwić istniejącej aplikacji obsługę pozostałych części procesu. Korzystając z tego podejścia, można stopniowo modernizować pozostałe części w czasie. Oddzielne wdrożenie niezależnych części procesu może również ułatwić bardziej elastyczny sposób wdrażania ulepszeń niezależnie od innych części procesu.

Przed przeprowadzeniem jakichkolwiek niestandardowych integracji należy ocenić możliwości wbudowanej w Power Apps integracji.

• Microsoft Teams: Power Apps aplikacje oparte na kanwie i agenty Copilot Studio mogą być osadzene w kanałach Teams. Korzystając z łącznika usługi Teams, aplikacje i przepływy mogą łatwo publikować i korzystać z komunikatów usługi Teams. Karty Power Apps mogą być używane jak mikroaplikacje do udostępniania przydatnych informacji w kanale Teams.

• SharePoint: Aplikacje Power Apps oparte na modelu można skonfigurować tak, aby łączyły się z dokumentami przechowywanymi w bibliotece SharePoint, aby udostępniać je z wiersza Dataverse. Za pomocą list Microsoft lub listy SharePoint użytkownicy mogą uruchamiać przepływy Power Automate w kontekście elementu listy.

• Power BI: Analizy Power BI mogą być wyświetlane w kontekście aplikacji opartej na kanwie Power Apps. Aplikację opartą na modelu można osadzić w raporcie Power BI, aby umożliwić użytkownikom działanie na podstawie szczegółowych informacji bez opuszczania Power BI.

Korzystanie z Dataverse jako głównego repozytorium danych dla zmodernizowanej aplikacji zapewnia kilka wbudowanych funkcji, które mogą być pomocne w integracji.

• Niestandardowe interfejsy API Dataverse mogą być używane do integracji na poziomie aplikacji przychodzących. Niestandardowe interfejsy API zapewniają unikatową operację, która jest skojarzona z niewielką ilością niestandardowej logiki kodu. Na przykład, system wysyłający mógłby użyć niestandardowego interfejsu API RequestNewProject, a pracownik wiedziałby, jak umieścić otrzymane dane w odpowiednich tabelach Dataverse. System wysyłający zostałby wyabstrahowany ze struktury tabeli Dataverse.

• Można wykonać integrację ruchu wychodzącego przy użyciu funkcji publikowania zdarzeń Dataverse. Dataverse można skonfigurować do publikowania w usłudze Azure Service Bus, Azure usłudze Event Hubs lub dowolnym odbiorniku elementu webhook. Na przykład po utworzeniu nowego wiersza tabeli projektu Dataverse można go opublikować w kolejce Azure Service Bus. Można również opublikować więcej zdarzeń koncepcyjnych pasujących do zdarzenia procesu biznesowego. Na przykład można definiować i publikować zdarzenia po zakończeniu projektu.

Na poniższym diagramie przedstawiono przykład zdarzeń przychodzących i wychodzących w środowisku Dataverse.

Organizacje powinny również rozważyć wstępnie utworzone opcje integracji dostępne od innych firm w Microsoft AppSource. Na przykład Microsoft ma wstępnie utworzone rozwiązanie dla organizacji, które muszą zintegrować SAP z Power Platform. To wstępnie utworzone rozwiązanie zawiera aplikacje i przepływy oraz dodaje nowe funkcje, które ułatwiają komunikację między systemem SAP organizacji a Power Platform.

Na przykład firma Ernst & Young wykorzystała gotową integrację SAP do szybkiego opracowania rozwiązania optymalizującego globalny proces finansowy o wysokiej częstotliwości. Poniższy diagram rozwiązania PowerPost firmy pokazuje, w jaki sposób użytkownicy finansowi księgują dokumenty w systemie SAP ERP księgi głównej za pomocą Power Platform.

Opcje łączności integracji

W miarę przenoszenia rozwiązań do chmury łączność z zasobami lokalnymi może być niezbędna do zapewnienia, że integracje nadal działają ze zmodernizowaną aplikacją. Aplikacje te muszą również mieć możliwość integracji z innymi tradycyjnymi zasobami w chmurze, które mogą znajdować się w różnych środowiskach sieciowych. Power Platform obsługuje cztery podstawowe opcje bezpiecznej łączności: bramy danych, bramy danych sieci wirtualnej, łącza prywatne i usługę ExpressRoute.

• Brama danych zezwala na używanie komponentów niskokodowych Power Apps, Power Automate oraz Power BI, aby wrócić do zasobów lokalnych w celu obsługi scenariuszy integracji hybrydowej. Bramy zapewniają zmodernizowanym aplikacjom niskokodowym szybki sposób uzyskiwania dostępu do źródeł danych, które nadal znajdują się lokalnie. Za pomocą bramy można łączyć się z danymi lokalnymi ze źródeł, takich jak lokalny system plików, DB2, Oracle, SAP ERP, SQL Server i SharePoint. Jedna brama może obsługiwać wielu użytkowników i dostęp do wielu źródeł. Bramy danych można również skonfigurować jako klastry, aby zapewnić wysoką dostępność.

  Obsługa bramki jest zintegrowana z procesem łączenia konektorów, umożliwiając wskazanie, kiedy brama jest wymagana i wybór skonfigurowanej bramy. Po skonfigurowaniu połączenia aplikacje i przepływy mogą używać konektora tak samo jak bez bramki.

  

• Bramy danych sieci wirtualnej umożliwiają przepływom danych Power BI i Power Platform łączenie się z usługami danych w sieci wirtualnej Azure bez potrzeby korzystania z lokalnej bramy danych na maszynie wirtualnej wewnątrz sieci wirtualnej.

• Azure Private Link i prywatne punkty końcowe sieci Azure umożliwia aplikacjom i przepływom bezpieczny dostęp do usługi Power BI. Prywatne punkty końcowe służą do prywatnego wysyłania ruchu danych przy użyciu podstawowej infrastruktury sieciowej Microsoft zamiast przechodzenia przez Internet. Prywatne punkty końcowe zapewniają, że ruch przechodzący do zasobów Power BI organizacji, takich jak raporty lub obszary robocze, zawsze odbywa się zgodnie ze skonfigurowaną ścieżką sieciową łącza prywatnego organizacji.

• Azure ExpressRoute umożliwia połączenie sieci lokalnej z usługami w chmurze firmy Microsoft za pomocą łączności prywatnej. Pojedyncze połączenie ExpressRoute może uzyskać dostęp do wielu usług online, takich jak Power Platform, Dynamics 365, Microsoft 365 i usług w chmurze Azure bez konieczności przechodzenia przez publiczny Internet. Usługa ExpressRoute wymaga znacznego planowania i konfiguracji oraz wiąże się z większymi kosztami dla usługi ExpressRoute i dostawcy łączności.

Niezależnie od tego, które podejścia są używane do łączności integracji, należy ocenić łączność, aby upewnić się, że ma wystarczająco małe opóźnienie i wystarczającą przepustowość, aby obsługiwać zarówno integracje, jak i zmodernizowaną aplikację.

Logika biznesowa

Budując nowoczesne aplikacje, możesz wybrać, za pomocą czego chcesz zaimplementować logikę biznesową i gdzie zaimplementować ją w architekturze aplikacji. Bez wskazówek większość organizacji pogrążyłaby się w chaosie logiki biznesowej. Posiadanie logiki wielokrotnego użytku, która zapewnia spójność implementacji, może pomóc w przyspieszeniu działań modernizacyjnych.

Dla naszych celów definiujemy logikę biznesową jako różną od logiki doświadczenia użytkownika. Na przykład logika przechodzenia między ekranami na podstawie wartości danych inspekcji jest logiką doświadczenia użytkownika. Logika zaimplementowana w celu określenia, czy inspekcja została zakończona, może zawierać kilka ocen warunków i będzie uważana za logikę biznesową.

Podczas projektowania rozwiązania, które zawiera niskokodowe, poniższe zagadnienia mogą pomóc w podjęciu decyzji, gdzie można umieścić logikę biznesową.

• W aplikacji Power Apps: Umieszczenie logiki biznesowej w aplikacji niskokodowej jest najprostszym podejściem, ale zapewnia ograniczone opcje ponownego użycia lub wymuszenia spójności między aplikacjami i automatyzacjami. Ogólnie rzecz biorąc, należy ograniczyć to podejście do prostej logiki, która nieważna dla misji, której inne aplikacje lub automatyzacje nie muszą używać. Narzędzia niskokodowe nie zapewniają środowiska debugowania wiersz po wierszu. Jeśli logika obejmuje więcej niż jeden ekran lub jest trudna do odczytania, należy rozważyć inne podejścia, które byłyby łatwiejsze w utrzymaniu. Często zdarza się, że część logiki biznesowej jest duplikowana lokalnie w aplikacji i w chmurze. Na przykład, jeśli użytkownik wprowadza rezerwację hotelu, reguła biznesowa mówi, że data wymeldowania nie może być wcześniejsza niż data zameldowania. Jeśli aplikacja nie zweryfikuje tego, użytkownik dotrze do końca i prześle rezerwację tylko po to, aby znaleźć konektor niestandardowy odrzucający rezerwację. Obsługa walidacji lokalnie w aplikacji i w chmurze zapewnia znacznie lepsze wrażenia użytkownika.

• W przepływie Power Automate w chmurze: Logikę biznesową można wyrazić w akcjach w przepływie, a przepływ może być wyzwalany w odpowiedzi na zdarzenie lub żądanie uruchomienia na żądanie z innych aplikacji i przepływów. Przepływ może zapewnić niskokodowe podejście do centralizacji logiki. Kroki w przepływie są niezależne i nie są częścią transakcji. Przepływy mogą jednak implementować kompensację w celu obsługi wycofywania w przypadku wystąpienia błędów. Przepływy mogą uruchamiać kroki przy użyciu połączeń, które mają uprawnienia wykraczające poza to, co użytkownik aplikacji może być w stanie zrobić, co umożliwia podniesienie uprawnień. Takie podejście pozwala również na zminimalizowanie uprawnień, których może wymagać użytkownik aplikacji.

• We wtyczce Dataverse: Wtyczki są uruchamiane w odpowiedzi na zdarzenie wiersza danych, takie jak tworzenie, aktualizowanie lub usuwanie. Ta logika jest uruchamiana za każdym razem, gdy wystąpi zdarzenie, niezależnie od tego, która aplikacja lub przepływ wykonał akcję lub czy została ona wykonana bezpośrednio z interfejsu API Dataverse. Zaletą tego zachowania jest to, że zapewnia spójność we wszystkich zastosowaniach. Ponadto wszystkie zmiany danych Dataverse z logiki dodatku plug-in są transakcyjne i albo wszystkie zostają zakończone, albo wszystkie są wycofywane. Logika wtyczek musi być krótka i wydajna, i nie powinna próbować implementować długotrwałych zadań. Czasami dodatki plug-in do zdarzeń nie są najlepszym podejściem, jeśli musisz nasłuchiwać zdarzeń w wielu tabelach, aby ukończyć jedno zdarzenie biznesowe, takie jak Close Inspection. Na przykład można rozważyć niestandardowy interfejs API Dataverse zamiast posiadania plug-inów na wielu tabelach. Wtyczki mogą wykonywać logikę z podwyższonymi uprawnieniami, których użytkownik normalnie może nie mieć. Takie podejście pozwala również na zminimalizowanie uprawnień, których może wymagać użytkownik aplikacji. Wtyczki plug-in można wdrażać w rozwiązaniu Dataverse wraz z aplikacjami i przepływami.

• W niestandardowych interfejsach API Dataverse: niestandardowe interfejsy API w Dataverse umożliwiają zaimplementowanie własnego, niestandardowego komunikatu API, który może uruchamiać logikę. Można na przykład utworzyć niestandardowy interfejs API zamykania inspekcji, który jest wywoływany w celu wykonania całej pracy w celu sprawdzenia i zamknięcia inspekcji. Nie będzie on sterowany zdarzeniami, ale będzie używany na żądanie przez aplikacje i przepływy, które go potrzebują. Podobnie jak w przypadku wtyczek sterowanych zdarzeniami, zmiany danych wprowadzone w niestandardowej wtyczce interfejsu API mają charakter transakcyjny. Niestandardowy interfejs API jest najlepszy, gdy jedyną usługą, z której korzysta, jest interfejs API Dataverse do innych zadań związanych z danymi. Plug-in dla niestandardowych interfejsów API można wdrożyć w rozwiązaniu Dataverse wraz z aplikacjami i przepływami.

Implementowanie interfejsu API kodu

Interfejsy API można zaimplementować w ulubionym środowisku uruchomieniowym hostingu interfejsu API, takim jak Azure Functions, Azure Container Apps lub dowolnej usłudze, która może hostować interfejs API REST. Te niestandardowe interfejsy API mogą implementować dowolną logikę i mogą z nich korzystać zarówno aplikacje niskokodowe, jak i tradycyjne. Niestandardowe interfejsy API nie zapewniają żadnej obsługi transakcji innej niż ta, która może być zapewniona przez interfejs API, którego używają. Na przykład niestandardowy interfejs API może używać konstrukcji transakcji serwera SQL, jeśli używa serwera SQL. Wdrożenie interfejsu API kodu będzie niezależne od zasobów niskokodowych, które mogą z niego korzystać. Możesz użyć Azure API Management, aby zarządzać użyciem tych interfejsów API i ułatwić ich odnajdywanie.

Zabezpieczenia

Zabezpieczenia, w tym uwierzytelnianie i autoryzacja, są istotną częścią architektury zmodernizowanej aplikacji. Nowoczesne aplikacje są często trudniejsze do zabezpieczenia niż starsze aplikacje. Obejmują one wiele usług w chmurze, a użytkownicy pracują z nimi z bardziej zróżnicowanych lokalizacji. Koncepcyjnie, bezpieczeństwo w platformie ma na celu zapewnienie, że użytkownicy mogą wykonywać swoją pracę przy jak najmniejszym tarciu, jednocześnie chroniąc dane i usługi.

Power Platform przyjmuje wielowarstwowe podejście do bezpieczeństwa, które można wykorzystać do zbudowania architektury bezpieczeństwa. Podstawowym założeniem tych możliwości jest to, że rozwiązania niskokodowe powinny integrować się z istniejącym aparatem bezpieczeństwa, aby zminimalizować wpływ ich wprowadzenia.

Przyjrzyjmy się wielu warstwom zabezpieczeń, które składają się na model bezpieczeństwa Power Platform.

• Użytkownicy są uwierzytelniani przez Microsoft Entra ID, a korzystanie z nich może być ograniczone przy użyciu zasad dostępu warunkowego.
• Licencjonowanie jest pierwszą bramą sterującą umożliwiającą dostęp do składników Power Platform.
• Możliwość tworzenia aplikacji i procesów jest kontrolowana przez role zabezpieczeń w kontekście środowisk.
• Możliwość wyświetlania i korzystania z zasobów Power Platform przez użytkownika jest kontrolowana przez udostępnianie aplikacji użytkownikowi. Zasoby są udostępniane bezpośrednio użytkownikowi lub grupie identyfikatorów Entra.
• W każdym środowisku muszą zostać zaimplementowane środowiska działające jako granice zabezpieczeń zezwalające na różne zabezpieczenia.
• Przepływy Power Automate i aplikacje oparte na kanwie korzystają z łączników. Konkretne poświadczenia połączeń i powiązane uprawnienia do usługi określają uprawnienia, kiedy aplikacje korzystają z łączników.
• Środowiska, w których wystąpienie Dataverse dodaje obsługę bardziej zaawansowanych modeli zabezpieczeń, które są właściwe do kontrolowania dostępu do danych i usług w tym wystąpieniu Dataverse.
• Użycie łącznika może być dodatkowo ograniczone do zasad ochrony przed utratą danych (DLP). Do łączników mogą być również stosowane ograniczenia przychodzące i wychodzące między dzierżawcami i wyładunkiem wychodzących.

Należy zauważyć, że podczas uzyskiwania dostępu do źródeł danych za pośrednictwem łączników wszystkie podstawowe zabezpieczenia, które oferuje źródło danych, są dodatkiem do warstw zabezpieczeń opisanych powyżej. Power Apps i Power Automate nie zapewniają domyślnie użytkownikom dostępu do źródła danych łącznika, którego jeszcze nie mają. Użytkownicy powinni mieć dostęp tylko do tych danych, których naprawdę potrzebują.

Gdy używasz Dataverse jako część rozwiązania, obejmuje ono model zabezpieczeń oparty na rolach, który można dostosować do wielu scenariuszy biznesowych. Dane można zabezpieczyć aż do pojedynczej kolumny w wierszu danych. Użytkownicy mają przypisaną co najmniej jedną rolę zabezpieczeń, które razem określają ich ogólne uprawnienia. Dataverse udostępnia bloki konstrukcyjne modelowania zabezpieczeń, takie jak jednostki biznesowe i zespoły. Na przykład jednostki biznesowe mogą służyć do definiowania granic zabezpieczeń w celu odizolowania danych między dwiema różnymi grupami użytkowników w organizacji. Za pomocą zespołów można grupować użytkowników, którzy potrzebują podobnego dostępu do danych. Możesz nawet przypisać własność grupy do wierszy danych. Na poniższym diagramie przedstawiono użycie jednostek biznesowych do izolowania danych dla oddziałów organizacji.

Projektowanie modelu zabezpieczeń

Dostosuj model zabezpieczeń zmodernizowanej aplikacji do ogólnej architektury aplikacji. Aplikacje korzystające z jednego repozytorium danych i bez łączników wymagają minimalnych nakładów pracy przy projektowaniu zabezpieczeń. Ponieważ aplikacje używają większej liczby łączników i repozytoriów danych, modelowanie zabezpieczeń musi obejmować inne zagadnienia.

• Tożsamość użytkownika: W jaki sposób użytkownicy uwierzytelniają się i czy zostało to już zamapowane na Microsoft Entra ID w scenariuszach pochodzących ze środowiska lokalnego? Obejmuje to mapowanie grup niezbędnych do obsługi grupy aplikacji lub przypisania zespołu w magazynach danych w chmurze, takich jak Dataverse.

• Tożsamość połączenia łącznika: Gdy aplikacje używają co najmniej jednego łącznika, jaki typ uwierzytelniania jest wykonywany dla połączenia i czy zapewnia poziom kontroli niezbędny do wdrożenia wymaganych mechanizmów kontroli zabezpieczeń? Na przykład aplikacje korzystające z jednostki usługi do nawiązywania połączenia nie wymagają, aby użytkownik aplikacji miał bezpośredni dostęp do łącznika, co może być korzystne w niektórych scenariuszach. Poszczególne połączenia użytkowników mogą być odpowiednie dla aplikacji, które muszą wiedzieć, który użytkownik wykonał operację, lub określać zakres odpowiedzi dla określonych użytkowników.

• Przenośność konstrukcji zabezpieczeń: Ponieważ aplikacje używają większej liczby łączników i repozytoriów danych, należy pamiętać, że nie wszystkie konstrukcje zabezpieczeń jednego mapują bezpośrednio na drugi. Na przykład w Dataverse istnieje wiele sposobów, w jakie użytkownik może uzyskać dostęp do wiersza danych, w tym udostępnić mu wiersz. Jeśli aplikacja kojarzy bibliotekę dokumentów SharePoint z wierszem, zabezpieczenia umożliwiające dostęp do biblioteki dokumentów są niezależne od zabezpieczeń kontrolujących dostęp Dataverse. Nie mapują bezpośrednio. Zmodernizowane aplikacje muszą uwzględniać tego typu niezgodności między łącznikami i repozytoriami danych, których używają.

Sztuczna inteligencja

W ciągu ostatnich kilku lat sztuczna inteligencja znalazła zastosowanie w wysiłkach związanych z modernizacją aplikacji. Podczas modernizacji aplikacji organizacje powinny rozważyć wykorzystanie sztucznej inteligencji, aby zwiększyć produktywność użytkowników i ułatwić podejmowanie świadomych decyzji. Wyniki wprowadzenia sztucznej inteligencji mogą również przełożyć się na lepsze doświadczenia klientów, które pozytywnie wpływają na wyniki biznesowe.

W tym sztuczna inteligencja wiązała się z wielkim wysiłkiem w celu zintegrowania logiki aplikacji i tworzenia niestandardowych wytrenowanych modeli. Dzięki dostępności i możliwościom dużych modeli językowych aplikacje mogą teraz wprowadzać nowe sposoby wykorzystania sztucznej inteligencji, aby pomóc użytkownikom w uzyskiwaniu odpowiedzi i wykonywaniu zadań. Użytkownicy mogą używać monitów w języku naturalnym do interakcji z możliwościami sztucznej inteligencji w szerokiej gamie pomocniczych scenariuszy biznesowych.

Microsoft wprowadziło Copilots do podstawowych produktów i usług, aby ułatwić dostęp do zaawansowanej technologii AI. Copilot wykorzystuje nowoczesne techniki sztucznej inteligencji i duże modele językowe i może wchodzić w interakcje z użytkownikami w aplikacjach, z których korzystają na co dzień, takich jak Microsoft 365, Windows, Dynamics 365 i Power Platform.

Rozszerz za pomocą wtyczek

Użytkownicy aplikacji obsługiwanych przez narzędzie Copilot mogą poprosić Copilot o pomoc w wykonywaniu typowych zadań w aplikacji. Usługę Copilot można rozszerzyć, aby uwzględnić dane i zadania, których jeszcze nie znają i które wykraczają poza zakres aplikacji, z którą pracuje użytkownik. Microsoft 365 Copilot może zawierać dane Power Platform przechowywane w Dataverse, dzięki czemu użytkownicy nie muszą przełączać się między aplikacjami. Na przykład z poziomu programu Outlook użytkownik może poprosić Copilot o wygenerowanie aktualizacji stanu dla wszystkich inspekcji, które zakończyły się dzisiaj niepowodzeniem. Microsoft 365 Copilot automatycznie dziedziczy natywną strukturę zabezpieczeń i nadzoru Dataverse oraz stosuje zabezpieczenia i uprawnienia użytkowników w czasie wykonywania.

Złącza jako wtyczki

Łączniki Power Platform są również ważne dla doświadczenia Copilot. Złącza mogą łączyć się jako wtyczki, aby rozszerzyć możliwości Copilot. Przykładowo, Microsoft 365 Copilot z łącznikiem Power Platform dla oprogramowania Jira może umożliwić kierownikowi projektu zażądanie statusu zgłoszenia do pomocy technicznej Jira i podjęcie działań na podstawie odpowiedzi, takich jak przekierowanie go do dalszego zatwierdzenia lub rozpoczęcie zlecenia zakupu nowego sprzętu. Korzystając z wtyczek, możesz zintegrować swoje procesy biznesowe i dane z Copilot, aby umożliwić użytkownikom interakcję z dowolnych aplikacji, z których korzystają.

Utwórz własnego pomocnika

W miarę jak użytkownicy coraz bardziej przyzwyczajają się do asystenta AI w swoich aplikacjach, oczekują jego obecności we wszystkich aplikacjach. Możesz zwiększyć atrakcyjność nowoczesnych aplikacji, dołączając pomocników tworzonych za pomocą Copilot stack, platformy programistycznej AI.

Możesz użyć wstępnie utworzonej kontrolki Copilot w Power Apps, aby dodać pomocników do aplikacji kanwy i aplikacji opartych na modelu. Konfigurując widok źródła danych i podstawowe informacje o monitach, możesz szybko zapewnić własne środowisko pomocnika w aplikacji.

Zarządzanie cyklem życia aplikacji

Ważną częścią wszelkich działań modernizacyjnych jest ustanowienie odpowiedniego procesu zarządzania cyklem życia aplikacji. Organizacje często chcą, aby ich wysiłki związane z małą ilością kodu pasowały do sposobu pracy z tradycyjnym zarządzaniem cyklem życia aplikacji (ALM) kodu. Power Platform udostępnia narzędzia ALM, dzięki którym można dołączać artefakty z małą ilością kodu do procesów, których zwykle używasz, lub obok nich.

Zarządzanie cyklem życia aplikacji (ALM) w Power Platform rozpoczyna się od sposobu tworzenia zasobów niskokodowych. Zasoby, które tworzysz, znajdują się w kontekście środowiska Power Platform. Środowisko może mieć jeden magazyn danych Dataverse. Możesz użyć wielu środowisk — zazwyczaj deweloperskich, testowych i produkcyjnych — do zaimplementowania stref docelowych w procesie zarządzania cyklem życia aplikacji (ALM), który obejmuje małą ilość kodu. Liczba i przeznaczenie środowisk są elastyczne, a organizacje mogą je dostosować do indywidualnych potrzeb projektu. Rozwiązanie Dataverse to kontener dla powiązanych zasobów niskokodowych, ułatwiający kontrolę wersji i transport z jednego środowiska do drugiego.

Potoki Power Platform zapewniają niskokodowe podejście do automatyzowania wdrożeń oraz implementowania ciągłej integracji i ciągłego dostarczania (CI/CD). Power Platform zarządza procesem podczas konfigurowania potoków. Administratorzy mogą centralnie zarządzać potokami i nadzorować je.

Organizacje mogą również korzystać z wybranych przez siebie narzędzi ciągłej integracji/ciągłego wdrażania. Power Platform CLI to narzędzie wiersza polecenia, którego można używać z większością narzędzi do automatyzacji ciągłej integracji/ciągłego wdrażania. Power Platform Build Tools zapewnia akcje dla GitHub i zadania dla Azure DevOps, które zapewniają wszystkie typowe akcje wymagane do tworzenia automatyzacji CI/CD, które obejmują artefakty o niskim kodzie.

Na poniższym diagramie przedstawiono przykład zespołu tworzącego aplikację Inspekcja. W swojej wewnętrznej pętli pracują w środowisku deweloperskim i przechowują swoją pracę w repozytorium Git. Pętla zewnętrzna składa się ze środowiska testowego i środowiska produkcyjnego. Potok kompilacji pobiera rozwiązanie z kontrolą wersji, przeprowadza wszelkie niezbędne kontrole i tworzy artefakt rozwiązania inspekcji. Następnie potok wydania wdraża rozwiązanie do przetestowania, gdzie testerzy mogą sprawdzić, czy jest gotowe do produkcji. Po zatwierdzeniu potok wydania wdraża rozwiązanie w środowisku produkcyjnym.

Podczas eksportowania rozwiązania z Dataverse jest ono eksportowane jako pojedynczy skompresowany plik. Aby przechowywać zasoby niskokodowe w kontroli wersji, można użyć narzędzi kompilacji, aby rozpakować plik rozwiązania do poszczególnych plików składników. Podczas automatyzacji kompilacji narzędzia kompilacji łączą poszczególne pliki z kontroli wersji w jeden skompresowany plik.

Wdrożenie rozwiązania w środowisku, które zawiera poprzednią wersję rozwiązania, korzysta z inteligentnego procesu uaktualniania, który stosuje tylko zmiany. Ten proces uaktualniania pozwala uniknąć konieczności stosowania skryptów różnicowych lub innych sposobów określania, co należy wdrożyć.

Gdy zmodernizowana aplikacja zawiera zasoby niskokodowe i tradycyjne, można połączyć je w jeden proces ciągłej integracji/ciągłego wdrażania lub zarządzać nimi niezależnie. Dzięki niezależnemu zarządzaniu zasoby mogą być rozmieszczane indywidualnie, a zespoły projektowe mogą osiągnąć większą elastyczność. Na przykład interfejs API używany przez aplikację niskokodową może zostać wdrożony niezależnie, jeśli zespół nie wprowadzi zmian powodujących niezgodność.

Monitorowanie i szczegółowe informacje

Zmodernizowane aplikacje muszą integrować się ze środowiskami operacyjnymi, które zapewniają możliwość diagnozowania problemów w różnych środowiskach, od programowania po produkcję. Application Insights, rozszerzenie Azure Monitor, zbiera dane telemetryczne z Power Apps oraz Dataverse. Te informacje nie tylko pomagają w identyfikowaniu i rozwiązywaniu problemów, ale także zapewniają wgląd w to, co użytkownicy robią w aplikacji. Możesz użyć tych analiz, aby ulepszyć aplikacje i procesy w zmodernizowanej aplikacji.

Gdy aplikacja Power Apps jest w fazie rozwoju, deweloperzy mogą dołączyć logikę do rejestrowania zdarzeń niestandardowych. Po połączeniu wdrożonej aplikacji z Application Insights rozszerzenie automatycznie gromadzi podstawowe dane telemetryczne, w tym więcej kontekstu z zarejestrowanych zdarzeń, gdy użytkownicy wchodzą w interakcję z aplikacją.

Administratorzy mogą również skonfigurować środowiska Dataverse do eksportowania danych telemetrycznych do Application Insights. Rejestrowane dane mogą obejmować wywołania interfejsu API Dataverse, wykonywanie dodatków plug-in, operacje zestawu SDK i wyjątki. Programiści tworzący niestandardową logikę plug-in mogą rejestrować więcej niestandardowych danych telemetrycznych bezpośrednio do Application Insights.

Używanie Application Insights w różnych aplikacjach może ułatwić korelowanie problemów z wieloma zasobami. Personel operacyjny może tworzyć alerty w programie Azure Monitor, które będą wyzwalane po wykryciu dużej liczby wyjątków. Regularna analiza zmodernizowanych aplikacji może zidentyfikować trendy, które wymagają dokładniejszego zbadania.

Podsumowanie

W tej białej księdze przeanalizowaliśmy korzyści, strategie i najlepsze praktyki modernizacji starszych aplikacji za pomocą Microsoft Power Platform. Uzyskano wgląd i wskazówki dotyczące wykorzystania możliwości niskokodowych Power Platform w celu zapewnienia powodzenia wysiłków modernizacyjnych w ramach cyfrowej transformacji organizacji.

Starsze aplikacje stawiają wiele wyzwań przed organizacjami. Aby je przezwyciężyć, organizacje muszą podjąć inicjatywy modernizacji aplikacji, aby ożywić swoją infrastrukturę i wykorzystać nowoczesne technologie. W tym oficjalnym dokumencie dowiedziałeś się, jak zastosować niskokodowe podejście do wysiłków modernizacyjnych - w szczególności, w jaki sposób niskokodowe możliwości programistyczne Microsoft Power Platform pozwalają szybko tworzyć i wdrażać nowoczesne aplikacje.

Low-code otwiera drzwi do szerszego grona osób niż tradycyjni programiści. Kluczowym czynnikiem organizacji, które odnoszą sukcesy dzięki podejściu niskokodowemu, jest upewnienie się, że osoby zaangażowane w modernizację aplikacji są przeszkolone w zakresie programowania niskokodowego, niezależnie od tego, czy są profesjonalnymi deweloperami, czy użytkownikami biznesowymi. Użytkownicy biznesowi są bliżej rozwiązywanego problemu biznesowego i mogą wnieść swoją wiedzę pozwalającą zaoszczędzić czas. Tradycyjni programiści kodu mogą zastosować techniki i umiejętności, które już posiadają, aby tworzyć rozszerzenia, które wypełnią wszelkie luki w niskokodowym programowaniu. Organizacje mogą być najbardziej efektywne, łącząc zasoby biznesowe i techniczne w czymś, co lubimy nazywać "zespołami fuzyjnymi".

Ten oficjalny dokument stanowi podstawę dla Ciebie. Kolejne kroki należą do Ciebie. Oto kilka sugestii:

• Poświęć kilka minut, aby dowiedzieć się, co Twoja organizacja już robi z platformą niskokodową. To może Cię zaskoczyć!
• Oceń możliwości modernizacji aplikacji.
• Zidentyfikuj i nadaj priorytet dobremu pierwszemu kandydatowi.
• Zatrudnij zespół, który zmodernizuje aplikację. Aby uzyskać najlepsze wyniki, upewnij się, że jest to zespół z różnych dziedzin ekspertyzy.
• Upewnij się, że zespół przeszedł niezbędne szkolenie, aby odnieść sukces.
• Pozwól zespołowi zmodernizować aplikację.
• Zastanów się nad wysiłkiem modernizacyjnym. Uściślij go i skaluj do innych aplikacji dziedziczone.

Droga każdej organizacji do modernizacji aplikacji jest wyjątkowa. Twój zespół obsługi klienta Microsoft lub partner Power Platform może pomóc Ci zaplanować podróż i utrzymać Cię na właściwej ścieżce po drodze.

Zasoby

• Całkowity wpływ gospodarczy™ funkcji premium Microsoft Power Platform
• Aplikacja American Airlines ConnectMe zapewnia płynniejsze podróżowanie klientom i lepsze narzędzia technologiczne dla członków zespołu
• Repozytorium Power Fx o otwartym kodzie źródłowym w serwisie GitHub
• Zestaw startowy Centrum doskonałości
• Ocena wdrożenia Power Platform
• Cyfrowa agencja ubezpieczeniowa automatyzuje złożony proces zakupowy za pomocą Power Platform
• Galeria PCF
• EY pomaga umożliwić wejście u źródła do globalnego procesu finansowego dzięki Power Platform, skracając czas realizacji o 95 procent
• Azure Private Link
• Microsoft Azure ExpressRoute
• Funkcja planowania wdrożeń Power Platform
• Przewodnik licencjonowania usługi Microsoft Power Platform
• Microsoft nakreśla ramy tworzenia aplikacji i Copilotów AI; rozszerza ekosystem wtyczek AI