SAP接入MCP：AI代理连接S/4HANA的5种架构模式

当大模型试图直接读取S/4HANA中的业务数据时，企业面临一个两难：要么为每个模型和每个工具单独开发连接器，要么放弃对现有治理体系的控制。模型上下文协议（MCP）正在改变这个局面——它把M×N的集成噩梦变成了M+N的标准接口。

本文基于对SAP MCP集成方案的深入分析，拆解五种已经在SAP生态中成型的架构模式，以及贯穿所有的治理原则。

为什么MCP对SAP集成至关重要

传统模式下，三个语言模型对接三个SAP工具，意味着九条脆弱的定制连接器。MCP把这件事标准化：每个模型只需实现一次客户端，每个工具只需暴露一次服务端，双方通过开放协议对话。

协议本身的机制并不复杂。宿主环境（如Claude Desktop、Claude Code、Copilot Studio或SAP Joule）为每个连接的服务器运行一个MCP客户端。服务器暴露三种构建块：模型可调用的工具（tools）、可读取的资源（resources）、可复用的提示模板（prompts）。本地服务器通过标准输入输出通信，远程服务器使用可流式HTTP。底层是JSON-RPC，代理在运行时通过tools/list发现工具，通过tools/call调用工具——代理内部不需要任何连接器代码。

真正复杂的是如何在SAP的企业级约束下落地这个协议。

MCP基于JSON-RPC 2.0构建，这是一种轻量级远程过程调用协议，使用JSON作为数据格式。与REST不同，JSON-RPC强制统一的请求/响应结构，包含jsonrpc、method、params和id字段，天然支持批量请求和通知。MCP在JSON-RPC之上定义了会话生命周期（初始化、能力协商、关闭）和三种原语（tools/resources/prompts），使客户端和服务器能动态发现彼此能力。对于SAP集成，这意味着代理无需预编译任何SAP特定逻辑，只需实现一次MCP客户端，即可与任意符合协议的SAP MCP服务器交互。

五种架构模式一览

SAP生态中已经分化出五条清晰的路径，每条对应不同的使用场景和治理需求：

1. 开发者工具链——基于ABAP Development Tools API的官方MCP服务器
2. 治理化企业路径——通过SAP Integration Suite中的MCP网关
3. BTP零代码服务器——从OData描述文件自动生成MCP工具
4. 运维服务器——面向Cloud Integration监控的轻量级Python服务
5. ABAP栈内嵌MCP——直接在ABAP系统中发布MCP端点

此外还有一类知识服务器，它们不执行操作，而是为模型提供与版本匹配的SAP文档上下文。

模式一：ABAP开发工具链

SAP为ABAP Development Tools发布了官方MCP服务器，同时支持Eclipse和VS Code。它复用了成熟的ADT Java栈及其连接性和缓存机制，支持多服务器网络，后端兼容NetWeaver 7.31。

这个服务器的安全设计值得注意：默认关闭，只允许白名单系统接入，编辑功能默认关闭（只读模式），写操作必须按包逐个授权并有人在环审核。

开源社区服务器使用相同的ADT REST服务。一个提供只读工具，另一个增加了完整的增删改查能力，包括锁定、语法检查、激活和传输。配置只需几行：用claude mcp add注册服务器，或在桌面配置的mcpServers块中加入系统URL、客户端和具有开发者权限的专用用户。

然后就可以直接提问。比如"读取这个类，解释它，修复SELECT语句，然后激活"——代理会自动完成搜索、读取、锁定、编辑、语法检查、激活和解锁的全过程。建议先在本地包中测试写操作，并始终审查生成的代码。

模式二：治理化企业路径（MCP网关）

这是生产环境最重要的模式。核心原则只有一句话：AI代理不应直接连接SAP。

正确做法是把MCP放在你已有的治理API层前面。代理对SAP Integration Suite中的MCP网关说MCP协议，网关是控制平面——处理认证、授权、限流和载荷保护，并提供完整的监控和追踪。网关运行在集成单元（cell runtime）上，而不是处理集成流的运行时。网关背后，Cloud Integration仍然是映射、路由、编排和重试的引擎。

用一句话概括分工：AI推理，MCP暴露，API治理，集成整合，SAP执行。

MCP服务器构件可以从三种来源构建：部署在集成单元上的API构件、由OpenAPI 3.0规范描述的HTTP端点、以及RFC（比如创建采购订单的BAPI直接变成代理工具）。每种来源有每服务器的工具数量上限，需查阅最新文档。之后需要策划工具名称和描述、添加提示模板、应用策略、部署并在Developer Hub中发布，用MCP Inspector测试。

身份是这里最关键的设计问题。 在主体传播（principal propagation）模式下，用户通过SAP Cloud Identity Services登录MCP客户端，JWT令牌到达Integration Suite（用户需要API Invoke角色），Cloud Connector为该用户签发短期X.509证书，S/4HANA通过证书规则将证书映射到真实SAP用户。这样后端执行的是该用户自己的权限。对于S/4HANA公有云，目的地使用OAuth到SAML bearer assertion，不需要Cloud Connector。

