工作流

撸码心得:为什么我选择XJR敏捷开发框架

本小妞迷上赌 提交于 2020-03-14 15:28:28
如今,编程领域发生了很大的变化,程序员花费了大量的时间来完善语法和代码结构的时候过去了。之前,从头开始以完美的语法编写代码是衡量程序员能力的最佳标准。但是,现在这种做法消失了,敏捷开发框架开始出现了,利用它程序员可以用更少的代码、更多的灵活性来构建一个强大的应用程序。 很明显,使用Java或者PHP等编程语言来编写程序,会比使用已经存在的框架花费更多的时间。使用众所周知的框架不仅可以让你尽可能快的完成事情,同时还可以享受其日积月累的好处,问题解决得更完美。 当然,如果你觉得这个框架不完美,那么也可以自己从头开始重写代码,以规避掉框架坏的部分,但是这样做可能需要更长的时间。如果项目对于上市和部署时间方面要求非常严格,那么强大的框架开发绝对是首选。 以下是这个 敏捷开发框架 的一些阐述: XJR敏捷开发框架技术特点 技术选型: 使用目前流行的多种web技术,包括springboot, JPA,Druid, Activiti,Lombok,swagger,poi,WebSocket,Jquery,BootStrap, maven,Jenkins 等等,支持多种数据库MySQL, Oracle, sqlserver等。 分层设计:使用分层设计,分为dao,service,Controller,view层,层次清楚,低耦合,高内聚。 安全考虑:严格遵循了web安全的规范,前后台双重验证

开源 C#工作流管理平台

不羁的心 提交于 2020-03-13 00:40:57
/*--> */ /*--> */ C# 工作流管理平台 前言 经过三个月研发, Smartflow-Sharp 工作流管理平台已经越来越成熟。在研发期间,我将我所有业余时间和精力完全投入到 Smartflow-Sharp 工作流研发中,研发过程实属不易,因为耗时耗脑力,对工作流管理平台的代码不断的优化,以期望其更加小巧精致,有更好的维护性。 研发 Smartflow-Sharp 工作流初衷是基于我现在的项目的需要,所以趁此机会研发 Smartflow-Sharp 工作流管理平台,期望打造成符合中国特色工作流管理平台,造福更多开发人员和企业。后续我会持续对 Smartflow-Sharp 工作流管理平台进行完善。我不会藏私,我完全公开 Smartflow-Sharp 工作流研发成果,完全免费,允许商用。在使用的过程,如有疑问或需技术支持都可以与我联系。 我为什么不选择使用现成工作流,而是重头研发,主要是基于对目前市面上工作流管理平台都不太满意,收费的太贵、免费又不是很好用。所以,我也来凑热闹研发一款属于我的工作流产品,完全开源、免费,希望能发挥他最大的作用,体现其价值,而不是把他放在家里硬盘里静静躺着,这样将失去他的价值。当然,我刚开始研发 Smartflow-Sharp 工作流管理平台也是有寄于变现的想法,毫不掩饰我对钱的追求,不过现在我完全不会有这种想法,只期望能发挥更大的作用

JWFDv0.96.3开源工作流-流程图提交异常BUG修改报告

只谈情不闲聊 提交于 2020-03-12 21:30:38
2011.2.25 BUG 将新建立的流程提交到数据库中的时候,发生异常,导致flow_manager的流程主记录未进入数据库中 请参考 JWFDv0.96 开源工作流引擎设计-数据库结构说明.doc 地址 http://www.cnblogs.com/comsci/favorite/260690.html 经过检查,发生问题出在 org.jwfd.workflowDesigner.UItools.Database.mysql.FlowsSqlControlModule.java 类中的new_flow()函数中BUG出现的原因是 由于v0.96数据库结构发生变化 flow_manager表结构和旧的flow_manager的表结构有几个字段发生变化而对应的SQL操作模块却没有进行及时的修改而导致的, BUG修正方法为,添加一个新的SQL操作函数 替换旧的SQL操作函数 修正BUG2011225001 所涉及的类和方法如下 ============================================================================================================ org.jwfd.workflowDesigner.UItools.Database.mysql.FlowsSqlControlModule

JWFD工作流-流程-数据同步控制的简明设计思路

爷,独闯天下 提交于 2020-03-12 19:56:26
前段时间,JWFD的设计由于遇到点困难和我忙于做迷你搜索引擎,所以暂停下来,这几天突然有了新的灵感,对于前面提到的数据-流程同步控制的问题,有那么一些想法,但是思考的还不是很透彻和成熟,不过我还是觉得需要和大家一起分享下这些想法,说不定对大家还有些帮助 流程-数据同步控制是JWFD工作流引擎在开发到v0.96.3版本之后,由于系统新增加了自动表单等外部业务数据,使得原有的流程自动运行控制机制无法适应这种新的情况,从而出现的新问题,请参考这篇文章 http://comsci.iteye.com/blog/1008791 来详细了解这个问题出现的背景和原因。。。 我们给出下面的简单定义 A是表单数据,B是流程引擎 这个问题的实质就是获得 “A驱动B运行 B依赖A运行 “的算法模型 经过一段时间的思考,我发现采用传统的方法并不是太容易解决这个问题的,所以使用了我以前在强人工智能设计中的思路,请参考这篇文章 http://edu.codepub.com/2009/1103/17319.php 来了解什么是跷跷板算法,其实顾名思义,跷跷板算法的实质就是建立对称的数据平衡态,通过对平衡状态的控制,来获得我们所需要的数据,当然,这个思路也不 是很成熟,也未经过什么实践的验证,不过,在这里我仅仅是借用这种模型来解决工作流的数据流程同步控制的问题,我设想A和B是跷跷板的两端,当我们仅仅只

JWFD工作流引擎设计--简单矩阵建模(初步讨论)

被刻印的时光 ゝ 提交于 2020-03-12 19:43:59
作者: comsci 发表于 2010-08-18 11:41 原文链接 阅读: 43 评论: 0 JWFD工作流引擎设计--简单矩阵建模(初步讨论) * 暂时忽略工作流状态的问题,仅仅表示工作流的拓扑结构 * * 为什么要搞这样的东东,jwfd v0.96版本中的引擎算法已经足以应付常见的工作流模型了,其它工作流系统的状态机模型也是比较不错的解决方案 * 因为在我设计0.96的引擎的时候,由于嵌入式代码模块和外部数据(表单等)的加入,核心引擎的代码出现了膨胀,引擎算法的结构出现复杂化的趋势 * 这个变化趋势让我感到流程系统的引擎核心由于负担的功能的增加而产生的代码量的膨胀和结构的复杂化是流程系统设计的一大障碍,因此我们有必要 * 为克服这个障碍而作出一些新的尝试,因此寻找一种更加清晰和简明的流程数学模型就成为必须 * * 这里还有一个重要的原因促使我要采用矩阵来构建流程的数学模型,因为在我前面对“JWFD工作流引擎设计--节点匹配搜索算法(再讨论)”这篇文章中 * 我遇到了如何用算法来寻找一对匹配的节点的问题(带条件选择的并行汇聚路由问题 http://comsci.javaeye.com/blog/339756),虽然采用递归 * 算法初步解决了这个问题,但是我始终认为有更为简单的办法来解决这个问题,经过一段时间的探索,我发现了一个比较有趣的现象,在流程矩阵中分支 *

视觉智能开放平台通过函数计算实现多人口罩佩戴识别

删除回忆录丶 提交于 2020-03-12 18:52:13
春节期间肺炎疫情来势汹汹,虽然时至今日疫情已得到了有效地控制但是由于复工潮的临近,仍不可掉以轻心。在公共场所对于口罩佩戴的监管依然是关键的疫情防控点,因此口罩佩戴检测是一项核心工作。 疫情当前,阿里云视觉智能开放平台(vision.aliyun.com)紧急推出了基于视觉AI分析的“人脸口罩检测”算法服务,通过对接该服务可快速构建监控系统并可统计人员的口罩佩戴情况,实现疫情防控的AI化,数字化。 除了单个人脸的口罩佩戴检测外,我们还合作了阿里云函数计算、Serverless工作流、OSS以及资源编排等多个服务,并结合自身算法成功实现多个API的能力串联,组合成为新的能力,例如使用人脸识别API和口罩检查API实现多人脸的口罩检测服务。通过此项能力可解决单张图片中多人脸口罩佩戴情况的检测,并且可协助开发者快速上云,部署环境。 那资源编排、Serverless工作流、函数计算是什么呢? 资源编排 (Resource Orchestration)是一种简单易用的云计算资源管理和自动化运维服务。用户通过模板描述多个云计算资源的依赖关系、配置等,并自动完成所有资源的创建和配置,以达到自动化部署、运维等目的。 Serverless 工作流 (Serverless Workflow)是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序,分支,并行等方式来编排分布式任务

20、Eternal框架-工程项目管理系统-自定义工作流

我们两清 提交于 2020-03-12 17:04:51
以无法为有法,以无限为有限。 用户自定义工作流,对流程的变更有极大的灵活性,如何能满足用户这样的灵活需求呢?每个节点的传递的表单可能不同,设定的条件可能不同,所以想实现 自定义工作流也同样需要实现自定义表单和自定义条件设定,才能使流程发挥灵活的作用。 流程节点的内容有哪些呢?“开始、结束、分支、汇聚、判断”这些? (看到手指,你是否忽略了手指所指的月亮)应该不是,对于用户来说这些很晦涩,或者得花费很大时间为他们讲解这些东西,使他们理解,这样他们才能用这些,设计出真正的实际流程。其实我们可以从用户角度去思考:没有这些,只有每个节点谁来处理和谁们来处理或申请,谁和谁们是什么呢?谁肯定是具体的人,谁们肯定是一组相似的人,相似的人在pms里是角色,所以节点就2种,人和角色。 每个节点是否处理都有条件设定,满足时才到这节点,如何做到条件自定义呢?说条件的自定义就得说这些条件来源于哪,从实际情况考虑应该来自3方面:1、表单里的内容;2、自定义的;3、流程的。先说2自定义的,未有实际系统这个无法推断有哪些啊,pms会实现一个自定义的规则功能,以后会详细说。来自流程的不用说啦,节点间的流转。表单里的这种情况最多,如借款、请假,当表单的里钱数、天数超过界限时,由不同的人来处理。把表单里的内容作为流程判断的条件,如果实现呢?pms里是当选择流程图的连接线时,会在属性面板里有条件选显卡

大数据技术之Oozie

夙愿已清 提交于 2020-03-12 07:52:08
第1章 Oozie简介 Oozie英文翻译为:驯象人。一个基于工作流引擎的开源框架,由Cloudera公司贡献给Apache,提供对Hadoop MapReduce、Pig Jobs的任务调度与协调。Oozie需要部署到Java Servlet容器中运行。主要用于定时调度任务,多任务可以按照执行的逻辑顺序调度。 第2章 Oozie的功能模块介绍 2.1模块 1) Workflow 顺序执行流程节点,支持fork(分支多个节点),join(合并多个节点为一个) 2) Coordinator 定时触发workflow 3) Bundle 绑定多个Coordinator 2.2 Workflow常用节点 1) 控制流节点(Control Flow Nodes ) 控制流节点一般都是定义在工作流开始或者结束的位置,比如start,end,kill等。以及提供工作流的执行路径机制,如decision,fork,join等。 2) 动作节点(Action Nodes ) 负责执行具体动作的节点,比如:拷贝文件,执行某个Shell脚本等等。 第3章 Oozie的部署 3.1 部署Hadoop(CDH版本的) 3.1.2 修改Hadoop配置 core-site.xml <!-- Oozie Server的Hostname --> <property> <name>hadoop.proxyuser

Windows WorkFlow Foundation入门

喜夏-厌秋 提交于 2020-03-12 07:39:52
一、工作流概述 工作流是由活动单元组成的集合,活动是真实过程的的一个模型。工作流提供了一种描述一系列相互关联的工作之间有执行顺序,这种工作从头到尾贯穿了整个活动,这些活动可能是由人工或系统来执行。 每一个运行的工作流实例由工作流运行时引擎来创建和维护的。虽然对于每一个应用程序域只能有一个工作流运行时引擎,但工作流运行时引擎内可以行多个工作流实例并发工作。 一旦一个工作流模型被编译,它就可以在任何一Windows进程内工作,包括控制台程序,窗口程序,Windows服务程序,Asp.net网站及Web Service等。因为工作流驻留在进程中,所以它可以很容易与它的宿主进程进行通信。 下面这幅图表明了工作流、活动以及工作流运行时引擎都存在于一个宿主程序中。 活动 如上所述,活动是工作流的基本单元,它们通过程序被加入到一个工作流中,其方式就好比将一个XML DOM子节点加入到根节点中。一旦工作流中的所有节点都运行完成,工作流实例就会结束。 WF由一系列标准活动类库组成,同时也提供了一个机制帮助开发人员开发自己的类库。这使得工作流之间的可扩展性和可重用性更加优异。 服务 当一个工作流运行的时候,工作流运行时引擎要使用到多个服务。这些服务组件是可插拔的,这使得应用程序可以在它们的运行环境中,提供具有唯一性的服务。Windows Workflow

Git - Pull Request工作流

﹥>﹥吖頭↗ 提交于 2020-03-11 12:58:41
Pull Requests 是 Bitbucket 上方便开发者之间协作的功能。提供了一个用户友好的 Web 界面,在集成提交的变更到正式项目前可以对变更进行讨论。 开发者向团队成员通知功能开发已经完成, Pull Requests 是最简单的用法。开发者完成功能开发后,通过 Bitbucket 账号发起一个 Pull Request 。这样让涉及这个功能的所有人知道,要去做 Code Review 和合并到 master 分支。 但是, Pull Request 远不止一个简单的通知,而是为讨论提交的功能的一个专门论坛。如果变更有任何问题,团队成员反馈在 Pull Request 中,甚至 push 新的提交微调功能。所有的这些活动都直接跟踪在 Pull Request 中。 相比其它的协作模型,这种分享提交的形式有助于打造一个更流畅的工作流。 SVN 和 Git 都能通过一个简单的脚本收到通知邮件;但是,讨论变更时,开发者通常只能去回复邮件。这样做会变得杂乱,尤其还要涉及后面的几个提交时。 Pull Requests 把所有相关功能整合到一个和 Bitbucket 仓库界面集成的用户友好 Web 界面中。 解析 Pull Request 当要发起一个 Pull Request ,你所要做的就是请求( Request )另一个开发者(比如项目的维护者),来 pull