例子:

当前有三张表A、B、C其中A和B是一对多关系,B和C是一对多关系,现在需要将B中A表的主键存到C中;
常规思路就是将B中查询出来然后通过一个update语句来更新C表就可以了,但是B表中有2000多条数据,
难道要执行2000多次?显然是不现实的;最终找到写一个存储过程然后通过循环来更新C表,
然而存储过程中的写法用的就是游标的形式。

【简介】

    游标实际上是一种能从包括多条数据记录的结果集中每次提取一条记录的机制。

    游标充当指针的作用。

    尽管游标能遍历结果中的所有行,但他一次只指向一行。

    游标的作用就是用于对查询数据库所返回的记录进行遍历,以便进行相应的操作。

【用法】

    一、声明一个游标: declare 游标名称 CURSOR for table;(这里的table可以是你查询出来的任意集合)
    二、打开定义的游标:open 游标名称;
    三、获得下一行数据:FETCH  游标名称 into testrangeid,versionid;
    四、需要执行的语句(增删改查):这里视具体情况而定
    五、释放游标:CLOSE 游标名称;
  注:mysql存储过程每一句后面必须用;结尾,使用的临时字段需要在定义游标之前进行声明。

【实例】

复制代码

-  BEGIN  
  --定义变量  declare testrangeid BIGINT;  
declare versionid BIGINT;   
declare done int;  
--创建游标,并存储数据  declare cur_test CURSOR for   
   select id as testrangeid,version_id as versionid from tp_testrange;  
--游标中的内容执行完后将done设置为1  
 DECLARE CONTINUE HANDLER FOR NOT FOUND SET done=1;   
--打开游标  open cur_test;  
--执行循环    posLoop:LOOP  
--判断是否结束循环  
        IF done=1 THEN    
      LEAVE posLoop;  
    END IF;   
--取游标中的值  
    FETCH  cur_test into testrangeid,versionid;  
--执行更新操作  
    update tp_data_execute set version_id=versionid where testrange_id = testrangeid;  
  END LOOP posLoop;  
--释放游标  CLOSE cur_test;  
  
END  -

复制代码

例子2:

我们现在要用存储过程做一个功能,统计iphone的总库存是多少,并把总数输出到控制台。

复制代码

--在windows系统中写存储过程时,如果需要使用declare声明变量,需要添加这个关键字,否则会报错。  delimiter //  drop procedure if exists StatisticStore;  
CREATE PROCEDURE StatisticStore()  
BEGIN  
    --创建接收游标数据的变量  
    declare c int;  
    declare n varchar(20);  
    --创建总数变量  
    declare total int default 0;  
    --创建结束标志变量  
    declare done int default false;  
    --创建游标  
    declare cur cursor for select name,count from store where name = 'iphone';  
    --指定游标循环结束时的返回值  
    declare continue HANDLER for not found set done = true;  
    --设置初始值  
    set total = 0;  
    --打开游标  
    open cur;  
    --开始循环游标里的数据      read_loop:loop  
    --根据游标当前指向的一条数据  
    fetch cur into n,c;  
    --判断游标的循环是否结束  
    if done then  
        leave read_loop;    --跳出游标循环  
    end if;  
    --获取一条数据时,将count值进行累加操作,这里可以做任意你想做的操作,  
    set total = total + c;  
    --结束游标循环  
    end loop;  
    --关闭游标  
    close cur;  
  
    --输出结果  
    select total;  
END;  
--调用存储过程  call StatisticStore();

复制代码

fetch是获取游标当前指向的数据行,并将指针指向下一行,当游标已经指向最后一行时继续执行会造成游标溢出。
使用loop循环游标时,他本身是不会监控是否到最后一条数据了,像下面代码这种写法,就会造成死循环;

read_loop:loop  
fetch cur into n,c;  
set total = total+c;  
end loop;

在MySql中,造成游标溢出时会引发mysql预定义的NOT FOUND错误,所以在上面使用下面的代码指定了当引发not found错误时定义一个continue 的事件,指定这个事件发生时修改done变量的值。

declare continue HANDLER for not found set done = true;

所以在循环时加上了下面这句代码:

--判断游标的循环是否结束  if done then  
    leave read_loop;    --跳出游标循环  end if;

如果done的值是true,就结束循环。继续执行下面的代码

使用方式

游标有三种使用方式:
第一种就是上面的实现,使用loop循环;
第二种方式如下,使用while循环:

复制代码

drop procedure if exists StatisticStore1;  
CREATE PROCEDURE StatisticStore1()  
BEGIN  
    declare c int;  
    declare n varchar(20);  
    declare total int default 0;  
    declare done int default false;  
    declare cur cursor for select name,count from store where name = 'iphone';  
    declare continue HANDLER for not found set done = true;  
    set total = 0;  
    open cur;  
    fetch cur into n,c;  
    while(not done) do  
        set total = total + c;  
        fetch cur into n,c;  
    end while;  
      
    close cur;  
    select total;  
END;  
  
call StatisticStore1();

复制代码

第三种方式是使用repeat执行:

复制代码

drop procedure if exists StatisticStore2;  
CREATE PROCEDURE StatisticStore2()  
BEGIN  
    declare c int;  
    declare n varchar(20);  
    declare total int default 0;  
    declare done int default false;  
    declare cur cursor for select name,count from store where name = 'iphone';  
    declare continue HANDLER for not found set done = true;  
    set total = 0;  
    open cur;  
    repeat  
    fetch cur into n,c;  
    if not done then  
        set total = total + c;  
    end if;  
    until done end repeat;  
    close cur;  
    select total;  
END;  
  
call StatisticStore2();

复制代码

游标嵌套

