企业级工作流解决方案(一)--总体介绍

  引言:国内对于流程引擎的介绍非常的少,但是不能否认流程引擎的重要性,流程引擎在各个行业都有应用,OA管理的请假流程、出差流程,项目管理上的合同审批流程、验收流程、启动流程,Erp中的采购流程、入库出库流程,政府里面的招标流程、结算流程等,都有流程引擎的身影,当然这里说的流程指审批意义的流程,还有一些不用人为参与的生产作业生产过程也是可以用工作流来解决的。

  工作了多年,是时候把工作中的一些东西沉淀下来,准备写一系列文章,系统的介绍企业级工作流管理平台的搭建以及设计思路,希望能对其他人有所帮助。这一系列文章基础技术的介绍会比较少一些,多偏向于设计思路以及方案的选型,有问题还请指正。

  先来一张总体的架构设计图

技术方案选型:

  微服务通信采用DotNetty,请求答复消息采用Json-Rpc 2.0格式标准定义,参照了surging的设计,去掉了服务注册,负载均衡等内容,地址:https://github.com/dotnetcore/surging

  基础组件采用的是Abp这套基础组件,这套开发框架出来了多年,社区活跃度一直都比较高,基本上是比较成熟了,国内也有很多文章介绍,大家可以在园子里面找,我这边的做法是把源码下载下来,改成自己的组件,扩展了一些功能,另外,全部舍去他里面zero这套东西。

  流程引擎这块,其实有三种方案选择,第一种就是本文要介绍的自已搭建,基于微软的WWF工作流开发平台来做设计开发的,第二种就是拿开源的流程引擎来改造,但我看了一下,开源的比较优秀的也不多,学习成本也非常之大,第三种就是花钱买别人的,比如K2,再做二次开发,同样学习成本也不小,还要花钱。

  流程引擎设计时采用的Devexpress这套UI工具,把WWF设计器集成到了Winform里面,自定义了各种活动设计界面。

  流程运行时采用WWF运行时持久化这套机制,真正的执行逻辑放到自定义活动里面,流程跟踪采用raphael这个js组件来根据流程运行时数据动态画出来的。

  前端框架采用ng-alain,也就是angular这个方向,工作流管理表单加载用angular动态创建组件实现。

  权限系统这块,没有用abp zore这套了,前端也没有用,自己设计,前端集成到ng-alain。

  关于自定义表单说明,自定义表单已经做了部分设计,参照着k2的smart form来做,这套东西太强大了,主要是ng-alain前端框架对组件的封装并不能满足各种自定义的需求,所以需要对他们做二次封装。地址:https://help.k2.com/onlinehelp/K2smartforms/UserGuide/4.7/default.htm#What_is_K2_smartforms.html%3FTocPath%3D_____1

架构说明

操作系统层

因为.net core不包含wwf,因此,工作流定义时和运行时服务都必须宿主到windows平台下,除去与工作流相关的,其他库都是用的.net standard开发的,可以选择部署到linux平台。

基础设施层

数据库可以选择Sql Server或者Mysql,数据访问采用的是frameworkcore封装的,整个系统多租户支持,读写分离支持。系统中用到了比较多的缓存,缓存部分可以流行的nosql实现。微服务传输通信用的是dotnetty。

基础组件层

基础组件就是用abp这套东西,对里面的配置管理、消息通知、权限认证、验证、Uow访问这块做了修改,增强了部分功能。另外还包括对微服务组件的封装。

应用服务层

应用服务里面的权限系统和基础服务的作用就相当于abp zero的作用,权限数据全部存储到缓存中,因为这部分数据更新频率低,访问量大。流程管理服务封装了业务系统与流程引擎之间的交互,如果第三方系统要与流程引擎对接,也是参照这套封装来做。流程定义时和运行时服务都是与工作流相关的,.net framework平台。业务系统插件就是具体业务所在的位置。

服务宿主层

