选择，选择，淘客大玩家，选择…
在进行CPI开发时，有几个用于开发映射的选项，即将一种消息格式转换为另一种消息格式。云集成映射：Morten Wittrock解释并比较了您的选项，权衡了不同的选项及其比较。
一方面，大数据的数据库，具有PI/PO背景的开发人员可能会因为熟悉消息映射而倾向于使用它。
另一方面，来自非SAP背景的开发人员通常更熟悉XSLT，因为它是一个开放的标准。
在我对Morten的博客发表评论将近一年之后，我确信Groovy确实是一种方法，除了CPI中最简单的映射（主要是1-1）。我邀请每一个值得一试的CPI开发人员来看看我下面的观点，并考虑将这项技能添加到他们的武器库中。
Groovy的案例
在我证明Groovy的案例之前，让我针对它的"反对者"来证明这一点。
i）消息映射（也称为图形映射）
在很大程度上依赖于队列和上下文概念，我只见过少数PI开发人员真正理解它不能很好地扩展复杂度（除了上面的概念之外，如果需要非标准功能，那么无论如何都需要Groovy）复杂的逻辑很难实现，特别是使用标准功能。回到PI时代，像下面这样的spiderweb映射并不少见。很难破译，很难排除故障，不破东西就不可能增强！
不能离线开发无法脱机测试/模拟WebUI测试模拟无法测试访问头/属性的映射逻辑不能很好地随场景的增加而扩展（如何确保新场景的逻辑不会破坏以前的场景？）我甚至敢说，这是PI时代的包袱（一种至少有15年历史的方法），最好不要用在任何新的CPI开发中
ii）XSLT
可以说是最陡峭的学习曲线通常仅限于在系统到系统集成的上下文中进行XML/Text到XML/Text的转换（尽管它也可以处理诸如HTML之类的其他格式）不容易调试要做任何实质性的事情，都需要一个好的XML编辑器，这通常是有代价的
好吧，现在让我们来看看Groovy
在CPI的许多领域（不仅仅是映射）都很普遍，因此无论使用什么映射方法，CPI开发人员都不可避免地需要Groovy能够进行任意转换整个开发生命周期所需的工具是免费的或开源的可以很好地扩展复杂度（由于直接使用源代码的灵活性）通过使用XmlSlurper进行解析和使用MarkupBuilder进行生成，XML转换很容易开发（与Java相比）（更多细节如下）XmlSlurper基于SAX，内存占用小可以离线开发和测试可以通过从调用脚本中注入这些值来测试访问头/属性的映射逻辑可以脱机调试（借助IntelliJ IDEA或Eclipse等IDE）由于有效负载解析和生成与平台无关，因此可转移的技能集（即到其他集成解决方案，如Mulesoft或Dell Boomi）最后但并非最不重要的是，快云服务器，当为每个测试用例实现单元测试时，它会随着场景的增加而扩展。作为一个玩笑，让我给你展示一下在3秒内运行8个测试的结果！
因此，如果您至少有一部分确信或有兴趣了解更多信息，那么让我们看看如何实际实现这一点。
使用XmlSlurper解析XML
如使用Groovy脚本轻松解析XML中所述，使用XmlSlurper在Groovy中轻松解析XML。字段的内容可以通过点表示法访问。下面是使用DOM和更简单的Groovy方法在Java中实现XML解析的比较。
使用MarkupBuilder生成XML
同样，与在Java中使用DOM相比，Groovy中的MarkupBuilder显著减少了生成XML的代码行。下面的示例显示了生成两级XML输出的比较。
示例场景
考虑一个具有以下要求的示例集成场景要求：-
将有效负载从源模式转换为目标模式转换日期格式（dd-MM-yyyy到yyyyMMdd）基于消息属性填充目标字段DocumentType（可通过外部化参数配置）–本例中为Z001下面IsBatchParent=true
的仅过滤项是输入有效负载和预期输出的示例有效载荷：-
将所有内容结合起来
基本知识准备就绪后，让我们看看如何根据场景的要求将所有内容结合起来。
所有这些准备就绪后，大数据的4，最后的源代码被列出下图：-
注意：当源负载中的某个特定节点不是直接分配给目标节点时，需要通过在节点末尾添加.text（）方法将其转换为文本字段。
设置单元测试
接下来，为了使其值得努力，我们将上述场景设为单元测试的测试用例。我将再次使用基于Spock的方法，这样一旦我们有了一个成功的测试用例，就会有一个基线来确保Groovy脚本将来的任何更改都不会破坏现有的场景。
开发将作为一个IntelliJ项目进行维护，人工智能的技术有哪些，基于我在上一篇文章中描述的如下目录结构，皮条客我的Groovy-促进消费物价指数Groovy发展与IntelliJ的想法。正在测试的脚本将OrderToPurchaseOrder.groovy文件，斯波克规范将是有序的RTO采购订单规范groovy. 输入XML负载和预期的XML输出负载作为项目中的资源进行维护。
