我们正在执行从旧系统生成的 XML 文件到 EDI 834/837 文件的映射过程。我们有 BizTalk 2010，并且正在使用 Microsoft 内置的 EDI 架构。
EDI 文件相当复杂，我们得到的 XML 文件也很复杂，有很多部分是固定的。我开始使用映射工具，但通过 XSLT 运行 XML 文件，我似乎可以消除很多重复。
我找到了以下链接，但我对只有一个来源并不满意。 http://blog.eliasen.dk/2009/07/08/CustomXSLTScriptingFunctoidOrBuiltinFunctoidsAQuestionAboutReligion.aspx
那么，与仅构建自定义 XSLT 相比，使用映射工具还有其他优势吗？
【问题讨论】：
我在 BizTalk 地图方面的经验是，使用 XSLT 非常简单的事情可以使用地图非常复杂。
有关 BizTalk 映射的反例，请参阅《BizTalk Server 2009 中的专业映射》一书。本书提供了一些可以使用 BizTalk 映射实现的非常复杂的示例，但它的缺点是实际上它们隐藏了脚本 functoid 中的所有复杂性。因此，地图不再是可视的（它们甚至没有节点之间的链接来提供至少提示来推断地图正在做什么）。
XSLT 可以比地图更直观，因为您可以在 XSLT 中看到生成的 XML（请记住，“文本”并不意味着“不可视” - 如果您在文本格式之间进行转换，那么自然方式可视化转换是通过查看文本）
BizTalk 映射可用于非常简单的映射，您实际上是将一组属性从一个结构复制到另一个具有相同属性的结构。然而，一旦你必须将一个结构映射到另一个不同的结构，你很快就会得到一些难以编写和难以阅读/理解的东西。
【讨论】：
不是真的，我也更喜欢 XSLT。它更容易记录（在源代码中使用 cmets），因此更易于维护。但是，请记住，在 BizTalk 2006 R2 you could not import external XSLTs 中，这会减少您的重用选项。我不知道这在 BizTalk 的后续版本中是否发生了变化，这有待您了解，也许让我们都知道...
【讨论】：
不是真正的答案，更多的经验分享；
在我的团队中，我们已经讨论过这个问题。地图的论点是大多数同事都理解它（因为它被每个基本的 BizTalk 培训所触及），而 XSLT 不是。
在我开始使用 BizTalk 之前，我个人使用 XSLT 已经很长时间了，并且发现映射器工具非常不直观。我建立的每一个联系都会引发更多的问题，而不是让我知道结果是什么。当源节点为零、不存在或重复时会发生什么？当目标节点定义为 minOccurs=2 时会发生什么？表映射functoid究竟做了什么？未找到值时，表值提取 functoid 会做什么？如何创建具有自动编号序列的节点，以及如何使用生成的编号关联可以与这些节点相关的其他已创建节点？
使用 XSLT 让我重新获得控制权，我确切地知道会发生什么。
XSLT 映射具有基于文本的附加价值，它与源代码控制中的分支和合并效果很好，并允许我们在源代码中添加注释。是否尝试过合并来自两个不同分支的地图的更改？
最终结果是我们现在更喜欢 XSLT 进行映射，但并不是每个开发人员都精通 XSLT。这需要一些培训。
最后一个提示：为您的地图投资单元测试工具。找到一个开源工具包，或者编写一些管道来自己测试你的地图。大多数 BizTalk 工件都是完全可测试的，即使看起来并非如此，但编排可能例外（无论如何，您都应该将其用作最后的手段）。
【讨论】：
国际海事组织：
XSLT 的好处
<xsl:include> 不起作用，所以你会
需要复制粘贴才能在多个地图 xslt 文件中重复使用。可视化地图的好处
【讨论】：
作为在 BizTalk 和另一个基于 GUI 的映射工具 (BridgeGate) 方面都有经验的人，我可以说对于非程序员来说，这些应用程序包含以映射接口形式解决大多数问题的解决方案。当它们达不到要求时，它们会提供一个后门，以退出以脚本functoid 形式的更加基于代码的解决方案。因此，虽然 XSLT 无疑是一种替代方案，但我发现喜欢它的人通常比不喜欢它的人更喜欢编写代码。
我对 837P 和 837I 文件的特别体验是使用之前的映射工具 (BridgeGate)，这很费力——但这主要是文件复杂性的错。我可以说和没有提到的是，在基于 GUI 的地图中，稍后对流程进行更改以适应客户更改请求要容易得多；我只能想象必须深入到一个足够大的 XSLT 来处理 837 转换并进行更改以触及涉及更改请求的每个节点。你知道 837 有多大，循环有多复杂。在做出选择时请记住这一点。
我不羡慕你的任务，但知道你完成它时的满足感会让这一切都变得值得。祝你好运！
【讨论】：