我第一次涉足云集成领域已经有三年半的时间了。此后发生了很大的变化——官方产品名称从HCI改为CPI（还有一些其他的名称没有坚持多久）；Eclipse被放弃了，大数据和小数据，取而代之的是WebUI（我仍然不同意，但已经选择继续）；困扰该产品初始版本的许多奇怪的bug和错误或多或少都得到了处理；而且该产品的实力也在不断增强，随着每月滚动的软件更新而不断成熟。当然，云100，有些地方没有改变，比如严重缺失的自助免费试用接入，但这将是另一天的故事/战斗。【2019年6月21日更新：SAP Cloud Platform Cloud Foundry（CF）环境中终于提供自助服务CPI试用版—耶！]

虽然有集成背景的人（如PI）比较容易掌握CPI并具有生产力，但确保集成流设计健壮并经得起时间的考验是另一回事。虽然Apache Camel（作为底层框架）支持灵活的建模环境，但它也将责任转移到开发人员/架构师身上，以确保接口设计良好。

在首先为SuccessFactors员工中心集成实现定制CPI开发之后，在A2A与内部部署的S/4HANA系统集成之后，我发现各种设计和开发实践对我来说尤其有效。在这篇文章的其余部分，我将与您分享。

某些适配器的配置参数与接口无关，因此可以/应该在多个接口之间重用。与PI不同，CPI中没有沟通渠道的概念。每个接口的设计都在自己的IFlow中，可重用的选项有限。去年ProcessDirect适配器的引入使我们能够克服这种限制。

例如，IDoc接收器可以使用发送方通道中的ProcessDirect将其建模为一个单独的IFlow，如下所示。

这允许多个IFlow通过ProcessDirect发送到同一个端点来调用公共IFlow接收器通道如下所示。

这种方法的好处是需要在IDoc接收器通道中填充的公共值（例如URL、凭证名称）只保留在一个地方。这简化了我们需要同时部署多个接口时的问题，以及公共接收器发生变化时的未来维护，多条消息（每个链接的IFlow对应一条消息）将出现在消息监视器中，并且这些消息可以与消息关联ID（如下所示）链接在一起。

这种方法不仅适用于对公共通道进行分组，还可以重用公共映射或公共扩展库（例如，如果您在多个应用程序中使用FormatConversionBean）对于大多数集成场景，映射是设计和开发中最关键的部分之一。映射对象在其整个生命周期中会发生多次更改—从初始开发、初始生产版本到维护期间的许多增强。有时，它可能最终看起来与最初开发时完全不同。

因此，决定使用哪种映射方法很重要–这会影响在映射对象的生命周期中开发、维护和增强映射对象的容易程度/有效性。就我个人而言，在使用成熟的编程语言时，我最自在。在CPI的上下文中，这意味着将映射开发为Groovy脚本，正如我在I*heart*Groovy mapping中详细描述的那样。

使用Groovy可以非常有效地开发、维护和增强映射。

Stream Groovy脚本中的XMLSlurper输入已经存在了两年，但是我在网上看到太多脚本（论坛）以及在CPI租户中使用以下低效的方式访问有效负载（消息体）。

虽然这是可以接受的，并且可能不会对较小的有效负载造成任何问题，但当有效负载变大时，它不能很好地扩展。

相反，物联网网关，始终使用读取器访问消息体（即使在不使用XmlSlurper进行进一步的XML解析的情况下）。

此外，您甚至可以使用强类型在随后的代码行中使用IDE的代码完成。另外，Groovy通过许多帮助方法扩展了Reader，使您能够高效地处理IO。

考虑使用外部化参数来优化IFlows的可配置性设计。这允许在不编辑IFlow的情况下更改IFlow的某些方面。对于SAP的预打包内容，它遵循相同的方法，其中大多数内容都是"仅配置"。

外部化参数的常见用例它们是：-

端点、URL、服务器、目录和凭据轮询适配器的调度程序IDoc合作伙伴简介详细信息用于控制有效负载日志记录的参数参数值在不同环境（开发、质量保证、产品）中不同

CPI中的监控能力有限。通常，当系统中有许多消息时，要唯一地标识需要进一步分析的消息并不容易。CPI没有PI中提供的用户定义消息搜索（UDMS）等功能。IDs的搜索功能仅限于按消息ID、相关ID或应用程序ID进行搜索。

幸运的是，我们可以利用应用程序消息ID进行搜索。这是通过用适当的值填充消息头SAP\u ApplicationID来实现的。根据具体情况，阿里大数据分析，以下是两个填充该标头的选项。

请注意，通过（1）填充的值可能会被（2）覆盖。