CN114637747A - 用于能源行业交互式互动平台的数据处理方法 - Google Patents

Abstract

本申请实施例提出了用于能源行业交互式互动平台的数据处理方法，包括基于低代码开发模块中的前端拖拽式界面对表单进行配置；在服务端基于表结构对象化设计元数据模型。能够实现前端应用的组件式高效率、高交互性开发、高可扩展性、高可维护性、易用性等特点，同时有效降低开发门槛，快速自主开发业务应用，可以大幅减少应用开发成本支出，缩短应用开发上线周期，快速响应业务运营变革和创新等各类需求。

Description

用于能源行业交互式互动平台的数据处理方法

技术领域

本申请涉及数据处理领域，尤其涉及用于能源行业交互式互动平台的数据处理方法。

背景技术

企业开展信息化建设和数字化转型，软件研发是必要的手段和途径。传统应用定制的研发模式，有诸多短板和限制，亟待寻求一种交互式的并且能够快速开发迭代的统一数字化模型开发方案。例如研发人员能力方面有着许多要求，如研发人员受限于对技术栈的掌握水平不同等；对于越来越繁杂的研发要求，开发方法是否能更浅显易懂、更易于交互，甚至能让业务人员也可参与其中也成为越来越受关注的事项。随着大数据、人工智能、互联网的快速发展，传统的软件定制开发方式已经无法满足企业高速发展的需求：既要满足个性化定制又要实现快速开发，用传统的编写代码方式是很难突破，一方面企业应用开发人力成本过高，后期维护及二次开发难度大，从而增加企业的运营成本给企业带来不少的压力，以上种种都会给企业进行软件研发，开展信息化建设和数字化转型带来负面影响，如何改变现有研发情况，构建一个统一可管控的数字化模型研发平台变得越来越重要。

发明内容

本申请实施例提出了用于能源行业交互式互动平台的数据处理方法，能够实现前端应用的组件式高效率、高交互性开发、高可扩展性、高可维护性、易用性等特点，同时有效降低开发门槛，快速自主开发业务应用，可以大幅减少应用开发成本支出，缩短应用开发上线周期，快速响应业务运营变革和创新等各类需求。

所述数据处理方法包括：

S1，基于低代码开发模块中的前端拖拽式界面对表单进行配置；

S2，在服务端基于表结构对象化设计元数据模型。

可选的，所述数据处理方法包括：

S11，针对表单进行表单格式定义，根据定义的内容完成模型构建；

S12，构建表单拖拽式设计器；

S13，基于构建后的表单模型，进行拖拽式的表单布局调整，并基于表单引擎对表单内的命令进行解释执行。

可选的，所述S11包括：

S111，构建表单元数据设计结构；

S112，根据数据设计结构对表单的布局进行规划；

S113，基于JSON描述中定义基础信息维护模块，用于根据展示出的信息进行布局中数据的索引构建。

可选的，所述S112包括：

单一型布局，一张Form表单只有一个大的控件元素；

上下型布局，通过多行设置多个表单部件；

上左右下型布局，页面分上、左、右和下四部分；

上左中右下型布局，页面布局分为上、左、中、右及下5个部分。

可选的，所述S12包括：

表单设计器为左中右三栏布局，

左侧是控件列表，列出了设计器支持的表单控件；

中间部分是画布，左侧的控件可直接拖拽到画布中，并支持包括控件调整顺序、复制在内的操作；

右侧是表单字段的配置区域，在画布中选中一个字段，右侧将展示此字段的所有属性用于执行包括配置字段标题、描述、校验规则在内的操作。

可选的，所述S13包括：

客户端发出页面访问申请；

引擎调用表单库管理器将表单编号传递过来，获得表单的定义信息；

根据表单定义信息获取表单布局模版类型，调用表单布局模版管理器获得表单布局模板；

根据表单定义得到表单内部部件的类型，调用表单内容模版管理器获得表单内部组件的布局模版；

