Power Query 中的 Microsoft Graph 缺乏支援

連線 至不建議或支持來自 Power Query 的 Microsoft Graph REST API。 相反地，我們建議使用者探索替代解決方案，以根據 Graph 擷取分析數據，例如 Microsoft Graph 資料連線。

您可能會發現您可以透過 或 OData.Feed 函式對 Microsoft Graph API 端點Web.Contents進行特定 REST 呼叫，但這些方法不可靠，因為長期解決方案。

本文概述 Power Query 中與 Microsoft Graph 連線相關的問題，並說明為何不建議這麼做。

驗證

Power Query 和OData.Feed函式的Web.Contents內建組織帳戶驗證流程與大部分 Graph 端點不相容。 具體而言，Power Query 的 Microsoft Entra ID 用戶端會要求 user_impersonation 範圍，這與 Graph 的安全性模型不相容。 Graph 使用一組豐富的許可權，這些許可權無法透過我們的一般 Web 和 OData 連接器取得。

基於安全性考慮，實作您自己的 Microsoft Entra ID 認證擷取流程，或是使用硬式編碼或內嵌認證，也不建議這麼做。

OData 連結庫的不相容性

Graph 的某些圖形端點和延伸模組可能需要使用 Power Query 內建 OData.Feed 函式不支援的 OData 連結庫和功能，因為 Graph 和 Power Query 可能會使用兩個不同的 OData 連結庫版本。 這些問題通常會導致擷取服務 $metadata 的文件時發生錯誤。 您可能會發現將 選項傳遞 Implementation = "2.0" 至 OData.Feed 函式呼叫的相關常見指引，以確保使用最新的支援的 OData 連結庫。 雖然此方法確實解決了某些 OData 不相容問題，但當 Graph 和 Power Query 在不同時間採用新版本的 OData 連結庫時，您仍然可能會發生錯誤。

效能

Microsoft Graph API 的設計訴求是支援許多應用程式案例，但對於大部分分析案例所需的大規模數據擷取而言則不理想。 如果您嘗試從 Graph API 擷取大量數據，可能會遇到效能問題。 如需案例適用性的詳細數據，請參閱 Graph 檔。

使用自訂連接器

某些 Power Query 使用者已透過自訂連接器啟用 Graph 連線能力，使其功能限制為圖形 API 的某些部分。 此方法可讓連接器開發人員透過使用 Graph 特定許可權來定義自己的 Microsoft Entra ID 用戶端，來解決一般驗證問題。 某些自定義連接器會使用 Web.Contents 和模擬其連接器邏輯內的 OData 支援，來解決 OData 挑戰。 不過，不建議使用此方法，因為用戶經常遇到上述的效能和延展性問題。 採用此路由的開發人員應該繼續考慮這些限制。