Google Cloud在2026年8月22日更新发布说明，确认Apigee控制台中的ServiceCallout策略创建故障已经修复。此前用户在API代理或共享流中添加该策略时，界面不会生成必填的HTTP目标字段，导致创建和添加按钮一直处于不可用状态。
这一问题对应编号543626585，影响的是Apigee管理界面的策略创建流程，而不是ServiceCallout运行时本身。修复上线后，用户不再需要先手工插入占位XML，才能绕过界面校验并保存策略。
必填HTTP目标缺失曾让创建按钮失效
ServiceCallout策略需要明确请求将被发送到哪里。故障发生时，控制台创建表单没有加入所需的HTTP目标字段，表单校验因此始终认为配置不完整。
受影响范围包括API代理和共享流。前者直接承载API请求处理逻辑，后者通常被多个代理复用，因此同一界面问题可能同时阻塞新代理开发和公共策略组件维护。
官方此前给出的临时办法是在策略XML中手工加入占位内容，再继续编辑。现在该办法已经不再必要，团队可以按正常界面流程创建策略，但既有占位配置仍应检查是否已经替换为真实目标。
ServiceCallout负责在代理流程中调用服务
ServiceCallout允许Apigee在代理执行期间调用外部REST服务，也可以调用同一组织与环境中的内部API代理。目标可以使用HTTP或HTTPS，常见用途包括读取补充数据、调用验证服务或把请求发送到后端辅助接口。
典型流程会先用AssignMessage构造请求，再由ServiceCallout发起调用，最后使用ExtractVariables从响应中提取字段。策略可以保存响应变量，供后续条件判断、消息转换或错误处理使用。
它还支持通过目标服务器管理后端地址和负载均衡，并可为需要Google身份的目标生成访问令牌或ID令牌。调用Secret Manager、Cloud Run等服务时，权限配置与目标地址同样需要单独验证。
此次修复只改变管理界面创建流程
这次发布说明明确描述的是Apigee UI缺陷。已经通过API、代码仓库或其他自动化方式部署的ServiceCallout策略，并不会因为这项修复自动更改目标、超时或请求内容。
控制台通常先创建策略实例，再把它附加到指定流程。用户可以直接编辑XML，也可以通过属性检查器调整配置。界面恢复正常后，保存成功仍不代表策略已被附加到正确的PreFlow、PostFlow或条件流。
开发者应把界面可创建与代理可正确运行分开验证。前者只说明表单问题已解决，后者还取决于变量、目标权限、网络连通性和响应处理。
目标地址、响应变量与超时仍要校验
ServiceCallout默认超时时间为55秒。调用超时会触发错误，并可能让代理返回HTTP 500，因此生产配置需要根据上游服务的延迟设置合理超时，同时定义故障规则和可识别的错误响应。
如果使用请求变量，必须确认该变量已经在调用前创建；如果保存响应，也要检查后续策略引用的是同一个变量名。目标地址应避免直接散落在多个策略中，频繁变更的后端更适合由目标服务器统一管理。
对于内部代理调用，还要核对组织、环境和代理路径；对于外部HTTPS服务，则要验证TLS、DNS和出口网络。界面修复不会替代这些运行时检查。
团队应重新测试曾被阻塞的策略变更
此前遇到按钮不可用的项目，可以重新打开原代理修订版，按照正常流程创建ServiceCallout并比较生成的XML。若曾使用占位配置绕过问题，应确认占位目标、临时变量和测试凭据已经全部清理。
部署前可以在Trace或调试会话中观察请求生成、目标连接、响应变量和故障分支，再使用小流量修订版验证。共享流的变更尤其需要检查所有引用它的代理，避免公共组件修复后影响其他接口。
团队还应在版本记录中标注该缺陷和修复日期，减少成员继续沿用旧的手工XML方案。若控制台仍出现相同现象，应记录组织、环境、浏览器和代理修订版信息，再提交支持请求，以区分缓存问题与新的界面故障。