根据元数据引擎的数据访问服务获得表单需要呈现的数据；

将表单布局模版、表单内部组件布局模版和表单定义以及数据结合，由表单引擎最终生成渲染出表单界面。

可选的，所述S2包括：

S21，元数据模型设计；

S22，定义实体之间的关系；

S23，元数据提供的数据访问接口；

S24，元数据的执行。

可选的，所述S21包括：

采用面向对象的设计理念，使用XMLSchema来定义元数据格式；

其中，元数据模型包括：

应用，指具体的应用信息属性，通过这样的树状表现结构，将软件系统的层次进行明确的划分；

实体，指数据结构的逻辑模型；

目录，使用目录的结构方式把各种实体组织在一起。

可选的，所述S22包括：

描述实体与实体之间通过实体属性发生的关联关系。

可选的，所述S23包括：

由两个服务接口类来实现：MetaService和DataService；

MetaService；提供对元数据的定义的访问，包括获取元数据的定义信息，如字段类型，字段长度描述在内的描述信息；

DataService；提供的是对数据的操作。

可选的，所述S24包括：

元数据引擎的底层实现原理及调用过程。

有益效果：

(1)覆盖需求广：交互式互动平台开发框架一般可以覆盖各类常见的业务管理需求(如生产管理、人事管理、进销存、合同、客户管理等)，只要有数据收集、分析、协作等需求，就可以直接搭建。便于国网内部快速推进各类信息化平台和应用的落地，降低了技术选型带来的时间成本，同时通过同一类类型的开发平台进行实现，解决了各个应用系统之间不同的技术栈问题。

(2)技术要求少：即使是没有软件开发专业基础的人员，也能快速上手。信息化部门无需耗费大量时间在应用搭建上，各业务部门都能搭建自己的管理应用，有助于实现团队的信息化自助。一方面降低了开发人员的门槛，有效减少人员招聘的成本消耗，以及人员流动带来的技术储备问题。同时，让业务部门参与到开发过程中，能够快速将需求转化成应用，避免了业务人员和开发人员在业务理解上偏差造成的沟通成本增加，大大提升开发对业务的交付价值。

(3)后期迭代易：业务发生变化时，维护人员直接在后台修改应用，即可实现业务管理应用的迭代，一般1～2天就能完成迭代，有效降低迭代成本，关键是真正实现了对于需求的快速响应和业务价值交付。相对于传统应用迭代一次需要数周乃至若干月，产生的业务价值是不可估量的，并且将大幅提升客户满意度。

(4)开发提速为IT团队价值转型赋能：传统的开发模式僵固化，开发周期长而成本高，难以根据企业业务变化而改变。交互式互动平台开发框架让管理系统可伴随业务变革不断进化升级，大幅缩短开发周期、降低开发成本、提高开发质量，让IT团队由典型的成本导向型组织向价值输出型组织转型。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提出的用于能源行业交互式互动平台的数据处理方法的流程示意图。

具体实施方式

为使本申请的结构和优点更加清楚，下面将结合附图对本申请的结构作进一步地描述。

本发明尝试设计用于能源行业交互式互动平台的数据处理方法，能够实现前端应用的组件式高效率、高交互性开发、高可扩展性、高可维护性、易用性等特点，同时有效降低开发门槛，快速自主开发业务应用，可以大幅减少应用开发成本支出，缩短应用开发上线周期，快速响应业务运营变革和创新等各类需求。

本发明设计出用于能源行业交互式互动平台的数据处理方法，如图1所示，能够解决现有技术中缺乏交互式应用的问题。

S1，基于低代码开发模块中的前端拖拽式界面对表单进行配置；

S2，在服务端基于表结构对象化设计元数据模型。

在实施中，表单模型的设计包括如下几个方面：

a)表单元数据设计体系

元数据各控件schema定义如下表述：

1)模块控件(module)

模块含有编码(code)、名称(name)和名称(displayName)属性。

2)表单控件(form)

