# #9 Nauka Power Platform | Obsluga bledow **Film YouTube:** https://www.youtube.com/watch?v=Xo9RZL1FeWs --- [Muzyka] Cześć. W dzisiejszym odcinku opowiemy sobie o obsłudze błędów zarówno w Power Automate, jak i w Power Apps. W jaki sposób możemy obsługiwać błędy, które mają prawo się wydarzyć na poziomie źródeł danych czy zapisu jakiś danych do źródłowych tabel. Warto wiedzieć jakie mechanizmy można zastosować żeby odpowiednio zabezpieczyć proces przed takimi problemami i wyjątkami. Najpierw przejdziemy sobie do Power Automate. Skorzystamy z przepływu, który już wcześniej stworzyliśmy w solucji zgłoszeń IT. Przypominam, że w tym przypływie reagowaliśmy na przyjście maila i składowaliśmy elementy na liste SharePoint. Żeby zabezpieczyć taki i każdy inny proces są pewne podstawowe takie standardy, które możemy zastosować. Warto stosować wtedy tak zwane scopy, czy w języku polskim będą to zakresy. Czym jest zakres? Zakres jest zbiorem akcji, które w ramach tego zakresu się wykonają, wykonują. Możemy tutaj przesunąć sobie tak jak teraz przesunąłem sobie do takiego scopu jakąś akcję i w ramach tego scopu ją wykonywać. W ramach takich standardów nazewnictwa i odniesienia trochę do języków programowania. Nazwę to sobie scopem tryworzę też drugi przepływ. Czyli te dwie akcje to są nasze podstawowe akcje, które chcemy wykonać w każdym przepływie. Natomiast w przypadku wystąpienia błędu, bo to chcemy obsłużyć, czyli chcemy obsłużyć wyjątki biznesowe, czy po prostu wyjątki od reguły coś się wydarzy po drodze nieprzewidzianego, zastosujemy sobie scope catch. Taki mechanizm jest bardzo popularny w językach programowania właśnie stosowany do przechwytywania błędów. I dzięki takiemu mechanizmowi możemy sobie zadbać o to, że w przypadku gdy ten scope try ten podstawowy spowoduje jakiś błąd, wystąpi jakiś błąd w tym scopie, w tym zakresie, to uruchomi się scope catch. W scop możemy sobie zadeklarować na przykład wysyłkę maila. To jest jeden z takich podstawowych w zasadzie metod wyłapywania błędów, gdzie wyślemy sobie maila. Błąd przepływu. Możemy sobie coś jeszcze w treści dopisać. Tu możemy to dowolnie nazwać. Możemy też pewne dane wyciągać z samego przepływu. No o tym nie chcę teraz, to i tak będziemy sobie jeszcze rozwijać. Na razie sam mechanizm, sam pattern, jak rozwiązać przechwytywanie błędów. To co jeszcze musimy zrobić to na tym scopie catch i na każdym scopeie możemy takie coś definiować. możemy określić co ma się wydarzyć po scopie try, czyli czy ten scope catch ma się uruchomić w takiej sytuacji gdy scope try i w naszym przypadku będziemy chcieli, żeby scope catch wykonał się w momencie gdy scope główny albo przekroczy czas wykonywania albo wywali błędem często stosowaną praktyką jest też dodanie scopeu finally, czyli w sytuacji gdy traj się wykona bądź cat się wykona zawsze chcemy, żeby coś na koniec się wydarzyło. Tu akurat nie mam pomysłu, co mogę pokazać. Natomiast może to być na przykład zmiana jakiegoś statusu albo po prostu wysłanie maila też w jakąś przestrzeń z określającą czy flow przebiegł pozytywnie czy negatywnie. Tak czy możemy sobie taki mechanizm zbudować. W przypadku finally znów musimy odnieść się do tego jak wykonał się poprzedni scope. A w przypadku finally chcemy, żeby wykonał się zawsze, więc w przypadku czegokolwiek co wydarzy się z catetchem, nawet jeśli nie zostanie wykonany, czyli zostanie ominięty, bo try zachowa się poprawnie, to i tak scope finally powinien się wyzwolić i uruchomić. I tu też możemy sobie już zamykając cały przepływ wysłać wiadomość. przepływ zakończony. To co jeszcze warto w tym wszystkim zastosować to w przypadku gdy zostawimy ten przepływ w taki sposób zrealizowany i nawet wystąpi błąd czyli dostaniemy tego maila Sketcha to status całego przepływu będzie zakończony sukcesem bo tak naprawdę wykonała się pewna sekwencja zgodnie z tym jak chcieliśmy, żeby się wykonała, żeby jednoznacznie wskazać sobie, że jest to błąd, to w catchu możemy dostać, możemy dodać takie coś jak Terminate, który przerwie, czy ta akcja przerwie nam wykonywanie całego przepływu ze statusem failed. >> Sorki za krótką przerwę, ale jeżeli nadal oglądasz ten filmik, to mam nadzieję, że cię zainteresował i poproszę cię w tym momencie o subskrypcję. Muszę też wspomnieć, że oprócz tego, że tworzę te materiały, proponuję też kilka form współpracy. Jeżeli jesteś zainteresowany pomocą we wdrożeniu automatyzacji w twojej firmie albo jesteś osobą, która chce rozwijać się w kierunku nauki per platformy, koniecznie skontaktuj się ze mną. W opisie tego filmu znajdziesz wszystkie potrzebne dane kontaktowe. To wszystko. Nie przeszkadzam. Miłego oglądania. Podsumowując ten pattern, wszystko co chcemy wykonać jako główne czynności w całym przepływie zapisujemy sobie w zakresie try. Następnie tworzymy zakres catch, który ma wykonać się tylko w sytuacji, gdy scope try przekroczy czas wykonywania albo zakończy pracę błędem i dodajemy sobie na sam koniec scope finally, który ma zakończyć się zawsze, czyli ma wykonać się zawsze, niezależnie od tego, czy wcześniej wystąpi błąd, czy nie. Dodatkowo, co warto wspomnieć, można sobie skorzystać z templatek, to znaczy w Power Automate, w zakładce Templates Microsoft przewidział taki dokładnie pattern i możemy sobie zobaczyć jak skonstruował to Microsoft. Jak widać mechanizm jest podobny, czyli mamy scope try. Jak wejdziemy sobie w ustawienia configurant after, tu akurat jest tylko wskazanie na fail, czyli catch ma się wykonać tylko, gdy coś spowoduje błąd w scopie try, a następnie finally ma się wykonać bez względu na to, jak wcześniej zachowały się poprzednie scopy. Przejdźmy teraz do Power Apps. W Power Apps przygotowałem w naszej już istniejącej aplikacji do zgłoszeń IT widok zgłaszania nowych pomysłów, nowych zgłoszeń. Przygotowałem prosty widok, labelkę, dwa pola do wpisywania tematu, opisu i przycisk zapisz. Na przycisku zapisz przygotowałem już formułę patch znaną już wszystkim z poprzednich lekcji. I teraz będziemy chcieli obłożyć tutaj tą funkcję odpowiednimi warunkami. Na tą chwilę jeśli uruchomimy sobie tą aplikację i damy zapisz, widzimy, że u góry przeleciały nam takie trzy kropeczki, ale w zasadzie nie wiemy nic więcej. Zobaczymy sobie na liście sharepointowej, czy coś się wydarzyło. I okazuje się, że tak, stworzyliśmy nowy wpis z pustym tematem, z pustym opisem, ponieważ nasza lista źródłowa nie ma żadnych walidacji, nie ma pól wymaganych, więc przyjmuje wszystko. Jak temu zapobiec? możemy użyć funkcji if, którą też już znamy. I najpierw nałożymy sobie taką funkcję. Będziemy chcieli zrobić tak, że jeżeli pole tematu jest puste lub pole opisu jest puste, to i tutaj chcemy obsłużyć właśnie błąd, czyli wskazać użytkownikowi że powinien coś zrobić. I mamy taką funkcję jak notify. W funkcji notify możemy użytkown użytkownikowi wyświetlić informacje, jakiego typu jest to problem. Czyli dajmy tutaj ogólnie uzupełnij wymagane pola. Możemy też określić typ notyfikacji. Mamy cztery do wyboru. One są odpowiednio potem w takich zmiennych sesyjnych zapisywane. Natomiast z punktu widzenia użytkownika to jest to po prostu kolorek na pasku komunikatu. I możemy tutaj w przypadku tego typu błędu użyć warninga. To będzie żółty paseczek z informacją, dzięki czemu użytkownik dostanie taką informację, co powinien zmienić i będzie mógł działać dalej. Natomiast jeśli wszystko jest uzupełnione, to po prostu wykonujemy funkcję patch. Zobaczmy teraz jak aplikacja się zachowa. O, jak naciskamy zapisz, mamy komunikat uzupełnij wymagane pola. Jest to takie przechwytywanie błędów na poziomie formularza, walidacji. Mamy jeszcze drugą bardzo ważną funkcję, która już sprawdza nam błędy na poziomie zapisu danych do tabel źródłowych, do dane do przestrzeni źródłowej. Jest to funkcja if error. Funkcja if error najpierw pobiera to, co ma zrobić. Czyli w przypadku wystąpienia błędu w tym, co masz zrobić w pierwszym argumencie, zrób coś dalej. I w tym przypadku zrobimy sobie również notifya. Tym razem damy sobie error, bo jest to już błąd, który wydarza się na poziomie zapisu danych do bazy. Więc też powinniśmy użytkownika odpowiednio w takim przypadku zapewnić jaki to jest błąd, co się wydarzyło. Więc damy sobie informację. Błąd zapisu danych. Spróbuj ponownie. Jeśli bunt będzie się powtarzał, skontaktuj się z IT telefonicznie. Musimy też podać oczywiście w funkcji if error warunek, co ma się wydarzyć, gdy nastąpi szczęście. I tu zrobimy sobie komunikat poprawnie zapisaną dane. Dziękujemy za zgłoszenie i notification type. Damy sobie success, co spowoduje, że kolorek będzie zielony. Zobaczmy sobie jak teraz to zadziała. Mamy nie wszystkie pola uzupełnione i wszystko jest poprawnie. W przypadku gdyby nastąpił jakiś błąd zapisu, dostalibyśmy czerwony komunikat z odpowiednią informacją do użytkownika. To jest takie podstawowe zabezpieczenie komunikacji z użytkownikiem na poziomie formularzy w Power Apps. Na dzisiaj to wszystko. Podsumowując, poznaliśmy takie dwa podstawowe mechanizmy przechwytywania błędów i obsługi błędów Power Automate i Power Apps, czyli takie naprawdę podstawy pracy już na budowie rozwiązań. W Power Automate zastosowaliśmy scope try catch finally, a w Power Apps zastosowaliśmy funkcję if do wyłapywania błędów na poziomie formularza, czyli pozostawiania na przykład pustych pól nieuzupełnionych przez użytkownika, a które są wymagane w procesie i funkcję ifror, która na poziomie zapisu danych już do tabel źródłowych sprawdza i waliduje, czy wszystko wykonało się poprawnie i też przechwytując błędy możemy dać użytkownikowi odpowiedni komunikat. Dzięki wielkie za uwagę. Oh. [Muzyka]