如何设计一个基于Lotus的可配置的工作流

如何设计一个基于Lotus的可配置的工作流,第1张

要实现流程的“可配置”,即相当于由用户自己“组建”流程,那么,对于程序的开发者,要做的事自然就是一个相反的过程(“拆解”流程)。考虑如何拆解流程能使用户重新组建时省力省心,实际上就是设计一个好用的、可配置的工作流的过程。

清楚了我们要做的事之后,在开始做事之前,我们还需要制定一些做事的原则(“拆解”的原则和方向),毕竟,我们的初衷,不仅仅是能把事做完,把事情做好才是最终目标。那么,什么才是一个好用的可配置的工作流呢?我们认为,好的工作流应包含下面几个特点:组建过程简单、快速,易于维护,用户无需培训、易于掌握等。

制定了上述原则后,我们现在就开始来拆解流程了,首先画一个简单的流程图作为参考。

简单流程图

大致看一下图1中的流程图,先不考虑复杂的内容,我们对一个流程最直观的判断是:流程由环节路径组成。如果仅将流程拆分成这两个元素,对用户来说是非常好理解的。那么下面,我们就尝试使用这两个元素建立可配置的流程。先粗略地拟一下各元素对应的表单需要包含的域:

1、环节文档:环节名称、处理人员

2、路径文档:路径起点环节名称、路径终点环节名称、流转条件

上面两个文档都是配置文档,要建立一个完整的工作流系统,除配置文档之外,我们还要建立一个包含待审批的业务信息的文档(以下称为主文档),主文档要与配置文档相关联,就需要在主文档中记录一些配置文档相关的信息,这里也先粗略地拟一下这些信息:

3、主文档:当前环节、当前用户

相关基础文档建立起来之后,接下来就开始考虑将各个分散的内容连接起来形成一个完整的工作“流”。假设当前主文档处于申请人环节,那么下一个环节是A领导还是B领导呢?从我们现有的配置文档来看,两个环节文档是通过路径文档连接的,那么我们首先要找到以申请人为起点的所有相关路径,搜索结果为:路径1、路径2、路径3都符合要求。接下来就是判断当前文档符合哪一个路径流转的条件即可筛选出唯一确定的一个路径。然后,从唯一确定的路径文档中可获得下一个环节的名称,通过下一个环节的名称搜索环节文档即可获得下一个环节的处理人员。将上述处理过程放大,就可以实现一个任意庞大的流程。

流程流转过程

看上去上面的方案似乎已经完全实现了一个“可配置”的流程,实际如何呢?下面,我们拿一个复杂一点的流程来分析这种方案的优缺点:

有重复环节和路径的流程图

可以看到,“B领导审核”环节和“会计”环节出现了2次,“B领导审核”到“会计”的路径也出现了两次,假设当前环节为“A领导审核”环节,如果通过上面的处理方式,我们搜索到的符合条件的下一个环节是“B领导环节”环节,然而,“B领导环节”以后有2个可能的路径,如果仍按上述方式处理,我们本来要走的路径5可能会走到路径6而导致流程最终无法流经“总经理”环节。为了避免这种情况,我们可以有很多种选择,下面列出了其中的两种:

第1种:将两个“B领导审核”环节命名为不同名称,如其中一个环节名称改为B领导审核2。

第2种:在环节文档中增加一个位置域,标志其所处位置以区别不同位置出现的同一个环节名称,即使用位置取代环节名称作为环节文档的关键字。

采用第1种方式虽然较“笨”,但是可以不修改我们原来的程序,而且流程的组建过程也是最简单的。但是有些用户可能不会接受这种方式,因为在这样的系统架构下,组建流程的管理员需要绞尽脑汁地考虑“第二名称”怎样命名,而且这个“第二名称”不一定会获得最终用户的认可。为了避免这些麻烦,我们可以采用第二种方式。

下面我们看看环节文档中增加了位置域的效果(图4)。采用“位置”域作为关键字,在主文档、路径文档也相应增加当前位置域即可以唯一确定流程的走向。

增加环节的位置信息

在环节文档中增加位置域的方法解决了环节名称重复的问题,但进一步看,我们仍需要为相同环节名称不同位置的两个环节建立两个环节文档,站在系统管理角度来说,这也是一种很不好的方式,因为调整这种重复环节文档中的任何信息(如:调整环节包含的人员)的时候都需要修改2个或者更多的文档(很可能改了一个忘了一个)。因此,我们有必要将环节名称的其他信息和位置信息再拆分,拆分后各文档包含的域有:

角色文档(职位文档):角色名称、处理人员

环节文档:角色名称、位置

同时,为了配合这一改动,我们还需要将路径文档、主文档中当前的环节信息拆分成当前角色和位置:

路径文档:路径起点的位置、路径终点的位置

主文档:当前角色名称、当前位置、当前用户

