SAP 集成平台：工具、许可与场景

把 SAP 集成进更大的系统环境，就像在拼一幅有几块怎么也对不上的拼图。不同的工具、平台和数据格式，都在争夺注意力。集成方案多得让人应接不暇，SAP Integration Suite 就是其中之一，每一个都说自己最合适。我见过团队花几周比较各种平台，最后才发现漏掉了很基本的东西，比如许可方面的影响，或者负载之下的系统延迟。

所以，这一页想把事情讲得更清楚些。也许做不到一清二楚，但足以让您放心做出选择。我从实用的角度来看 SAP 集成平台：

哪些工具真正能很好地配合
间接许可可能在哪里绊您一跤
SAP Integration Suite、CPI、PI 和 BTP 之间究竟如何比较
什么时候第三方工具比 SAP 自家的工具更合适

没有哪个答案适用于所有项目。但只要把使用场景定下来，合适的集成路径通常就会变得明朗。至少，我是这么希望的。

1. SAP Integration Suite 简介

SAP 实施很少只是把 SAP 搭起来。更多时候，是要让 SAP 与其他一切协同工作：遗留系统、云应用、数据库，以及企业多年来一直依赖的各种自建工具。

这正是集成变得关键的地方。它要么把整个系统环境牢牢系在一起，要么悄悄制造摩擦，直到出了故障才有人察觉。

实际上，集成往往被低估。团队把精力放在功能、流程设计和测试上。到了后期，有人才发现：

关键数据没有实时同步
API 限额几周前就已经触顶
因为间接使用，许可成本刚刚翻了一倍
选定的中间件扛不住负载下的数据量

这些事情一开始并不总是显而易见。但最终它们会影响工期、预算，甚至合规。

本页就从这个角度来看 SAP Integration Suite：它们在项目环境里究竟如何运作，解决什么问题，风险又往往藏在哪里。

开始您的实施评估 SAP 集成

2. SAP 项目中常见的集成场景

SAP 项目通常不是从一张白纸开始的。它们从一堆现有系统起步：有的文档齐全，有的几乎没人搞得懂。集成必须把这一切理出头绪，而且常常没有多少拖延的余地。

大多数系统环境里都会出现几种模式：

SAP 到非 SAP 系统的连接。仍在使用的遗留 ERP、CRM 或自研应用。
混合部署。云服务与本地系统并存，努力保持同步。
实时与批处理数据流。快是好事，但可靠往往更重要。
API 驱动与基于中间件。视情况而定，有时两者并用。

像 SAP Integration Suite 这样的工具，设计上就是为了应对其中许多模式，尤其是在混合或以云为主的环境里。但工具本身只是方案的一部分。

把 SAP 连接到外部平台听上去往往很简单，直到格式、安全或时序出来挡路。我见过团队为一点小小的不匹配卡上好几天。一边说的是 REST，另一边偏偏要平面文件。

混合部署一开始看起来很灵活。实际上，它们通常建立在一堆拼凑起来的例外之上。一个服务即时推送数据。另一个还靠夜间作业。

实时集成在规划阶段对每个人都有吸引力。但只有当两端系统都扛得住时，它才行得通。情况并不总是如此。

中间件提供结构，API 提供速度。选哪一个，与其说取决于偏好，不如说取决于现有基础，以及团队实际上能管得过来什么。

需要考虑的跨应用集成场景

1. SAP 与非 SAP 集成

SAP 经常需要与 Salesforce、Oracle 或行业专用工具等平台建立连接。这些集成保证关键业务系统和流程之间的连续性。

实现 SAP 与第三方平台之间的结构化数据交换
涉及认证、字段映射和转换层
在 SAP 推广期间帮助保留现有业务工作流

2. 混合环境（本地 / 云）

大多数 SAP 客户运行在混合环境中。本地 SAP 系统与云平台并存，使集成成为数据一致性和业务敏捷的必要条件。

