您经常会遇到这样一个需求：动态地对外部云OData服务实体执行查找，获取详细信息并修改CPI中的现有有效负载。我们在一个C4C数据迁移实现中也有类似的要求。
我们被要求查找OData公开的客户表，向其提供来自遗留CRM的主营业务负载的外部ID，并获取相应的C4C内部ID，并在原始负载中进行更新，最后将其提供给C4C。
最初，我们计划使用内容丰富器来实现这一点，但是，我们希望通过将这些值存储在数据存储中来持久化这些值，交通大数据，以便在同一天的后续调用中提高iflow性能，而且在同一iflow中还要求使用多个主键为另一个C4C实体执行查找，这在content enricher中是不可能的。因此，我们决定在CPI中尝试使用Hashmap对象以及XMLSlurper和XMLParser来解析和修改xml，因为它们是轻量级的xml解析器，因此我们强烈建议使用它们XML格式。在实际场景中，这个xml是从C4C OData调用获取的。我们将用大约30万条记录来测试它，工业物联网，看看它的性能有多好。
下面是iFlow屏幕截图-
将查找XML解析到HashMap对象的简单groovy脚本-
在接下来的两个步骤中，我们只是记录HashMap输出。
大约30万个键值对的测试负载将被触发到iFlow.
在30秒内我们可以得到输出。
CPI中的消息处理-
具有30万条记录的HashMap输出将以下面的格式存储在属性中-
我们经常犯错误，使用我们常用的和最喜欢的'For'语句循环XMLSlurper对象。这会严重影响iFlow的性能，如下所示。当查找大小在15000条记录以内时，这可能不是问题。对于较高的数字，大数据数据处理，处理时间呈指数增长，并影响iFlow性能。
下面是一个示例-
代码片段-
正如我们在下面看到的，此接口的性能受到影响，处理这些记录花费了近2个小时-
场景的第二部分将使用以前存储的HashMap in属性进行查找以获取每个记录中相应ExternalID的InternalID。
下面是更新的iFlow-
我们将使用XMLParser类而不是XMLSlurper，淘客小程序，因为我们希望同时读取和修改XML。这在XMLSlurper中是不可能的，因为它有一种惰性的解析xml文件的方法，也就是说，如果在循环中更新任何字段，则必须再次解析整个文档，因此这不是高效的性能。使用XMLParser，您可以用一行代码同时读取和修改XML。
代码片段-
一旦准备好，包含30万个密钥对值的XML再次被触发到iFlow-
处理在接近59秒的时间内非常有效。应该注意的是，在这个时间范围内，大约有30万条记录的xml被读取并解析成一个HashMap变量，返利，然后根据一个包含30K个业务数据记录的xml来查找HashMap，以更新每个记录的字段（InternalID）。这涉及到对每一条记录的读取和更新操作。
记录的有效负载-
下面是修改的业务有效负载中的2条记录的样本（总共约30K条记录）。
与内容丰富器相比的优势-
在下一篇博客中，我将介绍Json解析器方法，该方法可用于以下情况：来自查找服务的响应是JSON格式的，您希望避免将大型有效负载从XML转换为JSON格式。
