技术方案选型流程 第1篇
不确定“问题”就无所谓“解”。我们分析了解到电子政务领域的各种活动中，工作流程无处不在。我们系统包括综合办事系统、联合审批系统、社区事件管理等的业务审批，都存在各式各样的业务流程。我们对主要业务流程进行分析，了解各产品部门对流程控制要求。当前工作流程管理、控制上主要存在三大问题：
1、 流程逻辑与其它业务逻辑耦合，对业务流程的修改“伤筋动骨”
2、业务流程可视化程度低，可管理程度低
3、流程过程数据缺乏有效的记录
工作流引擎技术就是主要为解决这三大问题。
技术方案选型流程 第2篇
数据库持久层ORM
Hibernate3
持久化标准
支持JPA规范
支持JPA规范
事务管理
MyBatis机制/Spring事务控制
Bitronix，基于JTA事务管理
数据库连接方式
Jdbc/DataSource
Jdbc/DataSource
支持数据库
Oracle、SQL Server、MySQL等多数数据库
Oracle、SQL Server、MySQL等多数数据库
内部服务通讯
Service间通过API调用
基于Apache Mina异步通讯
集成接口
SOAP、Mule、RESTful
消息通讯
支持的流程格式
BPMN2、xPDL、jPDL等
目前仅只支持BPMN2 xml
引擎核心
PVM（流程虚拟机）
Drools
技术前身
jBPM3、jBPM4
Drools Flow
所属公司
Alfresco
技术方案选型流程 第3篇
这是一块需求高度确定的领域，因此有相应的技术组件，在2020年的时候，进行过技术预研，主要是jbpm和activiti以及由activiti分裂产生的flowable和camunda分支，梳理的发展脉络大致如下： 起源：jBPM3是一个完整的工作流系统实现，面向开发人员。 **发展：**jBPM4引入PVM，使其拥有更强大的扩展性，同时增加BPMS特性，这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。 分裂： 的主创人员Tom Baeyens与合作伙伴在JBPM的未来架构上产生了重大分歧，于是Tom离开了Jboss并加入了Alfresco公司，沿用jBPM4代码，创立了Activiti5。Activiti5基于jBPM4的开源工作流系统，与Alfresco的集成增加了其流程可视化与管理能力，同时通过创新的Activiti Cycle协作组件支持流程相关人员之间的协调，加强了集成能力。 公司完全抛弃了JBPM4的架构，基于Drools Flow进行彻底重构，推出了JBPM5。支持BPMN，通过与Drools的合并支持BAM，通过内容仓库增加对流程可视化的支持。由于放弃了jBPM4的PVM，引擎的可扩展性受到损害，并且不再支持jPDL。 裂变
从各方面收集的资料来看 activiti优于jbpm，jbpm首先出局 flowable优于activiti，即activiti也不再考虑 flowable与camunda之间，能查到资料是camunda更好一些，但缺乏多资料交叉印证。
基于上述情况，activiti主分支已落寞，在camunda和flowable这两个分支中选择了前者。集成原生工作流引擎工作量很大，当时投入了几个月，实现了主要功能，效果不是很满意，以下是当时进行集成开发的设计清单。
后端工作流引擎集成，对我而言完全不是问题。最大的问题在于前端基于的建模，一方面，前端建模组件自身复杂，且资料模糊，很难拿到需要的方法和数据实现功能，反复尝试耗时很长，最终有部分功能采取了后端处理的方式来间接解决；另一方面，activiti（camunda）是一个大而全的组件，定义了流程处理的方方面面，因此流程建模时有大量配置需要设置，包括一些相对晦涩的名称和概念，对建模用户特别是国内用户并不友好。 印象中比较深的是条件边设置，需要流程建模时，选中条件边，然后在表单窗体上，输入表达式，如${contractMoney}>100 0000，友好性差，易出错。
技术方案选型流程 第4篇
在进行技术预研的过程中，技术实现思路得到了启发。主要是找到了仿照钉钉流程建模的开源项目（），技术栈采用的也是vue3+element plus，与当前我的平台一致，实现效果如下： 这种模式，相比于camunda自带的基于规范的流程建模要简洁直观方便多了。
使用它作为流程建模的替代，面临的主要问题，就是如果把上面这个组件输出的json，解析后转换为bpmn协议约定的数据格式。这块自己来实现，通过调用camunda的API来实现转换。
以上方案选择，是综合考虑了各种因素，基于平台现有的前端技术栈（vue3+Element Plus），以及之前投入几个月的camunda后端集成实现，并提供给流程建模人员友好的UI和体验，最终决定的。
工作流是一个大组件，平台集成涉及到大量的开发，接下来开一个集成的子分类，依旧是每周一篇的节奏，敬请期待。
平台名称：一二三开发平台 简介： 企业级通用低代码开发平台 设计资料：CSDN专栏 开源地址：Gitee 开源协议：MIT 欢迎收藏、点赞、评论，你的支持是我前行的动力。
技术方案选型流程 第5篇
结合内部现状和外部发展，我们就可以基本锁定要解决问题范围，进而细化出我们的“解”需要达到的目标与效果。我们要在现有开发平台集成成熟的工作流技术，统一实现业务流程控制逻辑，使业务系统不需要关心业务流程控制，而专注于自身业务功能的开发，加快业务系统的建设。我们要实现目标和效果主要有：
1、 统一控制流程逻辑，使之与业务逻辑脱离
2、 具备开放性和可扩展能力：基于业界标准规范；支持自定义流程，方便与业务表单整合关联。
3、 可视化可管理能力：实时掌握流程状态，图形化展示；业务流程全过程档案，支持统计分析。
4、 快速实施能力：支持流程编排；流程快速部署实施。
技术方案选型流程 第6篇
通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。
前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。
如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。
前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。
那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。。。
实现前后端分离，主要是前端的技术架构变化较大，后端主要变为restfull 风格API，然后加上Swagger技术自动生成在线接口文档就差不多了。
对于目前用于前后端分离方案的前端技术架构主要有两种：
传统SPA指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过reac全家桶、vue全家桶，模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。
单页面应用的运行流程
用户通过浏览器访问网站url
单页面的html文件（）被下载到浏览器，接着下载html里面引用的css，js。
css，js下载到浏览器完成之后，浏览器开始解析执行js向后端服务异步请求数据。
请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。
服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。
它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。
服务端渲染应用的运行流程：
用户通过浏览器访问网站url
NodeJS服务端接收到请求，读取到对应的前端html，css，js。
NodeJS解析执行js向后端API异步请求数据。
NodeJs请求数据完成之后，进行数据绑定、渲染，得到一个最终的html。
NodeJs向浏览器输出html，浏览器进行展示。
PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。
看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？
SPA的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的SEO。
so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：
与传统 SPA (单页应用程序 (Single-Page Application)) 相比，服务器端渲染 (SSR) 的优势主要在于：
请注意，截至目前，Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 loading 图，然后通过 Ajax 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。
无需等待所有的 JavaScript 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应用程序而言，服务器端渲染 (SSR) 至关重要。
技术方案选型流程 第7篇
在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术（jsp），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。否则前端只能当一个“切图仔”，只输出HTML、CSS、以及很少量与业务逻辑无关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。