把 SAP ECC 或 S/4HANA 与 SuccessFactors、Ariba 等云产品连接起来
衔接不同的协议和安全模型
需要强有力的治理，以避免延迟和同步问题

3. 实时集成与批处理集成

在实时集成与批处理集成之间做选择，取决于系统能力、数据量和业务需求。并非所有流程都同样受益于即时数据同步。

实时适合订单创建或库存更新这类事务
批处理更适合价格、主数据或历史数据加载这类大数据集
大多数系统环境两者并用，视流程的关键程度而定

4. 基于 API 的集成

基于 API 的集成让应用借助轻量级协议直接通信。它们非常适合云原生服务和现代开发环境。

非常适合把 SAP 与移动应用、门户或微服务连接起来
部署更快，但需要严格的版本管理和安全处理
常与 SAP API Management 和 OData 服务搭配使用

5. 基于中间件的集成

中间件为 SAP 与多个系统的集成增加了一个中央控制点。它通过编排、消息队列和数据转换来帮助管理复杂性。

用于多个系统与 SAP 交互的系统环境
提供集中的监控和错误处理
例如：SAP PI/PO、SAP Integration Suite、MuleSoft、Dell Boomi

6. 混合集成方式

大多数企业会把 API 与中间件两种策略结合起来用。这种混合模式能适应系统的限制、团队的技能和长期支持的需要。

把直接集成与托管集成两种方法结合起来
为将来的扩展或工具更换提供灵活性
帮助让集成同时契合技术与业务的优先级

3. SAP Integration Suite 概览

说到 SAP 集成，选择合适的 SAP 集成套件，比大多数团队预想的更重要。这个决定不止关乎功能和速度。它会影响工期、支持模式，甚至许可。我见过项目卡住，不是因为集成失败了，而是因为平台与业务的运作方式不匹配。

SAP 提供多种集成选项：有的较老，有的较新，有的彼此重叠的程度超出人们的想象。该用哪个工具，常常引发争论。当然，要视情况而定：看您要连接什么，看数据需要怎样流动，也看团队熟悉什么。

没有哪个工具能涵盖一切。每个都有取舍。但只要弄清每个工具最适合用在哪里，整体格局就会渐渐清晰。

下面快速梳理最常用的 SAP 集成平台，依据的是它们在真实项目中的实际用法，而不只是 SAP 的宣传方式。

SAP 集成平台

1. SAP PI / PO（Process Integration / Orchestration）

多年来，PI/PO 一直是本地 SAP 集成的标准。它处理消息转换、工作流以及各种协议转换。虽然可靠，但在变化更快的环境里显得有点笨重。不过在处理复杂的后端逻辑时，它仍然能把事办成。

非常适合 SAP 到 SAP 以及遗留系统的集成
支持 IDoc、BAPI、RFC、SOAP 等
常用于基于 ECC 的部署或混合部署

2. SAP CPI / Integration Suite

SAP CPI 适应性更强，为云优先和混合环境而设计。它更容易上手，尤其对刚接触 SAP 的团队。预置的 iFlow 有帮助，不过真正的定制仍然要花时间。对大多数新的 S/4HANA 项目来说，这通常是默认选择。

支持云集成和混合集成
包含可复用的内容包和适配器
属于 SAP Integration Suite 的许可模式

3. SAP API Management

它更侧重治理，而不是数据的实际搬运。API Management 帮您控制谁在什么条件下访问什么。把它想成大门，而不是送货车。向合作伙伴或内部使用方开放 API 时，它很有用。

用于流量控制、限流和认证
向外部应用开放 SAP API 时很有用
常与 CPI 或其他后端工具互补

4. SAP BTP Integration Services

这是一个更大的伞，下面包括 CPI、API Management、事件处理等。它给您一个集中管理工具的地方，但这些工具本身的行为仍然相对独立。价值在于把它们打包在一起，并松散地统一起来。

把多个 SAP 集成组件组合在一起
通过 SAP BTP cockpit 集中访问
适用于多工具并存的集成环境

