AIOps 一场颠覆传统运维的盛筵
838
2022-12-26
事件流程引擎（事件处理引擎）
本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。
本篇文章给大家谈谈事件流程引擎，以及事件处理引擎对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享事件流程引擎的知识，其中也会对事件处理引擎进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
而一个框架内的事件引擎需要实现哪些基本的功能呢？
让我们来看一下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的事件可以设置为循环使用，处理会有小的区别，主要在回收事件时会将事件的内存保留在循环队列中，方便循环使用，提高内存使用效率。
空空如常
求真得真
个人理解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
本文目录一览：
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的事件可以设置为循环使用，处理会有小的区别，主要在回收事件时会将事件的内存保留在循环队列中，方便循环使用，提高内存使用效率。
空空如常
求真得真
流程引擎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
工作流是什么？工作流引擎又是什么？
工作流主要是工作业务模块需要的对应管理流程，工作流引擎，是为配置相关管理业务流程的工具
工作流的主要组成部分是：
首先看下是否单独的流程引擎，还是要体现中台价值，如果单独的流程引擎，就天翎的平台是使用的是平台模式，把流程嵌入到其他的系统做好门户和单点以及同步组织，实现数据共享和拿到第三方数据，统一呈现：同事支持和满足流程需要的各种吻合国情的审批和流转模式：支持单人办理、多人顺序、多人并行、抢占办理、内部循环、人工合并等场景
n 同时还封装主办加签、会办加签、协办、回退、回撤、子流程、节点跳转等20多种中国式流程操作
支持流程提交、到达、回退、过期、回撤、催办、抄送、到达的提醒设置；
n 支持消息中心、企业微信、钉钉 、邮件、手机短信的接收方式；
工作流引擎有哪些？
工作流引擎作为信息化管理系统事件流程引擎的重要组成部分，经过这么多年发展已经非常成熟，例如jBpm 、bai Werkflow、 XFlow、 Zebra很多开源产品，但是说实话在安全性、稳定性和适用性层面良莠不齐，如果只是业余研究看看无妨，但如果是正儿八经的商用，那还是建议找成熟产品，下面是网上看到一个开源activiti和国内自主研发的流程引擎对比事件流程引擎：
流程引擎/工作流引擎技术对比
自主知识产权、微服务架构，既能单独调用，还能使用其整套开发平台工具（包括表单、视图、报表、门户等等），对中国式业务流程处理更为擅长，我想这是国产流程引擎的优势所在，这也可以通过POC测试进行进一步比对。
特别的我们注意到一个重要行业讯息，及政务单位、国企都在大力推进信创工程，其核心要点就是这些单位、企业必须采用国产化信息系统，保障国家和国企高效办公和信息安全自主可控！
关于事件流程引擎和事件处理引擎的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 事件流程引擎的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于事件处理引擎、事件流程引擎的信息别忘了在本站进行查找喔。
相关文章
发表评论
暂时没有评论，来抢沙发吧~