复杂业务流程监控（基于Apache ODE）

流程运行状况的监控是实际流程执行过程中不可缺少的功能模块，因为在实际的执行过程中，需要观察阶段性的执行结果对流程实例进行终止、挂起等操作，还有对于不断改变设计版本的流程需要卸载旧版本流程定义，同时激活新的流程定义。

首先来看对整个系统的运行情况监控，这主要是指对系统所有已部署流程的监控。包括查看流程个数、实例个数、某流程定义文件、部署文件等。它的实现方式也很简单，在第三章的持久化小节中，我们说到所有的流程信息和实例信息都通过持久化层储存到数据库中，在这里我们只需要将持久化信息取出，并展现给用户便可以。

接下来是流程实例的监控，用户希望知道某次流程执行的实时情况，类似于程序的调试过程，可以查看流程执行过程中发送的信息、变量值和调用哪个Web服务，甚至暂停和继续执行实例等。这对于复杂流程的设计成功起着非常重要的作用，因为复杂流程设计难免出现纰漏，如果不能随着流程的实际执行过程进行调试，那么很难查找出流程运行过程中出现的问题、以及耗费时间最久的活动，并最终根据这些信息对流程进行改进。而监控正在运行的流程实例有一定的难度，处于运行态的流程实例只出现在引擎的内存空间中，其所有的当前执行信息都保存在流程定义对象中，而且这样的对象个数可能非常庞大（视流程所涉及的标签个数和标签被调用次数而定），如果通过读取这些对象的信息来获得实例运行状态，那么在用户请求的时刻就需要将该流程沿着它的路径再重新走一遍，来确定流程的执行状况。这无疑会增加系统负担，影响整体性能。

在本系统中，我们并没有设计实现具体的实例监控端，因为用户的需求不同可能会构建不同的监控平台（基于网页或客户端形式的），而是通过实例执行过程中不断触发不同的事件来监控流程运行。用户可以通过配置来指定所有事件的监听器来处理事件，如果只对某类事件感兴趣则只实现部分的监听器即可，配置好自己的监听器之后当流程运行过程中触发了该事件，就可以根据所截获的事件数据类型来判断流程当前的执行状况。事件中所包含的基本数据信息包括流程名称、流程ID、实例名称（流程名称加随机字串）、所触发的活动类型、触发时间、流程变量以及发送的内部消息格式等。用户拿到这些信息，同时结合流程定义，便可以判断当前实例的运行情况。

至于流程实例的生存周期管理的操作（暂停、恢复执行、终止等）的实现方法，其实在第三章流程运行小节中已经进行了简单介绍。在本系统中流程实例的执行过程，被分成了两个操作队列，一个是所定义的标签执行队列，另一个是所对应的回调队列。流程生存周期管理暂停、恢复执行、终止所对应的操作便是对这两个队列分别进行序列化、反序列化和清空的操作。这样便实现了实例运行状况的监控，用户可以使用系统预留的接口自定义所需的消息处理器，在获得消息数据之后经过用户系统加工，便可以形成一个流程系统监控程序，对设计的流程进行简单调试，加速流程设计的速度。

监控流程的运行状态，一般我们是通过判断节点的状态来完成的，节点如果该运行完成却没有完成，就会出现异常标志位，然后就在流程监控器上面用不同的颜色来标示，然后管理员就知道了，但是一个复杂的流程系统，需要监控的东西很多哦。。。。

恩，你说的很对，监控的东西是挺多的，所以在这个系统中触发的流程事件也非常多，可以选择监听某几个事件来获知流程的运行状态
你们的那种形式，是可以监控到每个服务节点上吗？这样服务一多会不会很麻烦？或者比较难配置？
这种基于事件的可以只在引擎节点上配置，然后监听便可以，虽然不能获知节点出了什么具体错误，但至少能知道是哪个出了问题，呵呵，这样，管理节点和执行节点的通信负载也会小一些

监控每个节点这种情况，如果同时又多个流程运行，有点点影响速度，特别是流程中节点比较多的情况，更是如此

基于事件的方法可以对整体进行监控，避免了详细监听的问题，

我们在设计上可以考虑把两种方法结合起来。。。。。。也许更好些

去年在设计一个流程系统的时候，曾经模仿微软的系统，为流程系统设计了一个基于消息队列的事件管理模块，但是没有经过实践的检验，并不清楚这样做是否对流程的管理有什么好处，仅仅是一种模仿而已。。。

通过事件和消息机制来做监控和管理，好像比直接通过状态改变来监控显得复杂。。。