Wdrożenie rozwiązania może nie być tak proste, jak wygląda na początku. Podczas jednego z naszych testowych wdrożeń wszystkie procesy zostały automatycznie wyłączone. Choć jest to dość normalna sytuacja po wdrożeniu, tym razem próba ich włączenia skutkowała komunikatem „ChildFlowNeverPublished”. Ciekawe, biorąc pod uwagę, że wcześniej nigdy nie było potrzeby ręcznego publikowania rozwiązań Power Automate. Jeszcze ciekawsze, że opublikowanie rozwiązania nie pomogło. Nie pomogło też publikowanie przepływów jeden po drugim. Co się więc stało? I dlaczego nie wydarzyło się to w środowisku deweloperskim?

Rozwiązanie
Po szukaniu odpowiedzi w swoich przepływach, przeszukałem internet. Po krótkich poszukiwaniach okazało się, że Tomek Poszytek również napotkał ten sam problem i u nas obojga przyczyną wyjątku były te same – odwołania cykliczne w rozwiązaniu.
Więcej: https://poszytek.eu/en/microsoft-en/office-365-en/powerautomate-en/childflowneverpublished/
Jednak projekt mojej automatyzacji był nieco inny niż Tomka.

Zgodnie z artykułem mojego kolegi, dodanie proxy powinno rozwiązać problem.

Powyższe rozwiązanie na pierwszy rzut oka nie wydaje się usuwać podstawowego problemu. Przepływ proxy nie przerywa odwołania cyklicznego w tym scenariuszu – po prostu dodaje do niego jeszcze jeden krok. Jednak żaden z przepływów nie odwołuje się bezpośrednio do innych, co może być tu kluczową wskazówką. Niestety powyższa implementacja nie rozwiązała problemu po wdrożeniu w środowisku testowym – wyjątek ChildFlowNeverPublished nadal występował.
Co więc zrobić? Odwołanie cykliczne wydaje się być problemem i powinno zostać przerwane, aby zapobiec pojawianiu się błędu. Jak można je przerwać? Po burzy mózgów doszedłem do wniosku, że w środowisku deweloperskim całe przetwarzanie nigdy nie zostało w pierwszej kolejności wyłączone. Po włączeniu wszystko działało bez zarzutu. Należy więc przerwać odwołanie cykliczne tylko po to, aby włączyć przepływy. Następnie ta zmiana mogłaby zostać cofnięta. I wydaje się, że Power Automate ma do tego narzędzie – warstwę niezarządzaną.
Aby to osiągnąć, edytowałem „Run a Child Flow” przepływu przetwarzającego, aby odwoływał się do fikcyjnego przepływu i zapisałem go. Pierwszy punkt dla mnie – zapisano poprawnie. Następnie włączyłem – drugi punkt, przepływ włączył się bez wyjątku. Odwołanie cykliczne jest tymczasowo przerwane, więc spróbowałem z innymi przepływami. Wszystkie włączyły się bez błędu. W końcu nadszedł czas na cofnięcie zmian. Z wszystkimi włączonymi przepływami usunąłem warstwę niezarządzaną z przepływu przetwarzającego i voilà! Żadnych wyjątków. Dalsze testy przepływu potwierdziły, że działa zgodnie z przeznaczeniem. Sprawa rozwiązana.

Podsumowanie
Wdrażanie rozwiązania z przepływami podrzędnymi może napotkać wyzwania, takie jak błąd ChildFlowNeverPublished. Kluczem do rozwiązania tego problemu jest zrozumienie, że może on być spowodowany odwołaniami cyklicznymi w rozwiązaniu. Tymczasowe przerwanie tych odwołań poprzez edycję przepływów i użycie warstwy niezarządzanej może pomóc we włączeniu przepływów bez wyjątków. Po włączeniu wszystkich przepływów zmiany można cofnąć, przywracając oryginalną strukturę rozwiązania.
Podobne przypadki zostały opisane przez Tomka Poszytka na jego blogu. Jego rozwiązanie polegało na dodaniu przepływu proxy w celu przerwania odwołań cyklicznych, co jednak w moim przypadku nie zadziałało. Każde wdrożenie może mieć swoje własne unikalne wyzwania, dlatego ważne jest, aby być elastycznym i kreatywnym w podejściu do rozwiązywania problemów.