表单具有这些属性。其中metaData属性指的是其绑定的元数据实体，表单要展现的就是这种元数据实体的内容。

3)表格控件(gridComponent)

表格组件含有名称(name)、宽度(width)、布局索引(layoutIndex)、元数据绑定(metaData)、默认宽度(defaultWidth)、初始SQL查询(initSql)和明细表单(detailForm)这些属性。

4)列控件(column)

列属性是用来描述元数据的属性即数据库的字段以表格列方式展现的元素。

5)表头组件包含名称(name)、宽度(width)、高度(height)、标题(caption)、布局索引值(layoutIndex)、布局列数(columns)、缺省标签宽度(defaultLabelWidth)、缺省录入宽度(defaultInputWidth)、初始化SQL(initSql)、元数据(metaData)。

6)表头项控件(vourchItem)

表头项对应于具体的输入项。

7)表单控件(vourchGridComponent)

表单组件有名称(name)、显示名称(caption)、宽度(width)、绑定元数据(metaData)、布局索引(LayoutIndex)、主表元数据(mainData)、明细表元数据(detailData)、主从表关联属性(detailParentKey)、初始化SQL语句(initSql)属性。

b)表单的布局

表单先预设好几种布局形式，对于布局的块进行编号，表单常见的有以下几种布局：

1)单一型布局：一张Form表单只有一个大的控件元素，例如表格控件，页面布局对应于控件的layoutIndex属性。

2)上下型布局：通过多行设置多个表单部件。

3)上左右下型布局：页面分上、左、右和下四部分。

4)上左中右下型布局：页面布局分为上、左、中、右及下5个部分。

表单模型定义：

该JSON描述中定义了一个叫“基础信息维护”的模块。该模块下包含一个表单，名字叫“人员列表”，对应的元数据定义是“User”。该表单包含一个列表控件(GridComponent)，就是以表格的方式展现人员信息。布局索引是1，指的是该组件放置在布局模板中的1号位置。人员信息包含userId,name,address,sex,comments等属性，在属性定义中指定了显示名称，显示列宽度等信息。

表单拖拽式设计器的结构类似设计软件的布局。表单设计器一般为左中右三栏布局；左侧是控件列表，列出了设计器支持的表单控件；中间部分是画布(canvas)，左侧的控件可直接拖拽到画布中，并支持控件调整顺序、复制等操作；右侧是表单字段的配置区域，在画布中选中一个字段，右侧将展示此字段的所有属性，用户可在此处配置字段标题、描述、校验规则等。

表单设计器的输出是一份描述表单字段的JSON Schema，表单设计完成后JSONSchema将直接存储到后端。表单发布后，前端再根据JSON Schema渲染表单。表单中所有字段的信息都是存储在Schema中，所以每次对表单的更新都是修改Schema中的内容，无需传统的编译过程。

JSON Schema是表单设计器和表单渲染组件之间沟通的语言。

定义如下：

表单由多个input控件组成，input控件包含多种形式，如：文本、数字、单选和多选等。Schema中除了描述字段对应的是哪种类型的input外，还需要描述控件的行为，例如是否限制输入长度，是否必填等。有了这些描述后，表单渲染组件才能根据Schema渲染出符合预期的表单。

在上面的类型定义中：

component表示该字段用什么input组件渲染；componentProps表示传给组件的props，用于控制组件的行为；type表示组件接受和期望返回的数据类型；FieldKey是字段在表单中的唯一标识，用户侧不透出；title表示表单中字段对应的label，它的值用户可读。

表单设计器的任务将已有的JSON Schema作为输入，对Schema中的字段做添加、删除和更新操作，最后输出Schema。整体来看，表单就是对每个控件的操作进行组合，组合的结果就是完整的JSON Schema。为了能够实现对表单字段的修改，在表单设计器中提供了字段配置区域，用户在配置区域中，可以通过可视化方式定义字段属性，而无需关心Schema的具体格式。表单设计器负责将配置值转化成Schema，同时也负责将Schema转化成配置值，用来回显配置后的页面表单。