在mysql中,每个begin end 块都是一个独立的scope区域,由于MySql中同一个error的事件只能定义一次,如果多定义的话在编译时会提示Duplicate handler declared in the same block。

复制代码

drop procedure if exists StatisticStore3;  
CREATE PROCEDURE StatisticStore3()  
BEGIN  
    declare _n varchar(20);  
    declare done int default false;  
    declare cur cursor for select name from store group by name;  
    declare continue HANDLER for not found set done = true;  
    open cur;  
    read_loop:loop  
    fetch cur into _n;  
    if done then  
        leave read_loop;  
    end if;  
    begin  
        declare c int;  
        declare n varchar(20);  
        declare total int default 0;  
        declare done int default false;  
        declare cur cursor for select name,count from store where name = 'iphone';  
        declare continue HANDLER for not found set done = true;  
        set total = 0;  
        open cur;  
        iphone_loop:loop  
        fetch cur into n,c;  
        if done then  
            leave iphone_loop;  
        end if;  
        set total = total + c;  
        end loop;  
        close cur;  
        select _n,n,total;  
    end;  
    begin  
            declare c int;  
            declare n varchar(20);  
            declare total int default 0;  
            declare done int default false;  
            declare cur cursor for select name,count from store where name = 'android';  
            declare continue HANDLER for not found set done = true;  
            set total = 0;  
            open cur;  
            android_loop:loop  
            fetch cur into n,c;  
            if done then  
                leave android_loop;  
            end if;  
            set total = total + c;  
            end loop;  
            close cur;  
        select _n,n,total;  
    end;  
    begin  
      
    end;  
    end loop;  
    close cur;  
END;  
  
call StatisticStore3();

复制代码

上面就是实现一个嵌套循环,当然这个例子比较牵强。凑合看看就行。

动态SQL

Mysql 支持动态SQL的功能

set @sqlStr='select * from table where condition1 = ?';  
prepare s1 for @sqlStr;  
--如果有多个参数用逗号分隔  execute s1 using @condition1;  
--手工释放,或者是 connection 关闭时, server 自动回收  deallocate prepare s1;


关于vue的npm run dev和npm run build

├─build
│   ├─build.js
│   ├─check-versions.js
│   ├─dev-client.js
│   ├─dev-server.js
│   ├─utils.js
│   ├─vue-loader.conf.js
│   ├─webpack.base.conf.js
│   ├─webpack.dev.conf.js
│   ├─webpack.prod.conf.js
│   └─webpack.test.conf.js
├─config
│   ├─dev.env.js
│   ├─index.js
│   ├─prod.env.js
│   └─test.env.js
├─...
└─package.json
以上是关于bulid与run的所有文件

指令分析

package.json里面

"dev": "node build/dev-server.js",

"build": "node build/build.js",

 

意思:运行”npm run dev”的时候执行的是build/dev-server.js文件,

运行”npm run build”的时候执行的是build/build.js文件。

build文件夹分析

build/dev-server.js

npm run dev 执行的文件build/dev-server.js文件,执行了:

检查node和npm的版本
引入相关插件和配置
创建express服务器和webpack编译器
配置开发中间件(webpack-dev-middleware)和热重载中间件(webpack-hot-middleware)
挂载代理服务和中间件
配置静态资源
启动服务器监听特定端口(8080)
自动打开浏览器并打开特定网址(localhost:8080)

说明: express服务器提供静态文件服务,不过它还使用了http-proxy-middleware,一个http请求代理的中间件。前端开发过程中需要使用到后台的API的话,可以通过配置proxyTable来将相应的后台请求代理到专用的API服务器。

build/webpack.base.conf.js

dev-server依赖的webpack配置是webpack.dev.conf.js文件,

测试环境下使用的是webpack.prod.conf.js

webpack.dev.conf.js中又引用了webpack.base.conf.js

webpack.base.conf.js主要完成了下面这些事情:

  1. 配置webpack编译入口

  2. 配置webpack输出路径和命名规则

  3. 配置模块resolve规则

  4. 配置不同类型模块的处理规则

这个配置里面只配置了.js、.vue、图片、字体等几类文件的处理规则,如果需要处理其他文件可以在module.rules里面配置。

build/webpack.dev.conf.js

在webpack.base.conf的基础上增加完善了开发环境下面的配置,主要包括下面几件事情:

将hot-reload相关的代码添加到entry chunks
合并基础的webpack配置
使用styleLoaders
配置Source Maps
配置webpack插件

build/check-versions.js和build/dev-client.js

最后是build文件夹下面两个比较简单的文件,

dev-client.js似乎没有使用到,代码也比较简单,这里不多讲。

check-version.js完成对node和npm的版本检测

build/utils.js和build/vue-loader.conf.js

webpack配置文件中使用到了utils.js和vue-loader.conf.js这两个文件,utils主要完成下面3件事:

配置静态资源路径
生成cssLoaders用于加载.vue文件中的样式
生成styleLoaders用于加载不在.vue文件中的单独存在的样式文件


vue-loader.conf则只配置了css加载器以及编译css之后自动添加前缀。

build/build.js

构建环境下的配置,

build.js主要完成下面几件事:

loading动画
删除创建目标文件夹
webpack编译
输出信息

build/webpack.prod.conf.js

构建的时候用到的webpack配置来自webpack.prod.conf.js,该配置同样是在webpack.base.conf基础上的进一步完善。主要完成下面几件事情:

合并基础的webpack配置
使用styleLoaders
配置webpack的输出
配置webpack插件
gzip模式下的webpack插件配置
webpack-bundle分析
说明: webpack插件里面多了丑化压缩代码以及抽离css文件等插件。

config文件夹分析

config/index.js

config文件夹下最主要的文件就是index.js了,

在这里面描述了开发和构建两种环境下的配置,前面的build文件夹下也有不少文件引用了index.js里面的配置。

