SAP R/3 与其他异构系统集成时是否需要应用 SAP XI

本文主要是介绍SAP R/3 与其他异构系统集成时是否需要应用 SAP XI，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

当需要做 SAP R/3 与其他异构系统集成时，面临两个方向的选择，一是采用简单而实用的文本方式（以下简称方案一），系统之间通过约定的公共目录进行数据交换，一般每个接口使用一个特定的文件；另外是采用 SAP XI （Exchange Infrastructure）作为中间件（以下简称方案二），SAP XI 全力支持 SAP 产品之间或 SAP 产品与其他第三方系统之间的集成。
这两种方式各有优劣，本文从若干角度进行分析。
从统一性角度考虑，方案一的每个接口都采用自己的连接方案，模式各不相同，方案二通过 XI 与 R/3 单点连接，在 XI 上可以统一管理各个系统的外部连接方式。
从操作/维护性角度考虑，方案一的每个接口都有自己的程序进行触发，正式投入使用后，日常维护人员需要对每个接口的状态进行监控，如果有异常还需要进行较复杂的人工干预来达到数据的一性；在方案二中， XI 通过集中处理，集中维护以及集中监控的手段，对于所有的接口进行监控和控制，通过技术手段和重发保证来完成所有的信息正确的传递到目的系统中，杜绝交易信息在传递过程中的丢失和重复。
从状态更新角度考虑，方案一通过文本进行数据传递，无法保证数据在传递过程中的丢失，只能通过最终的导入日志查询最终数据进入的状态；在方案二中，XI 如果采用 IDoc 方式与 R/3 集成的话，SAP 的 IDoc 状态更新可以保证数据在出站和入站的时候的各个状态更新，并且通过XI更可以了解到数据在各个状态的情况
从完整性角度考虑，方案一对于文本数据较难判断是否有重复的导入的现象，在程序中需要加入一定的判断以确定数据不会被重复传入；方案二中，SAP的 IDoc Audit 机制可以保证数据被接收系统准确的导入，并通过状态更新来确认数据是否准确的被导入到目的系统。
从出错处理角度考虑，方案一中，一般多个凭证通过文件打包的形式进行数据通讯，需要进行编程对其中一两条出错的文件进行单独处理；方案二中，每一个凭证数据都是一个 IDoc，很容易对不正确的 IDoc 进行再处理
从出错提醒角度考虑，方案一中，无法自动完成出错提醒，只能通过人员手工的去检查报表来发觉接口是否有出错的情况；方案二中，可以通过 XI 的 BPM 和 R3 的工作流来做自动提醒出错处理，支持 Email / FAX / SMS 等多种方式。但在测试中发现，XI 偶尔存在丢失消息的现象，比如 XI 将数据库表的数据读走，并改变表的标识字段表示已读走，但数据进入 XI 后丢失，在 XI 的 Adapter Monitor, Message Monitor 均无任何出错信息。这是一个很严重的问题。
从系统出错的可能性角度考虑，随着系统的增加，出错可能性成指数的增加。方案一中，如果对实时性要求不高，双方系统的当机，并不影响双方数据的一致性；方案二中，需要考虑 SAP XI 或者各系统如果当机，该如何处理，需要考虑如果确认 XI 有丢失消息的现象，该如何应对这种情况。
此外，对某些系统而言，安全性是一个重要的指标。XI 提供对消息加密传输的处理，这里不多叙。
从实施时间考虑，采用文本文件是最为简单的，可以迅速的构架并投入使用；方案二从单个接口的角度看实施时间比使用文本方式长，但是如果以后接口数量增加，实施速度可以迅速提高
从功能扩展性角度考虑，方案一中，如果有任何外围系统的变化或SAP系统的升级，即导出/导入的文件文件格式有变化，相关接口程序均要调整；方案二中，XI通过图形界面的数据匹配工具，屏蔽了由于某一方数据修改后，对其他方面产生的影响。
从实施费用考虑，使用文本文件对于整体项目在接口的开发费用是最低的，而方案二较之需要额外的软件实施费用加上软件许可费用。但考虑到接口开发的费用以及维护、扩展的费用，也有可能得到相反的结论。
总之，在项目的实施中，需要综合考虑实施的风险和 TCO 这两个因素，来确认是否需要使用 SAP XI 。

这篇关于SAP R/3 与其他异构系统集成时是否需要应用 SAP XI的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---