5. SAP Data Intelligence

当数据需要通过结构化的管道在各平台之间流动时，就轮到 Data Intelligence 了。偏分析，而不是事务。它把 SAP 与数据湖、机器学习工具，或其他不属于日常流程的外部数据源连接起来。

专注于跨平台的数据编排
与分析和机器学习技术栈集成
最适合数据管道，不适合高频事务

6. 选择合适的工具

没有哪个平台是唯一“最好”的。合适的工具取决于要集成什么、集成的规模，以及需要多大的灵活性。有时候，就看您的团队已经熟悉什么。这一点也算数。

从使用场景出发，而不是从工具出发
评估许可、技能储备和支持模式
通常会并行使用不止一个工具

可与 SAP 配合使用的第三方集成平台

1. Dell Boomi

Dell Boomi 提供低代码的云端平台，非常适合需要快速部署和可复用集成的组织。它通过预置连接器连接 SAP，实时和批处理工作流都能有效处理。

低代码界面，实施更快
把 SAP 与云应用、CRM 和遗留系统连接起来
适合有混合需求的中型企业

2. MuleSoft

MuleSoft 常用于集成需求规模庞大、超出 SAP 范围的企业。它提供 API 主导的连接方式和丰富的开发者体验。SAP 连接器很强，但要配置好，前期可能需要更多功夫。

API 优先的模式，服务设计灵活
用于把 SAP 集成进更广泛的企业架构
更适合复杂或分布式的系统

3. Informatica

Informatica 在数据密集的环境里表现出色。以 ETL、主数据管理或分析为主的集成，经常选它。它支持与 SAP 直接集成，不过通常不像其他平台那样侧重实时。

非常适合大批量数据的搬运和清洗
常与 SAP 搭配，用于报表或 MDM 场景
适合 BI 环境成熟的组织

4. 什么时候使用第三方平台

有时 SAP 的原生工具并不合适，尤其是在多种系统混杂的环境里。第三方工具可能提供更好的连接器、更简单的界面，或者只是更贴合内部现有的做法。

团队已经接受过外部平台的培训时
SAP 只是一个大得多的架构中的一部分时
需要实时、低代码或高级数据集成时

5. 许可与成本因素

各平台的许可差异很大。SAP 工具往往把集成打包进现有的订阅里。第三方工具也许更灵活，但定价模式可能随数据量或用户数迅速上涨。

按事务量和连接器数量来评估成本
留意与已获许可的 SAP 现有能力是否重叠
要考虑总拥有成本（TCO），而不只是许可费

6. 集成的维护与支持

第三方平台可能需要不同的支持模式。有的有供应商的有力支撑，有的则非常依赖内部技能。长期维护应当纳入决策，而不只是看最初的部署速度。

核对供应商的 SLA 和更新周期
把内部知识储备或对外部顾问的需求考虑进去
为治理、版本管理和安全更新做好规划

4. 在 SAP Integration Suite 中选择合适的组件

没有完美的集成工具。在一个 SAP 项目里行得通的做法，换到另一个项目可能徒增负担。在 SAP Integration Suite 中选择合适的组件，取决于您面对的系统环境，以及您的集成将承受什么样的压力：技术上的、运营上的，有时甚至是政治上的。

先按几项标准缩小范围：

系统环境：涉及多少个系统？全是 SAP，还是云与非 SAP 工具混用？
延迟要求：数据需要即时流动，还是可以接受延迟？
可扩展性：会经常新增系统吗？灵活性是否比标准化更重要？
数据量：您每小时搬运几条记录，还是每分钟搬运数万条？

下面粗略看看各平台与不同需求的对应关系：

SAP 到 SAP - PI/PO 或 CPI
云到云 - CPI、MuleSoft、Boomi
API 管理 - SAP API Management、MuleSoft
大批量 ETL - Informatica、SAP Data Intelligence
复杂编排 - PI/PO、MuleSoft、BTP Integration Services

