Microsoft Flow

Podniesienie uprawnień w SharePoint Workflow (zarówno w wersji 2010, jak i 2013) było dość łatwe. Służyły do tego przygotowane akcje.

To było przydatne rozwiązanie za każdym razem, gdy chcieliśmy, aby użytkownicy w trakcie procesu mogli aktualizować element, do którego nie mają bezpośrednich uprawnień do zapisu.

Jak odbywało się to w przepływach SharePoint 2010 i 2103?

To było dość proste. W trybie edycji należało kliknąć ikonkę „Impersonation Step” (SP 2010):

SharePoint Designer 2010, Impersonation Step, Workflow 2010
SharePoint Designer 2010, Impersonation Step, Workflow 2010

A jeśli miałeś dość szczęścia, by na farmie mieć Workflow Managera i w ten sposób obecne przepływy pracy SharePoint 2013, mogłeś użyć „App step” zamiast „Impersonation step”, pamiętając jednak o tym, by najpierw włączyć ficzer witryny „Workflow can use app permissions”:

SharePoint 2013 Workflow, feature: "Workflow can use app permissions"
SharePoint 2013 Workflow, ficzer: „Workflow can use app permissions”

I gotowe!

SharePoint Designer 2013, App Step, Workflow 2013
SharePoint Designer 2013, App Step, Workflow 2013

Przeczytaj więcej na ten temat na blogu Melissa Hubbard: https://melihubb.com/2017/04/11/app-step-vs-impersonation-step/

Jak podnieść uprawnienia w Microsoft Flow?

Prawdopodobnie istnieje jeszcze więcej sposobów niż przedstawionych poniżej, jednak stoi za nimi jedna główna zasada: musisz stracić kontekst użytkownika, aby Flow używał poświadczeń zdefiniowanych dla połączenia podczas jego tworzenia (zazwyczaj autor Flow, ale możesz też stworzyć połączenie używając wcześniej przygotowanego „Konta serwisowego”).

Wyobraźmy sobie scenariusz: masz Flow, który obsługuje zatwierdzenia i jest uruchamiany po utworzeniu elementu (lub modyfikacji, lub w obu przypadkach). Chcesz teraz zmienić status w powiązanym elemencie za każdym razem, gdy zatwierdzanie się zakończy, jednak użytkownik, który zainicjował przepływ nie powinien mieć już uprawnień do modyfikacji elementu. Zobacz, jak można to rozwiązać.

1) Trigger Flow poprzez HTTP Request

Utwórz drugi Flow, który będzie wyzwalany przy użyciu akcji „When a HTTP request is received”. Zdefiniuj treść żądania, np.:

{ "ItemID": 1, "NewStatus": "Completed" }

Pamiętaj także o użyciu akcji „Response”, dzięki czemu główny workflow będzie czekać aż do otrzymania odpowiedzi:

Update item in SharePoint using pre-defined connection, no user context
Aktualizacja elementu w SharePoint przy użyciu pre-definiowanego połączenia, bez kontekstu użytkownika

Potem po prostu użyj akcji „HTTP” w głównym przepływie, by zainicjować drugi Flow i przekazać mu parametry.

Pamiętaj, że użycie akcji HTTP w Flow wymaga subskrypcji Flow P1 dla twórcy i użytkowników wykonujących Flow.

2) Trigger Flow poprzez Azure Queue

W tym rozwiązaniu musisz ponownie utworzyć drugi przepływ, który będzie uruchamiany akcją „Azure Queue”. Następnie, gdy w głównym Flow zostanie zakończone zadanie, musisz po prostu umieścić wiadomość w kolejce, np .:

Putting message on Azure Queue
Wstawianie wiadomości do kolejki Azure Queue

Następnie utwórz drugi przepływ, który odczyta tę wiadomość i odpowiednio zaktualizuje element SharePoint:

Getting message from Azure Queue and parsing it
Odbieranie wiadomości z Azure Queue i przetwarzanie jej

Dla tego rozwiązania nie potrzebujesz subskrypcji Flow P1, zamiast tego potrzebujesz subskrypcji Azure. Azure Queue korzysta z modelu „Pay-as-you-go” (sprawdź ceny: https://azure.microsoft.com/en-us/pricing/details/storage/queues/)

W tym podejściu główny przepływ nie będzie czekał na zakończenie drugiego przepływu, ponieważ działają one całkowicie niezależnie. Możesz jednak zbudować workaround, np. pętlę, która sprawdza, czy w kolejce są jakieś wiadomości i jeśli tak, czy istnieje komunikat z odpowiedzią z drugiego przepływu. Jeśli tak – kontynuuj działanie. W przeciwnym razie wstrzymaj na przykład na 10 sekund:

Pause until response message is present in the Azure Queue
Czekaj do czasu pojawienia się wiadomości z odpowiedzią w Azure Queue

Możesz również zliczać wiadomości w kolejce, a gdy ich liczba wynosi 0 oznacza to będzie, że element jest zaktualizowany.

3) Trigger Flow poprzez Azure Service Bus

Podobnie jak w przypadku Azure Queue, Service Bus oferuje również kolejkę, w której podstawowy przepływ może zapisywać komunikat. Drugi przepływ będzie wyzwalany za pomocą akcji „When a message is received in queue” i w następstwie tego zaktualizuje element, by na koniec usunąć wiadomość z kolejki.

Azure Service Bus to trigger Microsoft Flow
Azure Service Bus wyzwalający Microsoft Flow

Do tego rozwiązania również potrzebujesz użyć subskrypcji Azure. Azure Service Bus korzysta z modelu „Pay-as-you-go” (sprawdź ceny: https://azure.microsoft.com/en-in/pricing/details/service-bus/)

Zapoznaj się także z poniższymi linkami, z których dowiesz się jakie są główne różnice pomiędzy Azure Service Bus i Storage Queue:

  1. https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
  2. https://www.c-sharpcorner.com/UploadFile/fe6121/deep-dive-into-azure-storage-queue-vs-azure-service-bus-queu/

4) Użyj Azure Function

Ostatnim rozwiązaniem, o którym myślałem, jest funkcja Azure. Jest to jednak najbardziej skomplikowane podejście i nie widzę żadnych realnych korzyści. Ponadto, aby wywołać funkcję Azure, ponownie musisz to zrobić za pomocą HTTP lub Storage Queue, zatem wciąż musisz mieć subskrypcję P1 lub subskrypcję Azure.

Główną zaletą korzystania z funkcji Azure jest możliwość zarejestrowania jej w AAD i przyznania jej dostępu za pomocą „uprawnień aplikacji”:

Granting application permissions to SharePoint in AAD
Nadawanie aplikacji uprawnień do SharePoint w AAD

Pozwoli to na realizację scenariusza, w którym element na liście jest faktycznie aktualizowany przez konto systemowe, a nie jakikolwiek sztucznie stworzone „konto usługi”.

Dziękuje za lekturę! Jeśli masz jakieś pytania, pozostaw je w polu komentarzy poniżej lub skontaktuj się ze mną bezpośrednio!