Ten post został zainspirowany sytuacją, z którą spotkałem się u jednego z moich klientów. Migrowałem SharePoint 2010 do SharePoint Online i w jednej witrynie klient posiadał wiele list, na których użytkownicy mogli tworzyć elementy. Za każdym razem, gdy ktoś utworzył lub zaktualizował element, przepływ pracy programu SharePoint Designer wysyłał im wiadomość e-mail z potwierdzeniem. Istotne było to, że listy korzystały z tej samej definicji przepływu pracy, skopiowanej dla każdej listy.

Oczywiście mógłbym po prostu utworzyć wiele przepływów wykonujących tę samą pracę, ale pomyślałem, że to tylko kwestia czasu, kiedy klient będzie musiał coś zmienić w logice przepływu. Ja musiałbym wtedy zaktualizować {n} przepływów pracy. Strata czasu. Poza tym uwielbiam optymalizować wszystko, co jest możliwe. Moim pomysłem było zatem znalezienie sposobu na utworzenie jednego przepływu, który można by uruchomić z wielu list SharePoint.

Po krótkich poszukiwaniach znalazłem ten wątek na Twitterze autorstwa Johna Liu:

#FlowNinja playing with @MicrosoftFlow again. See if you can guess what I'm doing…

I guess this is a livestream of sorts. Live-tweet. /1 pic.twitter.com/ZymAPgoSQ2

— John Liu 劉 (@johnnliu) June 2, 2018

A chwilę później jego niesamowity post opisujący, jak można osiągnąć ten cel za pomocą webhooków list SharePoint i subskrybowania do nich przepływu Power Automate: http://johnliu.net/blog/2019/3/one-flow-to-handle-them-all-how-to-subscribe-to-multiple-sharepoint-lists-with-one-flow.

Ogólna idea polega na utworzeniu dwóch przepływów:

1. Subskrybujący: wyzwalany zgodnie z harmonogramem, który sprawdza, czy przepływ obsługi jest zasubskrybowany do określonego webhooka listy, a jeśli nie – subskrybuje go.
2. Obsługujący: wyzwalany przez żądanie HTTP, które jest zasubskrybowane do webhooka listy i jest uruchamiane za każdym razem, gdy nastąpi zmiana na tej liście.

Jak to działa

Ważne! Całe rozwiązanie wymaga licencji premium na usługę Power Automate, ponieważ przepływ Obsługujący jest wyzwalany za pomocą akcji premium. Im więcej użytkowników będzie korzystało z rozwiązania, tym bardziej sugeruję rozważyć użycie licencji „per flow” zamiast „per user”, ponieważ rozwiązanie można uznać za obejmujące całą firmę.

Zasadniczo to, co opisał John, działa jak doskonale, chociaż bardzo brakowało mi części, która pomogłaby mi precyzyjnie uzyskać elementy, które zostały faktycznie utworzone/ zmodyfikowane, do chwili gdy uruchamiany jest przepływ Obsługujący, jednak już po czasie poprzedniego uruchomienia. Chodzi o to, że webhook wysyła tylko informację, że zdarzenie wystąpiło na określonej liście, ale nie wysyła np. identyfikatorów elementów, które uległy zmianie. W tym celu John zasugerował, aby po prostu pobrać wszystkie elementy zmodyfikowane w ciągu ostatnich 10 sekund. To nie jest najlepszy pomysł, ponieważ czasami przepływ Obsługujący był wyzwalany np. po 2 minutach. Jako rozwiązanie tego problemu, John podał link do posta Leo Siddle, w którym szczegółowo opisuje, jak używać endpoint Folder.GetListItemChanges i Change tokens: https://gist.github.com/zplume/1baf04cc05927b57a5da248454b15dcc.

Dla mnie było to trochę zbyt skomplikowane i szukałem czegoś łatwiejszego.

Jak ja to zrobiłem?

Jak faktycznie uruchomić jeden przepływ z wielu list SharePoint? To łatwiejsze niż myślisz!

Flow Subskrybujący

Najpierw przepływ Subskrybujący. Dodałem w nim informację o listach, które powinny być monitorowane dla których powinna być obsługa subskrybowania do ich webhooków. Zdefiniowałem zapytanie odata, aby uzyskać tylko listy z określonymi guidami:

and (Id eq guid'ec080920-5d86-4739-a14f-34298bcebfc7' or Id eq guid'a6ffb3c0-6b5c-4eb8-b4db-6b477f619485' or Id eq guid'f2d3252c-d00f-4da8-aabd-f2dd96029780' or ....)

Potem użyłem akcji „Send an HTTP Request to SharePoint”, by dostać wszystkie szczegóły monitorowanych list:

_api/web/lists?$filter=BaseType eq 0 and Hidden eq false and (Id eq .... )

Pamiętaj! BaseType eq 0 oznacza „listy”.

Następnie użyłem akcji filtrującej, aby uzyskać identyfikatory list (John użył tytułów, myślę, że identyfikatory są bezpieczniejsze) i na koniec dla każdego identyfikatora wygenerowałem URL do endpointa subskrypcji listy:

Następnie, dla każdego linka subskrypcji, podążając śladami Johna, pobieram wartość 'clientState’ oraz w kolejnym kroku 'resourceId’ – czyli guid bieżącej listy, by potem użyć go jako wartości parametru „resource” w akcji subskrybowania do webhooka:

1. To jest identyfikator GUID bieżącej listy wyodrębniony przez akcję „Compose” powyżej.
2. To jest adres URL przepływu Obsługującego, skopiowany z jego akcji wyzwalającej.
3. To jest informacja, jak długo powinna być ważna subskrypcja. Ustawiam ją na 30 dni. Po tym zostanie anulowana automatycznie.
4. Jest to guid przepływu Subskrybującego, który służy do sprawdzania, czy istnieje subskrypcja dla danej listy utworzona przez przepływ Subskrybujący. Możesz go uzyskać, używając wyrażenia workflow()?['Name'].

Flow Obsługujący

Przepływ jest uruchamiany wyzwalaczem „Po odebraniu żądania HTTP”. Kolejne kroki są takie same, jak opisał John w swoim drugim poście: http://johnliu.net/blog/2019/5/one-flow-to-handle-them-all-part-2-figuring- poza zmianami i są naprawdę dobrze wyjaśnione.

I tutaj dodałem swoje trzy grosze. Zamiast pobierać wszystkie pozycje z konkretnej listy zmodyfikowane w ostatnich 10 sekundach LUB używając złożonego rozwiązania opisanego przez Leo, zdecydowałem się użyć listy SharePoint, ponieważ całe rozwiązanie i tak jest dla SharePoint. Moja lista jest zbudowana z następujących kolumn:

1. Tytuł – nazwa monitorowanej listy.
2. GUID – identyfikator monitorowanej listy.
3. LastModificationDateTime – sygnatura czasowa ostatniej zmiany na liście . Przy pierwszym uruchomieniu ustawiłem aktualną datę i godzinę.

Następnie w moim przepływie Obsługującym odpytuję tę listę, aby uzyskać LastModificationDateTime dla listy, która wyzwoliła przepływ (używając identyfikatora GUID jako filtru), a następnie aktualizuję datę ostatniej modyfikacji do bieżącej daty i godziny:

To, co teraz robię, to pobranie listy wszystkich elementów, które zostały zmodyfikowane między poprzednim wartością „LastModificationDateTime” a bieżącą datą i godziną. I wreszcie, dla każdego takiego elementu, wykonuję te kroki, które były wspólne dla wszystkich przepływów pracy, które znalazłem w witrynie SharePoint 2010 przed migracją:

To działa idealnie! Gorąco polecam ten sposób radzenia sobie z sytuacjami, w których masz wiele list/ bibliotek (nawet w różnych witrynach), które używają dokładnie tych samych przepływów pracy. Zamiast zmieniać nazwę i kopiować istniejący przepływ dla każdej listy osobno, po prostu postępuj zgodnie z podejściem Subskrybujący – Obsługujący. Jest znacznie bardziej eleganckie i łatwiejsze w utrzymaniu, i rozwoju.

W komentarzach poniżej daj znać, co myślisz i czy jest to dla Ciebie przydatne. Dziękuję!