5. SAP Integration Suite 与 Oracle、Microsoft 和 Salesforce

在真实的 SAP 系统环境里，很少见到 SAP 孤立运行。许多环境里都有 Oracle、Microsoft 或 Salesforce 这类大型的、对业务至关重要的平台。每一个都带来自己的集成挑战：有的是技术上的，有的是结构上的，还有的落在许可的灰色地带。

1. SAP ↔ Oracle（ERP、HR、SCM）

在较大的企业里，SAP 与 Oracle 经常并存。一个管财务，另一个管供应链或 HR。让它们可靠地共享数据，一开始可能进展缓慢，尤其是当两者的数据模型差异超出预期时。

Oracle 的表通常需要通过 API 或暂存层对外开放
SAP 通常推送 IDoc 或使用 BAPI，这些都需要转换
时序是关键：批处理窗口可能造成同步延迟
如果 Oracle 应用自动触发 SAP 流程，间接访问的风险很常见

2. SAP ↔ Microsoft（Azure、Power Platform、M365）

Microsoft 与 SAP 的交汇点比大多数人想的要多。无论是 Power BI 从 SAP 拉取数据，还是 Teams 展示实时 KPI，连接都在增加。但集成需要谨慎设置。有些部分很顺畅，有些就不那么顺了。

Azure Logic Apps 可以调用 SAP API，但凭据需要小心管理
Power Platform 提供连接器，但复杂流程可能需要自定义函数
Microsoft 365（比如 Excel）常被用来离线编辑 SAP 数据，再同步回去。这种做法如果不加追踪，可能悄悄造成许可问题

SAP 与 Azure 的连通性在改善，但混合模式仍然需要强认证，尤其是涉及本地系统的时候。

3. SAP ↔ Salesforce（客户数据、订单、支持）

Salesforce 几乎总是面向客户的。SAP 处理后端。连接两者，通常是为了同步客户记录、订单状态和服务历史。

这些数据流常用 SAP CPI 或 MuleSoft
对象模型不同：Salesforce 更灵活，SAP 更刚性
Salesforce 的 API 速率限制可能让大批量同步停滞
如果 Salesforce 在没有已授权用户的情况下触发 SAP 事务，就有间接许可的风险

这些连接有时看上去很简单。但一旦数据量上来，或者流程在项目中途发生变化，复杂性就会显现。尽早为这些例外做规划，很少是白费力气。

CPI 集成

6. 什么是间接许可？

间接许可，指的是 SAP 之外的系统在幕后与它交互。没有人直接登录 SAP，业务流程却仍然依赖它。一个常见的例子是 Salesforce 自动在 SAP 中创建销售订单，没有任何 SAP 用户碰过屏幕。这也算数。

SAP 把这称为“间接访问”。这很重要，因为即使用户根本没见过 SAP，它仍然被视为需要许可的事件。

为了管理这一点，SAP 推出了数字访问（Digital Access）模式，把关注点从用户转向了单据。

一些典型的触发情形包括：

第三方门户把订单推送进 SAP
移动应用通过 API 查询库存水平
机器人不经登录就更新客户数据
CRM 从 SAP 实时拉取价格

界线在哪里，并不总是很清楚。但只要 SAP 是在替另一个系统处理某件事，就值得核查一下。

7. 许可与合规考量（直接 + 间接）

SAP 项目中的许可问题往往浮现得很晚，有时是在集成决策已经做完之后。但它很重要，比大多数人预想的更重要。尤其是当第三方系统开始在没有具名用户的情况下读取或写入 SAP 时。

核心问题往往归结为直接访问与间接访问。直接访问很简单：一个具名的 SAP 用户登录，触发一个流程，这个动作就是有许可的。而间接访问，是外部系统（Salesforce、自建门户，甚至机器人）在后台与 SAP 交互。按 SAP 的条款，这仍然可能算作使用。

为了应对这一点，SAP 推出了数字访问（Digital Access）模式。它不按用户收费，而是统计通过间接访问创建的特定单据类型的数量，包括销售订单、发票或物料移动这类单据。纸面上，这更清晰。实际操作中，仍然有灰色地带。