记住：AI永远不是你的授权层。

主体传播（Principal Propagation）是SAP云连接器（Cloud Connector）的核心安全机制，用于将云应用中的用户身份传递到本地SAP系统。在MCP场景中，用户通过SAP Cloud Identity Services完成OIDC登录，MCP客户端获得JWT令牌；该令牌随请求到达SAP Integration Suite，Cloud Connector验证令牌后，代表该用户向本地S/4HANA签发短期X.509客户端证书；S/4HANA通过证书主题映射规则（如CN字段）关联到真实SAP用户，从而在ABAP会话中还原用户上下文。整个过程无需在SAP系统中存储用户密码，且后端权限检查完全基于该用户的SAP角色。对于S/4HANA公有云，由于无法使用Cloud Connector，改用OAuth 2.0到SAML 2.0 bearer断言流程，由SAP Cloud Identity Services直接签发SAML断言给S/4HANA，实现同等效果。

模式三：BTP上的零代码服务器

OData MCP代理包允许你用一个JSON文件描述API，它自动生成工具。每个实体集变成一组工具：列表、获取、创建、更新、删除，加上导航属性。代理自动获取OData v2的CSRF令牌、通过SAP Cloud SDK解析BTP目的地、用XSUAA作用域控制viewer/editor/admin角色。

这个模式已经在驱动Cloud Integration、AI Core、BTP核心服务、审计日志和Cloud Foundry的MCP服务器。

OData（Open Data Protocol）是SAP广泛采用的RESTful API标准，用于暴露业务数据模型。OData v2中，所有修改操作（POST/PUT/MERGE/DELETE）必须携带CSRF（跨站请求伪造）令牌，该令牌通过先发送GET请求并读取响应头x-csrf-token获得，随后在请求头中回传。OData MCP代理自动处理此流程，对每个会话缓存令牌并在过期时刷新。此外，BTP目的地（Destination）是SAP BTP中用于存储后端系统连接信息（URL、认证方式、代理设置）的配置对象，SAP Cloud SDK可自动解析目的地并注入HTTP客户端，使MCP服务器无需硬编码连接细节。XSUAA（SAP Authorization and Trust Management Service）则提供OAuth 2.0作用域，用于在MCP工具层面实施细粒度访问控制（如viewer只读、editor可写）。

模式四与五：运维与栈内嵌

运维服务器是一个轻量级Python MCP服务器，用服务密钥包装Cloud Integration的OData API。代理可以列出失败消息、读取消息处理日志、检查包和运行时构件，然后用自然语言解释根因。凭证留在服务器端，永远不出现在提示词中。建议从只读开始，之后再加写工具和更强的控制。

ABAP栈内嵌MCP通过ABAP附加组件把MCP端点发布为ICF服务，和OData或SOAP一样，甚至支持非常老的版本。你指定表、视图和CDS视图，每个变成一个展示工具。增删改工具是ABAP类，一个方法对应动作，一个对应元数据。没有中间件，继承ICF安全机制（如单点登录）。但原始表读取会跳过应用层权限检查，因此需要行级授权和CDS访问控制——审计人员一定会问这个问题。

ICF（Internet Communication Framework）是ABAP应用服务器中处理HTTP请求的运行时框架，所有入站HTTP/HTTPS请求（包括OData、SOAP、UI5应用）均通过ICF服务处理。ICF服务在事务码SICF中配置，可继承SAP登录/SSO、SSL、会话管理等安全机制。将MCP端点发布为ICF服务意味着复用现有SAP认证栈（如SAML、Kerberos、X.509），无需额外网关。然而，ICF本身不执行ABAP应用层权限检查（如SAP授权对象S_TABU_DIS、S_PROGRAM），因此直接读取数据库表会绕过业务权限。CDS访问控制（CDS DCL）通过@AccessControl.authorizationCheck注解定义行级和列级权限，在CDS视图被访问时由ABAP运行时强制执行，可弥补此缺口。审计时需明确区分：ICF层认证证明“谁在调用”，而CDS DCL证明“该用户能看到哪些行”。

如何选择：场景对照表

• ABAP开发者生产力 → ADT MCP服务器
• 业务用户和生产代理 → Integration Suite MCP网关 + 主体传播
• BTP和管理API → 配置驱动的OData代理
• Cloud Integration运维支持 → 运维服务器
• 无中间件的ECC系统 → 系统内嵌附加组件 + 严格授权

上线前检查清单

使用最小权限的技术用户或传播用户；从只读开始，白名单系统和包；永远不要提交凭证，开发环境之外永远不要关闭TLS验证；每个写操作保留人在环；在网关层应用限流和审计日志；安装第三方服务器前先审查；向外发模型发送代码或数据前检查公司的AI政策。

架构的本质没有变——系统、API、集成、系统的链路依然存在。变的只是消费者：从人变成了代理。链路变成代理 → MCP → API → 集成 → SAP。AI做决策，集成做治理，SAP做执行。