Sposoby logowania Power Automate Cloud Flow bez Center of Excellence na przykładzie Dataverse

Tworząc oprogramowanie na bazie Power Platform, jedną z usług, które mamy do dyspozycji, jest Power Automate. Korzystając z Power Automate, możemy stworzyć automatyzacje, do przygotowania których dawniej byłyby wymagane dedykowane zespoły IT składające się z analityków, programistów i administratorów. Jednak takie uproszczenie niesie ze sobą również większą odpowiedzialność, szczególnie dla osób, które tworzą nowe automatyzacje.

Jedną ze wspomnianych odpowiedzialności jest zarządzanie i administracja przepływami, a w przypadku, gdy coś pójdzie nie tak – analiza przyczyn. W takich sytuacjach nieocenione stają się logi (dziennik) zawierające informacje o zdarzeniu, które nastąpiło. W Power Automate mamy oczywiście funkcję automatycznego logowania, jednak to rozwiązanie ma znaczące ograniczenia w przeglądaniu i wyszukiwaniu historycznych danych.

W artykule zapraszam do zgłębienia dodatkowych sposobów, które pomogą nam rozszerzyć standardowe logowanie, ułatwiając ich historyczne przeglądanie, odszukiwanie konkretnych uruchomień mechanizmów, czy też dodając kontekst biznesowy do każdego z uruchomionych mechanizmów.

Jakie problemy chcemy rozwiązać?

W momencie diagnostyki mechanizmów Cloud Flow możemy stanąć przed kilkoma wyzwaniami:

1. Trudności w odczytywaniu szczegółów historycznych uruchomień Power Automate Cloud Flow – ten, kto korzystał z odczytu historii uruchomień poszczególnych Cloud Flow, wie, że nie jest to najprzyjemniejsze miejsce do szukania informacji. W szczególności, gdy interesuje nas konkretne uruchomienie, ale sami nie wiemy które.
2. Trudności w identyfikacji konkretnego uruchomienia Cloud Flow, które chcemy zbadać – w Cloud Flowach uruchomionych produkcyjnie naturalną sytuacją jest uruchamianie takiego flow minimum setki razy dziennie. Taki flow może kończyć się różnymi stanami – Successful, canceled, failed. Oczywiście, w idealnym świecie powinniśmy dążyć do wyeliminowania uruchomień failed, jednak w praktyce często okazuje się, że musimy szybko zidentyfikować krytyczny przypadek, przez który nasza produkcyjna aplikacja nie działa. W takiej sytuacji standardowe logi mogą spowolnić nasze wysiłki rozwiązywania krytycznych błędów, a jak wiemy – utraconego czasu nie sposób odzyskać.
3. Trudności w identyfikacji, który konkretnie flow wpłynął w danym momencie na dany rekord – jeśli przygotowujemy aplikację, w ramach której działa wiele Cloud Flow wchodzących w interakcje z tym samym rekordem, może pojawić się problem kolejności wykonywanych działań (Cloud Flow są wyzwalane jako mechanizmy asynchroniczne). W takim przypadku nieocenione są informacje, jaki mechanizm spowodował poszczególną zmianę na rekordzie.

W dalszej części artykułu wymienię kilka propozycji, jak zapobiegać takim sytuacjom. Wskazane sposoby należy traktować jako pewną propozycję rozwiązań i wykorzystać te, które uważamy za najbardziej dla nas przydatne. Żadne z poniższych rozwiązań nie jest rozwiązaniem idealnym, jednak każde przybliża nas do odpowiedzi na wyzwania, przed którymi stajemy.

Na potrzeby artykułu będę wykorzystywał bazę danych Dataverse oraz funkcjonalność Audit History. Możemy z powodzeniem zastosować te same metody np. na listach SharePoint, bazach SQL, plikach Excel, czy w dowolnym rozwiązaniu, w którym da się dodać kilka pól czy tabel do przechowywania dodatkowych informacji.

Scenariusz biznesowy

Żeby bardziej wczuć się w sytuację i przybliżyć przypadki, których będzie dotyczyć ten artykuł, załóżmy, że pracujemy dla firmy Contoso, która sprzedaje swoim klientom miesięczny abonament na swoją usługę. W Contoso działają 4 mechanizmy Cloud Flow odpowiadające za:

1. Integracje z systemem ERP,
2. Integracje z systemem Marketingowym,
3. Integracje z systemem Sprzedażowym,
4. Proces zatwierdzeń.