合规风险往往来自出于好意的自动化。例如：

一款不经用户登录就从 SAP 拉取价格的移动应用
一个自动在 SAP 中创建客户记录的 CRM
一款每小时检查库存水平的排程工具

这些都很有用。但如果没有妥善追踪和上报，它们可能引发许可风险敞口。

控制成本是有办法的。SAP 为转向基于单据的许可提供数字访问采用计划（Digital Access Adoption Program，DAAP）的优惠。也有一些公司部署使用情况监控工具（SAP Passport 或外部日志工具），来追踪风险所在。

审计则是另一回事。审计可能是技术性的、商务性的，也可能两者兼有。有些审计可以预料，有些则不然。无论哪种，主动应对的代价，通常比措手不及要小。

1. Salesforce 在 SAP 中创建销售订单

销售代表在 Salesforce 中录入交易，Salesforce 随后自动把订单数据发送到 SAP。没有 SAP 用户登录，但后端单据被创建了。

问题所在： 销售订单是通过间接访问生成的，属于 SAP 数字许可的范围。
缓解办法： 采用 SAP 的 Digital Access 模式，把这些算作单据；或者重新设计，改由具名 SAP 用户的工作流来触发。

2. 自建门户从 SAP 读取价格

一个面向公众或合作伙伴的网络门户，显示通过 API 从 SAP 拉取的实时价格。没有使用任何 SAP 认证。

问题所在： 价格数据的访问绕过了具名用户，使 SAP 后端在无法追溯的情况下暴露在外。
缓解办法： 让访问经由 SAP API Management，并施加恰当的用户认证或配额控制。

3. 移动应用查询库存可用量

仓库团队使用一款移动应用查询 SAP 的实时库存，而不直接登录 SAP。

问题所在： 数据是间接访问的，视数据量或频率而定，这可能引发许可责任。
缓解办法： 为移动用户购买许可，或确保访问符合基于单据的许可门槛。

4. 电商平台创建发票

线上购买会自动在 SAP 中过账发票。整个过程完全是系统对系统，没有 SAP 用户参与。

问题所在： 如果是间接创建，在 SAP 的 Digital Access 模式下，发票创建属于需要许可的事件。
缓解办法： 把发票单据纳入您的数字访问许可计数，并监控数量趋势。

5. HR 系统向 SAP 写入员工数据

第三方 HR 软件管理员工主数据，并通过批处理作业更新 SAP HCM。

问题所在： 在没有已授权 SAP 用户的情况下创建主数据，视数据的处理方式，可能不合规。
缓解办法： 向 SAP 澄清这些是否被视为需要许可的单据，并实施使用情况跟踪，或改为经由具名用户路由。

6. BI 工具定期从 SAP 拉取报表

Power BI 或 Tableau 这类报表平台，按计划通过 OData 或 JDBC 连接 SAP 表，悄无声息地拉取数据。

问题所在： 如果没有经过认证，或者用户没有获得许可，频繁的数据提取可能违反访问政策。
缓解办法： 让访问经由已授权的报表用户，或使用能正确追踪许可的、经 SAP 认证的分析连接器。

8. 我能怎样帮您？

我在 SAP 和数字化转型领域做了 25 年，见过项目从启动到上线的全过程，也见过没人谈起的混乱中段。有时我从一开始就领头。有时，我是在事情出了岔子时被请来稳住局面的。

无论哪种，我的角色都一样：把业务真正需要的东西，与系统实际能交付的东西连接起来。没有行话，没有空话。您在这里看到的不是理论，而是多年一线经验的积累，是在真实压力下解决真实问题的结果。

收集需求

9. 一些集成最佳实践

项目早期，集成通常意味着先让东西跑起来：把数据从一个系统搬到另一个系统，勾几个框，然后继续往前。但真正的挑战出现在后面：某个环节悄悄坏了，或者没人记得当初接口是怎么搭起来的。

