你好伊丽莎白，

查看您提到的可能从PI（双栈）迁移到PO（仅Java）的主题的技术概述，我看不到其中仅存在于双栈中并且没有实现/移植的任何技术 仅限Java-即：

• 映射。 特别是图形映射。 无论如何，它们都可以编译成Java程序，并且通常可以将它们从双栈发行版很好地迁移到仅Java安装选项。 撰写本文后，我将注意到仍然建议在迁移后运行回归测试，因为标准映射函数的行为发生了一些变化（好消息是，其中大多数发生在从7.0版迁移时-因此， 从7.1版开始迁移，您将不会有太多差异（如果有的话）。
• 适配器。 RFC，文件和JDBC适配器最初是双堆栈中基于Java的适配器，因此可以很好地迁移到Java。 经典（基于ABAP的）IDoc和XI适配器具有其Java类似物-IDoc_AAE（对于IDocs）和具有XI消息协议的SOAP适配器（对于代理）。 对于Web服务，这取决于您使用哪种Web服务类型：如果是SOAP，那么SOAP适配器最初是基于Java的，因此可以很好地进行迁移，如果是WS-RM或HTTP（两者都是基于早期双协议栈版本的ABAP， （如7.1所述），则PO具有可用于替代的基于Java的WS_AAE和HTTP_AAE适配器。 此外，您可以检查Integration Directory迁移工具（可以在PO 7.5系统中找到并内置），该工具可以自动完成配置方案从双堆栈到仅Java方案的迁移活动，包括将通信通道从基于ABAP的适配器类型转换为 它们的Java类似物（如果适用）。
• 开发工具。 使用经典的ESR和Integration Directory工具可以完成PO系统中的大多数接口开发活动。 但是，有很少的例外-例如，仅Java中的iFlows只能通过NWDS创建，而不能在Integration Directory中创建-但此类功能很少。 在使用SAP PO系统时，NWDS被推荐为首选工具，但是ESR和Integration Directory并没有被弃用，可以并排使用-​​因此，使您从ESR/Integration Directory过渡到NWDS的体验更加增量和顺畅。 例如，您可以开发ESR对象（例如数据和消息类型，接口，映射-并且，是的，可以像在早期版本中一样使用PO 7.5中的导入对象进行操作 使用传统的ESR工具，通信渠道-使用传统的Integration Directory工具，并开始使用NWDS进行iFlow和警报规则开发。 然后，您可以逐渐将剩余的基于Integration Directory的开发活动移至NWDS，并通过将基于ESR的开发活动移至NWDS进行补充。

我不确定我是否理解您关于将RFC正确地用于ABAP代码（例如Z_Duplicate_file_Checks）的声明。 您的意思是说，您在PI中使用了ABAP映射程序，在那里您可以对外部ABAP系统进行RFC调用？ 如果是这样，那么PI中的ABAP映射程序将必须使用替代的映射技术（图形，自定义Java映射程序或XSLT-在处理从该映射发出的RFC调用时不太常见）来重新开发和重新实现。 ，仅当迁移到Java时，并且没有可以自动执行此过程的转换工具-这是一项手动操作。 虽然，我建议您检查是否可以查看此类映射的实现并使用图形映射功能重新开发它们，因为RFC查找功能是PO 7.5中提供的标准映射功能库的一部分（准确地说，它是 已经在PI 7.1中引入）。

关于使用PO 7.5进行云集成-这是一个广泛讨论的主题。 PO 7.5设备完善，可用于本地/云集成方案。 SAP集成产品组合中的另一个选项（也适用于中介的云集成）是SAP Cloud Platform Integration（CPI）产品，可以用作已经运行的SAP PO环境的补充平台。 在产品定位方面，PO被定位为适用于本地到本地，本地到云/云到本地集成方案的适当工具，而CPI则定位为更适合云到云以及 合理替代某些本地云到云到本地集成方案（注意重叠的混合-本地到云/云到本地到–放置PO和CPI的方案）。 决定使用哪种工具将本地系统与云系统和服务集成并不是那么简单，并且对于这个问题没有一个正确的答案，因为这很大程度上取决于您的公司是否在其他方面投资了SAP Cloud Platform 服务（然后CPI可以成为该订阅的逻辑扩展）（或者不是）（然后CPI单独不能带来那么多的价值，并且在这种混合方案中使用PO可能会成为明智的选择）。 如果您的策略是将来使用更多的云服务和应用程序（因此，可能会增加云与云集成方案的份额，并最终使它们占绝大多数），那么从长远来看，值得研究混合集成平台。

此致

Vadim

绝对棒的Vadim！

我们正准备进行一些有关Java的大规模谷歌搜索和一些培训课程。 我们仍然会这样做，但不是那么紧急。 非常感谢您的帮助

伊丽莎白