BizTalk Server 十大常见错误
5.00/5 (1投票)
以下是 BizTalk Server 的十大常见错误
在过去大约四年半的时间里，我所有的项目都基于 BizTalk Server 2004、BizTalk Server 2006 和（最近）BizTalk Server 2006 R2。在这段时间里，我看到了开发人员在使用、部署和管理 BizTalk Server 时犯的一些错误。
尽管存在许多常见的错误，但有十个错误出现的频率非常高。
- 将所有内容都用于编排
- 编写自定义代码而不是使用现有适配器
- 使用不可序列化类型并将它们包装在原子事务中
- 混合事务类型
- 依赖公共架构进行私有处理
- 在管道中使用
XmlDocument - 使用“立即指定”绑定
- 使用 BizTalk 进行 ETL
- 倾倒调试/中间结果以支持调试
- 传播 BizTalk 慢的谣言
列表很适合作为提醒，但您也需要了解细节。因此，让我们更详细地探讨每个错误。您将了解每个错误为何是错误以及如何解决它。
1. 将所有内容都用于编排
为什么这是一个错误 - 编排之于 BizTalk，就像抗生素之于我们一样——过度使用它们会使它们失效。
如何修复？
在处理 BizTalk 时，改变您思考解决方案的方式——思考消息以及它们如何在业务流程中流动。在许多情况下，编排是最后的手段。在使用编排之前，请使用基于端口的转换和路由、直接绑定以及交易伙伴管理。
2. 编写自定义代码而不是使用现有适配器
为什么这是一个错误 - BizTalk 提供了适配器，可以轻松调用存储过程、调用 Web 服务方法、与 MSMQ 交互等。当现有功能已提供、经过测试并由他人（Microsoft）支持时，为什么还要重新发明、维护和配置呢？
背景 - 许多开发人员通过编写程序集中的一些代码并从“表达式”形状调用它来调用 Web 服务方法或存储过程。虽然这样做很方便，但自定义代码需要一种获取配置信息的方式，需要部署，并且最终有人需要更新代码。
如何修复？
像 SOAP 和 SQL 适配器这样的 BizTalk 适配器非常棒。内置适配器易于使用和配置——而且您无需担心不必要地维护大量自定义代码！
通过查阅产品文档、阅读博客以及——最重要的是——自己尝试，来研究 BizTalk 适配器。您的客户会很高兴，因为您以后需要维护和部署的内容会更少。
3. 使用不可序列化类型并将它们包装在原子事务中
为什么这是一个错误 - 原子事务有其限制，并且可能导致性能问题。
背景 - 某些 BCL（.NET 基类库）类型是不可序列化的；因此，在长期事务中不能使用这些类型。一些开发人员通过将事务设置为“原子”来“解决”这个问题——这允许您同时使用可序列化和不可序列化类型。
如何修复？
应将不可序列化类型作为最后的手段。尝试使用 BizTalk 的功能来解决您的问题：使用适配器，研究 XLANG 的 xpath 函数，尝试提升或区分属性——有很多选择。
4. 混合事务类型
为什么这是一个错误 - 在编排中切换事务类型会迫使 BizTalk 将一些关于编排的信息持久化到其内部数据库。
如何修复？
尽量完全避免使用嵌套的原子事务——使用一个原子事务，或者合并流程，以便在原子事务中完成大量工作。
另请参阅“编写自定义代码而不是使用现有适配器”和“使用不可序列化类型并将它们包装在原子事务中”以获取更多指导。
5. 依赖公共架构进行私有处理
为什么这是一个错误 - 公共架构是您不拥有或不控制的架构。通过使用您不控制的类型，您就引入了对属于他人的类型的紧密耦合（或依赖）。公共类型的更改将迫使您更改解决方案。
背景 - 例如，您的解决方案可以调用 Web 服务并直接使用生成的消息进行进一步处理。您可以从交易伙伴那里接收一个平面文件，并以其格式为基础进行进一步处理。
从管理解决方案中类型（types）的角度来看，这两种方法都存在风险。
如何修复？
在设计阶段的早期解决此问题。将公共消息转换为等效的私有表示形式，或者通过采用一种“总线式”方法在解决方案中移动消息。这两种方法都不如直接使用公共类型那么容易，但额外的工作使您的解决方案更能抵抗变更。
顺便说一句，您是否考虑过创建一种“标准”类型来解决这个问题？不用费心了——那是第十一个错误！
6. 在管道中使用 XmlDocument
这适用于创建自己管道组件的开发人员——不适用于使用管道编辑器创建 BTP 文件并使用常规 BizTalk 管道组件的开发人员。
为什么这是一个错误 - XmlDocument 类型对 XML 文档的每个方面都会占用大量内存。管道就像高速公路上的超车道——您需要快速、精简。
背景 - 管道以高效而闻名，因为它们在处理接收或发送的信息时使用流。一些开发人员要么不知道流，要么不熟悉如何使用流，而是选择将 XML 加载到 XmlDocument 类型中。虽然 XmlDocument 类型很有用，但在管道中它没有任何合法用途，因为它会增加大量内存开销。
如何修复？
在创建第一个管道组件之前，请查看其他开发人员是如何做的，并阅读他们的代码。如果您找不到任何开源管道，可以使用 Reflector 来浏览 Microsoft 的 XmlReceive 管道。从那里，尝试使用流类型并了解如何处理您的场景，然后再承诺编写新管道，因为管道调试可能是一个复杂的过程。
已经卡在了一个使用 XmlDocument 的管道上？尝试将文档拆分成更小的部分，也许可以从编排中调用管道。
7. 使用“立即指定”绑定
为什么这是一个错误 - BizTalk Server 的设计目的是将解决方案与其运行环境解耦，从而使系统管理员能够以最佳方式部署应用程序。“立即指定”绑定会将开发人员工作站的配置与其它环境的配置耦合在一起。
背景 - 当您向编排添加端口时，弹出的向导会为您提供一些将逻辑端口绑定到物理端口的选项。如果您想使用自相关端口或直接绑定，请使用向导选择这些选项，如果您不打算使用其中任何一个选项。
如何修复？
避免使用“立即指定”绑定——而是优先使用“稍后指定”绑定。
稍后指定绑定提供了更大的灵活性，并使您的解决方案能够轻松地从您的工作站迁移到另一个环境（您甚至可能能够获得“在我的系统上可用”的认证！）。
“立即指定”绑定可能对演示和本地工作站上的测试有用，但仅此而已。
8. 使用 BizTalk 进行 ETL
为什么这是一个问题 - ETL 解决方案通常在短时间内处理大量数据。ETL 解决方案通常是线性的，并且很少更改。BizTalk 不是为此类用途设计的。
背景 - ETL 代表提取、转换、加载（Extract, Transform, Load）。
如何修复？
如果您正在使用 BizTalk 进行 ETL，那么您就使用了错误的工具。BizTalk 是一个消息传递平台。SQL Server Integration Services (SSIS) 非常适合 ETL——请改用 SQL Server Integration Services。
9. 倾倒调试/中间结果以支持调试
为什么这是一个问题 - BizTalk 提供了充足的调试支持，所以这完全没有必要。
如何修复？
您可以调试您的 BizTalk 解决方案。您知道您可以使用 Visual Studio 逐步执行 BizTalk Server 从映射、编排、管道等调用的自定义组件中的代码吗？您知道您也可以逐步执行编排吗？您还可以保存解决方案中的几乎任何消息。
因此，真的没有理由在您的解决方案中添加发送端口——发送那些将中间文件放到您系统硬盘上的某个位置，以便您检查消息的发送端口。
考虑使用自定义组件结合使用 DEBUG 符号的技巧？这与第二个错误有关！
10. 传播 BizTalk 慢的谣言
为什么这是一个错误 - BizTalk Server 速度很快——真的很快。我还没有遇到过 BizTalk Server 慢到无法处理特定问题的情况。
背景 - BizTalk 提供了许多性能测量和调优选项，以帮助您充分利用系统的硬件能力。
如何修复？
了解您系统中消息的类型；了解延迟和吞吐量之间的区别；测量性能（考虑购买 Team Foundation for Developers——它提供了出色的性能测量工具集）；了解可用的调优选项。
有一个项目需要帮助？需要指导？联系我——点击联系链接，可能会获得免费帮助（问问总没有坏处）！