Top
I hate SharePoint IT frustration

Problemy z adaptacją użytkowników w SharePoint i Office 365

User Adoption – ten poruszany często zwrot nie jest związany stricte z systemami IT. Określa w zasadzie jak szybko i chętnie użytkownicy przyswajają i akceptują nowy produkt, innowację, zmianę, itp… I to nie tylko w świecie IT. W zasadzie jest używany w każdym segmencie rynku, który jest nastawiony na produkcję dóbr konsumowanych przez klientów. Nowy telefon, nowy samochód, innowacyjna usługa. Im szybciej użytkownik “kupi”, tym szybciej rosnąć będzie ROI.

Podczas konferencji Collaboration Summit, która niedawno zakończyła się w Zagrzebiu, miałem okazję uczestniczyć na wykładzie Jussi Mori, na którym opowiadał właśnie o adaptacji użytkowników, próbując ocenić przyczyny, dla których użytkownicy wcale nie chcą (nie mogą?) łatwo przyswoić nowych rzeczy oraz o sposobach, jakimi można próbować to zmienić. Ten wykład zainspirował mnie do pogłębienia tematyki i napisania tego posta, opartego na własnych doświadczeniach i posiłkując się informacjami dostarczonymi przez Internet.

Ten post traktuje o adaptacji użytkowników w IT, w szczególności w zakresie pracy użytkowników z produktami Microsoft, a dokładniej – SharePoint i Office 365.

Office 365 – plany rozwoju na 2017 rok

Niedawno zakończona widekonferencja „SharePoint Virtual Summit” (https://resources.office.com/ww-landing-sharepoint-virtual-summit-2017) potwierdziła liczne „przecieki” na temat nadchodzących planów na dalszy rozwój Microsoft Office 365 w kontekście tzw. „Digital Workplace” – przestrzeni dedykowanej pracownikom, dostarczającej narzędzi niezbędnych do wykonywania pracy szybko i efektywnie.

W tym ujęciu, Microsoft szczególnie promuje następujące produkty:

To właśnie wobec nich planowane są najciekawsze zmiany.

Jak zaimportować dane z pliku XLSX do SharePoint przy pomocy Nintex i Microsoft Flow

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ć.

Sharegate migration Nintex

Migracja Nintex Workflow z on-prem do Office 365

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:

  1. Ograniczenia Sharegate
  2. Ograniczenia SharePoint Online
  3. Ograniczenia Nintex dla Office 365

Ale po kolei. Postaram się przedstawić po krótce każdą z nich. 

Praca z obiekatmi autoryzacyjnymi w Nintex dla Office 365 (RequestDigest, FedAuth, rtFa)

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:

  1. fedAuth cookie
  2. rtFa cookie
  3. RequestDigest token