亲爱的社区，
上一次我们谈到了在SAP CPI的iFlow开发中应用一些不错的DevOps实践。我们讨论了使用Azure板集成的敏捷开发，将代码更改与用户案例或问题联系起来，将groovy脚本发布到sapcpi，最后在租户中自动部署更新的iFlow。你可以在这里找到相应的博客文章。
但是，我在第一个博客上的持续整合过程是不完整的。今天，我想通过使用JUnit和Spock框架以及代码覆盖率的自动化单元测试来完成这个示例。一旦完成了，我就可以把我珍贵的小iFlows放在野外自生自灭了。
测试SAP CPI groovy脚本的演变
这个很棒的CPI社区空间中的大多数例子都是指在本地开发机器上手动测试groovy脚本。下面是事情的演变和我对它的看法
Vadim Klimov关于如何从您的CPI租户那里获得SAP特定Java库的帖子。有了它，您最终可以从IDE进行实际调试。https://blogs.sap.com/2017/10/02/dark-side-of-groovy-scripting-behind-the-scenes-of-cloud-integration-runtime/Vadims Post和Eng Swee Yeoh一起永远改变了我iFlow的发展：https://blogs.sap.com/2017/10/06/how-do-you-test-your-groovy-scripts/Eng-Swee通过一个很好的测试框架将其进一步发展，并通过Spock引入了测试驱动的设计原则：https://blogs.sap.com/2018/01/24/cpis-groovy-meets-spock-to-boldly-test-where-none-has-tested-before/vadimklimov开发了一个groovy包装器脚本，它允许您通过http和Postman发送groovy脚本，以获得groovy脚本的即时反馈。这会降低测试速度，一元云购下载，因为您不需要等待iFlow的部署。对于独立案例，这是一种非常酷的方法：https://blogs.sap.com/2019/06/17/rapid-groovy-scripting-in-cpi-dynamic-loading-and-execution-of-script-code-at-runtime/使用本地Figaf工具和Daniel Graversen的帖子的商业选项：https://blogs.sap.com/2019/08/25/run-unit-test-for-sap-cpi-easer/不惜一切代价避免地方发展？:@Dominic Beckbauer提供的出色的镀铬扩展，增强了追踪效果：https://blogs.sap.com/2020/03/05/cpi-chrome-plugin-to-enhance-sap-cloud-platform-integration-usability/Fatih Pense在CPI web ui上的模拟模式发布了一篇很好的帖子：https://blogs.sap.com/2020/04/13/使用模拟功能测试cpi中的部分流/。他还为groovy脚本的实时测试创建了一个网站：https://blogs.sap.com/2020/04/13/share-and-store-cpi-groovy-scripts-with-links/Chrome扩展在SAP CPI web ui上执行更复杂的groovy语法检查：https://blogs.sap.com/2020/05/22/supereasy-groovy-syntax-checker-for-cpi/
所有这些选项都提高了SAP CPI开发实践的质量。但是，它们不允许您完全使用DevOps进行持续集成和持续部署（CI/CD）。我知道您很想最终看到一些代码和图片，所以让我们深入研究一下。？
使之发生的移动部分
正如我在开始单元测试时所说的那样，是我的示例中缺少的一部分，用于更完整的持续集成DevOps实践。
图1集成项目概述
集成过程从图1右下角的IDE开始。在我的例子中是Eclipse，因为我希望能够在本地调试CPI groovy脚本。并不是所有的ide都完全支持groovy。在IntelliJ社区上还有其他示例。
图2基于GitHub提交的项目状态转换
图3来自GitHub请求的屏幕截图
图4 Gradle项目结构
图5来自Azure build pipe和代码覆盖设置的屏幕截图
图6来自script1.groovy的JaCoCo输出的屏幕截图
图7eclipse上单元测试运行的截图
图9 Azure DevOps上发布管道的截图
6-7 I与SAP CPI的API集成，使用python脚本更新目标iFlows的groovy脚本。更新后，相应的iFlow将自动部署。这样你就能得到真正的CD？
好的，我们已经确定了如何与单元测试进行适当的持续集成，以及如何将其融入DevOps实践的整体图景。看起来不错，不是吗？我同意，但有一种编码实践，与本地测试相比，这种方法确实开始大放异彩。
跨iFlows共享脚本
软件工程的一个公认的设计原则是"关注点分离"和"可重用性"。通常，对于CPI中较大的集成项目，万云，您可能需要相同的方法在不同的位置多次创建或修改消息。例如，需要创建OData时间戳。
我想向您展示两个选项，如何在租户的任何iFlow中重复使用上述函数。因此，未来的增强或错误修复只需要在一个地方进行。
首先，您需要一种方法来托管共享脚本。
一种很好的方法是使用单独的iFlow。这样，您就只有一个脚本实例，部署就很简单了。要在运行时从Utils iFlow加载groovy脚本，我们需要依赖@Vadim Klimov的发现。他调查了CPI，发现SAP正在使用OSGi作为服务运行时。
Vadim还帮我处理了请求的片段：
共享方法看起来像这样：
不幸的是，这种方法很容易破坏SAP的更改。它依赖于SAP部署CPI运行时的当前方式。例如，如果SAP放弃OSGi，它将停止工作。
我正在利用SAP的iFlow功能将自定义库作为JAR文件添加到groovy脚本中。
这意味着每个iFlow，要调用"shared"方法，需要一个JAR文件的副本。
图9 SAP CPI web ui iFlow resources的屏幕截图
