一种基于多场景应用的自动构建功能组件的方法与流程

1.本发明涉及计算机技术领域，尤其涉及一种基于多场景应用的自动构建功能组件的方法。


背景技术：

2.由于银行业受理的客户需求主体一致，但每个客户又在基础需求满足的条件下，会额外提出特色化要求，这就导致银行内针对每一类客户需求都进行需求开发，需要大量的重复开发，耗费大量人力资源。例如：银行受理各个集团客户发起的批量代发委托时，存在a客户要求代发完成短信通知，b客户要求银行受理任务前需要审核，c客户要求提供代发数据统计，d客户要求代发审核需要双人复核等各类特色需求，但无论增加多少的额外需求，整个业务场景的主体需求是银行接收代发单位的批量代发任务，完成资金发放工作。
3.在申请号为cn201911341274.6的发明专利申请文件中提到了一种组件化构建应用场景的快捷实施方法，所述方法包括以下步骤：步骤a，进行场景分析；步骤b，进行场景组件化；步骤c，进行场景配置；步骤d，进行配置信息解析；步骤e，进行构建应用；步骤f，进行部署应用。该发明提供的组件化构建应用场景的快捷实施方法提高了应用场景的构建效率，减少重复开发交付时间。但这种方法主要应用于游戏类应用场景开发领域。
4.在申请号为cn201910987691.1的发明专利申请文件中提到了一种标签配置方法、装置及计算机存储介质，解决了相似标签无法重用，新增和更新标签时工作量大的技术问题。在本发明实施例中，获取组件信息，根据组件信息构建标签原子组件，将标签原子组件加入原子组件集合；获取标签信息，根据标签信息从原子组件集合中选择标签原子组件；基于所选标签原子组件构建标签。本发明实施例将标签组件化，基于标签原子组件构建标签，使得复杂的标签能够通过多个标签原子组件拼接形成，相似标签只要构成的标签原子组件相同，即可重用，避免重复开发。新增或更新标签时，只需新增或更新标签原子组件，由该标签原子组件构建的标签均可得到更新，大幅减少工作量，降低更新或新增标签上线的难度。但该发明针对的是标签管理问题，并不能解决银行业受理的客户需求主体一致，但每个客户又在基础需求满足的条件下，会额外提出特色化要求，导致银行内针对每一类客户需求都进行需求开发，需要大量的重复开发，耗费大量人力资源的行业问题。


技术实现要素：

