📚 课程目录第4章 FactoryTalk Transaction Manager事务管理

4. FactoryTalk Transaction Manager事务管理

在制造追溯系统中，数据能否“不丢、不重、可查”往往比数据能否“采到”更关键。FactoryTalk Transaction Manager（以下简称 FTTM）正是 FactoryTalk 体系中承担这一职责的事务中间件：它把来自 PLC、SCADA、Historian 或 MES 的离散数据，按事务语义可靠地写入关系数据库，从而支撑批次追溯、工艺参数归档、质量判定记录等场景。理解 FTTM，核心是理解它的四个组成部分如何协同：事务（Transaction）定义“写什么、写到哪”，触发器（Trigger）定义“什么时候写”，存储过程（Stored Procedure）定义“怎么写、写之前做什么处理”，事务日志（Transaction Log）定义“写没写成功、失败后怎么办”。

一、事务管理器组件与运行结构

FTTM 的运行时由几个关键角色构成。最上层是 Transaction Manager Service，它作为 Windows 服务常驻，负责调度事务、管理连接池、维护事务日志。其下是 Transaction 对象，每个事务是一个独立的配置单元，包含数据源（Source）、目标（Target）、映射（Mapping）和触发条件。数据源通常通过 RSLinx Enterprise 或 OPC 接口读取标签值，目标则是通过 ODBC/OLE DB 连接的 SQL Server、Oracle 等数据库。

事务执行时，FTTM 会先读取源标签的当前值或历史值，按映射规则组装成参数集，再调用目标端的 SQL 语句或存储过程。整个过程被包裹在一个数据库事务中：要么全部提交，要么全部回滚。这一点对追溯数据尤其重要——例如一个批次记录需要同时写入“批次头表”和“批次明细表”，如果明细写入失败而头表已提交，追溯链就会断裂。FTTM 通过事务边界保证这种一致性。

二、触发器配置：决定“何时写”

触发器是 FTTM 的调度入口。配置触发器时，首先要明确追溯数据的产生节奏。常见触发器类型包括：

定时触发（Timer）：按固定周期执行，例如每 5 秒采集一次反应釜温度并写入工艺参数表。适合连续过程数据的周期性归档。
标签变化触发（Tag Change）：当某个标签值发生变化时触发，例如“批次号”标签从空变为“B20240612-001”时，启动该批次的追溯记录创建。
事件触发（Event）：由外部程序或系统事件调用，例如 MES 下发“批次开始”指令后触发 FTTM 事务。
手动触发（Manual）：用于调试或补录场景，工程师在 FTTM 控制台中手动执行一次事务。

配置触发器时有一个容易忽略的细节：触发去抖与重复抑制。如果标签在短时间内频繁跳变，可能产生大量重复事务。FTTM 允许设置最小触发间隔或使用“变化量阈值”来过滤。例如温度标签只有变化超过 0.5°C 才触发写入，避免噪声数据淹没追溯表。

三、存储过程调用：把业务规则前移到数据库端

FTTM 支持直接执行 INSERT 语句，也支持调用存储过程。对于追溯场景，推荐使用存储过程，原因有三：第一，存储过程可以在数据库端完成参数校验，例如检查批次号是否已存在、时间戳是否合法；第二，可以在一个存储过程中完成多表写入，减少网络往返；第三，便于后续统一修改业务规则而不需要重新部署 FTTM 配置。

下面是一个典型的追溯写入存储过程示例，用于将批次头信息和明细参数写入两张表：

CREATE PROCEDURE usp_WriteBatchTrace
    @BatchNo      NVARCHAR(50),
    @ProductCode  NVARCHAR(30),
    @StartTime    DATETIME,
    @EndTime      DATETIME,
    @Temperature  DECIMAL(8,2),
    @Pressure     DECIMAL(8,2),
    @Result       NVARCHAR(10)
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRY
        BEGIN TRANSACTION;

        IF NOT EXISTS (SELECT 1 FROM BatchHeader WHERE BatchNo = @BatchNo)
        BEGIN
            INSERT INTO BatchHeader (BatchNo, ProductCode, StartTime, EndTime, Result)
            VALUES (@BatchNo, @ProductCode, @StartTime, @EndTime, @Result);
        END

        INSERT INTO BatchDetail (BatchNo, Temperature, Pressure, RecordTime)
        VALUES (@BatchNo, @Temperature, @Pressure, GETDATE());

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        ROLLBACK TRANSACTION;
        THROW;
    END CATCH
END

在 FTTM 中配置该存储过程时，需要把源标签映射到存储过程的输入参数。例如 @BatchNo 映射到 PLC 中的 Batch_ID 标签，@Temperature 映射到 Reactor_Temp 标签。映射关系在事务的“参数”页中逐项绑定，并可以设置默认值或转换表达式。

四、事务日志与追溯数据写入的可靠性

事务日志是 FTTM 可靠性的最后一道防线。每次事务执行后，FTTM 都会在日志中记录：事务名称、触发时间、执行结果（成功/失败）、影响行数、错误信息以及重试次数。对于追溯系统，这些日志本身就是审计证据的一部分。

当写入失败时，FTTM 提供两种处理策略：重试和死信队列。重试适用于网络抖动或数据库短暂不可用的情况，可以配置重试次数和间隔。如果重试仍然失败，事务会进入死信队列，等待人工处理或后续批量补写。在实际项目中，建议把死信队列与报警系统联动，一旦出现死信立即通知运维人员，避免追溯数据出现空洞。

实践建议：在追溯数据写入场景中，建议为每个事务配置独立的日志表或日志文件，并保留至少 90 天。日志中应包含批次号、事务名称、执行时间和结果，便于在质量审计时快速定位某批次数据的写入记录。

注意：如果存储过程中使用了 THROW 或 RAISERROR 抛出异常，FTTM 会将其识别为事务失败并触发回滚。不要在存储过程中捕获异常后“静默吞掉”，否则 FTTM 会认为事务成功，导致追溯数据不完整却无法察觉。

综合来看，FTTM 的事务管理能力可以概括为一条清晰的链路：触发器决定何时启动，事务定义数据映射与边界，存储过程承载业务规则，事务日志记录结果并支撑重试与审计。把这四者配置正确，追溯数据才能做到“采得到、写得进、查得清、不丢失”。