中小型应用,一般把流程定义时和流程运行时宿主到一个Host,其他所有服务宿主在一起,不同的服务之间调用,走微服务调用这块流程,大型的应用可以把服务拆分开来部署,服务与服务之间的调用可以加nginx做负载均衡。

展现层

ng-alain这套前端开发框架,重写了里面的拦截器和用户认证与abp对接,工作流设计时工具是winform实现的,用于流程定义管理。Mobile暂时没有实现,准备用ng-alain系列实现。

用户层

流程定义一般由系统开发人员或者经过培训的系统管理员来定义,一般不是由用户来做。

第三方访问

第三方接入主要是调用工作流运行时提供的接口,可以参考工作流管理服务实现思路。

系列文章大致目录

微服务

总体架构介绍

消息处理模型之服务端处理

消息处理模型之消息传输通道

消息处理模型之与Abp集成

Tcp消息传输模型之消息编解码

Tcp消息传输模型之服务端处理

Tcp消息传输模型之客户端处理

集成Abp和ng-alain

权限系统

权限系统服务

用户身份认证与权限验证

用户权限验证

数据库读写分离

自动化脚本

Abp其他改造(配置功能补充、signalr消息通信)

T4Template

工作流

工作流实体模型

工作流表单模型

活动-插件模型

工作流设计时之活动介绍

工作流设计时之审批活动

工作流设计时之子流程活动

工作流设计时之流程设计器

工作流设计时之流程定义管理

工作流运行时之流程持久化

工作流运行时之流程跟踪

工作流运行时之创建流程

工作流运行时之流程规则解析

工作流运行时之试运行工作流

工作流运行时之运行工作流

工作流运行时之任务通知

工作流运行时之流程跟踪图

工作流管理之管理框架

工作流管理之与业务表单交互

工作流管理之活动保存、审批、转发、执行下一步骤审批人

工作流管理之任务管理

工作流管理之流程实例管理

系统截图

流程设计

任务分配规则

路由选择规则

子流程活动定义

流程管理

流程跟踪图

流程文档

工作台及新待办通知

流程实例管理

待办邮件

接下来详细介绍,喜欢可以继续,不喜欢,则可跳过。有问题可以QQ或者邮箱交流:邮箱:[email protected],QQ:523477776

原文地址:https://www.cnblogs.com/spritekuang/p/10805440.html

时间: 2024-11-07 18:19:56

企业级工作流解决方案(一)--总体介绍的相关文章

企业级工作流解决方案(二)--微服务总体介绍

微服务好处和概念性的东西就不介绍了,对于微服务,个人认为并不是越复杂就越好,相反要结合自己公司的现状,适当的做一些裁剪,比如对于规模和业务量不是特别大的企业,就没有必要把服务总线,服务健康检查,服务路由选择,熔断等等加进来,相反,这一部分职责可以通过配置文件,nginx代理,api网关等等外围的技术来控制,当企业达到一定的规模之后,再来完善这部分内容,但是对于微服务处理过程来说,没有任何影响. 我这里根据json-rpc 2.0标准,结合网上一些开源的微服务架构思想,采用dotnetty技术,搭

企业级工作流解决方案(五)--微服务消息处理模型之客户端端处理

微服务的服务端已经启动起来了,服务消费者怎么知道服务在哪个地方,通过什么方式调用呢,分布式如何选择正确的服务器调用服务? 这个就涉及到服务发现.服务健康检查的问题了,很多微服务架构的做法都是通过消息队列来实现的,消息队列天生就支持发布订阅功能,服务有变化之后,发布通知,每个消费者更新状态,还涉及到更新服务的metadata信息,同时还涉及到服务健康检查等等一系列功能,其实这些地方是非常容易出问题的地方,但是对于规模流量不是特别巨大的企业,这部分职责可以进行转移,服务的发现就直接通过配置文件实现,

企业级工作流解决方案(三)--微服务消息处理模型之服务端处理