最佳实践不是要死守某个僵硬的标准，而是要减少本可避免的风险。这可能意味着采用更强的认证，或者在规模扩大之前就把监控搭好。有时，它只是意味着比当时觉得必要的程度，多写一点文档。

有几件事有助于让集成长期保持健康：

使用 OAuth2、SAML 或 X.509 这类安全协议
搭建监控，哪怕数据流看起来很简单
构建可复用或可扩展的 iFlow 或 API
写明它如何运作，以及出故障时该怎么办

这些步骤很少紧急。但日后，它们能省下几个小时，有时是几天。

1. 保护每一个集成点

安全问题往往处理得很晚，通常是在上线前夕。但那时最难修。按场景选用 OAuth2、SAML 或证书。如果用了静态凭据，要妥善记录并轮换。别只是把它们丢在配置文件里，指望没人会忘。

使用端到端加密，而不只是对外加密
根据数据风险选择认证协议
尽早测试令牌的过期与续期

2. 从一开始就做监控

监控常常是出了事故之后才补上的。但它在任何东西坏掉之前就已就位时，效果最好。哪怕最简单的日志也有帮助。重点不在花哨的仪表盘，而在于知道什么失败了、什么时候失败、为什么失败。没有这些，哪怕一个小问题也可能要花几个小时去追查。

为失败和超时设置告警
记录响应时间和重试次数
有现成的 SAP 监控就用现成的

3. 为复用而设计，而不是为一时之需

用一个快速的、硬编码的修补来解决眼前的问题，很诱人。但每一次一次性的做法，日后都会增加摩擦。可复用的 iFlow、共享的转换逻辑和参数化的输入，在流程演变时能省下时间，而流程几乎总是会演变的。

尽可能使用模板
避免把业务规则放进映射步骤
把逻辑与传输层分开

4. 为运维着想来写文档

文档往往止步于设计阶段。但支持团队需要的不只是图。他们需要知道端点宕机时会发生什么，字段缺失时会发生什么。好的文档在工单被提出来之前，就已经回答了这些问题。

包含重试逻辑、故障处理和版本信息
说明对上下游系统的假设
随着数据流变化，保持文档更新

5. 明确责任人

有些集成运行了好几个月，才有人发觉没有人对它负责。它出故障时，每个人都以为别人在盯着。避免这种情况。指定责任人，哪怕是非正式的。这一步减少的停机时间，比大多数技术修复都多。

为每条数据流或每个接口明确责任
确保责任人能访问日志和工具
把责任人写进入职和交接文档

6. 为变化而构建，而不只是为上线

接口不是静止的。字段会变。API 会升版本。数据量会增长。如果数据流太僵硬，哪怕很小的变化也会让它崩掉。从一开始就为调整做好规划，即使眼下需求看起来很稳定。

对映射和配置使用版本控制
清楚记录已知的限制和约束
在发布周期内复查集成数据流

10. 总成本与投资回报考量

集成项目往往从技术目标开始：连接系统，同步数据，让一切跑起来。但在这之下，成本起的作用比多数人意识到的更大。不只是前期的许可费，更是日后才浮现的那类成本：工作负载扩大时、需求变化时，或者某个临时的变通办法变成永久方案时。

像 SAP CPI 这样的云工具，早期看起来可能更划算。没有硬件，部署更快。但在按使用量计价的模式下，成本会随数据量攀升。像 PI/PO 这样的本地方案，价格更稳定，却带着基础设施的开销。

再说第三方平台。每个都有自己的许可模式：有的按用户收费，有的按事务或连接器收费。费用会累积起来。

所以，从投资回报的角度看集成，要问的不只是“现在要花多少钱？”还要往前看：它将如何扩展？需要改动时，谁来买单？

1. 云与本地部署的成本

像 SAP CPI 这样的云平台部署更快，基础设施成本更低，但价格往往随使用量增长。像 PI/PO 这样的本地工具前期投入更大，但长期来看成本可能更稳定，尤其是在硬件已经到位的情况下。

