Spotkałeś się kiedyś z tym problemem? Workflow działa poprawnie i nagle, bez zrozumiałego powodu, przechodzi w stan „suspended” (zawieszony)? Wówczas, gdy najedziesz na ikonkę „i” obok statusu, by uzyskać więcej informacji, pokaże się komunikat, iż „The workflow instance was too large to persist”? Ja ostatnio zacząłem obserwować takie zachowania. Poniżej opisuję wyniki mojej analizy i rekomendacje, jak tego uniknąć lub rozwiązać ten problem.
W Nintex dla on-premisowych wersji SharePoint począwszy od 2010 (nawet w edycjach Standard) możliwe było używanie akcji, które pozwalały na wołanie Excel Services dostępnych na platformie SharePoint i w ten sposób na pracę z danymi, z plików xls i xlsx. Jednak w SharePoint Online ta usługa nie jest dostępna (ok, można z niej korzystać poprzez REST API, jednak nie w takim zakresie, jak można w on-premise), nie istnieje też możliwość skorzystania z niej poprzez dostępne akcje w Nintex for Office 365 czy Nintex Workflow Cloud. Zatem nie istnieje prosty sposób, by zrealizować taki scenariusz. Nasunęło mi się pytanie (zainspirowane licznymi z kolei pytaniami stawianymi na forum Community Nintex), w jaki sposób można to zrobić?
Najczęściej mawianym obejściem było zapisanie pliku xlsx do formatu csv, a następnie odczytanie jego zawartości i przetwarzanie jej poprzez użycie kolekcji (planuję napisać o tym oddzielny post).
Jednak ostatnio zauważyłem, że Microsoft Flow posiada już dostępne akcje, które właśnie używają Excel Services dostępnych w SharePoint Online. Co więcej, każdy ma dostęp do bezpłatnej wersji Microsoft Flowi tych akcji również. Teraz nie pozostało mi nic, tylko spróbować.
Niedawno brałem udział w projekcie, w którym dane i informacje były tworzone przez lata w SharePoint utrzymywanym w infrastrukturze klienta (SharePoint 2010 i 2013) jednak firma zdecydowała się na migrację swoich zasobów i aplikacji do SharePoint Online w Office 365. Mówiono, że migracja z użyciem Sharegate będzie prosta i szybka, ale… jak zwykle rzeczywistość okazała się nieco bardziej skomplikowana.
Zanim rozpoczęliśmy migrację zacząłem od lektury treści, które opisywały sam proces migracji z użyciem Sharegate i o możliwych problemach. Na bazie tego i własnych doświadczeń, mogę podzielić je na 3 grupy:
Ale po kolei. Postaram się przedstawić po krótce każdą z nich.
Ostatnio rozpocząłem testowanie dostępnego w Nintex dla O365 RESTful API (http://help.nintex.com/en-us/sdks/sdko365/) z poziomu samych przepływów pracy (nie np. PowerShell, czy C#). Pomimo tego, że nie wszystkie metody działają poprawnie (np. zapisywanie wskazywanego przepływu jako nowy), z uwagi na fakt, iż akcja „Web Request” nie wspiera jeszcze przekazywania danych w postaci stringów binarnych i zwyczajnie wycina puste bajty (0x00), co w efekcie powoduje, że przekazywany do API plik jest niepoprawny, jednak u samych podstaw tych eksperymentów natrafiłem na inne wyzwanie. Mianowicie, w jaki sposób, z poziomu przepływu pracy tworzonego w Nintex, dostać się do wartości ciastek FedAuth i rtFa?
Czytałem artykuły, przeglądałem Stackoverflow w poszukiwaniu podobnych tematów, starając się znaleźć odpowiedź na pytanie, w jaki sposób można pobrać ciastka przy pomocy JavaScript. Traciłem już nadzieję i wówczas na trafiłem na ten cenny artykuł: Remote authentication in SharePoint Online | … And All That JS i nagle wszystko stało się jasne 🙂
Niniejszy post prezentuje sposób na uzyskanie wartości trzech obiektów, których SharePoint używa w celu uwierzytelnienia sesji: