# #16 Nauka Power Automate — Child Flows

Cześć! Witam Was po dłużej przerwie, mam nadzieję, że teraz zdrowie pozwoli mi już kontynuować i będę mógł nagrywać regularnie odcinki i je publikować dla Was. Dzisiaj chciałem opowiedzieć o takim mechanizmie jak Child Flow w Power Automate, troszeczkę też pokazać trochę więcej zaawansowanych opcji w Power Automate przy okazji, pokazać jak z tego korzystać i jakie realnie może to przynieść korzyści.

Wyobraźmy sobie, że stworzyliśmy już kilka systemów w naszej organizacji: system Zgłoszeń Helpdesk IT, system Wniosków Urlopowych i system Wypożyczem Sprzętu IT. Wszystkie te systemy wykorzystują jedną z funkcjonalności powtarzających się — mianowicie wysyłkę maili. W każdym z tych procesów wysyłane są w jakiejś formie maile i tak naprawdę robiąc teraz jakieś przepływy w Power Automate, za każdym razem budujemy tam akcję wysyłki maila.

Możemy do tego podejść centralnie — i tutaj wchodzą właśnie Child Flows. Możemy stworzyć taki Child Flow „Wysyłka maili". Po co nam to? Możemy uruchamiać taki Child Flow z każdego z tych systemów niezależnie. Zamiast tworzyć trzy akcje osobne do wysyłki maili tworzymy jedną i każde kolejne rozwiązanie, które pojawi się w organizacji możemy sukcesywnie podpinać pod to Child Flow.

Child Flow jest tak naprawdę kolejnym Power Automate'em. Tylko jest to Power Automate, który przyjmuje pewne warunki na wejściu i daje jakąś odpowiedź czy wszystko wykonało się poprawnie. W środku może mieć miejsce coś, co wykorzystujemy wszędzie tak samo.

Child Flow daje nam to, że możemy go wykorzystywać wielokrotnie w wielu procesach. Nie musimy na nowo budować pewnych rzeczy. Możemy dzięki temu też zacząć budować standardy — możemy stworzyć taki Automate do wysyłki maili z pewną stałą stopką, papeterią mailową, więc zachowujemy sobie standard. Mało tego, jeśli w przyszłości uznamy, że zmieniliśmy branding organizacji, trzeba zmienić kolorki, trzeba zmienić podpis — nie zmieniamy tego w każdym procesie osobno, tylko wchodzimy do tego centralnego Power Automate'a, do tego Child Flow i tam nanosimy zmianę, przez co wszystkie procesy zaczynają korzystać już z tego nowego podejścia.

Zbudowałem sobie zwykły przepływ, natomiast zauważcie, że jego triggerem jest Manual Trigger Flow, czyli uruchamiany ręcznie przepływ. Zdefiniowałem w nim pewne wartości wejściowe. Możemy sobie wyobrazić, że naszym Automate, tym Child Flow, jest pewna funkcja, która przyjmuje parametry. W środku coś robi — w tym przypadku wysyła maila — i na koniec daje odpowiedź, czy mail został wysłany poprawnie, czy wystąpił jakiś błąd.

W tym przypadku mój Child Flow ma jako inputy wejściowe: email (do kogo ma zostać wysłany mail), treść wiadomości i temat wiadomości. Przygotowałem sobie zmienną do odpowiedzi, żeby wyłapać i wysłać z powrotem response — czy wszystko się udało, czy wystąpił jakiś błąd.

W bloczku Try-Catch-Finally — to jest taki pattern programistyczny. Ubrałem sobie wszystko, co się dzieje w bloku Try. W środku przygotowałem sobie templatekę HTML na maila. Następnie jedna akcja wysyłki maila, gdzie wprowadzam te wartości, które przyjąłem na wejściu: email, subject i content. Templatekę mailową dodaję na końcu, dzięki czemu za każdym razem do wysyłki doklejana jest ta templatka na dole maila.

Stosuję też Parallel Branch — możemy równolegle wykonać dwie czynności. Na każdej akcji w Power Automate na trzech kropeczkach możemy wejść sobie w Configure Run After i tam ustawić, kiedy ta akcja ma się wydarzyć. Bloczek błędu ma się uruchomić tylko wtedy, gdy akcja wysyłki maila wyczerpa się, bądź czas upłynie. Po lewej ustawiłem tylko i wyłącznie na sukces. Finally ma się wykonać zawsze — nieważne, czy wystąpi błąd, czy wejdzie to w catch — scope finally ma zawsze wysłać zwrotnie response.

Aby pokazać, jak działa taki Child Flow, jak wyzwolić Child Flow na przykładzie, przygotowałem prostą listę SharePoint, gdzie po prostu użytkownik może dodać wpis z tematem wiadomości, treścią i mailem. Pod to przygotowałem bardzo prosty przepływ z dwóch bloczków: trigger reaguje na wpis na tej liście i używamy akcji Run a Child Flow. Ta akcja pozwala nam wybrać dowolny Child Flow, do którego mamy dostęp w ramach całego środowiska i podpowiedziała od razu, jakie zmienne są wymagane.

Jesteśmy w stanie teraz w wygodny sposób poprzeglądać sobie wykonania — osobno widzimy wykonania przepływów dotyczące danego rozwiązania, a osobno widzimy wykonania przepływów tylko tego Child Flow.

Warto też dodać, że jeżeli nawet zaczynasz dopiero przygodę i tworzysz pierwsze rozwiązania, ale wiesz, że są pewne rzeczy, które z natury będą powtarzalne — na przykład ten email — to warto od razu zadbać sobie o taki standard, zbudować sobie osobną solucję z osobnymi przepływami pod takie centralne rozwiązania i już od początku z nich korzystać i rozwijać osobno, dzięki temu będzie coraz łatwiej i szybciej implementować kolejne rozwiązania.

Podsumowując, dzisiaj poznaliśmy koncepcję Child Flow, poznaliśmy też mechanizm Try-Catch-Finally. W kolejnych odcinkach postaram się pokazać jeszcze więcej rzeczy, jak ustawić lepiej i szczegółowo trigger takiego przepływu, jak korzystać ze zmiennych środowiskowych. Dzięki za dzisiaj, do zobaczenia.