表单引擎的解释执行过程如下：

客户端发出页面访问申请，如访问人员列表表单，访问地址是http；//localhost；8080/platform/form？formId＝userlist&querydatas＝all，解析地址获知访问的表单是userlist。引擎调用表单库管理器将表单编号“userlist”传递过来，获得表单的定义信息。根据表单定义信息获取表单布局模版类型，调用表单布局模版管理器获得表单布局模板。根据表单定义得到表单内部部件的类型，调用表单内容模版管理器获得表单内部组件的布局模版。根据元数据引擎的数据访问服务获得表单需要呈现的数据。将表单布局模版、表单内部组件布局模版和表单定义以及数据结合，由表单引擎最终生成渲染出表单界面。元数据模型设计，交互式快速开发框架中，后端开发需要设计的元数据结构如下：

1)App(应用)包含的属性有id(编号),label(标签),PlatVersion(平台版本)。

2)Directory(元数据目录)目录包含名称、ID。

3)元数据实体，属性包含元数据实体ID、实体名称、表名。

4)属性(Property)属性是最重要的定义，对应于表数据库的字段定义。Property属性描述：

1)length是字符串长度。

2)name属性是区别属性的标志，各种调用以及设定都需要通过name属性来实现。

3)column-name属性是对应的在表格中的字段名称。

4)label属性提供了属性显示的名称。

5)type属性为数据类型。

6)scale是精度，当type设定为浮点类型的时候需要设置。

7)disabled表示是否为禁用。

8)not-null不为空，设置为true的时候说明是必填项。

9)default-value为默认值，初始化的值。

10)display为显示样式的属性，可以在显示中设定显示样式。

11)description是描述信息，类似于备注字段。

12)enum-value是当为枚举类型的时候，可选择的值范围。

13)prompt是提示输入的属性，在页面上可以提示的信息。

14)error-message是出错后的提示信息。

15)tip是帮助信息。

16)display-width是编辑框设定的像素值。

17)max-length是输入选项的最大长度。

18)min-length是输入选项的最小长度。

19)max作为数值类型的时候有效，数值的最大值。

20)min作为数值类型的时候有效，数值的最小值。

例如设定“锅炉房消耗”对象，以“BoilRoomCon”作为元数据的名称属性，标签属性为“锅炉房消耗”，表各列分别为：

1)column-name属性：BoilRoomName。

2)type属性：String。

3)length属性：32。

4)scale属性：空。

5)disabled属性：false(默认)。

6)not-null属性：true。

7)prompt属性：“请输入锅炉房名称”。

8)error-message属性；“锅炉房名必须为字符串！”。

9)display-width属性：70。

4.实体之间的关系

描述实体与实体之间通过实体属性发生的关联关系。与数据建模中的关系是一样的含义。其包含的属性定义包括name(名称)、label(标签)、target-id(目标元数据id)、source-property(关系源属性)、target-property(关系对应目标属性)、delete-rule(级联删除规则)、to-many(一对多关系)、physical(是否为物理表即真实存在的表，非逻辑表)。

5.元数据提供的数据访问接口

元数据模型定义好以后，最终要提供对元数据和数据的操作接口，提供了这些接口才能最终实现数据访问的服务。主要由两个服务接口类来实现：MetaService和DataService。

a.MetaService；提供的是对元数据的定义的访问，包括获取元数据的定义信息，如字段类型，字段长度描述等。

b.DataService；提供的是对数据的操作，基本的增、删、改、查操作等。根据元数据的模型定义，可以知道元数据的基础类有App、Directory、Entity、Property等)。

App中会包含Directory集合，Directory类中包含Entity集合，Entity类包含Property集合。

定义IMetaService和IDataService两个服务接口，由MetaService和DataService类实现这两个接口。

6.元数据提供的数据访问接口