云：基于订阅，通常按消息或连接计费
本地：资本支出（CAPEX）占大头，经常性许可成本较低
价格取决于系统数据量和 IT 规模

2. SAP CPI 许可的影响

SAP CPI 采用分档的、按使用量计费的模式。收费依据消息量和吞吐量。在低到中等规模的场景下，费用是可预测的，但流量很大或数据流未经优化，可能导致成本急剧上升。

起步档通常从每月约 1000 至 2000 欧元开始
大批量消息或非标准适配器需另外收费
每月跟踪使用量，主动管理成本

3. 第三方中间件的定价

MuleSoft、Dell Boomi 和 Informatica 的定价模式各不相同：按连接器、按用户或按事务。基础价格看起来可能不贵，但一旦扩大规模，往往会触到各种限额，并带来新的费用。

MuleSoft：许可 + API 调用量 + 核心包（约 1.8 万美元以上/年）
Boomi：按集成流程、连接器或用户档位计费
Informatica：成本由 ETL 数据量和平台服务决定

4. 长期的变更成本

初始部署成本只是故事的一部分。变更（新的端点、更新的映射或业务规则的调整）可能带来额外的许可或开发成本，在僵化的环境里尤其如此。

在复杂的系统环境中，预估每年的变更成本为 15% 至 30%
模块化程度更高的平台，往往能减少变更时的摩擦
定制可能需要扩展许可或咨询服务

5. 支持与维护成本

成本测算中，支持常常被忽略。SAP CPI 包含基础的支持档位，但响应时间和 SLA 各不相同。第三方工具也许能提供更快的支持，但要付出代价，或者需要另外的服务合同。

SAP 的支持与现有的企业协议挂钩
第三方工具的支持费，每年可能收许可费的 15% 至 20%
内部支持的需求会随系统复杂度而增加

6. 评估部署之外的投资回报

真正的投资回报包含长期的拥有成本，而不只是实施成本。便宜的平台可能缺乏灵活性，而贵一些的工具也许能在日后减少停机或变更的工作量。要按整个生命周期来评估，而不只是看上线。

把许可、维护、支持和变更的总成本都算进去
按 2 到 3 年的周期估算投资回报，而不只是项目阶段
把失败或延期的集成成本作为潜在风险计入

常见问题

很多客户在最初考虑 SAP 实施时，会围绕同样的几个问题打转。

也许您自己也有其中几个：到底要多久，可能要花多少钱，或者系统上线之后需要什么样的支持。这些问题问得合理。

所以我不让您干猜，而是整理出清晰、坦率的回答，帮您更好地了解会发生什么，以及麻烦的部分通常出现在哪里。

联系我吧！

1. 什么是 SAP CPI？

SAP CPI，即 Cloud Platform Integration，是 SAP Integration Suite 的一部分。它帮助连接 SAP 与非 SAP 系统，主要用于云环境或混合环境。可以把它看作中间件，只不过是为分布式环境打造的。

它包括：

预置的集成流（称为 iFlow）
对 HTTPS、SFTP 和 OData 等协议的支持
可选的自定义映射、脚本和路由

当从本地迁移到云，或者第三方应用需要安全地与 SAP 通信时，CPI 尤其有用。

2. SAP 如何与 Salesforce 集成？

SAP 与 Salesforce 通常通过 API，或 SAP CPI、MuleSoft、Dell Boomi 这类中间件来交换数据。

常见的使用场景包括：

同步客户主数据
传输订单和发票明细
共享支持案例历史或价格信息

挑战往往来自数据模型的差异，以及 Salesforce 一侧的 API 限额。细致的映射和限流是关键。

许可也可能是个问题。如果 Salesforce 触发 SAP 中的操作，可能适用间接访问。

3. 什么是 SAP 间接访问？