1. Json-Rpc 2.0 参考地址:https://www.jsonrpc.org/specification JSON-RPC是一个无状态且轻量级的远程过程调用(RPC)协议,它允许运行在基于socket,http等诸多不同消息传输环境的同一进程中.其使用JSON(RFC 4627)作为数据格式,它为简单而生. 请求对象 发送一个请求对象至服务端代表一个rpc调用, 一个请求对象包含下列成员: jsonrpc指定JSON-RPC协议版本的字符串,必须准确写为“2.0” method包含所

企业级工作流解决方案(四)--微服务消息处理模型之消息传输通道

消息传输通道我这里只定义了3种,即:localInvoker,HttpInvoker,TcpInvoker,根据实际的情况,还可以进行扩展,比如消息队列,不过这都是后话了,先重点描述一下这3种方式. LocalInvoker 本地调用直接构造请求参数,直接调用服务端的JsonRpcProcessor服务处理执行服务处理过程,这个不多说. HttpInvoker 即执行http请求处理过程,由于.net framework和.net core的运行机制有所不同,处理方式也有所不同,但最终都落到服务

企业级工作流解决方案(九)--微服务Tcp消息传输模型之客户端处理

客户端启动 客户端启动主要做三件事情,1. 从配置文件读取服务调用配置,存储到全局对象中.2. 指定客户端编解码器工厂.3. 预连接,即预先建立与服务端的通信Chanel. [DependsOn(typeof(AbpKernelModule))] public class JsonRpcClientModule : AbpModule { public override void PreInitialize() { // 注册客户端配置,固定从Xml文件读取 SocketClientConfig

企业级工作流解决方案(六)--微服务消息处理模型之与Abp集成

身份认证传递 对于Abp比较熟悉的朋友应该对他里面的用户身份认证比较熟悉,他是通过实现微软提供的权限认证方式实现的,用户登录身份信息存储在System.Security.Claims.ClaimsPrincipal里面,但是用户的身份信息如何在不同的服务之间传递呢,不可能每一个服务都必须实现这套身份认证吧?比如我们请求调用过程如下: Portal站点获取用户信息没有问题,但如何传递到调用的其他微服务呢? 这在之前文章中提到的传输Header就起到了作用,有两种方式可以处理,第一种我们可以直接把a

企业级工作流解决方案(八)--微服务Tcp消息传输模型之服务端处理

服务端启动 服务端启动主要做几件事情,1. 从配置文件读取服务配置(主要是服务监听端口和编解码配置),2. 注册编解码器工厂,3. 启动dotnetty监听端口,4. 读取配置文件,解析全局消息处理模型5. 注册服务端处理对象到容器. JsonRpcServerModule代码如下,见备注说明 [DependsOn(typeof(AbpKernelModule))] public class JsonRpcServerModule : AbpModule { public override vo

企业级工作流解决方案(七)--微服务Tcp消息传输模型之消息编解码

Tcp消息传输主要参照surging来做的,做了部分裁剪和改动,详细参见:https://github.com/dotnetcore/surging Json-rpc没有定义消息如何传输,因此,Json-Rpc RpcRequest对象和RpcResponse对象需要一个传输载体,这里的传输对象主是TransportMessage,如下代码,这里的Content请求时为RcpRequest对象,答复时为RpcResponse对象,答复时Header一般情况下为空. /// <summary>

Hadoop高级编程之为Hadoop实现构建企业级安全解决方案

本章内容提要 ●    理解企业级应用的安全顾虑 ●    理解Hadoop尚未为企业级应用提供的安全机制 ●    考察用于构建企业级安全解决方案的方法 第10章讨论了Hadoop安全性以及Hadoop中用于提供安全控制的机制.当构建企业级安全解决方案(它可能会围绕着与Hadoop数据集交互的许多应用程序和企业级服务)时,保证Hadoop自身的安全仅仅是安全解决方案的一个方面.各种组织努力对数据采用一致的安全机制,而数据是从采用了不同安全策略的异构数据源中提取的.当这些组织从多个源获取数据,接