Ostatnio, podczas wdrażania nowych polityk DLP w środowisku klienta, część istniejących Dataflow przestała działać, zgłaszając, że używane przez nie połączenia zostały wyłączone i nie mogą być dalej używane.

Jako powód w komunikacie pojawiała się informacja, że „This could be because your tenant’s data loss prevention policies do not allow connections to this connector or endpoint.” Z kolei jako rozwiązanie komunikat sugerował: „Please contact your tenant administrator to adjust the policies to re-enable this connection. (Connector: webcontents, Connection ID: …, Request ID: …).„

Tymczasem, gdy otworzyłem sam Dataflow, komunikat nie wskazywał, który konektor jest objęty DLP, a jedynie informował, że połączenie jest wyłączone i nie może być używane:

Debugowanie

Na początku sądziłem, że przyczyną błędu jest fakt, że konektory Power Query Dataflows lub Power Platform Dataflows są zablokowane albo nie znajdują się w kategorii „Business”. Ku mojemu zaskoczeniu okazało się jednak, że były tam od początku.

Skupiłem się więc na samym komunikacie, a dokładniej na tej części, która opisywała zablokowany konektor: „Connector: webcontents„. Nie jest łatwo powiązać wewnętrzne nazwy konektorów z ich nazwami wyświetlanymi w interfejsie, dlatego trochę pogrzebałem i odkryłem, że webcontents to wewnętrzna nazwa konektora „HTTP with Microsoft Entra ID (preauthorized)„.

Nie wiedziałem wcześniej, że za każdym razem, gdy ktoś tworzy połączenie z poziomu Dataflow, w środowisku tworzona jest dodatkowa instancja połączenia „HTTP with Microsoft Entra ID (preauthorized)”. Dowiedziałem się też, że jeśli połączenie używa OAuth do autoryzacji, odpowiednia pozycja na liście wszystkich połączeń w środowisku wyświetla status „Connected”. Tymczasem jeśli połączenie jest anonimowe, status to „Reconnect”.

Ważne! Każde połączenie skonfigurowane w Dataflow tworzy w środowisku jedną instancję połączenia HTTP with Microsoft Entra ID (preauthorized) używane przez dany Dataflow.

Gdy już to odkryłem, sprawdziłem konfigurację DLP i okazało się, że ten konektor faktycznie jest przypisany do grupy „Business”. Następnie otworzyłem konfigurację endpointów konektora, aby sprawdzić, czy adres, z którego Dataflow pobiera dane, znajduje się na liście dozwolonych. I tutaj również odpowiedź brzmiała: „tak”.

Rozwiązanie

Rozwiązanie tego problemu zajęło mi dosłownie kilka godzin. Na pewnym etapie zmieniłem konfigurację endpointów konektora tak, aby tymczasowo pozwalał na połączenia ze wszystkimi endpointami:

To faktycznie rozwiązało problem. Po dłuższej chwili Dataflows ponownie zaczęły poprawnie odświeżać dane. Nie byłem jednak zadowolony z takiego podejścia, ponieważ nie chciałem, aby wszystkie endpointy były dostępne przez ten konektor.

Hint: Konieczne może okazać się usunięcie wszystkie istniejących połączeń w danym Dataflow, oraz usunięcie powiązanych połączenia na stronie „Connections” w portalu Power Automate, a następnie utworzenie je ponownie z poziomu projektanta Dataflow.

Następnie zajrzałem do samego Dataflow. Początkowo byłem tak skupiony na tym, że pobiera on dane z Web API, że nie zauważyłem, iż pobiera również dane z pliku Excel przechowywanego na SharePoint! Co więcej, zdałem sobie sprawę, że w konfiguracji endpointów dla konektora „HTTP with Microsoft Entra ID (preauthorized)” nie było dodanej maski „https://*sharepoint.com/*” jako dozwolonej. Po jej dodaniu Dataflow znów zaczęły działać. A co najlepsze – opcja „allow all” dla konfiguracji endpointów wcale nie była potrzebna! Yay! 🥳

Wnioski

Jeśli jesteś administratorem Power Platform i planujesz wdrożyć nowe zasady DLP, a w Twojej organizacji wykorzystywane są Dataflows, koniecznie zbierz informacje o wszystkich źródłach danych, z których korzystają – nawet jeśli wydają się najbardziej oczywiste (SharePoint, serio?). Następnie dodaj je do listy dozwolonych w konfiguracji endpointów konektora „HTTP with Microsoft Entra ID (preauthorized)”. Powodzenia!