Power BI中Web.Contents递归查询数据源计划刷新配置问题

你的问题核心在于手动编写的递归Web查询没有被Power BI自动识别为数据源，导致发布后网关无法关联，进而无法配置计划刷新。结合你的场景，我整理了几个关键解决步骤：

1. 显式定义可识别的数据源 #

Power BI Desktop不会自动识别硬编码在函数里的Web.Contents调用为数据源，你需要把基础URL抽离成独立查询，让Power BI能"看见"这个数据源：

• 新建一个名为BaseURL的查询：

  let
      Source = "http://exampleURL:1000"
  in
      Source
  

• 修改主查询Log Scroll，引用这个独立的URL查询：

  let 
      url = BaseURL,
      Source = RecursiveFetch(url, 5, null, null)
  in Source
  

• 同步修改RecursiveFetch函数，确保它使用传入的url参数（不要在函数内硬编码URL）。

这样操作后，Power BI会在数据源列表中显示这个Web数据源，发布后就能和网关中已配置的数据源关联起来。

2. 修复递归函数的语法逻辑错误 #

你的RecursiveFetch函数里有个明显的语法问题，会导致查询执行失败（甚至无限递归），这也可能间接影响刷新配置：
原代码中递归调用部分：

Return = if (Counter < scrollCount) then ParsedResults & RecursiveFetch(url, scrollCount scrollID, Counter) else ParsedResults

这里存在两个问题：

• scrollCount和scrollID之间缺少逗号，语法错误
• 没有传递正确的新scrollID（应该从返回的JSON中提取，比如Results[scroll_id]），且Counter需要递增（Counter + 1）

修正后的递归调用应该是：

Return = if (Counter < scrollCount) then ParsedResults & RecursiveFetch(url, scrollCount, Results[scroll_id], Counter + 1) else ParsedResults

这个修正不仅能让查询正常运行，也能避免发布后出现未知的执行错误。

3. 对齐网关与查询的数据源配置 #

确保网关中的Web数据源配置和查询完全匹配：

• URL必须完全一致：网关中配置的URL要和BaseURL的内容一模一样（比如http://exampleURL:1000，不要额外加路径或参数）
• 凭据统一管理：不要在查询中硬编码Authorization头的密钥，建议在Power BI Desktop中先给BaseURL对应的数据源设置凭据（路径：「数据」>「数据源」>找到该Web数据源>「编辑凭据」），选择基本身份验证并填入密钥。这样发布后，网关会自动关联同URL的数据源凭据。
• 检查网关状态：确保网关集群处于「运行中」，且能访问目标Web API（可以在网关管理页面测试数据源连接）。

4. 进阶方案：使用自定义连接器（可选） #

如果上述方法还是无法解决，你可以考虑用Power Query SDK开发自定义连接器，把你的递归API调用、身份验证逻辑全部封装进去。自定义连接器会被Power BI明确识别为数据源，网关配置和计划刷新的兼容性会更好，也更便于维护。

内容的提问来源于stack exchange，提问作者Carl Chittenden