解决了同一流程中重复环节的问题后,我们将流程继续扩展,接下来还将遇到不同流程使用同一环节,不同部门使用同一流程等问题。经过同样的分析过程,我们仍将面临为各种配置文档添加关键字域以区别不同情况或再次拆分成不同配置文档的情况。就像上面提到过的一样,选择添加域或者拆分各有有缺点,添加域可以维持程序的易用性,而拆分成不同文档可以减少系统中的重复配置,提高配置文档的可重用性和可维护性。易用性和可重用性这两个特性在大多数时候是一对矛盾体,如何取舍就全靠我们的系统设计人员把握了。我们这里采用的是以易用性为主,可重用性为辅的策略。图5显示了我们这种策略下的一种数据结构。

可配置的工作流的数据结构

刚才我们都是将流程不断扩大来细化我们的拆分方案,现在,我们将从另一个同样重要方向来继续这一过程,即流程环节的增、删、改。上面我们也曾提到过流程环节的“修改”(修改承办人员),一般情况下修改环节都不是问题,难点的在于增加和删除环节。下面我们尝试在“A领导审核”环节和“B领导审核”之间增加一个“C领导审核”,看看我们的系统是否需要做出修改,见下图:

增加环节

增加环节时,我们需要删除路径4文档(起点位置为2,终点位置为3),增加“C领导审核”环节文档和路径8文档(起点位置为2,终点位置为8)、路径9文档(起点位置为8,终点位置为3)。假如当前环节为“A领导审核”,程序流转时仍将使用主文档中保存的当前位置(位置2)搜索路径文档,此时结果可以从路径4文档变成路径8文档,可见这种设计是可以适应增加环节的。同样,这个设计也可以适应删除环节的情况。

注意,环节增删改时还有一种特殊情况,即删改当前环节。这种情况下不仅仅要修改流程配置文档,主文档中的相关内容也要进行更新,如果没有“外力”,主文档包含的当前处理人(这个还涉及了主文档的读写权限)和当前位置是不会自动发生变化的,因此,需要其他手段配合才能实现一个完美的“可配置”工作流。

到目前为止,一个简单的可配置的工作流就算完成了(跟关系式数据库建模的过程非常相似)。经过这一个过程,才发现其实IBM在Lotus WorkFlow中建立的工作流引擎(数据结构)在技术上已经是一种比较完美的方案了。我们绕来绕去自以为会发现新大陆,到了最后还是回到了前人走过的路上(对比Lotus WorkFlow,主要的不同之处是我们这里没有把人员和角色分拆,原因是不想再配置一次names.nsf中已存在的用户)。不管怎么样,从这个简单的可配置流程设计的过程中,我们还是获益匪浅,也深刻认识到一个再完美的工作流引擎也不可能成为普世真理,因为工作流的易用性和适应能力常常是矛盾的,不同的用户会提出不同的要求。因此,技术人员不必执着于技术不可自拔。

开发平台在国内已经发展了很久了,从有代码到低代码,甚至有些厂家声称可以无代码,当然无代码只是一个噱头。我们国家有很多经营了十几年二十年的老牌厂商,比如,天翎、宏天这种的;还有新兴起的简易云、搭搭云什么的,这些都是业内比较知名的品牌。天翎的特点就是平台稳定,因为是老厂商,技术成熟;搭搭云呢就是承接了国外一些新的理念,在轻量这方面做得不错。

开发的功能体系大都是支持.Net Framework和.Net Core下的快速开发,源码发布, 支持表单、流程、报表、门户、移动、微信和钉钉快速开发。同时支持传统单体应用和微服务架构,支持docker和k8s部署,具备亿级架构部署能力等等。

看我,我是官方,一些基本情况可能用户都说了,这里贴点资料,为网上用户放出来,欢迎@一起补充,关于力软部分基本差不多,迪西客部分请自行判断,不过要使用此类框架需要看公司具体情况,这里仅比较.net.部分。

浏览器兼容性

力软

支持各种主流浏览器,包含IE(微软)、Chrome(谷歌)、Safari(苹果)、Firefox(火狐)、Opera、360、遨游、猎豹等。

迪西客

支持IE8及以上、chrome(谷歌)、Firefox(火狐)、Safari(苹果)、360等主流浏览器。

平台技术

力软

基于ASP.NET MVC技术开发,具有分层逻辑,并且代码编写规范。该框架稳定、高效、成熟,能够保障后期开发系统的稳定性、安全性及良好的性能。

迪西客   

基于.NET技术构建,应用MVC设计模式,采用基于浏览器的三层结构(B/A/S),结合最前端技术HTML+jquery+ajax+json+webservice,为平台的拓展和发展提供了良好的基础和前景。

数据库支持

力软

框架支持Sqlserver、Mysql、Oracle等多种数据库(多个版本)。在同一系统中可同时连接多个数据库、多个数据库可以是不同类型的数据库。

迪西客 

低版本的框架只支持Sqlserver,高版本的框架还支持Mysql和Oracle。

支持的设备类型

力软   

支持电脑、平板、手机、智能硬件等多种设备。手机支持IOS、Android、支持微信企业号。

迪西客 