config/dev.env.js、config/prod.env.js和config/test.env.js

这三个文件就简单设置了环境变量而已,没什么特别的。

这是webpack的基本入门,webpack还有很多插件,还需要去探索

后面写这几个文件的源码解释。


本文章基于AgileBpm低代码平台开发文档,代码及个人理解

AgileBpm整体项目逻辑划分比较清楚,能按照开发文档对各个部分进行基本的了解。

Agilebpm模块分析

  1. 基础模块 Base

  2. 平台模块 Platform

  3. 业务对象+表单模块 Bus+Form

  4. 前端模块 Bpm-explorer

  5. 模块间依赖关系

 

1. 基础模块BASE

  • base-api 提供 通用请求入参、返回参数、基础实体、基础service/dao API定义、异常规范、校验定义

  • base-core 提供常用工具类、基础API实现 ID生成、通用校验实现等

  • base-db 整合数据源、mybatisjdbcTemplate 等持久化层相关的实现

  • base-rest 提供 Rest 服务基类、Rest服务相关的工具类 

 

2. 平台模块Platform

2.1鉴权项目模块

  • 在用户登录时安全验证,页面跳转时判断 当前用户所拥有的角色 是否满足 当前资源所需的角色

  • 安全支持,防止CSRF跨站请求攻击

2.2 org 组织架构管理模块

  • 用户管理

  • 组织岗位

  • 角色

  • 用户组关系

2.3 sys 系统功能模块

  • 提供 jmsfreemarkgroovyemailredisschedulerlog 等组件的服务接口定义

  • 数据字典、系统资源管理、系统环境属性、流水号、多数据源、菜单资源、子系统、国家节假日、日程、工作台 等系统功能

 

3. 业务对象+表单模块

3.1 业务对象模块

业务对象支持一对多、多对多、一对一、多层关联关系(学校-班级-学生),业务对象多表来自不同数据源,并支持多数据源分布式事务

  • 业务对象、业务实体的定义

  • 业务数据的持久化服务

  • 表字段控件定义(为生成表单做准备)

 

3.2 表单模块