5.本发明的目的在于提供一种基于多场景应用的自动构建功能组件的方法，旨在解决现有技术中银行内需要针对每一类客户的需求进行需求开发，需要大量的重复开发，耗费大量人力资源的问题。
6.为实现上述目的，本发明提出一种基于多场景应用的自动构建功能组件的方法，其包括以下步骤：s1：功能模块标准化、组件化：对接入的应用场景提供的服务进行清单化；s2：注册新增组件：复用场景组件库中已存在的功能组件，新增缺失的功能组件；
s3：配置文件：确定应用需求，根据应用需求对接入的应用场景定义其专属配置文件；s4：调度机制生效，进行逻辑处理：定义完成配置文件后，通过解析制度和调度机制配合完成该应用场景的专属配置文件的解析，调用对应的功能组件完成应用处理。
7.更进一步的，所述配置文件用于记录该应用场景从提供服务开始需要先后执行的逻辑流程。
8.更进一步的，所述s1在接入应用场景之前包括以下步骤：s00：接入新的应用场景，确定该应用场景需要提供的功能组件；s01：按照功能组件名称和功能在场景组件库记录表中进行模糊搜索，判断所需功能组件是否存在于场景组件库记录表中；s02：订阅存在于场景组件库记录表中的所需功能组件，新增不存在于场景组件库记录表中的所需功能组件，解除组件间的依赖关系；s03：将s02中新增的功能组件增加到场景组件库记录表中。
9.更进一步的，所述s03中将新增的功能组件增加到场景组件库记录表中还包括：依次记录新增功能组件名、功能概述、输入参数、输出参数，以及定义新增组件成功执行完成的输出值、异常输出值、每个定义的异常输出值对应的后续流程组件名。
10.更进一步的，所述场景组件库记录表用于记录已开发的功能组件信息，定义功能组件输入输出参数及异常处理流程。
11.更进一步的，所述s4具体包括以下子步骤：s41：初始化业务场景控制表；s42：启动解析机制，读取流程配置文件；s43：利用解析机制读取上一流程组件名、当前流程组件名及下一流程组件名；s44：更新业务场景控制表，将解析机制读取的三个组件名更新至业务场景控制表中；s45：平台执行调度机制，执行当前流程的功能组件；s46：更新业务场景控制表，将s45中功能组件执行结果会写入业务场景控制表中；s47：查询场景组件库，判断该组件执行结果是否成功，若是，则跳转至s48，若否，则跳转至s49；s48：判断下一流程是否结束，若是，则结束服务，若否，则重复s43，执行下一流程的功能组件；s49：根据场景组件库记录表的定义执行异常流程，结束应用服务。
12.更进一步的，所述s47中通过获取该功能组件的输出参数及功能组件名，查询场景组件库记录表。
13.更进一步的，所述业务场景控制表记录该场景当前逻辑流程执行的组件信息。
14.本技术的有益效果：（1）有效降低开发成本，通过功能组件配置化管理，通过一系列组件的定制、加载、运行就可快速实现业务需求；（2）通过复用在用的功能组件可有效降低新项目生产运行事故风险；（3）通过单个功能组件的升级就可快速实现共性需求的所有项目迭代升级，极大
地降低人工开发成本；（4）通过新增功能组件开发标准化、统一化，实现平台组件源代码可读性强，便于升级、改造、排错处理，有效降低所有定制化的项目后期运维成本。
附图说明
15.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据附图的结构获得其他的附图。
16.图1为本发明总流程图；图2为本发明新应用场景接入前准备流程图；图3为本发明逻辑处理流程图；本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
17.应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
18.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
19.需要说明，本发明实施例中所有方向性指示（诸如上、下、左、右、前、后
……
）仅用于解释在某一特定姿态（如附图所示）下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。
20.另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当人认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。
21.针对银行业受理的客户需求主体一致，但每个客户又在基础需求满足的条件下，额外提出特色化要求，导致银行内针对每一类客户需求都进行需求开发，导致大量的重复开发，耗费大量人力资源。例如：银行受理各个集团客户发起的批量代发委托时，存在a客户要求代发完成短信通知，b客户要求银行受理任务前需要审核，c客户要求提供代发数据统计，d客户要求代发审核需要双人复核等各类特色需求，但无论增加多少的额外需求，整个业务场景的主体需求是银行接收代发单位的批量代发任务，完成资金发放工作。
22.为解决以上技术问题，特提出一种基于多场景应用的自动构建功能组件的方法。
23.为便于理解，提出以下具体实施例：在本实施例中，如图1所示，本发明提出一种基于多场景应用的自动构建功能组件的方法，其包括以下步骤：s1：功能模块标准化、组件化：对接入的应用场景提供的服务进行清单化；s2：注册新增组件：复用场景组件库中已存在的功能组件，新增缺失的功能组件；s3：配置文件：确定应用需求，根据应用需求对接入的应用场景定义其专属配置文件；
s4：调度机制生效，进行逻辑处理：定义完成配置文件后，通过解析制度和调度机制配合完成该应用场景的专属配置文件的解析，调用对应的功能组件完成应用处理。
24.在本实施例中，所述配置文件用于记录该应用场景从提供服务开始需要先后执行的逻辑流程。
25.在本实施例中，所述s1在接入应用场景之前包括以下步骤：s00：接入新的应用场景，确定该应用场景需要提供的功能组件；s01：按照功能组件名称和功能在场景组件库记录表中进行模糊搜索，判断所需功能组件是否存在于场景组件库记录表中；s02：订阅存在于场景组件库记录表中的所需功能组件，新增不存在于场景组件库记录表中的所需功能组件，解除组件间的依赖关系；s03：将s02中新增的功能组件增加到场景组件库记录表中。
26.在本实施例中，所述s03中将新增的功能组件增加到场景组件库记录表中还包括：依次记录新增功能组件名、功能概述、输入参数、输出参数，以及定义新增组件成功执行完成的输出值、异常输出值、每个定义的异常输出值对应的后续流程组件名。
27.在本实施例中，所述场景组件库记录表用于记录已开发的功能组件信息，定义功能组件输入输出参数及异常处理流程。
28.在本实施例中，所述s4具体包括以下子步骤：s41：初始化业务场景控制表；s42：启动解析机制，读取流程配置文件；s43：利用解析机制读取上一流程组件名、当前流程组件名及下一流程组件名；s44：更新业务场景控制表，将解析机制读取的三个组件名更新至业务场景控制表中；s45：平台执行调度机制，执行当前流程的功能组件；s46：更新业务场景控制表，将s45中功能组件执行结果会写入业务场景控制表中；s47：查询场景组件库，判断该组件执行结果是否成功，若是，则跳转至s48，若否，则跳转至s49；s48：判断下一流程是否结束，若是，则结束服务，若否，则重复s43，执行下一流程的功能组件；s49：根据场景组件库记录表的定义执行异常流程，结束应用服务。
29.在本实施例中，所述s47中通过获取该功能组件的输出参数及功能组件名，查询场景组件库记录表。
30.在本实施例中，所述业务场景控制表记录该场景当前逻辑流程执行的组件信息。
31.具体的说，本方法提供具有共性需求的多应用场景快速实现的一种策略，避免共性功能组件重复开发，以提高代码的通用性和可复用性。
32.本方法对接入的应用场景提供的服务进行清单化，复用场景组件库中已存在的功能组件，同时新增缺失的功能组件；在应用需求确定，也即是对外提供的服务明确后，对接入的应用场景定义其专属配置文件，该配置文件记录该应用场景从提供服务开始需要先后执行的逻辑流程，先执行哪个功能组件，后续执行哪个组件......最后执行哪个组件；定义完成配置文件后，由本方法的解析机制和调度机制配合完成解释该应用场景的配置文件以
及调用对应的功能组件完成整个应用处理。
33.如图2所示，在接入新应用场景的准备阶段，需要确保场景组件库记录表1中具备该应用场景需要的所有功能组件，再根据实际应用需求定制该应用场景的配置文件。
34.首先确定应用需求，明确该应用场景需要提供的功能清单。将梳理的功能组件在场景组件库中依照组件名或功能进行模糊搜索，订阅匹配到的功能组件；对于缺失的功能组件，进行新增处理，在新增遵循单元功能模块化、组件化，输入输出标准化，解除组件间的依赖关系；完成新增功能组件的开发、封装后，将新增功能组件增加到场景组件库记录表1，依次记录新增组件名、功能概述、输入参数、输出参数，以及定义新增组件成功执行完成的输出值（默认输出0）、异常输出值，每个定义的异常输出值对应的后续流程组件名。确定场景组件库记录表1中具备该应用场景需要的所有功能组件后，遵循本方法定义的格式要求，定义该应用场景的配置文件，在配置文件中按照逻辑处理流程的先后顺序，记录第一个功能组件名、第二个组件名、第三个组件名......第n个组件名。
35.接入新应用场景的准备工作完成后，即可在本装置中对外提供服务，通过本方法的解析机制和调度机制配合完成解释该应用场景的配置文件以及调用对应的功能组件完成整个应用处理。
36.如图3所示，在本装置中对新应用场景开始提供服务时，先初始化业务场景控制表2，启动解析机制读取前两个功能组件名（第一个组件名、第二个组件名）并分别写入业务场景控制表2中的当前组件列、下一组件列；启动调度机制执行业务场景控制表2中的当前组件列中的功能组件，执行完成后获取该组件的输出参数i，根据该输出参数i以及功能组件名查询场景组件库记录表1，判定该组件执行结果是否成果或异常：如果异常则根据场景组件库记录表1的定义执行异常流程，结束应用服务；如果组件执行成功，由本装置的调度机制执行业务场景控制表2中的下一组件列的组件。待第一轮功能组件执行完毕，由本装置的解析机制读取应用场景的配置文件的第二轮功能组件清单，同时更新业务场景控制表2，进行第二轮的组件调用......，如此反复，直到整个应用处理完毕，本次新应用场景提供服务结束。
37.本技术的有益效果：（1）有效降低开发成本，通过功能组件配置化管理，通过一系列组件的定制、加载、运行就可快速实现业务需求；（2）通过复用在用的功能组件可有效降低新项目生产运行事故风险；（3）通过单个功能组件的升级就可快速实现共性需求的所有项目迭代升级，极大地降低人工开发成本；（4）通过新增功能组件开发标准化、统一化，实现平台组件源代码可读性强，便于升级、改造、排错处理，有效降低所有定制化的项目后期运维成本。
38.以上所述仅是本发明的优选实施方式，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。