Automatyzacja w Power Platform

Problem

Trzyosobowy zespół platformy obsługujący 7000 pracowników nie zbuduje ręcznie każdego zgłoszenia z działów, a większość z nich i tak nie jest pracą programistyczną. To powtarzające się schematy: powiadom tę grupę, gdy w tamtej bibliotece pojawi się dokument, utwórz stronę z szablonu z właściwymi metadanymi i uprawnieniami, zbierz cotygodniowy raport z listy, przypomnij o zaległym zadaniu. Zapisane jako kod, każde z nich oznacza wydanie, wdrożenie i osobę do utrzymania.

Co zrobiłem

Zbudowałem warstwę poniżej tworzenia oprogramowania na zamówienie: przepływy do onboardingu w spółce z grupy, powiadomienia o dokumentach jakościowych w dwóch zakładach, rejestr ochrony danych z mechanizmem sprawdzania spójności, zestawienia z Plannera, konwersję newslettera i wiele innych, od jednoakcyjnego narzędzia po przepływ onboardingowy ze 146 akcjami. Około jedna trzecia jest wywoływana przez aplikację Power Apps albo przez HTTP, więc przepływ jest serwerową częścią aplikacji, a nie powiadomieniem w tle.

Dla prawniczej bazy wiedzy zbudowałem trzy aplikacje Power Apps i ich przepływy back-endowe, dzięki którym zespół prawny sam tworzy sekcję, stronę, bibliotekę i jej uprawnienia, bez programisty. Te przepływy w większości w ogóle nie korzystają z konektora: 100 ze 105 wywołań konektora to ręcznie pisane żądania REST do SharePointa, bo standardowy konektor nie potrafi ustawić pól, których wymagał dział.

Decyzja i jej koszt

Przepływy zamiast kodu w tej warstwie, bo właściciel przepływu jest tam, gdzie przepływ działa: właściciel witryny może go przeczytać, a zespół platformy może go przekazać dalej. Azure Function wykonująca to samo zadanie to wdrożenie, sekret, monitoring i osoba do utrzymania; to uczciwa wymiana przy złożonej logice i zła przy „wyślij maila do tej grupy, gdy pojawi się plik”. Przepływ onboardingowy ze 146 akcjami to uczciwa granica tego argumentu, w której wymiana zaczyna się odwracać.

Ręczne wywołania REST mają własny koszt: to część najbardziej narażona na awarię przy zmianie API i ta, którą koledze z zespołu najtrudniej przejąć.