Blog
Digital Workplace, Flow, PowerApps, Nintex, Office 365, SharePoint
Będąc wciąż pod dużym wrażeniem możliwości, jakie dają Azure Functions, postanowiłem zbudować w końcu rozwiązanie dla Nintex Workflow w Office 365, które pozwoli mi publikować zapisane wcześniej przepływy pracy w różnych listach w danej witrynie. Dotąd, by osiągnąć ten cel, używałem PowerShell lub aplikacji takich jak Postman czy Fiddler. Jednak zależało mi na tym, by mieć jeden przepływ pracy, który całą tę magię wykona za mnie.
Gdy chcesz zawołać w swoim kodzie C# metody lub obiekty pochodzące z innych bibliotek, musisz je wpierw wymienić używając hasła „using”. Jednak co w przypadku, gdy jest to biblioteka customowa, publicznie nieodstępna? W takim wypadku należy wpierw wgrać odpowiednie pliki DLL do projektu i następnie odwołać się do nich poprzez referencję. To oczywiste, używając desktopowych IDE, jednak co w przypadku, gdy pracujemy przez konsolę Azure?
Pomimo faktu, iż InfoPath już wielokrotnie został uśmiercony, a jego przyszłość definitywnie zakończona, dla wielu firm budowanie formularzy dla przepływów pracy, z użyciem tego narzędzia, jest czymś tak oczywistym jak praca z Excel. Jednakże, gdy formularze są tworzone dla rozwiązań pracujących w Office 365 i SharePoint Online, ograniczenia i limity formularzy InfoPath są bardzo widoczne i stają się prawdziwym problemem.
Jakiś czas temu zmagałem się z problemem przekraczania dopuszczalnego rozmiaru instancji workflow (tutaj), który to był bezpośrednio związany z wielkością formularza InfoPath wraz z rozmiarem dołączonych do niego plików. Najbardziej oczywistym rozwiązaniem, jakie wówczas przyszło mi do głowy, było przeniesienie załączników z formularza do biblioteki dokumentów w SharePoint, jednak jak się okazało, nie było to łatwe do zrobienia z uwagi na algorytm, jaki jest używany w InfoPath do obsługi załączników.
Podczas konferencji Ignite, Microsoft pokazał nowe funkcje, jakie planuje wdrażać stopniowo na tenantach Office 365 oraz plany, kiedy będą one udostępniane produkcyjnie. Najbardziej interesujące, z mojego punktu widzenia, były te dotyczące Office 365 i w pewnym sensie połączonego środowiska SharePoint Online, PowerApps i Flow. Dalej w treści posta możesz znaleźć opis tych funkcji, które są już dostępne.
Krótkie dementi! Większość z opisanych dalej funkcji nie jest jeszcze dostępnych dla każdego. Część z nich jest obecna wyłącznie dla tenatów ustawionych na First Release lub istnieje w trybie „private preview”.
Ten artykuł stanowi kontynuację opisywanych wcześniej rozwiązań tworzenia prostego newslettera korzystając z SharePoint Designer 2013, opisanego tutaj i drugiego, korzystając z Nintex Workflow dla Office 365, opisanego tutaj. Tym razem chciałbym pokażę, jak podobne rozwiązanie może zostać zbudowane korzystając z Microsoft Flow i SharePoint Online.
Pracując nad moim rozwiązaniem umożliwiającym wysyłanie wiadomości e-mail z informacji tworzonych i przechowywanych w SharePoint doszedłem do wniosku, iż dobrym pomysłem byłoby, aby obrazy w takich e-mailach nie były osadzane w postaci adresu URL prowadzącego do pliku, umieszczonego w bibliotece SharePoint (takie podejście opisałem tutaj), ponieważ w takim rozwiązaniu użytkownik, nie mający dostępu do SharePoint lub nie będący zalogowanym, zwyczajnie tych obrazów nie zobaczy.
Ostatnio znalazłem się w sytuacji, gdy po utworzeniu nowej Modern Site (to była Team Site), moje konto, które pomimo faktu bycia zarówno administratorem kolekcji witryn oraz administratorem SharePoint, nie miało dostępu do linków prowadzących do galerii witryny (solucji, szablonów list, web partów, czy funkcji zapisywania list i witryn jako szablonów). Co więcej, przy próbie dostępu do wybranej funkcji używając bezpośredniego linka i wykonaniu operacji np. wgrania solucji, otrzymywałem odmowę dostępu.
Dłuższy czas temu zostałem poproszony o przemyślenie możliwości zbudowania mechanizmu do notyfikowania pracowników aplikacji zbudowanej na SharePoint 2013 o zmianach w niej wprowadzanych. Jednak, nie chodziło o używanie alertów, czy też tworzenie dedykowanego rozwiązania. Klientowi chodziło o coś w rodzaju newslettera, którym mógłby wysyłać wiadomości w formacie HTML do wybranych użytkowników lub grup użytkowników swojej aplikacji i ogólnie mających dostęp i konta w SharePoint (ale również i z poza organizacji).
W Nintex Workflow dla SharePoint (w każdej wersji), gdy używana jest akcja „Flexi task” i generuje ona, a następnie przydziela zadania dla konkretnych osób, gdy zalogowany użytkownik próbuje przejść do zatwierdzenia zadania (a nie jest to ta sama osoba, która jest do zadania przydzielona), aplikacja wyświetla komunikat: „You are not authorized to respond to this task.” – by móc wybrane zadanie zakończyć, użytkownik musi następnie kliknąć na link „delegate” i delegować zadanie na siebie. Dopiero wówczas może je zatwierdzić lub odrzucić.