Jeden z pracowników zgłosił nam, że zauważył błąd w systemie. Klient John Smith kupił miesięczną subskrypcję, ale system wyświetla go jako klienta potencjalnego, a nie jako aktualnego. Mamy zlokalizować przyczynę tego błędu. Zerknijmy na rekord klienta:

Na szczęście Dataverse ma dużą liczbę wbudowanych funkcji śledzenia zmian i operacji na rekordach. Jedną z nich jest historia zmian (Audit history[1]), dzięki której będziemy mogli zapoznać się ze zmianami na rekordzie:

Przeglądając Audit History, widzimy, że typ klienta został ustawiony przez użytkownika aplikacyjnego[2] Power Automate. Z dużym prawdopodobieństwem możemy stwierdzić, że w takim razie zrobił to któryś z naszych Cloud Flow. Ale który? A jak już dowiemy się, który mechanizm – to które jego uruchomienie?

Na nasze pytania nie znajdziemy odpowiedzi w Audit History, ponieważ system nie zapisuje tutaj tych informacji. Co prawda, Power Automate zapisuje 28-dniową historię uruchomień[3], ale gdy np. chcemy dowiedzieć się więcej o kontekście uruchomienia danego flow, czy sprawdzić który flow wpłynął na dany rekord, to musimy sami zadbać o zalogowanie takich danych. W tym artykule skupimy się na tym, jak radzić sobie z takimi wyzwaniami.

Sposób 1 – logowanie kontekstu zmiany na poszczególnych rekordach

Omówienie implementacji

Pierwszy sposób jest jednym z najprostszych i moich ulubionych – w szczególności w przypadku korzystania z Dataverse. Jedną z funkcjonalności OOTB (Out Of the Box) jest funkcjonalność Audytu/historii inspekcji, czyli osobnej tabeli, która automatycznie śledzi informacje o operacjach wykonanych na danym rekordzie.

W tym przypadku skupimy się na rozszerzeniu takiej historii audytu o dodatkowe informacje (Uwaga! Jeśli chcesz wykorzystać ten sposób logowania w innym systemie niż Dataverse – bez odpowiednika historii inspekcji, stracisz część benefitów tego rozwiązania! Jednak możesz przygotować podobny mechanizm samodzielnie, tworząc dodatkową tabelę, w której będziesz przechowywał historię zmian danego rekordu).

W przypadku korzystania z Power Automate możemy łatwo rozszerzyć logowanie, dodając informacje, który Cloud Flow i które jego historyczne uruchomienie wpłynęły na dany rekord. W tym celu wystarczy rozszerzyć nasze rozwiązanie o kilka elementów:

1. W naszym systemie dodajemy dwa nowe pola:
   • Pole nr 1 – Power Automate Instance URL,
   • Pole nr 2 – Power Automate Cloud Flow name.
2. W naszym Cloud Flow dodajemy dwie zmienne:
   • Zmienna nr 1 – PowerAutomateInstanceURL – będzie tworzyć i przechowywać unikatowy adres URL każdego uruchomienia Power Automate,
   • Zmienna nr 2 – PowerAutomateCloudFlowName – będzie odczytywać nazwę naszego Cloud Flow i ją przechowywać. Nawet jeśli zmienimy nazwę Cloud Flow, zmienna zawsze odczyta aktualną nazwę.
3. Rozszerzamy Cloud Flow tak, by za każdym razem, gdy edytuje rekord w systemie, zapisywał powyższe informacje na rekordzie.

Na potrzeby artykułu założymy, że jesteśmy już po rozszerzeniu naszego systemu o nowe pola i skupimy się na konfiguracji mechanizmu. Z perspektywy Cloud Flow musimy wykonać następującą konfigurację:

1. Dodajemy zmienną PowerAutomateInstanceURL, a jako jej wartość podajemy wyrażenie ujęte na stronie

2. Dodajemy zmienną PowerAutomateCloudFlowName, a jako jej wartość ustawiamy: workflow()?[’tags’][’flowDisplayName’]

3. Analizujemy nasz Cloud Flow i w każdej akcji, w której tworzymy czy też aktualizujemy rekord, uzupełniamy nasze nowe pola nowymi zmiennymi

4. Zapisujemy Cloud Flow i uruchamiany jego testowanie

Po uruchomieniu Cloud Flow możemy podejrzeć, jakie wartości zostały zapisane w zmiennych. Poniżej przykład zmiennej z dynamicznie budowanym adresem URL uruchomienia Power Automate:

Od teraz każde uruchomienie Cloud Flow zapisze nam na rekordzie, który mechanizm i które jego uruchomienie wpłynęło na rekord. Jeśli mamy skonfigurowane wiele Cloud Flow, to te dane będą się nam nadpisywać.

Jednak korzystając z Dataverse, otrzymujemy możliwość śledzenia historii zmian. Odkrywa ona całą siłę tej funkcjonalności – dostajemy historię operacja po operacji, co stało się z naszym rekordem. W tym przypadku głównym benefitem jest informacja, jaki konkretny mechanizm wpłynął na poszczególny rekord i jaki jest adres URL do prześledzenia historycznego uruchomienia. Jeśli użytkownicy zgłosiliby błąd danych czy błąd systemu powiązany z tym poszczególnym klientem, możemy w prosty i szybki sposób prześledzić, jakie mechanizmy wpłynęły na poszczególny rekord.

Jeśli nie korzystasz z Dataverse, możesz z powodzeniem zbudować taką samą historię zmian jako osobną tabelę, która będzie śledziła, jaki mechanizm wpłynął na dany rekord. Jednak wykracza to poza ten artykuł.

Z perspektywy aplikacji opartej o Dataverse otrzymujemy dodatkową informację, jakie jest źródło danej zmiany:

Konsekwencje i skutki uboczne

Jakie konsekwencje i skutki uboczne będzie miało wprowadzenie takiego rozwiązania?

1. W większości przypadków użytkownik, który ma dostęp do rekordu w bazie danych, otrzyma również dostęp do pola w linkiem URL historycznego wywołania. Umożliwi mu to odczytanie historii operacji i szczegółów Cloud Flow, a jeśli ma uprawnienia do edycji – również edycję Cloud Flow.

Poniżej przedstawię listę propozycji, jak możemy poradzić sobie z tymi konsekwencjami:

1. Aby uniknąć tego problemu, należy przejrzeć uprawnienia użytkowników i upewnić się, że użytkownicy nie będą mogli edytować tych Cloud Flow (np. Cloud flow uruchamiane przez wybrane wyzwalacze (ang. triggers[4]) można ustawić w trybie Run Only[5] dla wybranej grupy użytkowników).
2. W wybranych sytuacjach być może trzeba będzie stworzyć dwa Cloud Flowy: pierwszy flow jako Child flow[6] wykonujący całą logikę biznesową, i drugi flow, który w określonym momencie w systemie uruchomi Child Flow.
3. Rozwiązaniem najprostszym, choć nieidealnym, będzie ograniczenie dostępu użytkownikowi do tego pola, np. w Dataverse można to osiągnąć, stosując Column Security Profile[7]. Zastosowanie tej opcji ograniczy dostęp do tego pola użytkownikowi już na poziomie API Dataverse, tak więc niezależnie od tego, w jaki sposób będzie próbował odczytać dane, nie będzie w stanie tego osiągnąć.

Sposób 2 – logowanie wyniku uruchomień i poszczególnych Cloud Flow w osobnych tabelach

Omówienie implementacji

Innym sposobem niestandardowego logowania jest zapisywanie informacji o wyniku naszego Cloud Flow w osobnej tabeli, czy innym wybranym przez nas miejscu. Na potrzeby tego artykułu stworzę prostą tabelę przechowującą kilka informacji o naszych Cloud Flow:

1. Power Automate Cloud Flow name – pole tekstowe przechowujące informacje o nazwie naszego Cloud Flow,
2. Power Automate Instance URL – pole tekstowe przechowujące informacje o adresie URL wyzwolenia poszczególnego Cloud Flow,
3. Status operacji – wynik naszego Cloud Flow.

Możemy zauważyć, że elementy 1 oraz 2 są dokładnie takie same, jak w przypadku sposobu nr 1, tak więc będziemy tutaj wykorzystywać te same funkcje, co w poprzednim sposobie.

Jedyną zmianą w tym przypadku jest status operacji naszego Cloud Flow. Tutaj może pojawić się pytanie – jak odczytać taki status? Aby to zrobić, niezbędne będzie odpowiednie poukładanie operacji w naszych Cloud Flow. Poniżej znajduje się diagram, który przybliża nam strukturę sprzyjającą takiemu logowaniu:

Krótkie objaśnienie każdego z etapów:

Poniżej instrukcja dodania takiego loggera:

1. Krok 1 – po naszym scope „Do Business Logic” dodajemy kolejny scope i nazywamy go „Logger – Possitive”