支持电脑、平板、手机、智能硬件等多种设备。手机支持IOS、Android、支持微信企业号。

可开发的系统类型

 力软

可以开发OA、ERP、BPM、CRM、WMS、TMS、MIS、BI、电商平台后台、 物流管理系统、快递管理系统、教务管理系统等各类管理软件。

迪西客

可以开发ERP、OA、CRM、HRM、销售管理系统、资产管理系统等。并有部分价格版本的产品提供部分系统的开发模板。

权限管理 

力软   

独立的权限管理体系,多套系统可以统一管理权限。集合了组织机构、岗位、职位的权限管理(含盖各个功能模块),提供多种授权模方式;可对功能权限、数据权限、登陆IP及登陆时间进行管控;注重权限安全,拒绝一切非法访问。

迪西客

包括网页权限、应用权限、组件权限、流程权限、列表权限、表单的权限设置、搜索时的权限设置和树模块的权限设置。

主要应用组件

力软

组织架构、权限管理、工作流、自定义报表、快速开发、APP开发、微信组件、即时通讯、访问过滤、单点登录、导入与导出、自定义表单设计、报表图标分析、缓存集群、APP开发。

迪西客

工作流、表单设计、自定义报表、自定义图表分析、列表设计器、“树”设计器、搜索设计器、网页样板、导入与导出、权限设置、APP开发、微信组件。

开源程度

力软

全开源、全源码。

迪西客

最高价格版本有全部源码。

(低价格A方案部分运行源码。

中间价位B方案100%运行源码,无开发源码。

最高价格版本C方案,100%的运行源码和开发源码。)

授权体系

力软

完善的授权体系,购买签订合同后,进行框架所有源码的授权,并且一次授权终身使有效,不会有后期的收费。开发的系统如需出售,无需再次授权。并且不限用户数。

迪西客

所有价格方案都是运行端源码不限授权,可以多次开发,不需要支付额外费用。不限用户数。最高价格版本有开发源码。

免费售后服务

力软

协助安装、指导使用,提供一定期限内免费(视具体版本)的技术培训、版本升级、技术支持服务。

迪西客

提供一年内的协助安装和BUG修正、使用咨询,不提供一定期限内的免费技术培训、版本升级和技术支持服务。

界面UI

力软

前端UI基于Jquery +Bootstrap(后期会改成vue),界面简洁大气,UI底层库提供了大量UI组件开发者轻松就能完成各种炫丽界面的设计。不像EXT、EasyUI那样外观千篇一律,另外也省去了UI的授权费用,因为EXT、EasyUI都需要收费的。多套风格UI可选。

迪西客

dcxCreator全面采用潮流的网页设计理念和技术,时刻关注和参考流行前线的互联网产品体验,简单、漂亮是dcxCreator区别于同行产品的明显特征。

可扩展性及个性化

力软

提供所有源码,可扩展性强,可个性化定制。

迪西客

源码封装深,大部分版本只提供运行端源码,可扩展性一般,个性化开发难度较高。

开发难度

力软

全源码,有技术支持服务,开发过程中遇到的困难基本可以得到解决。

迪西客

简单系统的开发较为便捷。但进行深层次开发时,因为大部分版本只有运行端源码,且封装的很深,技术支持服务不到位,很难自己独立完成开发。但有部分价格方案有部分系统开发模板提供。

后期收费情况

 力软

售后服务(超过服务期后):合同总额的20%/年

上门服务:3000元/天,上门服务所涉及的差旅费由客户方承担。

其余无其他收费情况。

迪西客

远程培训:3000元/时

技术支持:15000元/月或80000元/年

升级服务:1000元/次

API文档:1500元/份

系统迁移协助:2000元/套/次

系统集成:视情况定价

售后服务(超过服务期后):8800至30000元/年

主要适用客户

力软

开发人员为有一定基础的开发人员和高技术人员的公司,如:中小型软件开发公司、非软件公司的软件部门、需信息化建设的企业。

(力软的敏捷开发框架整合了大量的功能组件和现有的业务逻辑,能够让开发者只注重于功能的实现,而不用浪费时间去进行架构。很大程度上减少了开发的代码量,这使得刚入门的开发者也能进行系统的开发。同时,开源的系统能够自动生成代码,能够让一些资深开发人员进行更深层的扩展和个性化的定制。)

迪西客

对所需开发系统个性化要求不高、且开发能力较差的公司。对开发人员的要求非常低,只需逻辑清晰的项目负责人或其他无基础的人员就能进行开发。但难以进行个性化定制和系统的扩展。

(迪西客大部分产品只提供运行端源码,开发人员接触不到代码,所以开发难度比较低。但是要进行系统的扩展和定制化的时候,开发难度就大大提高了。)

价格透明程度

力软

价格透明度高,不会出现价格虚报的情况。偶尔有优惠活动。

迪西客

价格透明度高,不会出现价格虚报的情况。偶尔有优惠活动。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9979439.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-04
下一篇 2023-05-04

发表评论

登录后才能评论

评论列表(0条)

保存