Top
Photo by Clint Patterson on Unsplash

Aktualizacja Power Automate Desktop do v2 schema


Ogłoszony wraz z wersją PAD z lutego 2023 r. nowy schemat Microsoft Dataverse do przechowywania danych Power Automate Desktop, tzw. „v2”, wymaga uaktualnienia wszystkich przepływów pulpitu do pierwszego kwartału 2024 r. Ja już to zrobiłem i stanąłem przed kilkoma wyzwaniami, którymi chciałbym podzielić się z Tobą.

Nowy schemat w wersji 2 „ułatwia pracę z interfejsami API Dataverse i umożliwia przyszłe ulepszenia produktów dzięki przepływom pulpitu. Nowy schemat danych jest publicznie dostępny wraz z usługą Power Automate dla komputerów stacjonarnych (wersja 2.29)” i nowszymi. Przeczytaj więcej na ten temat tutaj: https://learn.microsoft.com/en-us/power-automate/desktop-flows/schema.

Kroki do zaktualizowania do schema v2

  1. Zainstaluj najnowszą wersję Power Automate Desktop (musi być v2.29 lub nowsza).
  2. Zaktualizuj rozszerzenie Power Automate dla przeglądarki, aby używało Manifest V3 przed lipcem 2022 (https://learn.microsoft.com/en-us/power-automate/desktop-flows/manifest).
Manifest V3 extension

https://learn.microsoft.com/en-us/power-automate/desktop-flows/install-browser-extensions

  1. W Power Platform Admin Center przejdź do Environments > Settings > Product > Features > Enable storage of desktop flow files into v2 schema i przestaw na „On”:
Enable desktop flow schema
  1. Otwórz i zapisz ponownie każdy desktop flow, który chcesz zaktualizować do schematu w wersji v2.
  2. Jeśli planujesz przenieść przepływy pulpitu do innego środowiska, przejdź do solucji, w których są one przechowywane i kliknij, aby dodać dla nich wymagane obiekty.
Add required objects for a desktop flow
  1. Ta akcja spowoduje dodanie „Desktop Flow Binaries” do solucji, które jeśli nieobecne, spowodują błędy w uruchomieniach przepływów pulpitu. Liczba binarek może się różnić. W przypadku dużych przepływów może to być nawet blisko 100.
Desktop Flow Binary

I to tyle 😉

Problemy po aktualizacji

Problemy, z którymi spotkałem się w całym procesie aktualizacji, dotyczyły raczej tylko sytuacji po zakończeniu aktualizacji. Zasadniczo – wokół uruchamiania zaktualizowanych procesów. A przede wszystkim dlatego, że lista plików binarnych Desktop Flow była niekompletna we wdrożonym rozwiązaniu lub zostały one ponownie dodane po kolejnym wdrożeniu (czyli ich liczba na środowisku źrodłowym vs. docelowym była inna).

Nowo zaktualizowane przepływy pulpitu nie powiodły się z powodu błędów wymienionych poniżej (tylko przykłady, mogą być niekompletne):

{
  "error": {
    "code": "MalformedFlowError",
    "message": "Malformed flow detected: ControlRepository"
  }
}

Wystąpiły również inne błędy związane z XrmApiRequestFailed, np.:

Encountered an unexpected error during Desktop flow initialization: 'Microsoft.Flow.RPA.Desktop.Robin.Core.Packager.Exceptions.PackagerValidationException: A validation error occurred during project unbundling.
at Microsoft.Flow.RPA.Desktop.Robin.Core.Packager.ProjectValidator.CreateAndReturnFinalValidationResult()
at Microsoft.Flow.RPA.Desktop.Robin.Core.Packager.ProjectValidator.ValidateProject()
at Microsoft.Flow.RPA.Desktop.Robin.Engine.Packager.PackageProvider.<>c__DisplayClass12_0.b__0()
at Microsoft.Flow.RPA.Desktop.Robin.Engine.Packager.PackageProvider.ExecuteAndLogOperation(String methodName, Action action, Func1 func) at Microsoft.Flow.RPA.Desktop.Robin.Engine.Packager.PackageHelper.PackProjectToDirectory(Project project, String directory, Guid flowId) at Microsoft.Flow.RPA.Agent.Server.Components.ScriptEngines.RobinEngine.DataResolvers.DataResolverV2.GetFlowDataAndSetState(Guid scriptId, Guid runId, Dictionary2 flowInfoCache, String directory)
at Microsoft.Flow.RPA.Agent.Server.Components.ScriptEngines.RobinEngine.RobinScriptProvider.ResolvePackagePath(Guid flowId)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Flow.RPA.Agent.Server.Components.ScriptEngines.RobinEngine.RobinEngine.d__21.MoveNext()'.

Jednak były one bardzo zagmatwane i dlatego uznałem, że wszystkie są związane z procesem aktualizacji.

Rozwiązywanie problemów

Pierwszym krokiem jest sprawdzenie, czy wykonałeś kroki 5 i 6 powyżej, aby Twoje rozwiązanie zawierało pliki binarne Desktop Flow. Jeśli tak, ale nadal się kończy błędem, być może liczba plików binarnych między środowiskiem źródłowym i docelowym jest różna. W takim przypadku możesz spróbować ręcznie zaimportować solucję, korzystając z klasycznego interfejsu:

Swotch to classic interface

A następnie wybierz Upgrade (ponieważ ta czynność powinna usunąć komponenty nieobecne w twoim nowym wdrożeniu, więc w tym przypadku dodatkowe pliki binarne Desktop Flow) i Overwrite customizations (aby upewnić się, że żadne niezarządzane warstwy nie kolidują z nową wersją):

Classic solution import

Jeśli jednak to podejście również nie zadziała, jedynym rozwiązaniem, jakie znalazłem, jest usunięcie istniejącej solucji i ponowne wdrożenie.

Wzorzec ponownego uruchamiania przepływu, jeśli kod odpowiedzi to 400

Często zdarza się, że instancja przepływu desktopowego kończy się niepowodzeniem, a akcja w przepływie w chmurze, która uruchomiła RPA, wyświetla w odpowiedzi kod statusu „bad request” (400). Niektóre z możliwych przyczyn i możliwych rozwiązań można znaleźć tutaj. Ale liczba możliwych przyczyn jest znacznie większa. Wszystkie możliwe błędy można znaleźć w raporcie aktywności Desktop Flow:

Desktop flow activity report errors

Ale często chciałbyś, aby RPA zostało uruchomione ponownie, a nie zakończone niepowodzeniem. Możesz zastosować moje podejście tworzenia przepływu w chmurze, który uruchamia przepływ na pulpicie ponownie, jeśli ten kończy się kodem 400:

Pattern to run desktop flow as long as it ends up with bad requests

  1. Zmienna var_BotStatus służy do sterowania pętlą. Jest inicjowana wartością „Error”.
  2. Pętla działa tak długo, jak var_BotStatus jest równa „Error”, ale…
  3. Nie dłużej niż 1 godzina lub 4 razy – czyli aby cały proces nie ciągnął się w nieskończoność.
  4. Jeśli akcja wyzwalająca RPA zakończy się błędem, uruchamiana jest lewa gałąź, która sprawdza, czy outputs('Run_PAD_RPA')?['statusCode'] jest równe 400.
  5. Jeśli tak, var_BotStatus zachowuje wartość „Error”,
  6. W przeciwnym razie jest ustawiony na „OK”, co kończy pętlę.
  7. Jeśli akcja RPA zakończy się sukcesem, to…
  8. var_BotStatus jest ustawiony na „OK”, co kończy pętlę.

I to wszystko. Mam nadzieję, że pomoże Ci to stworzyć bardziej niezawodne procesy.


Tomasz Poszytek

Cześć! Nazywam się Tomasz. Jestem ekspertem w dziedzinie automatyzacji procesów i budowaniu rozwiązań dla biznesu z użyciem Power Platform. Jestem Microsoft MVP i Nintex vTE.

Brak komentarzy

Wyślij komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.