大家好，手机免费建站，

回到云话题，我想和大家分享我的经验，Apache Groovy脚本解析机制的XML文件使用可用的类，只是取代结构或建立从淀粉的输出XML文件向SAP CPI展示Groovy脚本中可用的解析XML文件的类，而不是集成方面。

您将能够用代码示例复制和复制其他类，这是这个主要信息源的汇编——下面的一些文本的参考：

用Groovy处理XML

我在2013年JSON发布的那一年用XML开发了这个程序，我只是想复制一下类似的场景，在JSON输入的情况下，它在某种程度上是相似的。

我将详细解释如何安装插入SAP Netweaver Developer Studio的groovy脚本更易于构建和测试，而不是直接在SAP云平台集成（CPI）中编码和编译。

版本：

许多版本可以在Github–GroovyScript中找到，尤其是，您可能希望尝试"快照版本"而不是发布版本。

如果您使用的是Netweaver Developer Studio，则必须为Oxygen设置：

Oxygen–SAP Netweaver Developer Studio 7.5 sp16

转到"帮助>安装新软件"

名称：Groovy Development Eclipse（建议，您可以添加任何内容）

位置：–选择所有程序包

单击下一步按钮两次

选择"我接受条款和条件"

单击完成按钮

更新完成后，必须重新启动Netweaver Developer Studio，单击"立即重新启动"。

您现在可以执行文件>新建>项目>Groovy>Groovy项目

或此处–帮助>Eclipse Marketplace>安装

或此处–帮助>关于Eclipse

新建项目>Groovy其他>Groovy

现在您可以在本地SAP Netweaver developer studio中进行开发，并在上载之前阅读和编写本地文件在sapcpi中，

如果您不想将您的项目保存在本地机器上，物联网竞赛，您也可以使用这些非常好的Groovy web控制台编码组

XmlParser和XmlSlurper（类似于java中的DOM或SAX）的解析非常相似。我们可以用这两种方法或多或少地取得相同的结果。然而，它们之间的一些差异可能会使尺度向一个或另一个倾斜。

首先，XmlParser总是将整个文档解析为DOM-ish结构。正因为如此，我们可以同时读写它。我们不能对XmlSlurper执行相同的操作，因为它对路径的计算更为迟缓。因此，XmlParser可以消耗更多的内存。

另一方面，XmlSlurper使用更直接的定义，使其更易于使用。我们还需要记住，使用XmlSlurper对XML进行的任何结构更改都需要重新初始化，云服务器好还是，如果一个接一个地进行许多更改，这可能会对性能造成不可接受的影响。

让我们先看看XmlParser和XmlSlurper之间的相似之处：

两者都可以更新/转换XML

XmlSlurper：懒散地评估结构。因此，如果更新XML，就必须再次计算整个树。解析XML时返回GPath结果实例比XML解析器占用更少的内存。

XML解析器：解析XM时返回几乎所有的Nodes对象比XML Slurper更快。可以同时解析和更新XML。

决定使用哪种工具时应谨慎，大数据专业怎么样，并完全取决于用例。

如果要将现有文档转换为另一个文档，则可以选择XmlSlurper如果您想同时更新和读取，那么XmlParser是您的选择。如果您只需要读取几个节点，XmlSlurper应该是您的选择，因为它不必在内存中创建完整的结构一般来说，这两个类的执行方式相似。甚至对它们使用GPath表达式的方式也是相同的（都使用breadthFirst（）和depthFirst（）表达式或（XmlSlurper.'**'）。查找{it.名称（）=='Node'}）

GPath是一种集成到Groovy中的路径表达式语言，它允许识别部分嵌套的结构化数据。从这个意义上说，它的目标和范围与XPath对XML的目标和范围相似。使用GPath表达式的两个主要位置是处理嵌套pojo或处理XML

除了读取和操作XML树之外，返利宝，Groovy还提供了从头开始创建XML文档的工具。现在让我们使用groovy.xml.MarkupBuilder：

使用Groovy和groovy.xml.dom.domcegory是一个类别类，它将GPath样式的操作添加到Java的DOM类中。

Java内置了对DOM的支持使用表示XML文档各个部分的类（如Document、Element、NodeList、Attr等）处理XML。有关这些类的详细信息，请参阅相应的JavaDocs.