2. Krok 2 – dodajemy nowy parallel branch wychodzący z Do Business Logic

3. Krok 3 – w nowym parallel branch dodajemy nowy scope, który nazywamy Logger – Negative i w szczegółach akcji konfigurujemy „Run After[9]”

4. Krok 4 – logger Negative powinien być uruchomiony tylko wtedy, gdy cały scope „Do Business Logic” wykona się negatywnie. Wobec tego zaznaczamy wszystkie opcje poza „Is Successful”

5. Krok 5 – mając tak przygotowane scope, możemy dodać logikę logowania. Przypominam, że najlepiej by było wykorzystać child flow, ale na potrzeby uproszenia artykułu, użyję zwykłego dodania rekordu. W naszym rekordzie logu zapiszemy sobie Nazwę Cloud Flow, adres URL wywołania i status naszego flow. Wynik takiej przykładowej konfiguracji można zobaczyć poniżej:

Z kolei w naszej bazie zaczną się odkładać informacje o historycznych uruchomieniach, ułatwiając przeglądanie informacji o błędach:

Konsekwencje i skutki uboczne

Jakie konsekwencje i skutki uboczne będzie miało wprowadzenie takiego rozwiązania? Poniższa lista przybliży nam odpowiedź na to pytanie:

1. Ze względu na to, że rozwiązanie nr 2 dziedziczy kilka funkcjonalności z rozwiązania nr 1 – wszystkie konsekwencje z poprzedniego rozwiązania mają zastosowanie również tutaj.
2. Zastosowanie tego rozwiązania doda nam do systemu nową tabelę, która będzie zwiększać swoją objętość za każdym razem, gdy mechanizm zostanie uruchomiony (innymi słowy – będzie zajmować nam cenną przestrzeń bazodanową).
3. Nowa tabela będzie dodatkowym komponentem, o którym będziemy musieli pamiętać, podczas nadawania dostępu administratorom czy innym osobom odpowiedzialnym za monitorowanie działania systemu.
4. Jeśli z jakiegoś powodu ostatni kafelek/akcja (logger) nie wykona się poprawnie, cały Cloud Flow zostanie oznaczony jako failed.

Poniżej również lista propozycji, jak możemy poradzić sobie z tymi konsekwencjami:

1. W przypadku zwiększania się objętości tabeli logów – możemy przygotować mechanizm regularnie usuwający logi z nowej tabeli. W przypadku korzystania z Dataverse możemy wykorzystać funkcjonalność Buld Delete[10] lub stworzyć kolejny mechanizm Power Automate w oparciu o Schedule Trigger[11], który usunie nam rekordy według ściśle określonej logiki (np. rekordy starsze niż 365 dni).
2. W przypadku zarządzania dostępem do nowej tabeli – w przypadku Dataverse możemy utworzyć nową niestandardową rolę (Security Roles)[12], którą będziemy nadawać osobom odpowiedzialnym za monitorowanie działania systemu.
3. W przypadku błędu w wykonaniu ostatniego kafelka – tutaj niestety jedyne, co możemy robić, to monitorować sytuację z poziomu Microsoft Power Automate | Home i sprawdzać historię wywołań, korzystając np. z XRMToolBox[13] i Flow Execution History[14], a następnie eliminować problemy, które spowodowały błędy w mechanizmie logowania. Niestety, nie ma sposobu, aby niestandardowo zalogować błąd w niestandardowym mechanizmie logowania 😊 W tym wypadku jest to nasz ostateczny punkt potencjalnego błędu.

Sposób 3 – logowanie uruchomienia i zakończenia poszczególnych Cloud Flow w osobnych tabelach

Omówienie implementacji

Ostatni sposób w tym zestawieniu łączy oba poprzednie. Jednak tym razem dodamy dodatkowy etap, który poinformuje nas o tym, że jakiś flow jest w trakcie procesu. Takie logowanie jest szczególne przydatne np. w przypadku korzystania z Approval Connector, gdzie możemy mieć uruchomiony szereg różnych procesów akceptacji, nie mając do końca świadomości o tym i nie znając skali zjawiska.

Na potrzeby tego rozbudowanego scenariusza musimy również zaktualizować naszą strukturę Cloud Flow. Poniżej zaktualizowana struktura:

Krótkie objaśnienie zaktualizowanych etapów:

I aktualizacja naszych Cloud Flow. Zaczynamy od dodania mechanizmu logującego nad „Do Business Logic” (jak już wspomniałem – w większości przypadków powinien być to Cloud Flow Child Flow, ale na potrzeby artykułu zrobimy zwykłą pojedynczą akcję). W naszym przypadku dodamy tutaj akcję „Create a new record”, która stworzy nowy log Power Automate i ustawi jego status na „In Progress”.

Mając tak skonfigurowaną akcję, pozostaje nam jedynie zaktualizować operację na końcu naszych mechanizmów. Teraz na końcu mechanizmów zamiast tworzenia nowych rekordów będziemy aktualizować istniejący. Usuńmy operację tworzenia nowego rekordu, a w jej miejsce wybierzmy operację aktualizacji rekordu. Jako ID aktualizowanego rekordu podamy ID rekordy utworzonego w etapie nr 2:

Pozostaje ustawić odpowiedni status: „”successful” dla logera Positive i „Failed” dla loggera negative. Poniżej wynik końcowy takiej konfiguracji:

A jak to będzie wyglądać z perspektywy systemu? Jeśli otworzymy nasz widok Cloud Flowów w trakcie wykonywania jakiegoś mechanizmu, zobaczymy, że status operacji jest „In Progress”. Mając link URL, możemy przejść od razu do szczegółów uruchomienia Cloud Flow, sprawdzić na jakim jest etapie, na jakie zatwierdzenia czeka, itp. Gdy Cloud Flow skończy pracę zmieni swój status na „Successful” lub „Failed” (w zależności od tego, co się wydarzy).

Konsekwencje i skutki uboczne

Jakie konsekwencje i skutki uboczne będzie miało wprowadzenie takiego rozwiązania? Poniższa lista przybliży nam odpowiedź na to pytanie:

1. Z racji, że to rozwiązanie jest połączeniem obu wcześniejszych opcji, to wszystkie wcześniej wymienione konsekwencje i skutki uboczne będą mieć tutaj zastosowanie.
2. Jeśli kafelek/akcja Start Logger wykona się niepoprawnie/błędnie, może doprowadzić do przerwania całego Cloud Flow.

Poniżej również lista propozycji, jak możemy poradzić sobie z tymi konsekwencjami:

1. W przypadku kafelek/akcja Start Logger – jeśli zależy nam, by wykonać logikę biznesową nawet wtedy, gdy mechanizm logowania zawiedzie, możemy skonfigurować operację Run After tak, aby Cloud Flow wykonał dalszą logikę niezależnie od wyniku logowania. Niestety, finalnie bez rozpoczęcia logowania nie uda się również jego zakończenie, co spowoduje błąd na samym końcu procesu i oznaczenie Cloud Flow jako wykonanego niepoprawnie. W przypadku wykrycia takich sytuacji rekomendowałbym śledzenie historii uruchomień za pomocą standardowych mechanizmów Power Automate.

Podsumowanie i dalsze kroki

W artykule skupiliśmy się na niestandardowych mechanizmach logowania Cloud Flow. Należy zaznaczyć, że przedstawione wyżej sposoby to jedynie propozycje, które mogą, ale nie muszą, pasować do danego projektu. Mogą być gotowym sposobem rozwiązania problemu lub też dobrym wstępem do poszukiwania własnego sposobu. Zachęcam do opracowania mechanizmów dostosowanych do indywidualnych potrzeb sytuacji i projektu 😊

***

Jeśli interesuje Cię tematyka Power Platform, zajrzyj koniecznie do drugiego artykułu autora: Power Platform od strony administracyjnej – podstawy konfiguracji środowisk

[1] Dokumentacja funkcjonalności

[2] W ekosystemie Microsoft możemy autoryzować się jako użytkownik zwykły i nieinteraktywny. Jednym z podtypów użytkowników nieinteraktywnych jest Application User

[3] Funkcjonalność szczególnie przydaje się w sytuacji podstawowej diagnostyki błędów

[4] Dokumentacja triggerów

[5] Omówienie Run Only Users

[6] Omówienie Child Flowów

[7] Omówienie funkcjonalności Column Security Profile

[8] Dokumentacja Variables

[9] Dokładniejsze omówienie operacji Run After

[10] Dokumentacja funkcjonalności

[11] Dokumentacja Cloud Flow wyzwalanych automatycznie o określonej porze

[12] Omówienie tworzenia i zarządzania Security Roles w Dataverse

[13] Omówienie XRMToolBoxa

[14] Omówienie narzędzia Flow Execution History