Biztalk 脱水水合回路

我有一个简单的Biztalk应用程序2013-r2，它将文件导入到表中，然后执行长时间运行的导入后进程（通过存储过程）

症状：导入2个文件时

• 导入第一个文件没有问题
• 然后，后处理开始（由于存储过程运行时间长，所以速度慢如预期）

---

• 然后，如果删除第二个文件，第一个文件后处理将消失，并进行第二次导入
• 然后它们开始来回交替（您可以看到后处理字段按预期填充）
• 两个发送端口都处于活动状态，有时您会看到第三个端口脱水

由于没有报告错误，这必须是一个设置，还是我需要将后期处理从长时间运行的事务中移出？

详情：

• 业务流程事务类型正在长时间运行
• 后处理发送端口的超时时间为59分钟
• 后处理存储过程调用子存储过程
• 任何地方都没有报告错误
• 两个发送端口都已检查订单传递

后处理存储过程：

    CREATE PROCEDURE [sync].[MPostProcessing]
        @Code NVARCHAR(2)
    AS 

    ----
    ---- 2. Normalize Address
    ----
    IF @Code = '99'
        EXEC sync.AElBatch @Code = @Code


CREATE PROCEDURE [sync].[AElBatch ] @Code AS VARCHAR(2)
AS 
    DECLARE @ID AS INT

    WHILE EXISTS ( SELECT   ID
                   FROM     sync.[mtable]
                   WHERE    Code = @Code
                            AND PostProcessingDone = 0 ) 
        BEGIN

            SELECT TOP 1
                    @ID = ID
            FROM    sync.[mtable]
            WHERE   Code = @Code
                    AND PostProcessingDone = 0



            EXEC sync.PParse @ID = @ID


            UPDATE  sync.[mtable]
            SET     PostProcessingDone = 1
            WHERE   Code = @Code
                    AND ID = @ID

        END

然后PPArse存储过程会执行更多操作（所有操作都正常，没有报告错误）

Biztalk Server管理控制台的映像

---

所以这篇评论太长了，但我还是不能100%肯定你的问题。无论哪种方式：

您的SPs似乎有一些问题。重构它们以使用基于集合的查询，而不是

while

循环（或游标，如果有的话）。强制SQL Server将每个单独的标量变量作为单独的调用进行处理将阻止它完全优化在

sync.PParse中执行的任何操作-如果需要，将表变量传递给它或其他对象，以便它可以正确地并行化它，并停止如此糟糕的操作

很可能，
sync.PParse
中有一个错误，它正在读取不应该读取的数据。尤其是
AElBatch
中的这些行令人不安：

        SELECT TOP 1
                @ID = ID
        FROM    sync.[mtable]
        WHERE   Code = @Code
                AND PostProcessingDone = 0

您可能希望在其中添加某种批次标识符，以便后处理2不会开始提取真正用于后处理1的内容

仔细检查sp_who2的情况，看看是否有问题。即使没有正确地出现错误，也有可能发生了一些事情

最后，如果这些都不起作用，您可能必须将它们放入BizTalk调用的单个SP中，以便
有序交付
将两个作业保持在同一队列中，而不是让文件加载2在后处理作业1完成之前完成。
我不完全清楚您的问题是什么。你说没有错误，所有处理都成功了-你只是想知道为什么会有水合/脱水循环？然后如果你删除第二个文件，第一个文件后处理就会消失，第二个导入也会发生。然后它们开始来回交替（您可以看到后处理字段按预期填充）第一个文件加载是否未完成？只有文件加载部分完成，后处理完成一半，删除所有行以导入第二个文件时。此外，Biztalk Server管理控制台中的“导入”和“后处理”两个发送端口都处于活动状态