Microsoft PowerApps, SharePoint Online, Power Automate i te niesforne załączniki

4 minut(y)

W ostatnim czasie miałem okazję pracować trochę z PowerApps. Scenariusz jaki przyszło mi obsłużyć zakładał wrzucanie plików wraz z kilkoma informacjami do Listy w SharePoint Online. Aby ograniczyć bezpośredni dostęp do SharePoint Online użytkownikom końcowym, postanowiłem jako interfejs “wejściowy” wykorzystać aplikację stworzoną w PowerApps. Po pomyślnym umieszczeniu pliku na liście, użytkownik miał otrzymywać wiadomość e-mail wraz z wprowadzonymi przezeń informacjami, w tym także bezpośredni link do załącznika.

Spis treści:

1. Integracja SharePoint Online i Power Automate

“Na szczęście” z poziomu Listy SharePoint Online można w łatwy sposób dodać automatyzację wykorzystując do tego celu usługę Power Automate (dawniej Flow).

SharePoint Online and Automate W ramach dostępnych szablonów możemy wybrać opcję When an item is created. Działa to całkiem zadowalająco. Po utworzeniu elementu listy w ciągu kilku/kilkunastu sekund odpowiedni wyzwalacz jest wywoływany i nasza automatyzacja może się zadziać.

2. Przepływ Power Automate

Gdy już mamy “połączenie” naszej Listy w SPO z Power Automate możemy przejść do działania. Tworzymy prosty przepływ polegający na pobraniu listy załączników (2) z utworzonego elementu (1), a następnie umieszczeniu bezpośrednich adresów do tychże (4) w zmiennej AttachmentURL (3). W celu “weryfikacji”, czy załącznik został przesłany, sprawdzamy jeszcze warunek (5), czy zmienna AttachmentURL jest pusta czy też nie. Jeśli jest, to kończymy przepływ błędem i odpowiednim komunikatem (6). W przeciwnym razie kończymy sukcesem (7).

Power Automate

Jako że SPO pozwala dodać wiele załączników do jednego elementu listy, wynikiem akcji Get attachments jest lista obiektów załączników - stąd też pętla Apply to Each. Jednak w moim scenariuszu występować miał tylko jeden załącznik per element listy. OK, jak do tej pory wszystko idzie gładko. Przejdźmy zatem do PowerApps.

3. PowerApps i SharePoint Online

PowerApps posiadają cały zestaw funkcji do obsługi List w SharePoint. Dokładny opis można znaleźć oczywiście w dokumentacji.

W tym wypadku użyjemy funkcji SubmitForm(), a konkretnie:

SubmitForm(Form1)

SubmitForm

Poniżej wideo pokazujące jak wygląda ów proces w praktyce.

Jak widać, w podstawowym scenariuszu wszytko idzie “jak po maśle”. Niemniej, jak wiadomo, życie i realne przypadki potrafią płatać figla. Bo wyobraźmy sobie scenariusz, gdzie osoba przesyłająca plik w taki właśnie sposób, ma bardzo słabe połączenie internetowe (niski Upload), a plik do wysłania znacznych rozmiarów (w chwili pisania ów posta, jest to maksymalnie 50MB). Pytanie - co się wydarzy?

4. Problemy z załącznikami

Otóż z moich obserwacji i testów wynika, że dodając nowy wpis wraz z załącznikiem z poziomu portalu SPO wszystko działa tak jak powinno - Automate uruchamia się po zakończeniu przesyłania.

SubmitForm

Natomiast z poziomu PowerApps funkcja SubmitForm() tworzy obiekt na liście niemal natychmiast, a następnie dosyła nasz załącznik. Tej akcji “nie widzimy” z poziomu portalu bo dzieje się “pod spodem”, a my cały czas widzimy okienko dodawania elementu do czasu przesłania załączników. Zatem zdarzyć się może, że nasza Automatyzacja wystartuje jeszcze przed ostatecznym zapisaniem załącznika na liście.

Widać to na zrzucie poniżej - wartości Utworzony i Zmodyfikowane są jednakowe, bo mój załącznik cały czas się wysyłał, a przepływ został mimo to uruchomiony. SubmitForm

Zobaczmy to na filmie.

Parametry testowe: W celu symulacji problemów z prędkością wysyłania ograniczyłem mój upload do 1Mbps

Jak widać na wideo, scenariusz z automatycznym wyzwalaniem automatyzacji nie do końca się sprawdza. Oczywiście można by tu dodać jakiś Delay, ale w sumie to nie wiemy ile czasu wystarczy. Nie możemy też czekać np. godziny - bo wtedy użytkownik czekałby tą godzinę na adres do załącznika. Można też spróbować skorzystać z Trigger Conditions, dzięki którym możemy sprawdzić czy załącznik jest, czy też go nie ma wykorzystując do tego funkcję empty. I muszę przyznać, że faktycznie to działa… niemniej w przypadku braku załącznika, nasz przepływ w ogóle się nie uruchomi - zatem nie jest to to, czego potrzebujemy.

Po napisaniu wpisu zauważyłem, że w moich testach pominąłem scenariusz “Wysyłanie dużego załącznika przez Portal z ograniczonym internetem”. Niemniej, do dalszej części wpisu ten scenariusz nie jest niezbędny.

5. Rozwiązanie

Jak wywnioskować można z powyższych testów, wyzwolenie przepływu nie może odbyć się automatycznie po utworzeniu wpisu na Liście. Należy zatem wyzwolić taki przepływ z samej aplikacji. Problem jaki tu się pojawia jest następujący - skąd będę wiedział, który element listy sprawdzić pod względem załącznika? Na szczęście i na to jest sposób :) Po krótkich poszukiwaniach można natrafić na jedną z ciekawych właściwości obiektu Form, a mianowicie parametr <form_name>.LastSubmit. Dzięki niemu możemy “wyciągnąć” informacje o ostatnim przesłanym elemencie na Liście. Zobaczmy poniższe wideo:

Już prawie jesteśmy w domu. Po utworzeniu elementu otrzymujemy informacje o nim, a w tym również unikalny identyfikator obiektu. Posiadając ów identyfikator możemy przekazać go z PowerApps do Power Automate wykorzystując możliwość uruchomienia przepływu bezpośrednio z aplikacji. W tym celu zamieniamy w istniejącym przepływie trigger z SharePoint na PowerApps. A następnie dodajemy akcję uruchomienia tegoż przepływu po zakończeniu przesyłania załącznika.

If(
    SubmitForm(Form1),
    'Nazwa_Przepływu'.Run(Value(Form1.LastSubmit.'Identyfikator (ID)'))
)

Warto tu zwrócić uwagę na wykorzystanie funkcji Value, która to zamienia typ Text na Number. W przypadku jej pominięcia, otrzymalibyśmy informację o błędzie, gdyż akcja Get Item wymaga Identyfikatora elementu, który jest liczbą.

Poniżej cały proces na wideo.

Mając już działające rozwiązanie, które “czeka” na zakończenie przesyłania załącznika wystarczy rozbudować nasz przepływ o akcję “Wyślij email” wraz z adresem do załącznika wykorzystując do tego np. connector SMTP.

6. Podsumowanie

Jak widać, “ready to use” rozwiązania podstawiane nam niemal na tacy przez platformę nie zawsze muszą spełnić nasze wymagania. Warto więc rozpisać możliwie dokładnie tzw. User Stories i wypunktować możliwe problemy. Dzięki temu można uniknąć “dużego” przemodelowania logiki aplikacji w przyszłości ;)

Zostaw komentarz