偶然有一个PO项目的标，通常PO都是做为实施项目中的一部分，很少单独为PO立项，这个项目很少见，而且规模还不小…那就正好借此机会对SAP的系统集成做一个系统的学习和梳理。
过去太旧的内容就不需要花费精力，一句代过就可以，现在都是PO7.5，唯一需要考虑和云有没有关系，下面是几个比较好的帖子的笔记，备忘。重点是ISA-M，这是个宝贝。

参考：
https://sapintegrationhub.com/cpi/sap-po-to-cpi-migration-guide/
https://sapintegrationhub.com/pi-po/difference-between-sap-pi-vs-po/
https://blogs.sap.com/2020/05/14/new-version-of-the-sap-integration-solution-advisory-methodology-template-released/

PO背景

PO的发展过程：

如果再加上CPI就是：

SAP PO生命周期：

选择PO还是CPI

选择PO 还是CPI，这完全取决于不同情况、未来路线图、投资和法规等条件。

Pros and Cons

考虑是否要升CPI的话，参考下面Pros and Cons

从PO升到CPI的好处

1. 首先要考虑的就是PO的生命周期问题，上周可以看出来SAP PO的End of Maintenance计划，虽然后来又延长到了2030年(标准支持到2027年，可以延长到2030)，不急了，但总是要考虑的一个重要因素。至于PO7.5以前的版本就更不用说了，2020年就已经停止维护了。
2. CPI 支持每一个增长的基于云的系统集成，意思就是，越来越多的系统都开始上去，为啥你要坚持用一个本地部署的中间件。
3. 从Lisence的角度，它们的收费方式是不同的，SAP PO 是Core-based，CPI是Message Volume-based lisence model，它更灵活，更适用于小型客户。具体的价格我也不清楚，可以咨询公司的采购部门。
4. 从系统运维的角度，CPI硬件不需要自己维护，省了维护的相关费用。

从PO升到CPI的缺点

1. 如果要从PO迁移到CPI，SAP CPI没有多个标准的SAP PO选项，所以迁移并不简单，如果原来PO的landscape就很大的话，迁移需要重新设计很多东西。这里是一个lesson learn
2. CPI对OP的集成还是有一些局限性。SAP有可能有新的集成方案出来,并且SAP明确提到SAP CPI应该只用于云到云的连接，而内部部署应该保留SAP PO。
3. 数据的区域政策限制。有些行业甚至不允许数据在互联网上。
4. CPI的专家很少，但SAP PO的人很多。

Lesson Learn

这些是之前PO到CPI迁移项目的经验中学到的经验教训：

• 缺少自动迁移选项
• 没有数据类型的中央存储库
• PO和CPI之间映射兼容性的局限性
• 在迁移 enhanced receiver determination场景时需要人工参与
• CPI中对有效负载日志记录的局限性
• CPI中缺乏基于有效负载的消息监控功能
• 启动和停止通信信道的限制
• IDOC acknowledgments处理有问题
• 缺少适配器CIDX, RNIF, BC, File

ISA-M Cycle

SAP Integration Solution Advisory Methodology (ISA-M) SAP的集成方案咨询方法论，准确说是一套PPT，现在最新版本是3.3，要的话需要给isam@sap.com发邮件，网上只找到了3.2版本。

首先引用了一个周期环，把几个步骤做成了环的形状（现在好像一切有和敏捷相关了），意思就是逐步优化吧。它包含了4个过程：

• 评估现有集成策略
• 设计混合集成平台
• 定义集成最佳实践
• 启用实践
  

评估现有集成策略

ISA-M提供了一种逐步的方法，它允许客户和合作伙伴评估组织的当前集成策略:从集成域级别上的高级范围开始，然后是集成风格和相关用例模式的范围。就是上面周期环中最内圈的三个要素：集成域，集成风格，用例模式。

集成域 Integration Domain：

差不我多们能想到的集成相关方都可以在上图体现了。

集成用例模式Integration Use Case Patterns和集成风格Integration Styles

集成用例模式与技术无关，它可以映射到特定的集成技术。为此目的，ISA-M模板提供了一个用例模式定义库，这些用例模式定义按照集成样式分组。集成样式涵盖了关键的集成原型，如流程集成、数据集成、用户集成和事物集成。不能映射到单一集成样式的用例模式被分类为交叉用例。交叉用例的一个例子是基于事件的集成，它可以应用于流程和事物的集成场景:对于第一个例子，业务事件通过应用事件驱动的体系结构和用于分发事件的发布和订阅模型来实现业务应用的松散耦合集成。在事物集成用例中，通常会发出和处理来自物理设备的大量通知事件。客户和合作伙伴可以根据需要添加定制的模式，从而扩展预先交付的集成用例模式目录。

设计混合集成平台

为了塑造一个组织的混合集成平台，前一阶段的相关集成域和用例模式集被映射到集成技术和服务类别(下图)。这种映射受到客户上下文的高度影响，如现有投资、商业方面等。在大多数情况下，单个集成平台可能不足以支持普遍的集成需求。因此，企业架构师可能需要结合多种技术，如集成平台即服务、物联网平台来设计组织。
将集成样式和用例模式映射到集成技术类别

定义集成最佳实践

启用实践