在BizTalk业务流程中使用类和方法

我继承了支持和制作BizTalk应用程序作为我开发角色的一部分。 我是一名普通的C开发人员，所以我很高兴看到我可以创建类并从编排的表达式形状调用方法。 这意味着我可以使用我熟悉的代码完成所有的数据操作，而且速度更快，而不是学习BizTalk方法

在这一点上，我并不关心这是否是一个好主意

---

是否有任何纯粹的技术原因我不应该这样做？

从技术上讲，您是在增加部署并维护外部程序集的复杂性，例如，某些合同中的任何更改都需要更改程序集和编排。

---

您正在失去BizTalk映射引擎用于数据转换的所有优势，而数据转换通常是一个容易学习的部分

我这么说，以BizTalk方式开发BizTalk应用程序对于未来的可维护性非常重要

例如，如果您在一个应该在映射或XPath中完成的外部类中执行消息操作，我将在代码审查中失败，您将不得不重构

---

原因是，无论谁从您手中接手，都应该期待BizTalk应用程序。我见过您描述的情况，这确实使升级、增强和支持新的业务需求变得更加困难，因为现在开发人员必须适应BizTalk和外部流程。

从技术上讲，使用.NET类不会破坏BizTalk中的任何内容。许多BizTalk组件都是基于.NET framework的，例如适配器、管道组件等。在我看来，根据不同的场景，请同时使用BizTalk和.NET。e、 g.如果需要将入站XML映射到出站XML，请使用BizTalk映射，因为它们更容易实现，也更快速，在这种情况下，使用.NET类比使用map更繁琐。我认为在使用BizTalk功能（如映射、业务流程、管道组件）方面没有太大的学习曲线。

您必须确保所调用的任何外部方法都具有多线程功能，并且能够处理高吞吐量

如果您没有实现上述目标，那么您可能会遇到一些由交叉线程污染引起的非常奇怪的问题，或者会在BizTalk中造成瓶颈，从而降低消息吞吐量

---

您还需要确保错误得到处理、重试并在失败时正确传播回调用业务流程。我遇到了一个解决方案，其中开发人员出于某种原因决定使用外部类调用web服务。这个web服务经常会抛出一个错误，但是类只会在返回到编排时传递错误消息，就好像它是一个有效的响应消息一样。这将导致业务流程稍后在尝试使用消息时出现故障，而消息与预期消息不匹配。当我得到分配预算时，我用一个正确配置的发送端口替换了这个类，该端口在遇到web服务错误时也会自动重试消息，然后它成功地处理了。

作为说明，从技术上讲，我正在寻找能够确定这样做会导致BizTalk崩溃的领域的答案。谢谢，但这个答案是关于流程和可维护性的。我对发现这种技术是否破坏BizTalk功能感兴趣。支持调用外部方法。它不会“破坏”任何东西。你只是冒着很高的风险，阻止将来以最简单、最便宜的方式完成某件事。在这种情况下，它确实“破坏”了BizTalk开发模式。谢谢，但这个答案是关于流程和可维护性的。我感兴趣的是发现这种技术是否会破坏BizTalk功能。正如@Jonhs-305之前评论的那样，不，你没有破坏任何东西