间接访问，指的是外部系统在没有用户直接登录的情况下与 SAP 交互。例如，某个门户或第三方应用通过 API 在 SAP 中创建销售订单。

SAP 认为这在其 Digital Access 模式下需要许可，使用量按单据类型（订单、发票等）来统计。

这可能让团队措手不及。系统在后台安静地运行，却生成了会引发许可风险敞口的单据。

要管理这个问题：

评估外部系统如何使用 SAP
监控单据创建的数量
考虑 SAP 基于数字单据的许可结构

4. 哪个 SAP 集成工具最好？

这取决于您要集成什么、它多久变化一次，以及谁来维护。

云到云或混合：SAP Integration Suite（CPI）
本地的 SAP 到 SAP：SAP PI/PO
API 治理：SAP API Management
数据管道和分析：SAP Data Intelligence
更广泛的企业集成：MuleSoft 或 Dell Boomi

大多数系统环境是混用的。什么是“最好”，更多取决于契合度，而不是功能。

5. SAP 能与 Microsoft 和 Oracle 集成吗？

能，而且经常发生。

SAP ↔ Microsoft

Azure Logic Apps、Power Automate，或 Power BI 中的 SAP 连接器
常见用途：把 SAP 数据拉进 Excel、Teams 或仪表盘

SAP ↔ Oracle

通常需要中间件（CPI、PI 或第三方）
使用场景包括财务、采购或 HR 集成

挑战包括认证模型不同、时序不匹配，以及某些情况下的许可问题。

6. 什么是 SAP Integration Suite？

SAP Integration Suite 是 SAP 用于连接系统、应用和数据的云原生平台。它包括 CPI、API Management、Open Connectors 以及事件网格（event mesh）能力。

可以把它看作一个工具箱。有些部分是预置的，有些是可配置的。它为云优先和混合环境而设计。

核心好处：

常见集成的预置内容
实时和批处理
安全、监控和治理工具

它被定位为 SAP 面向现代系统环境的战略性集成层。

7. SAP CPI 会取代 PI/PO 吗？

在以云为主或混合的系统环境里，会：SAP CPI 是首选方向。但 PI/PO 仍然受到支持，并被广泛使用，尤其是在基于 ECC 的系统或本地部署中。

SAP 建议随着时间推移转向 Integration Suite，但并不强制切换。这取决于项目时机、系统路线图和成本。

有些公司两者并用，逐步引入 CPI。

8. SAP 如何处理 API 安全？

SAP 支持标准的安全协议：

OAuth2，用于基于令牌的认证
SAML，用于联合身份
X.509 证书，用于系统间信任

Integration Suite 还提供 API 限流、配额执行和策略管理。大多数团队会把 SAP 的安全工具与 Azure AD 或 Okta 这类企业身份提供商结合起来使用。

安全需求因场景而异，所以要尽早规划。

9. 什么决定了 SAP 集成的成本？

有几个因素会影响成本：

工具类型（云与本地）
事务或消息的数量
接口和系统的数量
许可模式（例如，CPI 按使用量计费）

例如，SAP CPI 的许可起初可能看起来不高，但会随数据量迅速攀升。第三方中间件可能按连接器或用户收费。

估算时，务必把支持和变更成本也算进去，而不只是许可费。

10. 如何监控 SAP 集成？

SAP Integration Suite 内置监控仪表盘、日志和跟踪工具。您可以：

实时查看消息日志和错误
跟踪性能和延迟
为失败或缓慢的数据流设置告警

对于 PI/PO 这类本地系统，监控在 Integration Engine 中处理，或通过 SAP Solution Manager 进行。

关键是尽早搭好监控。等到出了故障才动手，代价通常比提前规划更大。

请告诉我您正在做的事。

一次30分钟的通话。您说明项目、需要做的决策或遇到的问题。我会告诉您我能否帮上忙；如果不能，我会告诉您谁可能帮得上。

洽谈您的项目

SAP Integration Suite：工具、许可与真实场景

请告诉我 您正在做的事。

请告诉我您正在做的事。