我们有一个BizTalk应用程序，其中输入的消息的顺序非常重要并且必须保留，这意味着它们必须以相同的顺序输出。通常有序的交付将在这里诀窍。
但是我读到只有在将接收位置直接连接到发送端口时，才能保证有序发送。您使用业务流程的那一刻，订单交付不再保证。有办法解决或解决这个问题吗？因为这种破坏我们的整个应用程序，我们已经在这几个月一直在努力。
我从微软那里读了一个工作，他们使用了一个额外的字段，它有一个计数器，并且他们使用一个检查计数器的结束编排。但这对我们来说太过分了。所以这个工作是不行的。此外，并非所有消息都被翻译，这会在我们的流程中产生漏洞，而且并非所有消息都来自同一来源，无论如何都会使这些消息无效。
还有其他想法吗？
答案 0 :(得分：1)
查看this页面。 它解释了如果您有一个遵循单例模式的业务流程，以确保只存在一个业务流程实例，并确保将业务流程的接收端口设置为有序传递，那么您应该获得有效的端到端有序传递方案
要提供端到端的有序交付，必须满足以下条件：
必须使用适配器接收消息，该适配器在将消息提交到BizTalk Server时保留消息的顺序。在BizTalk Server 2006中，此类适配器的示例是MSMQ，MQSeries和MSMQT。此外，HTTP或SOAP适配器可用于按顺序提交消息，但在这种情况下，HTTP或SOAP客户端需要通过一次提交消息来强制执行订单。
您必须使用将Ordered Delivery选项设置为True的发送端口订阅这些消息。
如果使用业务流程来处理消息，则只应使用业务流程的单个实例，应将业务流程配置为使用顺序队列，并且业务流程接收端口的Ordered Delivery属性应设置为True
答案 1 :(得分：1)
BizTalk中有序传递的重新排序策略：
我最近回复了LinkedIn用户question关于BizTalk中订购的投放选项。
我认为让人们理解使用BizTalk重新排序消息的一些策略会很有用。
通常作为BizTalk Developer，您需要集成到不可更改的业务线系统。这可以是出于许多不同原因中的一个或多个。例如，更改系统的成本可能过高，或者供应商许可证声明如果系统发生更改，可能会撤消支持。
这通常不会代表供应商提供精心设计的API作为集成点端点的问题。但是，正如许多集成开发人员很快学到的那样，这种情况很少发生。
精心设计的API是什么意思？好吧，除了所有SODA主体（服务组合，错误合同等）之外，API最重要的特性是支持消耗以错误顺序到达的数据。
这是一件相当简单的事情。例如，如果您是供应商并且提供了HTTP操作作为集成点，那么您可以在操作中公开的字段之一是时间戳，或者更好的是序列号。这意味着如果使用过时的有效负载进行呼叫，则相关的补偿机制可以启动 - 这可以像丢弃数据一样简单。
本文讨论了当供应商未将此功能构建到API时要执行的操作，因此作为集成商，您必须实施端到端有序交付作为集成解决方案的一部分。
正如我在response中对用户关于LinkedIn的帖子所述（参见上面的链接），在BizTalk中订购，但最简单的场景中的任何一个都是最复杂的，最坏的情况下可能代表巨大的在开发和支持方面，成本增加了复杂性。基本原因是BizTalk被设计为大规模并发以实现高吞吐量，并发和订购之间存在直接且不可避免的冲突。 Shoe-horning E2E订购交付到BizTalk解决方案依赖于诸如单件编排等人工制品，这会引入复杂性并增加故障率和每次故障成本数。
更好的解决方案是将并发处理保持在尽可能接近业务线系统端点的位置，然后在每个端点周围实现所谓的 re-sequencer wrapper 这需要以正确的顺序交付数据。
如何在BizTalk中实现这样的包装器取决于一些因素，如下表所示：
|Sequencing |Messages|Database |Wrapper |
|field |are |integration?|strategy |
| |deltas? | | |
|--------------|--------|------------|----------------------------------|
|n of a total m| N | Y |Stored procedure |
|n of a total m| N | N |Singleton orchestration |
|n of a total m| Y | Y |Batched singleton orchestration |
|n of a total m| Y | N |Batched singleton orchestration |
|Timestamp | N | Y |Stored procedure |
|Timestamp | N | N |Singleton orchestration |
|Timestamp | Y | Y |Buffer table with staggered reader|
|Timestamp | Y | N |Buffer table with staggered reader|
第一个因素 Sequencing field 与以下想法有关：为了实现任何类型的重新定序器包装器，至少要求您的消息数据包含一些排序信息。这可以采用源时间戳的形式;然而，一种更好但更罕见的排序信息由序列号和消息总数组成，例如，消息1中的10，2中的10，等等。
第二个因素消息是增量？与消息的有效负载是否包含对数据的单个状态更改或所有过去更改的总和有关数据。换句话说，是否有可能从此消息重建数据的完整当前状态？如果消息有效负载只包含一个更改，则可能无法从单个消息重建数据的状态，在这种情况下，您的消息是 delta 。
第三个因素数据库集成？涉及系统的集成入口点是否是数据库。重要的是，在数据库层进行集成是一种相当常见的集成方案，如果可用，可以大大简化处理重新排序的过程。
上表中的策略详述如下：
存储过程包装器 这是最简单的重新测序策略。创建新的存储过程，在决定是否更新目标数据之前查询目标数据。决定可以像我的数据比目标系统中的数据更新一样简单吗？
当然，为了实现这种策略，目标数据还必须包括源数据的排序字段，尽管如果需要可以通过依赖目标中可能已存在的现有时间戳来进行近似。数据。存储过程包装器既可以包含在目标数据库中，也可以包含在单独的数据库中。
Singleton业务流程包装 这个策略背后的想法是单身编排。这是您可以实现的模式，以确保任何时候只存在一个业务流程实例。网上有很多文章演示了如何在BizTalk中实现这种模式。
这个想法的核心是单身人士只是跟踪最近成功处理的消息序列（或时间戳）。如果单例接收到比最近序列更旧的消息，则将其丢弃。这是有效的，因为消息是 non-deltas ，因此目标系统只能提交最新的一些消息，并且数据将处于最新状态。只有在成功提交数据时，才会更新单例所持有的最新序列。
批处理的单件编排包装 此策略基于上面的Singleton业务流程包装器，但它更复杂。不是仅将最新的序列信息保存在内存中，而是需要使用单例来在内存中创建并保存消息的工作集，它将重新排序，然后在批处理的所有预期消息都处理后再处理到达。这是因为消息是增量，因此目标系统必须按照预期的顺序接收每条消息。成功发送批次后，单例可以终止。
要做到这一点，源数据的必备条件是它包含一些描述的相关标识符，它允许定义批消息。例如，处理来自客户的定义的订单集，入站消息必须包含客户的标识符。然后，可以使用它将消息路由到与此客户关联的单一业务流程实例。此外，可用的消息序列字段必须是总m 形式的 n。
初始化单例后，它会在内存中汇编一组有用的消息，并在新消息到达时继续填充它。我看到这样做的一种方法是使用 System.Collections.Generic.List 作为工作集的容器。一旦列表完全填充（列表长度= m），则假定已经接收到批处理中的所有消息，然后业务流程按顺序循环遍历工作集并将消息处理到目标系统中。
批处理单例编排包装器的一个好处是它允许通过相关标识符进行并发处理。在上面的示例中，这意味着将同时处理来自两个客户的消息。
包含交错阅读器包装的缓冲表 可以说是最复杂的策略，当您使用基于时间戳的排序字段进行增量消息传递时，将使用此解决方案。它可以用一些描述的数据库来实现，该数据库充当重新排序缓冲区。
值得注意的是，这种重新排序的包装不能保证有序交付，但很好地使用它很有可能使订购交付。
当消息到达时，它们被写入缓冲区，并且在同一操作中缓冲区被重新排序，因此缓冲区中保存的消息的顺序始终是正确的。
要创建缓冲区读取器，请先将接收位置读取缓冲区中的消息，然后再将消息传递到启用了有序传送的发送端口，然后将该消息处理到目标系统中。如果目标系统的API语义对于发送端口来说过于复杂，您还可以使用单独的业务流程作为中介。
但是，正如我上面所描述的那样使用这个包装器将不会启用有序传递，因为消息几乎肯定会以错误的顺序提交到缓冲区，这将导致消息被处理到目标系统中相同（错误）的顺序。这就是交错查询的用武之地。这是一种说法，你的缓冲区查询只需要按时间间隔选择数据 T ，并且只选择那些行行号低于缓冲区总行数减去C 。
这具有允许在适当的时间跨度进行测序的效果。大多数BizTalk开发人员都熟悉 T 作为某些适配器（例如 WCF-SQL 适配器）的轮询间隔。 C 设置稍微困难一些，但通过增加此数字，您可以减少轮询时丢失的信息，这些信息将比检索到的数据集中的最新信息早。
T 和 C 取决于很多因素，尽管这些值应基于您的延迟SLA和您的消息量（或吞吐量）。作为指导原则，如果您有SLA在30秒内将数据传送到目标系统并且您每秒处理10条消息，那么 T 应该是大约10秒而 C 应该大约100行。
当然，这仅适用于源系统在短时间内（理想情况下背靠背）发送给定相关ID的消息。发送之间的间隔越长， C 所需的值就越大，包装器的效率就越低。
此策略的一个好处是，如果数据源容易发送重复消息且目标系统端点不是幂等的，您还可以在缓冲区中执行消息的重复数据删除。您还可以使用缓冲区来实现 FILO 和其他非标准排队语义。
<强>结论 我在这里讨论的策略是将BizTalk折叠到一个没有设计的任务的方法。因此，每个人都有关于支持成本和复杂性的警告，也可能在某些情况下不起作用。我想听听任何在BizTalk中实现其他有序交付模式的人。