消息处理原理及扩展

1.      消息处理原理

依托于消息队列，当消息发送到消息队列后，根据消息中的“操作类型”来匹配对应的消息处理器，并由该消息处理器执行该消息，此处只涉及消息处理器的扩展。

标准产品内置的消息处理器如下：

在消息处理器定义中，同一种操作类型只允许定义一个处理器，但可以挂上多个插件。

其中“操作类型”指消息队列表（t_sfc_messagequeue）中的字段FOperationType，对于同一组别的消息，操作类型取自“待执行”状态的那一条消息。如生成不良类的消息，其同一组别的消息中，存在“组装扫描”和“生成不良”两种操作类型，此时取后者。

对于组装扫描、批量扫描、包装扫描等同属于生成工序汇报的扫描操作，虽然其最终都生成工序汇报单，但有细微差异，因此仍然把它们区分成不同的操作类型，以便有针对性地处理。在此也建议将处理器粒度尽量最小化，通用的处理则可以放到超类中。

下图是组装扫描消息处理器的定义：

1.1.  消息处理器机制

每条消息的执行入口为“处理器实现类”，还可以自定义多个“插件”，其中处理器与插件间可传递当前处理的消息对象（MsgHandlerParam），还可以通过“参数类”来自定义其他可传递的参数。

         所有处理器实现类的超类为AbstractMsgExecutor，所有插件实现类的超类为AbstractMsgPlugIn，所有参数类都由MsgExecutorParamAttribute以[MsgExecutorParam]属性的形式注册到实现类中，以便参数在处理器和插件间传递。

         以标准产品中的扫描类消息处理器ExecuteByCacheInfoExecutor和更新工序汇报子单据体字段的插件示例OptRptMsgPlugIn为例，类图如下：

执行顺序图如下：

可以在消息的执行前、执行后通过处理器实现类进行扩展，也可以在事件处理前、事件处理后通过插件实现类进行扩展。

2.      二开扩展

2.1.  自定义插件

在现有业务的基础上，定义插件，配合已有的消息和消息处理器使用。

例如：在组装扫描界面增加录入字段“操作员”返回到汇报单分录中，通过消息队列写入到单据中。

1)   消息发送格式

在向消息队列发送消息时，需要往T_SFC_MessageQueue表中写入字段FExtendJSONData，格式如{"EmpinfoId_Id":120798}，其中EmpinfoId_Id为工序汇报子单据体中操作工的属性名，120798为要写入的值。

2)   实现插件，插件代码如下：

3)   注册插件

在“消息处理器定义”中，针对组装类消息处理器ASScanning，增加插件实现类：

2.2.  自定义处理器

定义一个全新的处理器，处理独立的个性化业务，与“消息发送”模块配合使用，单独处理某一类型的消息。

例如，用户自定义了单据A，并在扫描时发送了消息到消息队列，希望通过消息处理器来生成该单据。

1)   约定“操作类型”，以便在发消息时、注册处理器时使用，注意与已有的操作类型区分开；

2)   实现处理器，扩展AbstractMsgExecutor，可参考ExecuteByCacheInfoExecutor；

3)   注册处理器。