Jakiś czas temu opublikowałem post na temat problemu, który pojawia się, gdy próbujemy włączyć przepływ w solucji zbudowanej w innym środowisku, który zawiera cykliczne odniesienia do innych przepływów w tej solucji.

Post można znaleźć tutaj — opisuje on architekturę przepływów, jak na poniższym obrazku:

Napisałem wtedy, że rozwiązaniem tego problemu jest stworzenie pomocniczego przepływu sterującego (controller child flow), który jest wywoływany przez przepływy etapowe (stage flows), a następnie sam wywołuje przepływ typu maszyna stanów (state machine flow):

Jednak okazuje się (co było w sumie do przewidzenia), że takie podejście również tworzy pętlę cykliczną:

1. Przepływ sterujący wywołuje maszynę stanów
2. Maszyna stanów wywołuje przepływ etapowy
3. Przepływ etapowy wywołuje przepływ sterujący

Ale gdy przychodzi do próby włączenia przepływów po pierwszym wdrożeniu — to i tak nie zadziała, ponieważ nadal:

1. Aby włączyć przepływ zmiany stanu, musi być wcześniej włączona maszyna stanów…
2. Aby włączyć przepływ maszyny stanów, najpierw musi być włączony przepływ etapowy…
3. Aby włączyć przepływ etapowy, musi być wcześniej włączony przepływ zmiany stanu…

I tak wciąż nie da się uruchomić całego rozwiązania. Kończy się to takim błędem, niezależnie od tego, który przepływ próbujemy włączyć:

Turn on failed. Flow client error returned with status code "BadRequest" and details "{"error":{"code":"ChildFlowNeverPublished","message":"The workflow with id 'flow-guid' cannot be used as a child workflow because it has never been published. Child workflows need to be published at least once before they can be included in a published parent workflow."}}".

Rozwiązania?

Miałem kilka pomysłów — jedne gorsze od innych 😉

1. Przerwać pętlę cykliczną, zastępując jeden z wyzwalaczy wyzwalaczem typu Web request i wywołując przepływ podrzędny za pomocą akcji HTTP.
2. Edytować przepływy podrzędne w środowisku produkcyjnym, usunąć odniesienie, opublikować, dodać z powrotem odniesienie — to okropne rozwiązanie, które dodatkowo tworzy warstwę unmanaged.
3. Przerwać pętlę cykliczną, wywołując przepływy podrzędne za pomocą pomocniczej listy SharePoint lub tabeli Dataverse — np. kiedy zostanie utworzony nowy element. A to już po prostu koszmar!

Sprawy stają się jeszcze trudniejsze, jeśli w środowisku, w którym wdrożono zarządzane rozwiązanie, administrator wyłączył możliwość wprowadzania zmian niezarządzalnych (unmanaged) — wtedy właściwie nie da się edytować przepływów i przerwać pętli.

Mimo że Microsoft obiecał naprawić tę niedogodność, problem nadal występuje i psuje świetne rozwiązania innych deweloperów.

Naprawdę działające rozwiązanie

To w sumie dość proste.

1. Usuń istniejące rozwiązanie ze środowiska docelowego. Tak — na razie i tak nie uda Ci się go włączyć 😉
2. Przerwij pętlę w środowisku deweloperskim. Usuń dowolną akcję „Uruchom przepływ podrzędny” w jednym z przepływów z pętli, aby przerwać cykliczne odniesienie.
   
3. Opublikuj przepływ.
4. Wdróż rozwiązanie ponownie.
5. Włącz przepływy — zaczynając od tego, w którym przerwałeś odniesienie. Naturalnie, o ile już nie są włączone.
6. Przywróć cykliczne odniesienie w przepływie z punktu 2.
7. Wdróż ponownie.

I wszystko działa jak należy! Mam nadzieję, że Tobie też pomoże. Daj znać w komentarzu, jak poszło.