表单是业务对象的展示层,依赖业务对象模块

  • 提供在线表单的生成(PC 、移动端、iview版本等..其他UI版本 

  • 表单高级控件的配置

  • 表单模板管理

  • 自定义SQL列表,与表单组合实现增删改查

      在前端平台进行0代码开发时,一般都是先进行业务实体和业务对象的创建(此时也会在后台数据库进行对应table的同步),然后按照之前建的业务对象进行表单的生成,可以选择几个固定模板(单列,二列,三列,四列),生成完后还可以再自己进行类似于Word方式的调整。

模板生成表单

表单的调整

4. 前端模块

Agilebpm的流程引擎基于activiti 5.22

 

Activiti5是由Alfresco软件在2010517日发布的业务流程管理(BPM)框架,它是覆盖了业务流程管理、工作流、服务协作等领域的一个开源的、灵活的、易扩展的可执行流程语言框架。Activiti基于Apache许可的开源BPM平台,创始人Tom BaeyensJBoss jBPM的项目架构师,它特色是提供插件,开发人员可以通过插件直接绘画出业务流程图。 

 

5. 模块间依赖关系

 

(在开发文档中作者描述WF为流程模块,但实际并未找到单独的WF,应该是随着更新嵌入到前端bpm-explorer中)

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

本文链接:https://blog.csdn.net/callpink/article/details/108058853


今年2月23日,外国低代码平台提供商Creatio宣布获得6800万美元融资;2月22日,国内SaaS软件厂商黑湖智造宣布完成C轮近5亿元人民币融资。国内外的低代码开发平台备受投资方青睐,被各大软件和互联网媒体捧上“C位”。老K也写过几篇评论低代码开发平台的文章,想必你都见闻不少。


那么,你真的懂低代码了吗?抛开冗长晦涩的专业术语,我想写一篇最接地气的文章,给大家说清楚“低代码”是怎么一回事儿。


01


“低代码”的起源和走过的路


低代码的故事要从上世纪80年代说起,当时计算机科学理论已逐步发展成熟,不少高级程序设计语言都逐渐开发完善。这时,编程界推出了“结构化语言”,即以功能指令为单位,把相应的代码封装好。当程序员要系统运行某个功能时,只需发出指令,计算机就知道要运行对应的代码。


到了2000年,“VPL”(可视化编程语言)出现了。顾名思义,就是在第四代编程语言的基础上,把系统运行的过程以更视觉化方式呈现,例如图标、表格、图表等形态。


随着高级编程语言不断发展成熟,以及国内外计算机人才的培养规模逐渐扩大,2010-2015年称得上是传统软件和SaaS软件兴起的时代,市场规模稳步增长。就是在这一时期,编程人员承接了许多软件开发项目。他们发现:软件的功能大同小异,重复度很高,导致很大部分的软件开发成本都浪费在重复的功能编程上。


而Forrester,一家国际知名的技术和市场调研公司,敏锐地发现了这一问题,并在2014年首次提出低代码和零代码的概念:只需用很少甚至几乎不需要代码就可以快速开发出系统,并可以将其快速配置和部署的一种技术和工具。随后在2018年,Gartner提出aPaaS(应用平台即服务)和iPaaS(集成平台即服务)的概念。




图自:CSDN


在这两个概念出现并逐渐传播的时间里,国外软件厂商就陆续发布出低代码或零代码开发平台,探索并证明了这类产品成功的可能性。基于外国的成功初探,中国市场也掀起了“低代码/零代码”的热潮,并在近两年逐步形成完整的产品生态体系。




图自:海比研究院


02


“低代码”为何而生?


低代码开发平台至今已发展得较为成熟,现在我们站在较高的“上帝视角”,回顾“低代码”诞生的合理性。其实,低代码平台除了击破重复编程的高成本痛点之外,还解决了两大难点:沟通隔阂和效率问题。


1、需求方与技术方之间的认知和沟通隔阂


传统的软件定制开发环节中,需求方往往会提一大堆业务流程、数据收录、界面设计等要求。经验丰富的技术员能理解甲方的业务流程,用正确的逻辑完成开发。而欠缺业务经验的技术员则照着“单子”来开发,这种粗暴的方式往往也埋下了不少系统逻辑不自洽、出bug、流程不通等隐患。技术方不懂业务怎么运转,需求方不懂系统语言和逻辑,双方存在认知和沟通隔阂。


低代码开发平台凭着自身可视化、易理解的配置功能,让业务人员更清楚如何用上面的功能来开发应用;开发人员也能借助平台的界面、功能使用指南,更轻松地让业务人员理解应用实施逻辑。现在市面上绝大多数的低代码平台也在主张由业务人员自行实施应用,背后也是这个道理。


2、友好的操作界面提高应用实施、漏洞排查和修复效率


也是因为可视化、交互化、简洁的平台界面,应用开发者能更高效地实施开发,不用对着满满一屏幕的黑底白码埋头苦干。同样地,排查及修复bug的效率也因信息简化了而更容易提高效率。




以轻流产品为例,展示数据表字段配置界面


03


“低代码”的技术特点


谈完低代码是为降低软件开发的成本、沟通和实施效率而生,我们来看看它有哪些技术特点。


1、两种模式:基于表单或引擎驱动 以及 基于aPaaS平台


目前大部分低代码开发平台都属于下述模式的其中一类。



基于表单或引擎驱动


基于aPaaS平台


定义


通过建立多张表单,使用流程串联,定义报表输出方式,构建表单类轻应用


以应用开发平台为核心,承载各种开发工具和复杂技术手段,并将其可视化、低代码化来使用


优点


· 功能简单易用易学


· 具备基础的自动化流程运转能力


· 采购成本较低


· 功能更多元


· 应用细节的颗粒度更高


· 应用开发的灵活度更高


· 开发技术壁垒高


· 场景局限性弱,满足大中小客户的需求


· 基本可实现复杂的系统开发和对接


缺点


· 开发技术壁垒低,缺乏技术竞争力


· 难以实现复杂的系统对接和功能配置


· 场景局限性强,主要服务中小客户


· 对应用开发者有技术能力要求


· 采购和实施的各项成本较高


更适合的应用场景


表单类应用,如:人事行政、资料归档、OA审批、客户管理等


复杂场景应用,如:ERP、生产全流程管理、CRM、物联网等


典型代表产品


魔方网表、云表、活字格


ClickPaaS、氚云、宜搭


大家可能还感觉不到有啥区别,让我来举个对比例子:






表单驱动模式的低代码平台主要以表单的形式运转业务流程;而aPaaS模式能借助应用平台打造一个立体空间,让不同部门的不同业务线彼此交叉贯通,还可以对接外部的系统。


2、颠覆传统:“低代码”和传统企业管理系统架构的差异


低代码开发平台除了自身模式不同,和传统企业系统管理相比,在系统结构和管理理念上也有颠覆式差异。


“低代码”将多个“系统烟囱”归整为一个集大成者,更灵活敏捷地创建中台架构。


传统的企业系统中,每个部门有不同的系统需求,于是各自采购自己的系统。但这些系统彼此孤立,独立运作,导致企业采购的软件系统冗杂。低代码平台则让绝大部分部门的业务系统都能在一个平台里搭建,彼此联系,打破信息系统孤岛,同时降本增效,提升内部生产力。


“低代码”重塑业务部和技术部的分工定位,为业务部赋予系统定制化的能力和自由。


重塑业务和技术的分工定位,主要在于宏观到微观的企业系统管理运维上。技术部负责统筹企业在低代码开发平台上的整体架构分布,维护系统运维的稳定性和安全性,修复漏洞。而业务部则有更多自由,利用“低代码”自主开发出业务所需的管理系统,并实现跨部门应用交互。另外,当重新定义了二者的分工后,企业技术部的价值才能从修电脑、装wifi、买服务器这些琐事中进阶,为公司数字化管理做建设性实事。


04


“低代码”能否继续干得漂亮?


1、势头:稳定增长


2021年初,海外研究机构Infolob表示,低代码应用平台保持着40%的年复合增长率,预计到2022年,低代码应用程序市场总规模达212亿美元。Gartner预测2024年应用软件开发活动中,65%将通过低代码方式完成;75%的大型企业将用至少四种低代码开发工具开发应用。


“低代码”在国外发展势头强劲,无论是市场培育还是商业模式都渐趋成熟。在国内,它的表现也毫不逊色。2020年企业数字化浪潮让低代码市场规模迅速扩展,也因此鼓动了不少软件厂商转型做“低代码”。海比研究院预测,2021年至2025年,中国低代码市场将保持规模扩张的良好态势。






图自:海比研究院


2、机遇:物联网和大数据也需要“低代码”


物联网和大数据都是时代的技术主旋律,而它们的发展也需要“低代码”助力。像物联网平台需要调度“云、管、边、端”各方资源,还要兼顾传感、语音等交互,并适应环境变化的状况——可想而知它的开发难度之大。“低代码”凭着灵活敏捷的开发功能,恰好能帮助降低物联网项目的开发门槛,缓解成本、人才等痛点。


据我所知,像优锘科技、畅图科技等物联网和地理信息大数据系统厂商,都在与低/零代码厂商明道云合作,并取得良效。个人认为, 低代码开发平台能抓住物联网和大数据的风口,挖掘自身产品在高精领域的协作可能性,是很聪明的差异化拓业策略。


3、挑战:客户观念尚未扭转


APICloud创始人刘鑫曾在一次访问中提到:“很多企业都说需要一个大数据、人工智能工具,但很少会说我需要一个开发工具。客户的需求并不是一个低代码平台,而是低代码能够产生的价值。“客户依然习惯性寻求贴身服务,观念尚未扭转,自身也难以培养低代码开发能力。“低代码”要真正普及,还需要继续教育市场和客户。


“低代码”的市场在时刻变化着,头部厂商在主动普及低代码教育,也有小众厂商探索该市场下的细分赛道,还有传统ISV躬身入局,加入战场。在机遇与挑战激荡的成长期里,我们尚且一起见证“低代码”的变迁。


尾语


日本富豪前泽友作买下马斯克火箭公司的第一张绕月飞行船票,并赞助10位艺术家与自己同行。他说:“过去的人类宇宙史里,只有科学家能上太空。我希望让艺术家也能去看看太空,看看另一个曼妙的世界。”


低代码仿佛也有这样的力量,让不会代码的人也能通过可视化操作,感受开发一套应用软件的成就感、获得感。不少程序员觉得低代码、零代码开发平台就是个玩具,但我认为,低代码、零代码不是所谓的“低智盛行”,而是“人人平等”,人人都可以是开发者,去探索技术的宇宙。


参考资料:


《谁在抢占“低代码”高地?》澎湃号 吴俊宇


《低代码,能让程序员脱离996吗?》甲子光年


《低代码:下一次IT技术革命?》36氪新风向


《2021年中国低代码&无代码市场研究报告》中软网


《零代码简史》明道云博客 任向晖


《从表单驱动到模型驱动,解读低代码开发平台的发展趋势》CSDN 低代码观察




作者简介:流水不争先,零代码APaaS软件从业者,不安分斜杠女青年。用一笔一墨,勾勒出互联网时代的清明上河图

————————————————

版权声明:本文为CSDN博主「技术领导力」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/yellowzf3/article/details/114384844


IT技术支撑了全球信息化浪潮,然而软件开发效率却难以像摩尔定律一样快速提升,以至于成为瓶颈。

近几年,低代码领域发展迅速,赛道跑出了超10亿美元估值的独角兽OutSystems,巨头企业AWS、Google、Microsoft、Oracle、西门子等也纷纷推出低代码开发平台或通过收购布局低代码。国内也出现了一批低代码创业公司,具备早期创投机会。

低代码开发平台,是指那些无需编码或通过少量代码就可以快速生成应用程序的工具,其一方面可以降低企业应用开发人力成本,另一方面可以将原有数月甚至数年的开发时间成倍缩短,从而帮助企业实现降本增效、灵活迭代的价值。

36氪近日对十多家低代码相关企业进行了采访、调研、产品试用等,包括多家低代码创业公司,用友、销售易、北森等企业软件和知名SaaS公司,OutSystems、Mendix等海外头部公司等。最终撰写了本文,部分核心信息包括:

低代码开发方式,可将软件开发效率提升数倍甚至10倍以上;

低代码赛道正在热起来,国外已经跑出超10亿美元独角兽,预计2020年平台市场规模达155亿美元;

低代码赛道竞争的5个关键点剖析:平台能力,商业模式、商务能力、生态建设、融资能力;

低代码领域处于早期探索阶段,入局创业尚不晚,创业公司估值大多在2亿元内,有早期投资机会;

RPA、BPM、中台、低代码,背后是一个趋势。

不写代码快速开发应用将开发效率提升10倍

1、低代码开发的概念和价值

我们先来通过几个案例,来直观感受下低代码开发的价值:

OutSystems帮助施耐德电气在20个月内推出了60款应用,将开发过程加速了2倍,仅在第一年就节省了650天的工作量。

ClickPaaS告诉36氪,某传统化工内企业客户,原先通过Oracle和SAP构建了整体信息化架构,包含CRM,DMS,OMS,ERP。业务模式发生变化后原先的方案需要重构,在Oracle和SAP上重构的方案原先实施公司报价在6个月,400万元。通过ClickPaaS快速构建业务模型替换掉了CRM,DMS,OMS,只用了1个月,70万元年租。

创科技告诉36氪,某地产中介搭建海外服务板块系统,传统开发方式需要12个人开发6个月,报价小几百万元。宜创基于低代码开发方式,4个人开发1个月完成交付,项目金额数十万元。

效率提升的背后,都来源于低代码这种新型的应用开发方式:开发者可以基于图形化界面,通过拖拉拽、参数配置、逻辑规则定义、模板组件调用等方式,同时兼容代码编写模式,完成软件应用构建,将开发效率提升数倍甚至10倍以上。

经常和低代码一起提到的还有零代码(无代码),零代码是指完全不写代码实现应用开发,其面向的开发场景往往较简单。

特别说明一点,本文讨论的低代码开发平台,是指广义的低代码开发平台,包含了低代码和零代码,包含了支持低代码快速开发的相关模块,包括通用PaaS层、中间件、aPaaS层、iPaaS层、组件、模板等。

OutSystems的低代码开发界面(图片来源:OutSystems官网)

2、低代码开发如何提高开发效率和降低成本?

效率方面,首先,通过图形化拖拉拽的方式,替代原本编写代码的方式,能够降低大量工作量。第二,编写代码的方式,往往会花很多时间在寻找代码bug和解决bug上,低代码因为很少需要直接写代码,因而有效的规避了代码本身的bug问题。第三,支持将开发完的应用一键部署到多种环境,包括PC客户端、web端、移动端,以及IOS、Android、H5、小程序等。第四,通过云化的开发全流程协同、版本管理,可以提高协同效率。

除此之外,宜创科技CEO宜博还告诉36氪,传统写代码开发,开发总时长的缩短与投入人力的增长并不是成正比的,传统开发是紧耦合、串行开发模式,即开发者之间需要紧密配合、联调等,很多开发环节需要等待上一环节完成。宜创低代码开发平台非常关键的一点是,底层核心技术从紧耦合的MySQL、Java等,变成了松耦合的NoSql、JavaScript等,从而实现了从串行开发到并行开发。

成本方面,软件应用开发的成本主要是人力成本,通常按“人天”或“人月”来衡量,可以按照这个公式来核算:开发成本=人员日均工资*人数*开发天数。效率的提升会直接成比例降低“人数、开发天数”的值,同时,低代码开发模式降低了对开发者水平的要求,很多开发工作不需要那么贵的高端开发人才来做了,这样也降低了“人员日均工资”值,从而整体降低成本。

低代码赛道国外已跑出独角兽2020年平台市场规模达155亿美元

低代码开发在早期经常被看做“玩具”,难以在实际生产场景落地。近年来,随着技术和市场的逐渐发展,低代码开发领域也逐渐“热”了起来。

2018年6月,低代码开发平台OutSystems获 KKR 和高盛3.6 亿美元融资,估值超过10亿美元,成为独角兽。其年营收远高于1亿美元,并且每年增长率超过70%。

2018年8月,西门子宣布以6亿欧元收购低代码应用开发领域的知名公司Mendix。

AWS、Google、Microsoft和Oracle等也于近些年纷纷推出各自的低代码开发平台。

再看国内,奥哲网络、ClickPaaS、宜创科技、数式科技、轻流、搭搭云等低代码创业公司也于2018、2019年纷纷获得投资。其中奥哲获得阿里5000万元A+轮投资,和高榕资本的亿元级B轮投资。

2019年上半年,明道发布新产品明道云,转型成为零代码开发平台;APICloud发布了低代码开发平台Plus Mode。

市场规模上,Forrester的报告显示,低代码开发平台的市场将从2015年的17亿美金增长到2020年的155亿美金,预计到2020年,75%的应用程序将在低代码平台中开发。

需要注意的是,这里的155亿美元的市场估计仅指低代码开发平台的市场,而基于低代码平台提供服务的市场,并未计入其中。

两类主流玩家头部SaaS企业通用平台企业

Gartner在2018年的报告中提出了hpaPaaS(高生产力应用程序平台)的概念,即一个支持快速开发、部署、运行应用程序的云平台,核心能力聚焦在低代码和零代码开发。

下图是Gartner在2018年报告中绘制的hpaPaaS魔力象限:

资料来源:Gartner报告

可以看到,右上角的“领导者”象限有四家公司:Salesforce、ServiceNow、OutSystems、Mendix,这四家公司也代表了全球低代码开发平台的两类核心玩家:头部SaaS企业和通用平台企业。

1、头部SaaS企业

头部SaaS和应用软件企业,做低代码开发平台的直接驱动力是:提高产品开发和定制化开发效率。长期驱动力是:建立平台生态。

代表企业包括国外的SaaS龙头Salesforce、ServiceNow等,国内的知名SaaS企业销售易、北森,以及老牌应用软件企业用友、金蝶等。

SaaS企业需要快速迭代产品,同时扩充更多产品线和功能,以覆盖更广泛的业务场景,涉及到大量产品开发工作。另一方面,中大型客户往往会给SaaS企业带来更可观的营收,但是标准化的SaaS产品满足不了大客户的需求,SaaS企业需要针对每个大客户进行大量定制化开发,沦为“项目公司”。

低代码开发平台则能有效解决上述问题,降低SaaS和软件企业的产品开发和定制化交付成本,提高整体效率。

头部SaaS企业的低代码开发平台,参照Salesforce、ServiceNow的成功经验,目前已有较清晰的发展路径:

第一步,将平台用于内部开发效率的提升,包括产品持续开发对待和定制化交付。

第二步,将平台提供给客户和集成商/代理商使用,让客户能够基于平台二次开发,持续满足自身的业务迭代和个性化需求。让集成商/代理商能够基于平台进行二次开发,满足客户的定制化需求,实现快速低成本交付。

第三步,将平台开放给第三方应用开发商ISV,在平台上构建新应用,借助平台的流量售卖给平台客户,从而突破SaaS企业自身的业务范围,形成平台应用生态。或直接将平台售卖给ISV,独立开发和交付ISV自己的应用软件。

Salesforce已实现了第三步,典型案例是Veeva基于Salesforce的应用开发平台Force.com,开发了针对医疗行业的CRM系统,目前市值已超过200亿美元。

2、通用平台企业

头部SaaS企业是先有业务,然后造了低代码开发平台去支撑自己的业务扩张,以及更长远的生态建设。通用平台企业则是先把平台工具造出来,然后提供给所有(理想情况)的应用程序开发场景使用。

低代码开发平台,对于头部SaaS企业来说是工具,对于通用平台企业来说是核心产品服务和新的商业模式,36氪希望关注到更多创业投资的新机会和新趋势,限于篇幅,后文会把焦点放在通用平台企业的研究分析上。

通用平台的代表企业包括国外的OutSystems、Mendix等,国内的企业有奥哲网络(氚云)、ClickPaaS、宜创科技、炎黄盈动、数式科技、轻流、搭搭云、黑帕云、易度软件等低代码创业公司,以及APICloud、明道云等延伸或转型到低代码领域的创业公司,以及大型企业旗下的业务模块,如帆软的简道云、阿里的宜搭等,还有Joget等正在拓展中国市场的海外公司。

如何进一步去分出通用平台企业的差异呢?赛道的关键点有哪些?

我们通过多家企业走访调研、产品试用和行业分析后,认为可以从以下五个维度去衡量平台能力,商业模式、商务能力、生态建设、融资能力。

平台能力决定了平台能提供多大的应用价值(开发效率提升多少倍,成本降低多少倍);

商业模式决定了应用价值能转化为多大的商业价值;

商务能力直接影响获客(尤其是大客户获客)能力,决定了商业价值能被多大程度落地;

生态建设指的是平台的教程、培训、帮助支持和社区等体系的搭建,直接影响平台的推广速度、推广成本和品牌;

融资能力很重要则是因为,优质的低代码开发平台研发是个高投入(数年、上亿元)、高门槛的事情,前期需要持续烧钱,直到平台商业化落地产生稳定营收。

后文我们会详细分析下平台能力和商业模式这两个较复杂的关键点。

如何衡量低代码开发平台的平台能力

平台能力核心决定了2件事情,也是低代码开发平台最核心的价值体现:能开发多广泛场景和多复杂场景的应用;开发效率和开发成本能优化到什么程度。

这两点决定了低代码企业的天花板有多高、产品落地性和竞争力有多强、是否具备大客户复杂场景服务能力。

一个关键的问题来了:如何衡量平台能力?

我们认为可以从两个角度去衡量,一个是从平台的技术路径和架构去衡量,一个是通过平台的应用效果衡量。

技术路径方面,我们与国内多家通用低代码开发平台负责人,以及销售易、北森、用友的平台产品技术负责人进行了访谈交流,得出了以下结论:

大的层面,可以将低代码开发平台按照技术路径架构分为两类

一类是基于表单/引擎驱动的模式,通过建立多张表单,使用流程串联,定义报表输出方式,构建表单类轻应用。该类模式的技术壁垒不高,主要支持开发表单类应用,场景有一定局限性,主要服务中小客户。

一类是基于aPaaS平台的模式,包含多种具体的技术手段和路径,例如模型驱动、代码生成、可视化编程等,底层技术涉及云原生、元数据、多租户等。该类模式的技术壁垒较高,颗粒度更细,复杂度、灵活度更高,能够支持广泛场景的复杂应用开发,具备服务大客户和中小客户的能力。不过此类平台往往很难进一步划分出几个清晰的技术流派,往往是每一家都有较大差异。

再来看另一个角度,通过平台的应用效果衡量。

首先,可以直接看平台的核心价值实现效果,即:

成功交付了多大规模的客户。横向广度上能覆盖多少行业、领域的应用开发场景,纵向深度上能开发多复杂的应用场景。

开发这些应用场景,能在多低的人天量完成,反应的是开发效率和开发成本能优化到什么程度。

除此之外,销售易CEO史彦泽和产品副总裁叶晓峥还补充了3点:(叶晓峥曾任Netsuite(现Oracle云ERP)产品总监,曾在Siebel作为项目带头人构建了Siebel CRM应用引擎)

有多少ISV基于平台进行原生应用开发,以及产生了多少应用数量,质量有多高。

对客户数据量的处理能力(销售易在单个租户可以支撑亿级)。

国际标准机构的认证,如Gartner高效开发平台的推荐供应商名单等。

五大商业模式寻找低代码价值出口

低代码开发平台本质是个工具,产生“提高开发效率、降低开发成本”的核心应用价值。如何寻找最优质的价值出口,怎么将这把“利器”转化为可观的商业价值,对于创业公司的成败和未来体量都至关重要。

更具体的,其中涉及到选择的行业和场景是否有足够痛点,客户的付费能力有多高以及付费通道是否通畅,利润空间有多大,是否能够规模化扩张,扩张的边际成本是否足够低,该模式的天花板有多高,是否能够形成较高的壁垒等等。

经过调研分析,我们将低代码开发通用平台的商业模式,初步总结为以下5大类:

成为表单类轻应用开发平台。包括轻量型的ERP、CRM、进销存、项目管理、OA等应用的快速构建,好处是能较快较轻的切入市场,用户使用门槛低,问题是支持开发的应用场景有限,大多服务中小企业,技术壁垒不高。

成为企业IT项目开发商。市面上有庞大的软件外包开发公司,承接着庞大的企业IT项目建设的需求。既然自己有强大的工具,干脆直接去承接企业外包开发需求,能够比其他公司缩短数倍的开发时间,降低数倍的开发成本,从而在交付时间和报价上产生大幅度优势,同时客户还能基于平台未来继续快速构建应用。该模式的问题在于,需要具备大量客户资源、熟悉客户业务,在交付过程中,会涉及大量的咨询工作,梳理客户的业务流程。当然,先自己把规模做起来,后面成为有核心开发工具优势的高生产力众包平台也是一种路径。

赋能咨询公司、集成商。不直接面对终端客户做项目,而是针对直接服务终端客户的咨询公司、集成商、外包公司等,给他们提供低代码开发平台工具产生营收。这样低代码公司不用去争抢自己积累较少的终端大客户资源,不用花大量时间在客户业务咨询和需求梳理上,能较快的规模扩张,借助渠道把平台较快打入更多客户,再延伸潜在的客户服务。该模式下,平台要足够易用、降低使用门槛,且要做好培训、支持体系的建设,让渠道商有意愿和容易使用。同时,渠道商的水平参差不齐,也会直接影响到平台的落地效果,进而影响品牌形象。

赋能中大型SaaS企业。前文已分析,低代码开发平台能够有效解决,SaaS企业在快速低成本开发迭代产品线和功能,响应大客户定制化需求的痛点。头部SaaS企业大概率会自己研发构建aPaaS平台,规模次之的中大型SaaS企业,往往很难下决心投入长周期和高成本去自己构建,直接采购成熟的平台融入自身是较优的办法。不过这里的很大问题在于,中国的SaaS企业,绝大多数都处在水深火热之中,第一阶段的获客销售问题还没解决好,在构建aPaaS上可能决心不足。

成为企业中台解决方案商。基于低代码开发平台,帮助企业构建完整业务中台和数据中台能力,快速、低成本完成企业所有业务应用的开发和迭代,同时灵活、快速响应外部变化。让低代码中台成为企业信息化建设和智能化应用的入口,延伸出应用商城平台等更大的想象空间。在当前中台尚处于早期落地阶段,该模式需要找到痛点最强的企业客户,同时也会面临已有中台解决方案商的竞争。

以上5大类商业模式,还可以从另一个维度去考量推敲:是直接售卖平台工具,还是基于工具售卖服务,以及售卖什么服务。

低代码创投机会创业入局不晚投资有早期机会

国内的低代码开发通用平台玩家,大多在2014年后启动相关业务,整体发展非常早期,尚处于产品初步落地、商业化探索阶段,营收大多在数百万元、千万元级别

目前奥哲网络是国内低代码领域发展规模靠前的企业,我们也做过详细报道。奥哲成立于2010年,以BPM产品切入流程管理领域,2014年,推出公有云BPM产品“氚云”,2019年,推出“业务中台”概念的低代码平台“云枢”。

奥哲网络2018年营收已过亿元,其商业逻辑是,轻量级零代码产品“氚云”基于钉钉平台获取大量客户流量,将一些有更多需求的中大型企业,引流至BPM和云枢业务,赚取高客单价的业务收入。

对比国外的头部企业,OutSystems目前在 25 个国家拥有 400 多家企业客户,包括丰田,罗技,德勤,施耐德电气和通用金融等,ARR(年度经常性收入)远高于1亿美元,并且每年增长率超过70%,估值超过10亿美元。

相比之下,国内创业公司还有非常大的成长空间,目前估值大多在2亿元以内,数倍PS,存在较合理的早期投资机会,且大多低代码创业公司都正在融资

创业机会方面,虽然aPaaS的技术门槛较高,需要创业团队过往有多年的aPaaS经验,并投入数年的平台构建和打磨时间,但是低代码开发市场目前在国内依然处于非常早期阶段,需要技术产品和市场教育的进一步成熟,这就给了想进入该领域的创业公司宝贵的时间窗口,所以我们判断依然有新入局创业公司的机会

RPABPM中台低代码背后是一个趋势

当我们观察了BPM、RPA、中台、低代码这些似乎关联性不大的技术服务后,发现了一些很有意思的关联性和共通点。

这些技术服务其实都在响应一个共同的大趋势:企业要打破信息系统孤岛,快速迭代响应外部快速变化的市场环境,同时降本增效,提升内部生产力。

在这个大趋势下:

传统BPM基于企业已有的各个系统,通过代码开发、接口对接的方式,构建一个贴合客户业务流程的系统。

RPA则是规避了错综复杂的底层开发和对接,直接基于界面操作的手段,很取巧的完成大量“规则固定,重复性高”的工作,快速在各个系统孤岛嫁接桥梁,形成新的业务流。

中台则是想从根本上解决问题,在企业原有系统之上,搭建了数据和业务中台,把这些企业各类数据、业务接口都整合好,由中台统一向上输出干净、有条理、标准化的数据和业务能力,更像是“中医”疗法。

低代码则想进一步提高中台的效率,通过开发效率的数倍提升,解决中台落地时,项目制、模式重的问题。相比于BPM和RPA,低代码除了解决已有系统的和打通串联问题,还可以直接构建新应用,场景其实更广。

当然,这并不是说未来一定是某一项技术的天下,在企业信息化发展参差不齐、市场应用场景广阔复杂、技术持续发展演进的背景下,这些技术会以合适的方式组合融合,服务于合适的应用场景。

事实其实已经如此,奥哲的BPM业务通过低代码技术快速开发交付;UiPath等RPA企业基于拖拉拽的图形化操作方式设计RPA流程,其实就是特定场景的低代码应用;数式网络基于低代码提供中台解决方案;轻流也将RPA工具集成到了低代码解决方案。

最终一切还是归结到一个根本问题:为什么客户,在什么场景,提供什么核心价值,产生多大商业回报。技术归根到底是工具,至于用什么工具,其实从来不绝对。

结语

回归冷静,我们看到低代码的发展依然处于早期探索阶段,即便是全球最领先的公司OutSystems,成立于2001年,发展至今接近20年,估值超过10亿美元,其实也并不是一个很亮眼的成绩。

低代码开发到底能适应多广泛场景?做出多复杂应用?效率能提高1倍还是10倍?商业模式如何设计?卖工具产品还是卖服务?卖什么服务?怎么收费?市场什么时候能真正起来?等等。这些问题都有待低代码创业公司、企业、投资人等去摸索和解答。

我们先不去揣测终局,是否会诞生新的开发语言、应用生态、新的企业信息架构,我们更希望看到产业从业者能够打磨好工具利器,真正扎根落地,解决问题,产生价值,而非炒概念、造热点、吹泡沫。

我们期待着,在古老的软件开发领域,能产生一次生产力大变革。

36氪本着伴随产业一起成长的初衷,撰写了本篇文章,由于时间、资源、视野有限,本文难免出现错误、片面等问题,欢迎各位指正交流。

我是36氪分析师陈绍元,持续关注低代码领域的发展。欢迎与我交流行业或寻求报道,我的微信:963757163,添加后请注明公司、职位、姓名



作者:36氪
链接:https://xueqiu.com/5215025851/131738118
来源:雪球
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
风险提示:本文所提到的观点仅代表个人的意见,所涉及标的不作推荐,据此买卖,风险自负。