实时警报通知：微信告警通知的重要性解析
973
2022-12-26
事件与流程引擎（规则引擎 流程引擎 区别）
本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。
本篇文章给大家谈谈事件与流程引擎，以及规则引擎 流程引擎 区别对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享事件与流程引擎的知识，其中也会对规则引擎 流程引擎 区别进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
工作流主要解决的主要问题是：为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。
工作流概念起源于生产组织和办公自动化领域，是针对日常工作中具有固定程序活动而提出的一个概念，目的是通过将工作分解成定义良好的任务或角色，按照一定的规则和过程来执行这些任务并对其进行监控，达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。尽管工作流已经取得了相当的成就，但对工作流的定义还没有能够统一和明确。
Georgakopoulos给出的工作流定义是：工作流是将一组任务组织起来以完成某个经营过程：定义了任务的触发顺序和触发条件，每个任务可以由一个或多个软件系统完成，也可以由一个或一组人完成，还可以由一个或多个人与软件系统协作完成。
1993年工作流管理联盟(Workflow Management Coalition，WfMC)作为工作流管理的标准化组织而成立，标志着工作流技术逐步走向成熟。WfMC对工作流给出定义为：工作流是指一类能够完全自动执行的经营过程，根据一系列过程规则，将文档、信息或任务在不同的执行者之间进行传递与执行，而符合这一流程规范的公司比较少，现在做的比较好的就是天翎了。
个人理解JAVA API是从上到下通过JAVA类一级一级调用，RESET API则是从下到上通过注解+接口一层一层实现，如果你只是使用Camunda实现一些简单的操作，用JAVA API就能满足。
有时候我们需要在部署直接做一些校验，那么可以利用下面这个静态方法： BpmnModelInstance modelInstance = Bpmn.readModelFromStream(is)
通过BpmnModelInstance我们可以做一些简单或者深入的判断，比如判断流程有没有结束事件：
modelInstance.getModelElementsByType(EndEvent.class).isEmpty()
判断启动任务有没有设置表单
（1）查看单个流程
（2）查看流程定义列表
流程定义key值相同的情况下，版本是从1开始逐次升级的，流程定义的id是【key：版本：生成ID】
流程定义key值可以理解为，一个流程只有1个固定key值，你每修改一次流程定义，key值不变，但流程ID，版本号会改变，流程ID会重新生成，版本号会在之前基础上加1；
.latestVersion() 实际是通过key值对列表进行了过滤，只保留最后一版的流程定义。
（3）获取流程定义的文件资源-XML
（4）获取流程
通过BPMN，流程可以与业务战略保持一致，藉由业务部门内部甚至超越公司边界的流程优化，有助于提高公司的运转效率。
BPMN在国内的应用很广泛，但很多企业花费大价钱购买了第三方的流程平台，却没有得到相应的收益；我认为其根本原因还是在于对BPMN本身的理解不足——它远没有看上去那么简单，仅仅是BPMN2.0版本规范文档就已经达到了500页。
因此，在我看来，要想顺利的实施BPMN，一个对它有透彻理解的设计者是必不可少的；同时，设计者还需要兼具业务思维、管理思维，和一定的技术思维。
本文以一个物业维修流程为例，目的在于介绍一个系统的BPMN建模方法，为刚刚踏入这个领域的人提供一个方向和选择。
这是一个典型的物业维修流程，这个流程提供的信息量很少，以至于如果我们要仅仅基于此去设计一个完善的BPMN流程是几乎不可能的，但是即便是最专业的物业管理师，这也是他们仅能提供的流程图了.
为了达到我们的目标，我们需要先建立一个战略层面上的流程，它可能很粗糙，但是它的目的并不是在初期就呈现一个完整详细的视图.
它的作用可能有如下几点:
1.澄清什么是，和什么不是这个流程的一部分
2.为流程确定资源和分配责任
3.确定关键绩效指标并明确其特征
4.在对流程着手优化前先对其进行一个大致的回顾
体积：战略流程模型应当尽可能小，流元素最好不要超过10个，如果一个流程横跨几张纸的话，是没人能理解得了的.
语法：尽可能正确，但是在必要时可以不那么严谨
想要对一个流程进行初步建模，往往比想象的要难得多，有时手头有充足的资料和标准的操作流程可以用，那会好些，但大多数时候都不得不去与客户深入交流.
当产品去和客户开会沟通时，我能很容易的想象到下面的景象——当你只画了一个圈两个矩形：
客户参会人员：
我们的维修流程并不总是这样从业主填写维修单开始的，业主也可能是电话报修
如果维修的工程量比较大的话，我们还得先提出方案，然后交给公司领导审批
如果过了保修期的话，那我们还要收钱的
业主如果是预约的话，我们还得根据他预约时间安排工作
并不一定是业主报修，也可能是在物业巡检的时候发现问题，由巡检员报修
..........
..........
..........
如果没有一个狠人来主持会议的话，产品会很容易迷失方向，也会导致客户的参会人员对你的方案失去兴趣，更差的情况是，其他人糊里糊涂地对一个错误的模型达成了一致.
所以主持会议的人，需要在开始的时候先声明好：所有的流程模型都是不完整的，但是它依然有一些作用.
在一开始找出每一种可能性是不可能的，在这次会议开始前，就应当告诉客户，这第一次的迭代目标是什么.
1.我们要记录流程从开始到结束的过程
2.我们最多只记录这个流程的N个步骤
3.我们只记录这个流程的标准形式
如果会议期间仍有人想跳出圈定的范围，应当立刻阻止.
下面回到正题——物业维修流程.
基于上面的传统流程图，我们可以得到以下信息：
1.这个流程往往是由业主有维修需求引起
2.发起人填写一个维修单，发单部门（也就是行政部）将维修单提交到客户服务中心，客户服务中心的经办人填写工程单汇总表，然后把维修任务下发到维保部门，主任分配工作给维修工，维修工执行任务，并会同发单部门验收以确认维修完成.
3.当维修完成的时候，这个流程也就结束了.
基于关键信息，我们可以构建如下的流程图，这里我们出于BPM原则，要先把结束事件放在需求方的泳道上.
尽管这个模型有很多问题，但是这个阶段我们要确保客户能毫不费力的理解它，因此做到这样就可以了.
接下来，我们可以开始逐步的纠正这个错误的模型了.
首先是泳池和泳道，根据BPMN的规范要求，每个流程都应当有一个最高的统筹者（这个请自行查阅BPMN规范），负责协调流程中的参与人和系统，但这个流程不是由流程引擎控制的（它是由发起人控制的），因此它目前不存在这么一个协调者，当业主报修时候，无法路由到下一个活动 (如果把分配到下一节点的受让人当成一种路由方式的话，那么这时候其实是流程引擎在当协调者).因此这边应该建模成消息流，另外，应当把业主分配到另一个池里.
我们建模越详细，发现的问题也随之增加，比如，业主如果中途不想维修了，在这个模型下流程是无法"正常"地结束的 ，如果需要满足这个业务需求又不希望通过技术手段生硬的结束，那么就会需要用到边界事件；另外，如果维修工需要用到一些材料的话，他该怎么办，是否需要申请，又向谁申请？
对于战略模型，为了尽可能简单，通常不会使用多个池，除非是像上面这种业主是独立于物业公司之外的情况，可是由于我们的关注点依然应当集中在物业公司的内部流程上，因此接下来讲业主的池进行折叠.
任务经常出现在战略流程模型中，但是子流程很少出现. 在战略流程模型中不会去指定任务的类型，也不使用除了循环之外的标记，因为循环相对来说很容易理解.
子流程应该细化流程模型，在维修流程模型中，我们定义的这些任务，背后可能并不简单，他们可能对应着非常复杂的操作。 但是对于发单人填写登记表这类任务，从我们得到的信息来看，只管填就行了，所以我们就还是把它们当做任务. 基于这些考虑，我们可以得到下面的模型.
我们只是对于可能存在复杂逻辑的任务做一个子任务标记，就足够了.
上面给出的模型，只是基于最常见的情况，对于一些确实有必要做分支的情况，我们就需要用网关来对这类情况进行建模，但一般来说不会在战略流程模型中引入网关.
在战略流程模型中使用的事件类型是有限制的:
空类型可以用在开始，中间，结束事件上，中间事件可以记录流程执行过程中的某个状态，客户也很容易理解.
消息类型和定时类型可以被允许作为开始事件和中间事件使用，因为它们的符号一看就能看懂，很容易理解.
至此战略流程模型就可以结束了。
在操作流程模型中，就可以开始呈现出流程关于人和技术的细节了，这里会涉及到一些问题：
1.对于流程设计者：工作是如何完成的?
2.流程开发人员：需要通过流程引擎来实现什么功能？
3.流程参与人员：该怎么完成自己的工作？
要调和这三个角色并不简单，而这也正是操作流程模型需要做的事情，如果很好的回答了这三个问题，那么就可以得到以下好处：
1.操作流程模型的逻辑，在实际操作和技术实现上是一致的.
2.缩小了业务和技术之间的理解沟通的沟壑，双方以流程模型作为共同语言.
3.藉由流程引擎实现的流程，更易于观测.
在这个层面上的模型，就不像战略流程模型能容忍一些语法上的错误了，我们必须按照规范来进行建模.
除了规范之外，必须实现的还有精确性，因为客户需要根据这个流程模型安排工作，同时，我们也应当尽可能的不让这个流程显得过于复杂，毕竟流程参与者关注的是他们的工作本身而不是BPM，流程对于他们只是一种达到目的的手段.
之前有说到，操作流程模型应当足够精确但又不过于复杂，这听起来可能很矛盾. 为此，我们先作一张表格，来看看操作流程模型在三个角色中的视图是怎样的. 流程参与者只需要关注自己需要怎么做，以及什么时候需要等待其他人完成什么，这样就不会被其他人所做的细节分散掉注意力.
操作层面的流程模型的核心思想，在于区分编排和协作，如之前所讲，每个流程参与者都有自己的一个池.
把流程引擎作为一个单独的池，可以让流程开发者更好的关注它.
流程设计者的角色在这边非常重要，需要非常懂BPMN，并且能够从不同参与者的视角对流程进行建模.
设计者的工序可能如下：
1.审查战略流程模型
2.分割泳道到单独的池
3.在不同参与者的视角下进行建模
4.为技术层面的建模做准备
5.进行技术层面的建模，不一定可执行，目的在于细化模型
6.加上必要的注释
当然这也只是一种经验方法而已，你也可以直接在技术层面开始分析和建模，自下而上.
继续我们的物业维修流程例子，为了简化对于每个流程参与者的模型复杂性，我们需要将物业公司下面的三个参与者泳道都分割到单独的池中，同时，我们也要解决一些显而易见的逻辑上的错误，比如:
1.验收没有联合业主一起
2.省略了仓管这一参与者
3.省略了客服专员的每周汇总和进度督促.
4.业主报修的时候更多是电话申报
这里最大的难点在于，由于存在代发起的情况，我们很难把业主的池和接线员的池完全隔离开，虽然在流程引擎的层面上可以用两个流程变量来解决问题（发起人，拥有人），但是在模型展示的层面上这种办法是没法很好的表达出意思的，而且也会增加开发的工作量，因此我们可以采用多个开始事件的形式，来对这一情况进行建模.
这就是将流程参与者分割到单独的池后的模型图，这里依然存在一些问题，比如我们还没有对维修项目做分级，验收未通过的话怎么调整参数等等，但这一步我们也只是澄清各个流程参与者之间的关系，没必要过于深究.
从这一步开始，往往就需要与流程参与人员进行更详细的交流了.
从业主开始，我们可以看到业主相关的参与者有接线员，行政部门和机电维修部门，此时我们可以把这两者的池进行折叠.
根据我们已知的业务场景：
如果业主申报的维修项目是有偿服务，需要由客服与其进行再次确认
如果涉及付费服务，业主需要有一个付款的操作
在更深一步的考虑之后，我们发现业主池还会涉及到客服部门，最终我们得到如下模型.
行政部门的流程比较简单，涉及到的其他池有业主和客户服务中心:
客户服务中心这边应当注意，在客户给出的传统流程图中，有提到定时性质的统计和催促的任务，这种情况我们应当将它作为另一个单独的流程模型，与当前的维修流程模型区分开来.
通过调研可以发现，客户服务中心这边往往在完成物业服务之后还会有一次回访调研的过程，因此在维修结束，确认业主验收完成后，我们也应当加上回访的过程，但是回访并不存在于某个特定的流程中，因此我们在此处暂时省略，后续作为一个独立的流程进行建模.
另外，客户服务中心还需要在派单之前与业主进行事前沟通，需要有一定的规则来给维修事项进行分级：
1.是小修，中修，还是大修？
2.是否需要收费？
经过调研我们可以了解到:
三种类型的维修都有可能会需要收费
中修和大修往往还需要经过额外的审批流程才能继续.
我把维修项目评估任务放在了这里，是因为客服联系业主之前需要知道维修的价格以及其他情况.
机电维修部这边应当考虑以下因素：
主管分配工作的细节
1.是否应当记录返工次数？
2.区分不同级别的维修项目
主管分配工作这个任务的前置条件是收到维修需求，确切的说，是收到由客户服务中心填写的工程单汇总表，当前表中已存在的属性可能有客户的姓名，维修地址，联系电话，维修内容，预约时间等.
主管此时需要根据已知的情况，判断当前的维修方案是否需要走额外的审批流程， 而这个流程，应当与当前的维修流程独立开来. 至于这个额外的流程有着怎么样的过程，目前我无法得知，因此依然用一个子流程来代替.
仓管这边需要考虑验收没有通过的情况下，流程如何进行？ 这里的验收事实上应当是物料仓库的验收，与维修流程无关，但是客户往往无法清晰的表达出来这层意思. 因此这边应当暂时省略验收这个步骤， 作为一个独立的物料仓检流程在下一步的时候进行建模.
最后是接线员，接线员的流程比较简单，接到电话报修后填写维修单就可以:
之前都是讲的人与人之间的流程，从这步开始引入流程引擎，原因之前也提及过，开发者需要知道他们要用流程引擎来做些什么事情，因此这个步骤也会添加包括技术实现上的更多细节，比如对于业主是否已经付款的校验.，但第一版的技术流程模型 不一定是可执行的 .
第一版的技术流程模型如下：
再接下来的设计，就需要考虑更多外部因素了，如果我们发现维修流程中，某个泳道的流程能够被其他的流程模型复用，我们就需要将他们抽离并单独部署，如果我们满足于将这个庞大的维修流程进行单独部署，那我们可能还需要再做更多的修改，尤其是事件类型上（消息事件的用法在这里是违反BPMN规范的，如果部署在同一个流程定义中的话，更适合的是条件事件），情况不同，我们后续的设计和实现也会非常不一样.
对于当前这个维修流程，我更倾向于将所有流程都分开设计和实现，主要理由有如下几点：
1.一个庞大的模型，它的版本迁移过程往往非常复杂，如果将它进行恰当的分解，那么我们只需要对发生了变动的部分进行迁移即可，可以有效的降低迁移成本
2.对于开发者来说，庞大的或者过于复杂的模型会导致理解和开发成本迅速上升，而且一个单体模型，几乎只能由一个开发者来负责，不适合多人协作，而分解的手段可以将一个单体复杂模型分解成多个简单、可独立开发的流程模型，可以提升开发效率和降低理解难度.
3.对于企业工作流来说，多个工作流之间经常会存在共通的部分，就像这里的物业服务的回访流程，将这些公共部分剥离出来，长远来看，可以提升模型的复用率，从而提升开发效率.
但是这种方案的缺点也是显而易见的，主要有:
1.分解到什么程度并不那么容易把握，虽然按照经验来说往往是分解到每一个流程参与者，但在有些时候也可以将一些任务比较简单的参与者流程进行合并.
2.为了实现流程实例之间的通信，往往会存在较多的消息/信号事件或者调用活动，要求开发者对BPMN中的事件有足够的了解
3.流程走向的观测可能会比较繁琐，因为需要在多个流程实例之间来回切换观察
下面给出第一版的技术流程实现，它依然还有很多值得改进的地方，比如支付流程的分离和异常处理，维修主管分配任务的自动化规则，接线员流程的规则化（使用规则任务来根据输入参数判断该发送什么类型的消息事件，可能是代填维修单，也可能是代填其他的表单），但出于成本考虑我们不可能就第一版的实现去无止尽的细化：
https://github.com/LLLLimbo/camunda-demo.git
而一个框架内的事件引擎需要实现哪些基本的功能呢？
让我们来看一下fs的事件引擎是如何实现的。
centos：CentOS release 7.0 (Final)或以上版本
freeswitch：v1.8.7
GCC：4.8.5
fs中event事件的实现主要在以下俩个文件。
src\include\switch_event.h
src\switch_event.c
涉及到的主要结构体如下
其中switch_event是传递事件消息的结构体，switch_event_node则是记录事件回调的结构体。
struct switch_event_header {
/*!the header name */
char*name;
/*!the header value */
char*value;
/*!array space */
char**array;
/*!array index */
intidx;
/*!hash of the header name */
unsignedlong hash;
structswitch_event_header *next;
};
struct switch_event {
/*!the event id (descriptor) */
switch_event_types_tevent_id;
/*!the priority of the event */
switch_priority_tpriority;
/*!the owner of the event */
char*owner;
/*!the subclass of the event */
char*subclass_name;
/*!the event headers */
switch_event_header_t*headers;
/*!the event headers tail pointer */
switch_event_header_t*last_header;
/*!the body of the event */
char*body;
/*!user data from the subclass provider */
void*bind_user_data;
/*!user data from the event sender */
void*event_user_data;
/*!unique key */
unsignedlong key;
structswitch_event *next;
intflags;
};
struct switch_event_node {
/*!the id of the node */
char*id;
/*!the event id enumeration to bind to */
switch_event_types_tevent_id;
/*!the event subclass to bind to for custom events */
char*subclass_name;
/*!a callback function to execute when the event is triggered */
switch_event_callback_tcallback;
/*!private data */
void*user_data;
structswitch_event_node *next;
};
struct switch_event_subclass {
/*!the owner of the subclass */
char*owner;
/*!the subclass name */
char*name;
/*!the subclass was reserved by a listener so it's ok for a module to reserve itstill */
intbind;
};
总图
src\include\switch_event.h 文件中，常用的接口列表
//事件引擎初始化接口
switch_event_init
switch_event_shutdown
//事件发布者接口
switch_event_create_subclass
switch_event_add_header
switch_event_destroy
switch_event_fire
//事件订阅者接口
switch_event_bind
switch_event_get_header
事件引擎是一个典型的PUB/SUB模型，发布者负责发布事件消息，事件引擎提供消息通道和转发，订阅者注册消息回调函数，由事件引擎根据事件消息调用回调函数，处理业务逻辑。
事件引擎模型图
函数原型
SWITCH_DECLARE(switch_status_t)switch_event_init(switch_memory_pool_t *pool)
函数逻辑
[if !supportLists]1， [endif]全局变量初始化。MAX_DISPATCH的大小范围是（2，(cpu核数/2)+1）。
[if !supportLists]2， [endif]初始化事件分发的消息队列EVENT_DISPATCH_QUEUE。
[if !supportLists]3， [endif]启动1个事件分发线程，执行线程函数“switch_event_dispatch_thread”。线程函数中监听EVENT_DISPATCH_QUEUE消息队列，并根据消息类型执行注册的回调函数。
[if !supportLists]4， [endif]设置全局变量SYSTEM_RUNNING = 1。
事件引擎初始化后的内存模型图
函数原型
SWITCH_DECLARE(switch_status_t)switch_event_shutdown(void)
函数逻辑：
[if !supportLists]1， [endif]设置全局变量SYSTEM_RUNNING = 0。
[if !supportLists]2， [endif]向EVENT_CHANNEL_DISPATCH_QUEUE发送NULL包，通知channel分发线程结束处理。
[if !supportLists]3， [endif]向EVENT_DISPATCH_QUEUE发送n个NULL包，n的数量由dispatch分发线程数目决定，通知dispatch分发线程结束处理。
[if !supportLists]4， [endif]等待所有的EVENT_DISPATCH_QUEUE_THREADS线程结束退出。
[if !supportLists]5， [endif]清空EVENT_DISPATCH_QUEUE队列，销毁所有未处理完的event。
[if !supportLists]6， [endif]遍历CUSTOM_HASH，清理所有subclass注册。
[if !supportLists]7， [endif]如果支持事件回收，清理事件回收队列的内存。
[if !supportLists]8， [endif]处理结束。
函数原型
SWITCH_DECLARE(switch_status_t) switch_event_create_subclass_detailed(constchar *file, const char *func, int line,
switch_event_t **event, switch_event_types_tevent_id, const char *subclass_name);
#define switch_event_create_subclass(_e,_eid, _sn) switch_event_create_subclass_detailed(__FILE__, (const char *)__SWITCH_FUNC__, __LINE__, _e, _eid, _sn)
函数逻辑：
[if !supportLists]1， [endif]如果支持事件回收，从回收队列获取一个事件。不支持则重新分配一个新的事件。
[if !supportLists]2， [endif]事件预处理，添加固定头域格式。
[if !supportLists]3， [endif]处理“subclass_name”对应头域。
新创建的事件的内存模型如图
函数原型
SWITCH_DECLARE(switch_status_t) switch_event_add_header(switch_event_t*event, switch_stack_t stack, const char *header_name, const char *fmt, ...)
函数逻辑：
[if !supportLists]1， [endif]获取参数列表。
[if !supportLists]2， [endif]获取一个头域结构体header。
[if !supportLists]3， [endif]header结构体赋值。
[if !supportLists]4， [endif]将header添加到“event-headers”中。
增加头域后的事件的内存模型如图
函数原型
SWITCH_DECLARE(void)switch_event_destroy(switch_event_t **event)
函数逻辑：
[if !supportLists]1， [endif]遍历”hp = event-headers”，如果“hp-array”不为空，先循环释放“hp-array[i]”内存，然后释放“hp-array”内存，再释放“hp-name”和“hp-value”和“hp”，“hp”的释放需要判断事件循环使用标识。
[if !supportLists]2， [endif]释放“event-body”和“event-subclass_name”。
[if !supportLists]3， [endif]根据事件循环使用标识，判断是否释放“event”。事件循环使用则把“event”发送到队列“EVENT_RECYCLE_QUEUE”。
[if !supportLists]4， [endif]处理结束。
函数原型
SWITCH_DECLARE(switch_status_t)switch_event_fire_detailed(const char *file, const char *func, int line,switch_event_t **event, void *user_data);
#define switch_event_fire(event)switch_event_fire_detailed(__FILE__, (const char * )__SWITCH_FUNC__, __LINE__,event, NULL)
函数逻辑：
[if !supportLists]1， [endif]参数校验
[if !supportLists]2， [endif]检查EVENT_DISPATCH_QUEUE队列大小，如果队列满了，则对当前dispatch线程数和MAX_DISPATCH比较，并增加新的dispatch分发线程。
[if !supportLists]3， [endif]将事件event推送到EVENT_DISPATCH_QUEUE中。
[if !supportLists]4， [endif]处理结束。
事件较多时，事件引擎的线程模型如图
函数原型
SWITCH_DECLARE(switch_status_t)switch_event_bind(const char *id, switch_event_types_t event, const char*subclass_name,
switch_event_callback_t callback, void*user_data)
函数逻辑：
[if !supportLists]1， [endif]参数校验。
[if !supportLists]2， [endif]检查subclass_name，针对不同的subclass owner，添加一个新节点到CUSTOM_HASH。
[if !supportLists]3， [endif]分配新内存块event_node，对event_node初始化，绑定事件回调函数。
[if !supportLists]4， [endif]将event_node插入EVENT_NODES[event]节点下的链表头部。
[if !supportLists]5， [endif]处理结束。
事件绑定后的内存模型如图
函数原型
_Ret_opt_z_ SWITCH_DECLARE(char *)switch_event_get_header_idx(switch_event_t *event, const char *header_name, intidx);
#define switch_event_get_header(_e, _h)switch_event_get_header_idx(_e, _h, -1)
函数逻辑：
[if !supportLists]1， [endif]对header_name执行默认HASH函数（TIME33算法），得到hash值。
[if !supportLists]2， [endif]遍历hp = event-headers，查找到满足条件“((!hp-hash
|| hash == hp-hash) !strcasecmp(hp-name, header_name))”的头域，则返回”hp-value”。
[if !supportLists]3， [endif]如果header_name的值为“_body”，则返回“event-body”。
[if !supportLists]4， [endif]匹配失败，返回NULL。
freeswitch可以通过设置全局变量“events-use-dispatch”的值，来控制事件分发的模式。
默认情况下“events-use-dispatch=1”，使用dispatch模式分发事件，dispatch线程数量大小范围为（2，（cpu/2）+1）。
当“events-use-dispatch=0”时，使用线程池模式分发事件。
fs的事件可以设置为循环使用，处理会有小的区别，主要在回收事件时会将事件的内存保留在循环队列中，方便循环使用，提高内存使用效率。
空空如常
求真得真
本文目录一览：
- 1、流程引擎是什么吗？跟工作流引擎是一个意思吗？有对应的学习资料吗？
- 2、流程引擎Camunda开发记录（二）上
- 3、BPMN建模方法论
- 4、ITSM系统全称是什么？
- 5、freeswitch的事件引擎实现分析
- 6、工作流引擎哪家好？
流程引擎是什么吗？跟工作流引擎是一个意思吗？有对应的学习资料吗？
工流程引擎和工作流引擎同一个意思，指“业务过程的部分或整体在计算机应用环境下的自动化”。是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。在计算机中，工作流属于计算机支持的协同工作（CSCW）的一部分。后者是普遍地研究一个群体如何在计算机的帮助下实现协同工作的。工作流主要解决的主要问题是：为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。
工作流概念起源于生产组织和办公自动化领域，是针对日常工作中具有固定程序活动而提出的一个概念，目的是通过将工作分解成定义良好的任务或角色，按照一定的规则和过程来执行这些任务并对其进行监控，达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。尽管工作流已经取得了相当的成就，但对工作流的定义还没有能够统一和明确。
Georgakopoulos给出的工作流定义是：工作流是将一组任务组织起来以完成某个经营过程：定义了任务的触发顺序和触发条件，每个任务可以由一个或多个软件系统完成，也可以由一个或一组人完成，还可以由一个或多个人与软件系统协作完成。
1993年工作流管理联盟(Workflow Management Coalition，WfMC)作为工作流管理的标准化组织而成立，标志着工作流技术逐步走向成熟。WfMC对工作流给出定义为：工作流是指一类能够完全自动执行的经营过程，根据一系列过程规则，将文档、信息或任务在不同的执行者之间进行传递与执行，而符合这一流程规范的公司比较少，现在做的比较好的就是天翎了。
流程引擎Camunda开发记录（二）上
Camunda的使用有两种方法，一种是JAVA API，一种是RESET API个人理解JAVA API是从上到下通过JAVA类一级一级调用，RESET API则是从下到上通过注解+接口一层一层实现，如果你只是使用Camunda实现一些简单的操作，用JAVA API就能满足。
有时候我们需要在部署直接做一些校验，那么可以利用下面这个静态方法： BpmnModelInstance modelInstance = Bpmn.readModelFromStream(is)
通过BpmnModelInstance我们可以做一些简单或者深入的判断，比如判断流程有没有结束事件：
modelInstance.getModelElementsByType(EndEvent.class).isEmpty()
判断启动任务有没有设置表单
（1）查看单个流程
（2）查看流程定义列表
流程定义key值相同的情况下，版本是从1开始逐次升级的，流程定义的id是【key：版本：生成ID】
流程定义key值可以理解为，一个流程只有1个固定key值，你每修改一次流程定义，key值不变，但流程ID，版本号会改变，流程ID会重新生成，版本号会在之前基础上加1；
.latestVersion() 实际是通过key值对列表进行了过滤，只保留最后一版的流程定义。
（3）获取流程定义的文件资源-XML
（4）获取流程
BPMN建模方法论
BPMN（业务流程管理）是一种用于捕获、设计、执行、记录、测量、监控和控制自动化以及非自动化流程，以满足公司的目标和业务策略的系统方法。通过BPMN，流程可以与业务战略保持一致，藉由业务部门内部甚至超越公司边界的流程优化，有助于提高公司的运转效率。
BPMN在国内的应用很广泛，但很多企业花费大价钱购买了第三方的流程平台，却没有得到相应的收益；我认为其根本原因还是在于对BPMN本身的理解不足——它远没有看上去那么简单，仅仅是BPMN2.0版本规范文档就已经达到了500页。
因此，在我看来，要想顺利的实施BPMN，一个对它有透彻理解的设计者是必不可少的；同时，设计者还需要兼具业务思维、管理思维，和一定的技术思维。
本文以一个物业维修流程为例，目的在于介绍一个系统的BPMN建模方法，为刚刚踏入这个领域的人提供一个方向和选择。
这是一个典型的物业维修流程，这个流程提供的信息量很少，以至于如果我们要仅仅基于此去设计一个完善的BPMN流程是几乎不可能的，但是即便是最专业的物业管理师，这也是他们仅能提供的流程图了.
为了达到我们的目标，我们需要先建立一个战略层面上的流程，它可能很粗糙，但是它的目的并不是在初期就呈现一个完整详细的视图.
它的作用可能有如下几点:
1.澄清什么是，和什么不是这个流程的一部分
2.为流程确定资源和分配责任
3.确定关键绩效指标并明确其特征
4.在对流程着手优化前先对其进行一个大致的回顾
体积：战略流程模型应当尽可能小，流元素最好不要超过10个，如果一个流程横跨几张纸的话，是没人能理解得了的.
语法：尽可能正确，但是在必要时可以不那么严谨
想要对一个流程进行初步建模，往往比想象的要难得多，有时手头有充足的资料和标准的操作流程可以用，那会好些，但大多数时候都不得不去与客户深入交流.
当产品去和客户开会沟通时，我能很容易的想象到下面的景象——当你只画了一个圈两个矩形：
客户参会人员：
我们的维修流程并不总是这样从业主填写维修单开始的，业主也可能是电话报修
如果维修的工程量比较大的话，我们还得先提出方案，然后交给公司领导审批
如果过了保修期的话，那我们还要收钱的
业主如果是预约的话，我们还得根据他预约时间安排工作
并不一定是业主报修，也可能是在物业巡检的时候发现问题，由巡检员报修
..........
..........
..........
如果没有一个狠人来主持会议的话，产品会很容易迷失方向，也会导致客户的参会人员对你的方案失去兴趣，更差的情况是，其他人糊里糊涂地对一个错误的模型达成了一致.
所以主持会议的人，需要在开始的时候先声明好：所有的流程模型都是不完整的，但是它依然有一些作用.
在一开始找出每一种可能性是不可能的，在这次会议开始前，就应当告诉客户，这第一次的迭代目标是什么.
1.我们要记录流程从开始到结束的过程
2.我们最多只记录这个流程的N个步骤
3.我们只记录这个流程的标准形式
如果会议期间仍有人想跳出圈定的范围，应当立刻阻止.
下面回到正题——物业维修流程.
基于上面的传统流程图，我们可以得到以下信息：
1.这个流程往往是由业主有维修需求引起
2.发起人填写一个维修单，发单部门（也就是行政部）将维修单提交到客户服务中心，客户服务中心的经办人填写工程单汇总表，然后把维修任务下发到维保部门，主任分配工作给维修工，维修工执行任务，并会同发单部门验收以确认维修完成.
3.当维修完成的时候，这个流程也就结束了.
基于关键信息，我们可以构建如下的流程图，这里我们出于BPM原则，要先把结束事件放在需求方的泳道上.
尽管这个模型有很多问题，但是这个阶段我们要确保客户能毫不费力的理解它，因此做到这样就可以了.
接下来，我们可以开始逐步的纠正这个错误的模型了.
首先是泳池和泳道，根据BPMN的规范要求，每个流程都应当有一个最高的统筹者（这个请自行查阅BPMN规范），负责协调流程中的参与人和系统，但这个流程不是由流程引擎控制的（它是由发起人控制的），因此它目前不存在这么一个协调者，当业主报修时候，无法路由到下一个活动 (如果把分配到下一节点的受让人当成一种路由方式的话，那么这时候其实是流程引擎在当协调者).因此这边应该建模成消息流，另外，应当把业主分配到另一个池里.
我们建模越详细，发现的问题也随之增加，比如，业主如果中途不想维修了，在这个模型下流程是无法"正常"地结束的 ，如果需要满足这个业务需求又不希望通过技术手段生硬的结束，那么就会需要用到边界事件；另外，如果维修工需要用到一些材料的话，他该怎么办，是否需要申请，又向谁申请？
对于战略模型，为了尽可能简单，通常不会使用多个池，除非是像上面这种业主是独立于物业公司之外的情况，可是由于我们的关注点依然应当集中在物业公司的内部流程上，因此接下来讲业主的池进行折叠.
任务经常出现在战略流程模型中，但是子流程很少出现. 在战略流程模型中不会去指定任务的类型，也不使用除了循环之外的标记，因为循环相对来说很容易理解.
子流程应该细化流程模型，在维修流程模型中，我们定义的这些任务，背后可能并不简单，他们可能对应着非常复杂的操作。 但是对于发单人填写登记表这类任务，从我们得到的信息来看，只管填就行了，所以我们就还是把它们当做任务. 基于这些考虑，我们可以得到下面的模型.
我们只是对于可能存在复杂逻辑的任务做一个子任务标记，就足够了.
上面给出的模型，只是基于最常见的情况，对于一些确实有必要做分支的情况，我们就需要用网关来对这类情况进行建模，但一般来说不会在战略流程模型中引入网关.
在战略流程模型中使用的事件类型是有限制的:
空类型可以用在开始，中间，结束事件上，中间事件可以记录流程执行过程中的某个状态，客户也很容易理解.
消息类型和定时类型可以被允许作为开始事件和中间事件使用，因为它们的符号一看就能看懂，很容易理解.
至此战略流程模型就可以结束了。
在操作流程模型中，就可以开始呈现出流程关于人和技术的细节了，这里会涉及到一些问题：
1.对于流程设计者：工作是如何完成的?
2.流程开发人员：需要通过流程引擎来实现什么功能？
3.流程参与人员：该怎么完成自己的工作？
要调和这三个角色并不简单，而这也正是操作流程模型需要做的事情，如果很好的回答了这三个问题，那么就可以得到以下好处：
1.操作流程模型的逻辑，在实际操作和技术实现上是一致的.
2.缩小了业务和技术之间的理解沟通的沟壑，双方以流程模型作为共同语言.
3.藉由流程引擎实现的流程，更易于观测.
在这个层面上的模型，就不像战略流程模型能容忍一些语法上的错误了，我们必须按照规范来进行建模.
除了规范之外，必须实现的还有精确性，因为客户需要根据这个流程模型安排工作，同时，我们也应当尽可能的不让这个流程显得过于复杂，毕竟流程参与者关注的是他们的工作本身而不是BPM，流程对于他们只是一种达到目的的手段.
之前有说到，操作流程模型应当足够精确但又不过于复杂，这听起来可能很矛盾. 为此，我们先作一张表格，来看看操作流程模型在三个角色中的视图是怎样的. 流程参与者只需要关注自己需要怎么做，以及什么时候需要等待其他人完成什么，这样就不会被其他人所做的细节分散掉注意力.
操作层面的流程模型的核心思想，在于区分编排和协作，如之前所讲，每个流程参与者都有自己的一个池.
把流程引擎作为一个单独的池，可以让流程开发者更好的关注它.
流程设计者的角色在这边非常重要，需要非常懂BPMN，并且能够从不同参与者的视角对流程进行建模.
设计者的工序可能如下：
1.审查战略流程模型
2.分割泳道到单独的池
3.在不同参与者的视角下进行建模
4.为技术层面的建模做准备
5.进行技术层面的建模，不一定可执行，目的在于细化模型
6.加上必要的注释
当然这也只是一种经验方法而已，你也可以直接在技术层面开始分析和建模，自下而上.
继续我们的物业维修流程例子，为了简化对于每个流程参与者的模型复杂性，我们需要将物业公司下面的三个参与者泳道都分割到单独的池中，同时，我们也要解决一些显而易见的逻辑上的错误，比如:
1.验收没有联合业主一起
2.省略了仓管这一参与者
3.省略了客服专员的每周汇总和进度督促.
4.业主报修的时候更多是电话申报
这里最大的难点在于，由于存在代发起的情况，我们很难把业主的池和接线员的池完全隔离开，虽然在流程引擎的层面上可以用两个流程变量来解决问题（发起人，拥有人），但是在模型展示的层面上这种办法是没法很好的表达出意思的，而且也会增加开发的工作量，因此我们可以采用多个开始事件的形式，来对这一情况进行建模.
这就是将流程参与者分割到单独的池后的模型图，这里依然存在一些问题，比如我们还没有对维修项目做分级，验收未通过的话怎么调整参数等等，但这一步我们也只是澄清各个流程参与者之间的关系，没必要过于深究.
从这一步开始，往往就需要与流程参与人员进行更详细的交流了.
从业主开始，我们可以看到业主相关的参与者有接线员，行政部门和机电维修部门，此时我们可以把这两者的池进行折叠.
根据我们已知的业务场景：
如果业主申报的维修项目是有偿服务，需要由客服与其进行再次确认
如果涉及付费服务，业主需要有一个付款的操作
在更深一步的考虑之后，我们发现业主池还会涉及到客服部门，最终我们得到如下模型.
行政部门的流程比较简单，涉及到的其他池有业主和客户服务中心:
客户服务中心这边应当注意，在客户给出的传统流程图中，有提到定时性质的统计和催促的任务，这种情况我们应当将它作为另一个单独的流程模型，与当前的维修流程模型区分开来.
通过调研可以发现，客户服务中心这边往往在完成物业服务之后还会有一次回访调研的过程，因此在维修结束，确认业主验收完成后，我们也应当加上回访的过程，但是回访并不存在于某个特定的流程中，因此我们在此处暂时省略，后续作为一个独立的流程进行建模.
另外，客户服务中心还需要在派单之前与业主进行事前沟通，需要有一定的规则来给维修事项进行分级：
1.是小修，中修，还是大修？
2.是否需要收费？
经过调研我们可以了解到:
三种类型的维修都有可能会需要收费
中修和大修往往还需要经过额外的审批流程才能继续.
我把维修项目评估任务放在了这里，是因为客服联系业主之前需要知道维修的价格以及其他情况.
机电维修部这边应当考虑以下因素：
主管分配工作的细节
1.是否应当记录返工次数？
2.区分不同级别的维修项目
主管分配工作这个任务的前置条件是收到维修需求，确切的说，是收到由客户服务中心填写的工程单汇总表，当前表中已存在的属性可能有客户的姓名，维修地址，联系电话，维修内容，预约时间等.
主管此时需要根据已知的情况，判断当前的维修方案是否需要走额外的审批流程， 而这个流程，应当与当前的维修流程独立开来. 至于这个额外的流程有着怎么样的过程，目前我无法得知，因此依然用一个子流程来代替.
仓管这边需要考虑验收没有通过的情况下，流程如何进行？ 这里的验收事实上应当是物料仓库的验收，与维修流程无关，但是客户往往无法清晰的表达出来这层意思. 因此这边应当暂时省略验收这个步骤， 作为一个独立的物料仓检流程在下一步的时候进行建模.
最后是接线员，接线员的流程比较简单，接到电话报修后填写维修单就可以:
之前都是讲的人与人之间的流程，从这步开始引入流程引擎，原因之前也提及过，开发者需要知道他们要用流程引擎来做些什么事情，因此这个步骤也会添加包括技术实现上的更多细节，比如对于业主是否已经付款的校验.，但第一版的技术流程模型 不一定是可执行的 .
第一版的技术流程模型如下：
再接下来的设计，就需要考虑更多外部因素了，如果我们发现维修流程中，某个泳道的流程能够被其他的流程模型复用，我们就需要将他们抽离并单独部署，如果我们满足于将这个庞大的维修流程进行单独部署，那我们可能还需要再做更多的修改，尤其是事件类型上（消息事件的用法在这里是违反BPMN规范的，如果部署在同一个流程定义中的话，更适合的是条件事件），情况不同，我们后续的设计和实现也会非常不一样.
对于当前这个维修流程，我更倾向于将所有流程都分开设计和实现，主要理由有如下几点：
1.一个庞大的模型，它的版本迁移过程往往非常复杂，如果将它进行恰当的分解，那么我们只需要对发生了变动的部分进行迁移即可，可以有效的降低迁移成本
2.对于开发者来说，庞大的或者过于复杂的模型会导致理解和开发成本迅速上升，而且一个单体模型，几乎只能由一个开发者来负责，不适合多人协作，而分解的手段可以将一个单体复杂模型分解成多个简单、可独立开发的流程模型，可以提升开发效率和降低理解难度.
3.对于企业工作流来说，多个工作流之间经常会存在共通的部分，就像这里的物业服务的回访流程，将这些公共部分剥离出来，长远来看，可以提升模型的复用率，从而提升开发效率.
但是这种方案的缺点也是显而易见的，主要有:
1.分解到什么程度并不那么容易把握，虽然按照经验来说往往是分解到每一个流程参与者，但在有些时候也可以将一些任务比较简单的参与者流程进行合并.
2.为了实现流程实例之间的通信，往往会存在较多的消息/信号事件或者调用活动，要求开发者对BPMN中的事件有足够的了解
3.流程走向的观测可能会比较繁琐，因为需要在多个流程实例之间来回切换观察
下面给出第一版的技术流程实现，它依然还有很多值得改进的地方，比如支付流程的分离和异常处理，维修主管分配任务的自动化规则，接线员流程的规则化（使用规则任务来根据输入参数判断该发送什么类型的消息事件，可能是代填维修单，也可能是代填其他的表单），但出于成本考虑我们不可能就第一版的实现去无止尽的细化：
https://github.com/LLLLimbo/camunda-demo.git
ITSM系统全称是什么？
ITSM，即：IT服务管理（IT service management 简写ITSM），是IT团队向其最终用户提供:设计、交付、管理和改善等所有IT服务的过程。ITSM致力于使IT流程和服务与业务目标保持一致，从而帮助组织更好地发展。
ITSM的核心概念是认为IT应该作为服务交付。ITSM最常见的场景是请求新硬件，例如：笔记本电脑。假设您要申请一台笔记本电脑，您需要在指定的地方提交请求，填写相关信息的工单，之后就开始对应的工作流程（这种工作流程是可重复的）。然后，故障单将落在IT团队的队列中，在故障单的队列中，传入的请求会根据重要性进行排序和处理。
人们经常将ITSM误解为基本的IT支持。相反，ITSM团队负责监督各种工作场所技术，从便携式计算机到服务器，再到关键业务软件应用程序。
IT行业中存在一个共同的思路，即正确的ITSM方法应按以下顺序执行三个步骤：
1）构建和实施IT技术。
2）引入并执行正确的流程。
3）人们可以学习技术并遵守流程。
团队是第一位的。IT团队应该不断学习和改进，以促进团队改善工作方式。IT团队无需回答分层报告结构或严格流程所强加的规则，而是可以就采用SLA和要实施的软件等方面做出明智的决策。由于IT团队可以实现生产力和数字化转型，因此强大的IT团队对于强大的组织至关重要。这样的团队是ITSM流程和技术的中心。
另外，软件和技术应支持团队的实践并扩大其影响。优秀的ITSM软件可通过跨团队协作帮助IT人员接触组织中的其他人员。它赋予最终用户权力，并使平凡的工作自动化，因此每个人都有更多时间专注于对他们最重要的事情。当ITSM的流程运转良好时，一切都非常顺利，但如果流程被技术阻碍，一切就会变得复杂。ITSM的流程越顺利，越能反映出IT团队的辛勤工作。
一款优秀的ITSM工具能让企业组织事半功倍。ITSM工具的选择上，并不是越贵越好，企业组织需要根据自己的需求和特点，选择适合自己的工具。ManageEngine ServiceDesk Plus 服务台，可根据不同情况配置不同的服务台功能，每个企业都可以选择最适合自己的功能。
参考文献：ITSM初学者指南
freeswitch的事件引擎实现分析
freeswitch是由事件驱动的，fs内部有各种事件来标识状态的变化包括呼叫的变化、配置的变化、号码的变化等等。而一个框架内的事件引擎需要实现哪些基本的功能呢？
让我们来看一下fs的事件引擎是如何实现的。
centos：CentOS release 7.0 (Final)或以上版本
freeswitch：v1.8.7
GCC：4.8.5
fs中event事件的实现主要在以下俩个文件。
src\include\switch_event.h
src\switch_event.c
涉及到的主要结构体如下
其中switch_event是传递事件消息的结构体，switch_event_node则是记录事件回调的结构体。
struct switch_event_header {
/*!the header name */
char*name;
/*!the header value */
char*value;
/*!array space */
char**array;
/*!array index */
intidx;
/*!hash of the header name */
unsignedlong hash;
structswitch_event_header *next;
};
struct switch_event {
/*!the event id (descriptor) */
switch_event_types_tevent_id;
/*!the priority of the event */
switch_priority_tpriority;
/*!the owner of the event */
char*owner;
/*!the subclass of the event */
char*subclass_name;
/*!the event headers */
switch_event_header_t*headers;
/*!the event headers tail pointer */
switch_event_header_t*last_header;
/*!the body of the event */
char*body;
/*!user data from the subclass provider */
void*bind_user_data;
/*!user data from the event sender */
void*event_user_data;
/*!unique key */
unsignedlong key;
structswitch_event *next;
intflags;
};
struct switch_event_node {
/*!the id of the node */
char*id;
/*!the event id enumeration to bind to */
switch_event_types_tevent_id;
/*!the event subclass to bind to for custom events */
char*subclass_name;
/*!a callback function to execute when the event is triggered */
switch_event_callback_tcallback;
/*!private data */
void*user_data;
structswitch_event_node *next;
};
struct switch_event_subclass {
/*!the owner of the subclass */
char*owner;
/*!the subclass name */
char*name;
/*!the subclass was reserved by a listener so it's ok for a module to reserve itstill */
intbind;
};
总图
src\include\switch_event.h 文件中，常用的接口列表
//事件引擎初始化接口
switch_event_init
switch_event_shutdown
//事件发布者接口
switch_event_create_subclass
switch_event_add_header
switch_event_destroy
switch_event_fire
//事件订阅者接口
switch_event_bind
switch_event_get_header
事件引擎是一个典型的PUB/SUB模型，发布者负责发布事件消息，事件引擎提供消息通道和转发，订阅者注册消息回调函数，由事件引擎根据事件消息调用回调函数，处理业务逻辑。
事件引擎模型图
函数原型
SWITCH_DECLARE(switch_status_t)switch_event_init(switch_memory_pool_t *pool)
函数逻辑
[if !supportLists]1， [endif]全局变量初始化。MAX_DISPATCH的大小范围是（2，(cpu核数/2)+1）。
[if !supportLists]2， [endif]初始化事件分发的消息队列EVENT_DISPATCH_QUEUE。
[if !supportLists]3， [endif]启动1个事件分发线程，执行线程函数“switch_event_dispatch_thread”。线程函数中监听EVENT_DISPATCH_QUEUE消息队列，并根据消息类型执行注册的回调函数。
[if !supportLists]4， [endif]设置全局变量SYSTEM_RUNNING = 1。
事件引擎初始化后的内存模型图
函数原型
SWITCH_DECLARE(switch_status_t)switch_event_shutdown(void)
函数逻辑：
[if !supportLists]1， [endif]设置全局变量SYSTEM_RUNNING = 0。
[if !supportLists]2， [endif]向EVENT_CHANNEL_DISPATCH_QUEUE发送NULL包，通知channel分发线程结束处理。
[if !supportLists]3， [endif]向EVENT_DISPATCH_QUEUE发送n个NULL包，n的数量由dispatch分发线程数目决定，通知dispatch分发线程结束处理。
[if !supportLists]4， [endif]等待所有的EVENT_DISPATCH_QUEUE_THREADS线程结束退出。
[if !supportLists]5， [endif]清空EVENT_DISPATCH_QUEUE队列，销毁所有未处理完的event。
[if !supportLists]6， [endif]遍历CUSTOM_HASH，清理所有subclass注册。
[if !supportLists]7， [endif]如果支持事件回收，清理事件回收队列的内存。
[if !supportLists]8， [endif]处理结束。
函数原型
SWITCH_DECLARE(switch_status_t) switch_event_create_subclass_detailed(constchar *file, const char *func, int line,
switch_event_t **event, switch_event_types_tevent_id, const char *subclass_name);
#define switch_event_create_subclass(_e,_eid, _sn) switch_event_create_subclass_detailed(__FILE__, (const char *)__SWITCH_FUNC__, __LINE__, _e, _eid, _sn)
函数逻辑：
[if !supportLists]1， [endif]如果支持事件回收，从回收队列获取一个事件。不支持则重新分配一个新的事件。
[if !supportLists]2， [endif]事件预处理，添加固定头域格式。
[if !supportLists]3， [endif]处理“subclass_name”对应头域。
新创建的事件的内存模型如图
函数原型
SWITCH_DECLARE(switch_status_t) switch_event_add_header(switch_event_t*event, switch_stack_t stack, const char *header_name, const char *fmt, ...)
函数逻辑：
[if !supportLists]1， [endif]获取参数列表。
[if !supportLists]2， [endif]获取一个头域结构体header。
[if !supportLists]3， [endif]header结构体赋值。
[if !supportLists]4， [endif]将header添加到“event-headers”中。
增加头域后的事件的内存模型如图
函数原型
SWITCH_DECLARE(void)switch_event_destroy(switch_event_t **event)
函数逻辑：
[if !supportLists]1， [endif]遍历”hp = event-headers”，如果“hp-array”不为空，先循环释放“hp-array[i]”内存，然后释放“hp-array”内存，再释放“hp-name”和“hp-value”和“hp”，“hp”的释放需要判断事件循环使用标识。
[if !supportLists]2， [endif]释放“event-body”和“event-subclass_name”。
[if !supportLists]3， [endif]根据事件循环使用标识，判断是否释放“event”。事件循环使用则把“event”发送到队列“EVENT_RECYCLE_QUEUE”。
[if !supportLists]4， [endif]处理结束。
函数原型
SWITCH_DECLARE(switch_status_t)switch_event_fire_detailed(const char *file, const char *func, int line,switch_event_t **event, void *user_data);
#define switch_event_fire(event)switch_event_fire_detailed(__FILE__, (const char * )__SWITCH_FUNC__, __LINE__,event, NULL)
函数逻辑：
[if !supportLists]1， [endif]参数校验
[if !supportLists]2， [endif]检查EVENT_DISPATCH_QUEUE队列大小，如果队列满了，则对当前dispatch线程数和MAX_DISPATCH比较，并增加新的dispatch分发线程。
[if !supportLists]3， [endif]将事件event推送到EVENT_DISPATCH_QUEUE中。
[if !supportLists]4， [endif]处理结束。
事件较多时，事件引擎的线程模型如图
函数原型
SWITCH_DECLARE(switch_status_t)switch_event_bind(const char *id, switch_event_types_t event, const char*subclass_name,
switch_event_callback_t callback, void*user_data)
函数逻辑：
[if !supportLists]1， [endif]参数校验。
[if !supportLists]2， [endif]检查subclass_name，针对不同的subclass owner，添加一个新节点到CUSTOM_HASH。
[if !supportLists]3， [endif]分配新内存块event_node，对event_node初始化，绑定事件回调函数。
[if !supportLists]4， [endif]将event_node插入EVENT_NODES[event]节点下的链表头部。
[if !supportLists]5， [endif]处理结束。
事件绑定后的内存模型如图
函数原型
_Ret_opt_z_ SWITCH_DECLARE(char *)switch_event_get_header_idx(switch_event_t *event, const char *header_name, intidx);
#define switch_event_get_header(_e, _h)switch_event_get_header_idx(_e, _h, -1)
函数逻辑：
[if !supportLists]1， [endif]对header_name执行默认HASH函数（TIME33算法），得到hash值。
[if !supportLists]2， [endif]遍历hp = event-headers，查找到满足条件“((!hp-hash
|| hash == hp-hash) !strcasecmp(hp-name, header_name))”的头域，则返回”hp-value”。
[if !supportLists]3， [endif]如果header_name的值为“_body”，则返回“event-body”。
[if !supportLists]4， [endif]匹配失败，返回NULL。
freeswitch可以通过设置全局变量“events-use-dispatch”的值，来控制事件分发的模式。
默认情况下“events-use-dispatch=1”，使用dispatch模式分发事件，dispatch线程数量大小范围为（2，（cpu/2）+1）。
当“events-use-dispatch=0”时，使用线程池模式分发事件。
fs的事件可以设置为循环使用，处理会有小的区别，主要在回收事件时会将事件的内存保留在循环队列中，方便循环使用，提高内存使用效率。
空空如常
求真得真
工作流引擎哪家好？
分享一款JVS开源框架系列-流程引擎「含开源地址」
一、项目简介JVS是面向软件开发团队可以快速实现应用的基础开发框架，采用微服务分布式框架，提供丰富的基础功能，集成众多业务引擎，它灵活性强，界面化配置对开发者友好，底层容器化构建，集合持续化构建。
项目仓库：
https://gitee.com/software-minister/jvs
社区版已开源，在授权情况下支持100%源码同步，支持商用。
二、流程引擎介绍流程引擎本质是解决业务流转过程中，带来的大量的重复的业务逻辑的，通过流程引擎可以缩减大量的业务开发成本，并提供一系列机制确保我们的业务的流畅度与准确性。
目前市面上流程引擎有比较多种：Osworkflow、JBPM、activiti、flowable、Camunda等这几种主流的方案，目前我采用的是可视化交互性更好的流程引擎，下面给大家简单介绍下：
1、新建了流程，设置好相关条件，点击设计流程
2、流程设计界面
3、流程设置
4、完成发布的流程可以直接在流程申请入口自动生成
5、配置任务节点与条件
6、支持配在线表单
7、跳转表单配置（单独详细介绍表单的配置）
三、 亮点与差异相对业内其他方案，我们的表单引擎具备以下亮点：
青谷工作流系统是一套提供给集成商、软件开发商和最终客户的基础平台软件，它以流程管理和流程应用为核心，通过配置及二次开发，实现流程的自动化处理，系统由流程引擎、设计工具、管理工具和应用工具4 部分组成。流程引擎作为青谷工作流产品的核心组件，具备高内聚、松耦合等特性，并且内置大量接口，方便集成第三方系统。针对国内用户特点，青谷工作流引擎在业内率先提供多角度指定流程办理人、流程流向、办理方式、表单属性自动调整、多路并发、异步流转等多种流程操作手段等功能，充分满足用户实际业务需求。更多功能等您来发现！
雀书的工作流引擎很不错。可以自定义表单，有关联表；可视化流程图编辑器；节点权限控制；规则引擎；自动化引擎；
天翎的工作流引擎就很棒啊！！
从审批路径控制-审批人员控制-批对象权限控制-审批时限控制-批动作控制-审批网关控制-审批通知控制
无死角工作流
来，
看看下面简单的介绍：
审批路径控制
图形化箭头指向，真实模拟流程流转路径；指哪打哪，无论前进还是回退，进入送出均可 条件校验。
审批人员控制
可从组织机构、角色库、页面数据、流程变量和规则脚本等获取审批人；可通过维度内外部多因素单独或联动关系筛选审批人。
批对象权限控制
可对表单字段及操作按钮权限进行详实控制；可按业务规则提供只读、隐藏和修改等权限 设置。
审批时限控制
严格控制审批时限，超时可自动提交或触发指定动作；提供设计模式和脚本模式双重控制机制。
批动作控制
支持单人办理、多人顺序、多人并行、抢占式办理、内部循环、人工合并等处理场景；
除常规操作，主办加签、会办加签、补签意 见、异步提交、指定回退、自由指派、节点
排序、节点互斥、子流程单实例等中式流程操作应有尽有。
审批网关控制
不管是常规流程还是流程嵌套，不管是往前流转还是往后回退都详实控制；到达（聚合、非聚合）、通过（或、且、非）和送出（并行、串行）各个节点严格把关。
审批通知控制
提供待办、已办、抄送等通知窗口，轻松获取发起人、业务名称和关键字段等流程摘要；通知方式灵活多样，包括站内消息中心、邮 件、短信、微信、APP等。
你可以看看这个IBM Business Automation Workflow，下面的文档你可以深入了解一下。
没遇到好用的，看基于什么业务场景
关于事件与流程引擎和规则引擎 流程引擎 区别的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 事件与流程引擎的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于规则引擎 流程引擎 区别、事件与流程引擎的信息别忘了在本站进行查找喔。
相关文章
发表评论
暂时没有评论，来抢沙发吧~