BizTalk：XSLT与映射工具

Question

我们正在从遗留系统生成的XML文件到EDI 834/837文件进行映射过程。我们有BizTalk 2010，并使用Microsoft内置的EDI架构。

EDI文件相当复杂，我们得到的XML文件也很复杂，并且有大量的文件。我开始浏览映射工具，但似乎有很多重复，我可以通过XSLT运行XML文件来消除。

我找到了以下链接，但我对一个来源不满意。 http://blog.eliasen.dk/2009/07/08/CustomXSLTScriptingFunctoidOrBuiltinFunctoidsAQuestionAboutReligion.aspx

那么，使用映射工具而不仅仅是构建自定义XSLT的任何其他优势呢？

Answer 1

我对BizTalk地图的体验是，使用XSLT非常简单的事情可能会非常复杂。

有关BizTalk映射的良好反例，请查看“BizTalk Server 2009中的专业映射”一书。本书提供了一些使用BizTalk映射可以实现的非常复杂的事例，但其缺点是实际上它们隐藏了脚本functoid中的所有复杂性。因此，地图根本不再是可视的（它们甚至没有节点之间的链接，至少提供推断，以推断地图正在做什么）。

XSLT可以比地图更直观，因为您可以在XSLT中看到生成的XML（请记住，“文本”并不意味着“不可视” - 如果您在文本格式之间进行转换，那么这是一种自然的方式通过查看文本可视化转换

BizTalk映射可用于非常简单的映射，您实际上是将一组属性从一个结构复制到另一个具有相同属性的结构。但是，只要你必须将一个结构映射到另一个不同的结构，你就会很快得到一些难以编写且难以阅读/理解的东西。

Answer 2

不是，我也更喜欢XSLT。更容易记录（使用源中的注释）并因此进行维护。但是，请记住，在BizTalk 2006 R2 you could not import external XSLTs中，这会减少您的重用选项。我不知道BizTalk的后续版本是否有所改变，这是为了让你找到并让我们都知道......

Answer 3

不是真的答案，更多分享expierence;

在我的团队中，我们已就此问题进行了讨论。地图的论点是大多数同事都理解它（因为它被每个基本的BizTalk培训所触及），而XSLT则没有。

在我开始使用BizTalk之前，我已经在XSLT上工作了很长时间，并且发现映射器工具非常不直观。我所做的每一个联系都会引发更多的问题，而不是让我在知道结果的情况下获得安慰。当源节点为零，不存在或重复时会发生什么？当目标节点定义为minOccurs = 2时会发生什么？表格映射functoid究竟做了什么？当找不到值时，表值提取functoid会做什么？如何使用自动编号序列创建节点，以及如何使用生成的数字关联与这些节点相关的其他已创建节点？

使用XSLT让我有了控制权，我确切知道会发生什么。

XSLT地图具有基于文本的附加价值，适用于源代码管理中的分支和管理，并允许我们在源代码中添加内容。曾经尝试过合并来自两个不同分支的地图的变化吗？

最终结果是我们现在更喜欢XSLT进行映射，但并不是每个开发人员都能熟练使用XSLT。这需要一些培训。

最后一个提示：为您的地图投资单元测试工具。找一个开源工具包，或者写一些管道来自己测试你的地图。大多数BizTalk工件都是完全可测试的，即使它看起来并非如此，但编排可能存在例外情况（无论如何都应该将它作为最后的手段使用）。

Answer 4

IMO：

XSLT的好处

• 通过使用XSLT apply + call重用映射功能，可以获得更好的DRY 模板和自定义脚本函数（例如C＃脚本）相同 地图。不幸的是，AFAIK <xsl:include>不起作用，所以你会这样做 需要复制粘贴才能在多个map xslt文件中重用。
• XSLT原生调用模板往往比C＃脚本更具性能（大多数functoids are implemented anyhow）
• 您可以在Visual Studio中使用XSLT debugger。
• 并强调ckarras的观点，即对于复杂的地图，XSLT实际上更容易理解而不是视觉蜘蛛网。

视觉地图的好处

• 琐碎地图的生产力，例如：其中所有元素的名称和类型完全相同，并且可以在根级别映射，或者如果需要具有硬编码输出元素值的虚拟映射。
• 我猜XSLT的障碍率可能很高。

Answer 5

作为具有BizTalk经验以及另一个基于GUI的映射工具（BridgeGate）的人，我可以说，对于非程序员，这些应用程序包含其映射接口形式的解决方案，以解决大多数问题。当它们不足时，它们提供了一个后门，以脚本functoid的形式退出到更基于代码的解决方案。因此，虽然XSLT当然是一种替代方案，但我发现那些喜欢它的人往往是那些编写代码比不熟悉的人。

我对837P和837I文件的经验是使用先前的映射工具（BridgeGate），并且它很难 - 但这主要是文件复杂性的错误。我可以说的是什么，没有提到的是，在基于GUI的地图中，为了适应客户变更请求，过程后期的更改变得更加容易;我只能想象如何深入了解足以处理837转换的XSLT并进行更改以触及变更请求所涉及的每个节点。你知道837有多大，循环有多复杂。做出选择时请记住这一点。

我不羡慕你的任务，但是当你完成任务时知道满足感会让一切变得有价值。祝你好运！