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.
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ć?
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ę”.
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.
Nintex zapowiedział tę innowację kilka miesięcy temu podczas koferencji InspireX w Nowym Orelanie (luty tego roku). Podczas swojej prezentacji „Extensibility on the Nintex Workflow Platform” Vadim Tabakam i Brad Orluk, a potem na Blogu Nintex zostały pokazane i opisane pierwsze wrażenia z nowej funkcji.
Aktualnie funkcja dostępna jest wyłącznie w tzw. „Beta preview”. Czym jest? Nintex nazywa to „extensibility framework”. Jest to narzędzie, które pozwala klientom na dodawanie do Nintex Workflow Cloud własnych RESTowych endpointów, które następnie są „zamykane” w gotowe do użycia akcje. Jak to działa?