消息引擎
1. 消息类型
2. 实现方法
消息类型
系统内置的实现，有二种类型，工作流消息和自定义消息。
工作流消息来自于工作流的设定，在不同的流程中，产生不同的讯息。比如，处理工程更改后，要通知工程部和生产部的相关负责人，这个功能直接在工作流中设置即可完成。
还有一类工作流消息，来自于系统内置的消息，比如，产生MRP运算之后，要产生大量的需求提示信息。在销售单过帐之后，也可发送邮件到仓库组，安排送货。
界面如下，Workflow Message和Custom Message.
Custom Message是用户直在此输入的消息，相当于一个内部通讯盒，当被通知的人员登陆ERP系统时，可以查看到通知消息。如下图所示
在工作流中，设定消息的界面如下, 这里的消息要2个要点
1 消息可以接受Macro，也就是用户可以定义一个Macro,设定Macro的取值规则，或从数据库，或从系统环境变量，取值后，当消息呈现在用户面前时，动态的赋值。
如图中所示,SECURITY_LEVEL就是Macro,在运行时，由环境给出变量值。
2 如果是条件式消息，比如满足条件A，发送消息”Got it”, 否则发送消息”Understood”, 条件表达式如下
这种消息机制实现的难点是，解析条件表达式。
实现方法
1. 直接用原生的SQL+ADO.NET，这样做最稳妥，新建立消息表Message, 用户表User，然后是实现保存，发送，新建立，并提供足够的接口封装，供各种情况下使用。
可能产生消息的程序，不是.NET程序，当提供Web Services方式供其他类型的程序调用。基本的原则是，外部程序对数据库表一无所知，只能操作接口，以达到稳定性和统一。
如果服务器暂时不可连接，可以缓存消息在要本地，待连接到服务器中时，再发送消息。
2. SQL Server Services Broker 实现
SQL Server 2005导入Services Broker技术，是另一种消息通讯的实现。而且有大量的内置特性，功能肯定会比自行开发的ADO.NET要强，可能唯一的遗憾是Services Broker只能在SQL Server 平台，不能移植到其他的数据库平台中去，另外，只有SQL Server 05才开始支持，而现在还有大量的用户在使用SQL Server 2000,。在可用性方面，比ADO.NET要差一些。
创建队列CREATE QUEUE InspectionQueue
创建服务 CREATE SERVICE InspectionService ON QUEUE InspectionQueue
发送消息
BEGIN TRAN
DECLARE @workRequest UNIQUEIDENTIFIER;
BEGIN DIALOG CONVERSATION @workRequest
FROM SERVICE InspectionService
TO SERVICE 'CentralMaintenanceService';
SELECT @workRequest;
DECLARE @workRequest UNIQUEIDENTIFIER;
SET @workRequest = '6AF33B51-EE4A-DA11-91C9-00904B8B6392';
SEND ON CONVERSATION @workRequest
('<WorkRequest>
<Action>ECN Posting</Equipment>
<Data>ECN00612001</Reason>
</WorkRequest>'
);
COMMIT TRAN
3. Message Queue. Windows内置的机制消息队列。
string queueName = @".\private$MSMQ";
if (!System.Messaging.MessageQueue.Exists(queueName))
{
MessageQueue queue=System.Messaging.MessageQueue.Create(queueName, true);
}
异步的接收
queue. ReceiveCompleted += new ReceiveCompletedEventHandler(QueueReceiveCompleted);
queue.BeginReceive();
EndReceive(asyncResult.AsyncResult);