我将仅向您展示–XmlSlurper和StreamingMarkupBuilder

概念验证，邮递员通过HTTPS呼叫模拟后端系统，SAP CPI平台收到以下消息步骤：

由于SAP PI和SAP CPI图形映射不能仅用标准函数解析此逻辑，因此您当然可以使用UDF进行解析，但在2013年，我接受了这个挑战，但没有JAVA方面的任何经验来开发我的第一个JAVA映射解决方案，学习和分享知识，任何人都可以复制和理解我为什么喜欢这个解决方案。

XML输入–MT_GraosSAP_Resp:

BlocoFI–与SAP FI/CO相关

BlocoMM–与SAP MM相关

BlocoNFe–与巴西电子发票相关

XML输出–从标签

中接收MoviminentoAsientOnTaFinancial

AsientResponse–与BlocoFI相关

MoviminentResponse–与BlocoMM相关

NotaFinancialResponse–BlocoNFe plus自定义详细信息清楚吗？

该结构的映射比例为1:1，您可以在groovy之前使用图形映射，以便更容易解析

BlocoFI→AssientoReponse

BlocoMM→moviminentoresponse

如果您从外部软件调用无法解析主XML中启用的CDATA字符串，那么图形映射中会有一个错误

我真的不知道，因此，我决定在groovy之后开发XSLT transformer，以保留

图形映射错误，因为我试图在内部模拟测试。

SAP CPI中为测试导入的原始XML：

输出的详细映射要求根据输入响应消息中启用的XML字符串NF-e：

要求构建，对某些值进行1:1映射，但必须使用XML NF-e CDATA字符串的值创建，如下所示

我相信这很清楚，对吗？

现在让我们进入SAP CPI以及我是如何做到这一点的。

集成流程详细信息：

发送者Groovy XmlSlurper类或Groovy StreamingMarkupBuilder类仅当使用XMLSluper呈现结束消息为什么不图形化映射Viana？

请检查上面的错误，所以我决定通过groovy解析所有输入消息。

CPI–XML Supler为什么是XSLT？

XSLT在标记中保留启用CDATA XML的XML。

这仅在您决定使用XmlSlurper和XmlParser进行解析时需要，正如您在第11.5点联机编译器透视图中看到的，这两个类都不能保留CDATA。

XSLT映射程序详细信息：

Groovy的XmlSlurper和XmlParser不保留如前所述。

CPI–StreamingMarkupBuilder:

邮递员执行：

请求消息：

内容类型为application/XML的SAP CPI端点下的邮递员工具，在使用发送方HTTP部署场景后，复制端点。

响应消息–HTTPS调用是SAP CPI中的同步默认行为（您可以不需要使用请求重播集成模式）

在线编译器视角：

代码使用XMLSluper

代码将与在线编译器的链接共享所有详细信息，如果发现错误请告诉我。

使用XMLSluper之前必须使用图形映射（CPI BUG）或XSLT，因为这段代码是带有替换功能的结果消息。

XML Sluper

代码使用StreamingMarkupBuilder

代码将与联机编译器的链接共享所有详细信息，如果您发现错误，请告诉我。

StreamingMarkupBuilder

预期结果与7年前DOM解析博客的类似图像：

result SAP PI–Javamapping DOM解析：

导致SAP CPI使用：

根据默认配置在CPI上发送HTTPS调用它是同步的，因此下面的图像是记录消息后的回放，看，解析Groovy解析XmlSlurper工作得很好，在

邮递员呼叫

在线编译器

之后插入节点rescustasefaz，正如您在在线编译器中看到的，我不能使用XSLT来保持

示例：<；？xml version="1.0"encoding="UTF-8"？>；

Java（DOM解析）–40行代码

Groovy只需要24行代码就可以完成同样的Java DOM解析，减少50%。

如果您有兴趣了解更多信息，我建议您购买Eng Swee Yeoh和Vadim Klimov的SAP press book–Groovy–查看以下博客：

Groovy SAP press

我想感谢您……

让我们推荐所有在SAP CPI平台上发布与此PoC相关的Groovy脚本的专业人士：

我*heart*Groovy映射HCI：使用Groovy脚本轻松解析XMLI*heart*XSLT映射CPI的Groovy脚本中文本文件的处理在Groovy脚本中流化XMLSlurper输入

我希望您喜欢我的创新方法