PI双重用途或流程编排

2020-09-25 01:17发布

点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)大家好 我希望有人能最好地建议...

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


大家好

我希望有人能最好地建议去哪里看

我们目前处于双堆栈7.1方案中,希望进行升级。 我们正在寻找的选项是PI 7.5双重用途和Process Orchestration 7.5。 我们打折了PI单个堆栈,因为似乎有一些关于有限PI设施的参考。

关于PO是否也会限制我们的PI功能,我们有不同的观点,尽管我知道它与我们当前不使用的新内容(BRM和BPM)捆绑在一起。

我正在研究PO上的许多文档以及关于双重用途的任何文档。 我的困难是找到有用但客观的东西,采购订单上的大多数信息几乎都是推销。

由于时间限制,我们试图像在PI config上一样确定与我们当前拥有的选项最相似的选项。 这似乎是双重用途。

使用PO仅是Java,我们对能否继续使用ESR导入的对象(如

)存在疑问

Idoc结构FIDCC1.FIDCCP02

RFC到ABAP代码,例如在我们的映射中使用的Z_Duplicate_file_Checks

加上ABAP代理

和我们首选的图形映射(没有使用Java或样式表的经验)

Netweaver开发人员工作室可能还需要学习。

我们不需要做的就是为仅Java设置重写当前接口。

我们主要是文件适配器,一些JDBC和一项Web服务。 标准Idoc入站,很多代理进出。

对我们来说,未来的方向包括使用云。 为此,我们已经安装了单个堆栈PI 7.5,纯粹用于通过DMZ在我们和云之间进行路由。 尚未通过查看向我发布,因此尚不知道其内容。 我们也处于SAP移动项目的中间,该项目正在进行中。 我怀疑PO会为将来的移动工作提供帮助,尽管双重用途也可能会。

我认为主要是我们担心,我们最终不会获得一种解决方案,该解决方案将剥夺我们目前拥有的功能,意味着重写现有接口,学习新概念,技术和术语,并且匆匆忙忙 每个人都感到困惑,并拖延了一些未来计划中的项目。

任何指针将不胜感激

谢谢伊丽莎白

2条回答
My梦
2020-09-25 02:03 .采纳回答

你好伊丽莎白,

查看您提到的可能从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

一周热门 更多>