21 sierpnia 2019 r. Microsoft ogłosił, że akcje w Microsoft Flow ze stosu Outlook zostaną przeniesione z używania interfejsu API REST programu Outlook v1.0 na Microsoft Graph v1.0. Oprócz tych informacji napisano również, że istniejące Outlook REST API v1.0 zostanie wycofane z użytku 1 listopada 2019 r. Po tej dacie wszystkie stare akcje w Microsoft Flow również zostaną usunięte.
Post stanowi rozszerzenie informacji, jakie zawarłem w poprzednim poście traktującym o wzorcach Try-Catch w Microsoft Flow. W tym skupiam się na opisaniu, jak rejestrować błędy występujące w przepływach Microsoft Flow, w jednym miejscu, korzystając z usługi Azure Application Insights.
Ostatnio miałem przyjemność zaprezentować swoje demo podczas Microsoft Flow Online Conference 2019 na temat budowania bezbłędnych przepływów pracy w Microsoft Flow. W rzeczywistości chodziło raczej o rejestrowanie i debugowanie, aby w końcu otrzymać bezbłędne przepływy pracy.
Wpis, który teraz czytasz, został zainspirowany pytaniem, które ostatnio zobaczyłem na swoim Twitterze. Użytkownik pytał, czy możliwe jest przypisanie zadania do innego pracownika, jeśli aktualny przypisany jest nieobecny, bez dostępu do swojej usługi Office 365. Kwestia zmiany wykonawcy zadania czy generalnie przypisania zadania innemu pracownikowi jest bezpośrednio powiązana z dobrze znaną funkcjonalnością aplikacji biznesowych o nazwie „zastępstwa”.
Jedynym wyzwalaczem wbudowanym w Microsoft Flow dla Twittera jest „Kiedy nowy tweet jest opublikowany”. Lista zdarzeń dostępnych w dokumentacji aktywności konta (Account activity) API Twittera jest jednak znacznie szersza i składa się z 19 opcji. Ale jak z nich skorzystać?
Ten post jest związany z screencastem, który niedawno zrobiłem. Opisuje w szczegółach, w jaki sposób Flow, używany przez to rozwiązanie, jest zbudowany. Życzę przyjemnego oglądania i nauki jednocześnie, jak takie rozwiązanie można wykonać. Ten wpis jest również częścią serii, którą piszę o „Adaptive Cards”.
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.
Szykując się do nowego projektu, zacząłem sprawdzać, czy różne oczekiwania klienta są możliwe do zrealizowania z użyciem PowerApps. Pierwsze z nich to możliwość użycia pliku XML jako danych wejściowych, do zbudowania tabeli w aplikacji i ew. późniejszego ich zapisania do SQL.
W mojej codziennej pracy nad procesami biznesowymi w Office 365, konkretnie w SharePoint Online jedna rzecz denerwuje mnie najbardziej – mianowicie brak mechanizmów informowania mnie, że workflow się zawiesił, czyli jest w stanie „Suspended”.
Rozwiązania nie dostarcza ani Microsoft, ani też Nintex, z którym pracuję od dawna. Istnieją jedynie obejścia problemu, jednak okazują się niewystarczające, mnie zaś zależało na tym, by móc reagować proaktywnie, a nie reaktywnie na każde zdażenie zawieszenia się przepływu.
Klient zapytał mnie, czy jest możliwe, by wstawić ręczny podpis do pliku PDF generowanego wyłącznie z użyciem narzędzi dostępnych w Office 365. Moja pierwsza myśl była „nie”. Potem sprawdziłem, że istnieje pole o nazwie „Pen input”, a myśl zmieniła się na „tak”. Potem zacząłem próbować i szukać wskazówek jak to można zrobić i znów pojawiła się myśl „nie, nie da się”.