元数据引擎就是提供后端服务的工具，用户提出服务请求如某个数据的检索要求，查询属性编号为“1001”的人员实体。调用元数据引擎方法：findObject(Classcls,Stringid)。如调用findObject(User.class,“1001”)；将会返还一个人员id为1001的User对象。它的实现过程分以下3个步骤：

1.Sql生成器生成sql

元数据sql生成器根据元数据类型是User,获取其User的模型定义信息，获知User的属性及对应的数据字段，字段的类型及长度等，假设User类对应的table－name是tb_user,user的id属性对应的数据库字段是user_id,则sql生成器会生成“select*from tb_user where user_id＝‘1001’”这样的sql语句。

2.执行sql

元数据引擎将生成的sql语句传递给sql执行器，sql执行器调用数据库驱动返回查询结果。

3.将查询结果转成对象返回

元数据引擎将数据库的查询结果转成User对象返回给申请用户。从执行过程中可以看出，元数据引擎根据元数据的模型定义信息来生成SQL，语句，最终的SQL执行还是靠数据库驱动来完成，SQL执行的数据库查询结果，再通过反射等方法创建成对象返回。

以上所述仅为本申请的实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.用于能源行业交互式互动平台的数据处理方法，其特征在于，所述数据处理方法包括：

S1，基于低代码开发模块中的前端拖拽式界面对表单进行配置；

S2，在服务端基于表结构对象化设计元数据模型。

2.根据权利要求1所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述数据处理方法包括：

S11，针对表单进行表单格式定义，根据定义的内容完成模型构建；

S12，构建表单拖拽式设计器；

S13，基于构建后的表单模型，进行拖拽式的表单布局调整，并基于表单引擎对表单内的命令进行解释执行。

3.根据权利要求2所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述S11包括：

S111，构建表单元数据设计结构；

S112，根据数据设计结构对表单的布局进行规划；

S113，基于JSON描述中定义基础信息维护模块，用于根据展示出的信息进行布局中数据的索引构建。

4.根据权利要求3所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述S112包括：

单一型布局，一张Form表单只有一个大的控件元素；

上下型布局，通过多行设置多个表单部件；

上左右下型布局，页面分上、左、右和下四部分；

上左中右下型布局，页面布局分为上、左、中、右及下5个部分。

5.根据权利要求2所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述S13包括：

客户端发出页面访问申请；

引擎调用表单库管理器将表单编号传递过来，获得表单的定义信息；

根据表单定义信息获取表单布局模版类型，调用表单布局模版管理器获得表单布局模板；

根据表单定义得到表单内部部件的类型，调用表单内容模版管理器获得表单内部组件的布局模版；

根据元数据引擎的数据访问服务获得表单需要呈现的数据；

将表单布局模版、表单内部组件布局模版和表单定义以及数据结合，由表单引擎最终生成渲染出表单界面。

6.根据权利要求1所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述S2包括：

S21，元数据模型设计；

S22，定义实体之间的关系；

S23，元数据提供的数据访问接口；

S24，元数据的执行。

7.根据权利要求6所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述S21包括：

采用面向对象的设计理念，使用XMLSchema来定义元数据格式；

其中，元数据模型包括：

应用，指具体的应用信息属性，通过这样的树状表现结构，将软件系统的层次进行明确的划分；

实体，指数据结构的逻辑模型；

目录，使用目录的结构方式把各种实体组织在一起。

8.根据权利要求6所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述S22包括：

描述实体与实体之间通过实体属性发生的关联关系。

9.根据权利要求6所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述S23包括：

由两个服务接口类来实现：MetaService和DataService；

MetaService:提供对元数据的定义的访问，包括获取元数据的定义信息，如字段类型，字段长度描述在内的描述信息；

DataService:提供的是对数据的操作。

10.根据权利要求6所述的用于能源行业交互式互动平台的数据处理方法，其特征在于，所述S24包括：

元数据引擎的底层实现原理及调用过程。

Images