CN111666098A - 基于业务组件创建toB工程的方法及系统 - Google Patents

Abstract

本发明公开基于业务组件创建toB工程的方法及系统，其中，该方法包括：根据用户需求生成工程目录清单，根据功能ID查询功能仓库中是否已存在需要的目录项，若查询到需要的目录项，则获取该目录项所在工程的npm包，创建新工程并将npm包安装到新工程中，或者同时获取该目录项所在工程的npm包、页面配置文件和工程菜单配置文件以直接创建生成新工程；若未查询到需要的目录项，则按照工程目录清单创建新工程；将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将新工程的npm包存储到npm仓库中。该系统采用上述方法，方便快捷的将业务组件的复用到新的项目工程中，降低了项目定制的成本，减少了开发的工作量。

Description

基于业务组件创建toB工程的方法及系统

技术领域

本发明涉及toB服务技术领域，尤其涉及基于业务组件创建toB工程的方法及系统。

背景技术

在toB领域云服务项目的前端设计和开发中，通常做法是需求梳理完成后，基于项目开发的基线版本分出一个分支，然后对该分支进行定制开发，这种做法是典型的基线版本+定制版本的toB项目开发策略，但这种常规策略存在许多缺点和不足：

1、需要手动到基线版本或定制版本的代码分支中去抽取所需要的业务组件的代码及配置信息；

2、由于不同项目的业务组件在页面展示的方式存在许多差异，带来不必要的改造工作量(比如调整路由、更改页面等)，但是这些改造工作量与业务需求本身没有关系；

3、一方面，由于基线版本与各个分支的定制版本差异巨大，将各个分支进行归一的成本和风险非常巨大；另一方面，如果各个分支不进行归一，则时间越久，各个分支之间差异越大，进而更加无法合并，导致需要投入更多的人力进行项目维护，增加成本；

4、由于toB市场的特殊性，大规模的服务项目交付时往往需要引入合作资源，如SI和ISV，若采用基线版本+定制版本的toB项目开发策略，使得代码需要完全开放给第三方合作厂商，进而导致公司核心资产有泄露风险。

发明内容

本发明的目的在于提供基于业务组件创建toB工程的方法及系统，能够方便快捷的根据业务需求将已有的工程、操作流或者业务组件复用到新的项目工程中，降低了项目定制的成本，减少了开发的工作量。

为了实现上述目的，本发明提供如下技术方案：

一种基于业务组件创建toB工程的方法，包括：

根据用户需求生成工程目录清单，所述工程目录清单包括目录项的名称和功能ID，所述目录项按照层级从大到小依次包括工程、操作流和业务组件；

按照层级从大到小的顺序，根据功能ID查询功能仓库中是否已存在需要的目录项，直至查询到需要的目录项或者查询完毕为止；

若查询到需要的目录项，则获取所述目录项所在工程的npm包，或者同时获取所述目录项所在工程的页面配置文件和工程菜单配置文件；利用所述npm包和所述页面配置文件直接创建生成新工程，或者按照所述工程目录清单创建新工程并将所述npm包安装到新工程中；若未查询到需要的目录项，则按照所述工程目录清单创建新工程；

将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将所述新工程的npm包存储到npm仓库中。

具体地，所述工程目录清单中，一个工程包括一个或多个操作流，一个操作流由一组具有关联关系的业务组件构成，一个业务组件对应一个用户需求点；

每个工程、操作流及业务组件分别对应唯一的功能ID。

优选地，根据功能ID查询功能仓库中是否已存在需要的目录项的方法包括：

调用功能仓库的查询接口，根据工程的功能ID查询所述功能仓库中是否已存在需要的工程；

如果所述功能仓库中存在需要的工程，则不再查询所述功能仓库中是否已存在构成所述工程的操作流；如果所述功能仓库中不存在需要的工程，则根据工程包含的操作流的功能ID逐一查询所述功能仓库中是否已存在需要的操作流；

如果所述功能仓库中存在需要的操作流，则获取所述操作流所在工程的功能ID，不再查询所述功能仓库中是否已存在构成所述操作流的业务组件；如果所述功能仓库中不存在需要的操作流，则根据所述操作流包含的业务组件的功能ID逐一查询所述功能仓库中是否已存在需要的业务组件；

如果所述功能仓库中存在需要的业务组件，则获取所述业务组件所在操作流的功能ID，进而获取所述操作流所在工程的功能ID；如果所述功能仓库中不存在需要的业务组件，则直接结束查询操作。

进一步地，如果在所述功能仓库中存在需要的工程，则获取工程的npm包、页面配置文件和工程菜单配置文件，利用所述npm包、所述页面配置文件和工程菜单配置文件直接创建生成新工程；

如果在所述功能仓库中查询到需要的操作流或业务组件，则根据所述操作流或业务组件所在工程的功能ID获取工程的npm包，创建新工程并将所述npm包安装到新工程中。

优选地，获取工程的npm包的方法包括：

根据工程的功能ID在所述功能仓库中获取工程的npm包名，或者同时获取工程的页面配置文件；

根据所述npm包名从所述npm仓库中查询并获取对应的npm包。

优选地，按照所述工程目录清单创建新工程的方法包括：

创建工程的工程菜单配置文件、页面配置文件、操作流配置文件和业务组件配置文件，其中，

所述业务组件配置文件包括业务组件的逻辑功能实现文件和配置信息；

所述操作流配置文件包括业务组件之间的关联关系；

所述页面配置文件包括页面所包含的业务组件的列表；

所述工程菜单配置文件包括每个业务组件的布局信息。

具体地，将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将所述新工程的npm包存储到npm仓库中的方法包括：

将所述新工程通过npm工具进行打包并命名，得到npm包；

将所述npm包上传至npm仓库；

将所述新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件上传到功能仓库进行结构化存储。

优选地，所述npm包中包括所述操作流配置文件和所述业务组件配置文件。

一种基于业务组件创建toB工程的系统，包括目录清单生成模块和工程创建模块，所述工程创建模块包括查询单元、复用单元、新建单元和沉淀单元，其中，

所述目录清单生成模块用于根据用户需求生成工程目录清单，所述工程目录清单包括目录项的名称和功能ID，所述目录项按照层级从大到小依次包括工程、操作流和业务组件；

所述查询单元用于按照层级从大到小的顺序，根据功能ID查询功能仓库中是否已存在需要的目录项，直至查询到需要的目录项或者查询完毕为止；

所述复用单元用于在查询到需要的目录项时，获取所述目录项所在工程的npm包，或者同时获取所述目录项所在工程的页面配置文件和工程菜单配置文件；

所述新建单元用于利用所述npm包、所述页面配置文件和工程菜单配置文件直接创建生成新工程，或者按照所述工程目录清单创建新工程并将所述npm包安装到新工程中；还用于在未查询到需要的目录项时，按照所述工程目录清单创建新工程；

所述沉淀单元用于将新工程的npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将所述新工程的npm包存储到npm仓库中。

一种电子设备，所述电子设备包括：

至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行前述权利要求1-7任一项所述的基于业务组件创建toB工程的方法。

与现有技术相比，本发明提供的基于业务组件创建toB工程的方法及系统具有以下有益效果：

本发明提供的基于业务组件创建toB工程的方法中，首先根据用户需求生成工程目录清单，然后根据功能ID查询功能仓库中是否已存在需要的目录项，若查询到需要的目录项，则获取该目录项所在工程的npm包，或者同时获取该目录项所在工程的页面配置文件；利用npm包、页面配置文件和工程菜单配置文件直接创建生成新工程，或者按照工程目录清单创建新工程并将npm包安装到新工程中；若未查询到需要的目录项，则按照工程目录清单创建新工程。可见，在确定业务需求后，可以自动将能够实现需求的业务组件及其所在工程的npm包自动复用到新工程中，降低定制交付成本，减少开发工作量。最后，将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将新工程的npm包存储到npm仓库中，以方便于下次进行迭代交付或相似场景的定制开发时，直接根据用户需求查询复用。

本发明提供的基于业务组件创建toB工程的系统，采用上述基于业务组件创建toB工程的方法，通过将业务需求与业务组件建立固定的联系，方便快捷的根据业务需求将业务组件的复用到新的项目工程中，降低了项目定制的成本，减少了开发的工作量。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明实施例中一种基于业务组件创建toB工程的方法流程示意图；

图2为本发明实施例中业务组件的结构示意图；

图3为本发明实施例中页面的结构示意图；

图4为本发明实施例中操作流的封装结构示意图；

图5为本发明实施例中查询目录项并创建新工程的流程示意图；

图6为本发明实施例中创建新工程并存储的流程结构示意图；

图7为本发明实施例中一种电子设备的结构示意图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其它实施例，均属于本发明保护的范围。

实施例一

请参阅图1，本实施例提供的一种基于业务组件创建toB工程的方法，包括：

根据用户需求生成工程目录清单，工程目录清单包括目录项的名称和功能ID，目录项按照层级从大到小依次包括工程、操作流和业务组件；

按照层级从大到小的顺序，根据功能ID查询功能仓库中是否已存在需要的目录项，直至查询到需要的目录项或者查询完毕为止；

若查询到需要的目录项，则获取目录项所在工程的npm包，或者同时获取目录项所在工程的页面配置文件和工程菜单配置文件；利用npm包、页面配置文件和工程菜单配置文件直接创建生成新工程，或者按照工程目录清单创建新工程并将npm包安装到新工程中；若未查询到需要的目录项，则按照工程目录清单创建新工程；

将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将新工程的npm包存储到npm仓库中。

在确定业务需求后，利用该方法不仅可以将能够实现需求的业务组件及其所在工程的npm包复用到新工程中，降低定制交付成本，减少开发工作量，还可以解决传统的基线+定制的toB服务开发策略中常见的问题，让基线与定制的能力可以完美地在一个项目中融合，而不会产生冲突。此外，将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将新工程的npm包存储到npm仓库中，以方便于下次进行迭代交付或相似场景的定制开发时，直接根据用户需求查询复用。

请参阅表1，表1示例的工程目录清单中，一个工程包括一个或多个操作流，一个操作流由一组具有关联关系的业务组件构成，一个业务组件对应一个用户需求点；每个工程、操作流及业务组件分别对应唯一的功能ID，表中的BOMID即为一个唯一的功能ID。值得注意的是，操作流与组件之间是N对N的关系，即一个操作流包含多个组件，一个组件也可能存在于多个操作流之中。

表1工程目录清单示例

本领域技术人员应当明白的是，表1中，工程目录项代表一个前端工程，最终打包生成一个npm包；操作流目录项代表完成一组实现用户需求的业务场景的业务组件的集合，操作流内部的业务组件之间有固有的跳转关系；每个业务组件对应于一个用户需求的业务场景。将功能仓库中没有查询到的目录项标志为todo，todo表示未完成的目录项，即目前功能仓库中没有的组件、操作流和工程。

具体地，如图2所示，业务组件Component包括图形用户界面层UI、业务层、领域层和数据层，业务组件是能完成具体业务动作的，与后端能力连接的组件，而非基础交互控件。举例来说，商品列表、购物车、订单列表都是前端业务组件，而Button、Input、List等属于基础控件Base Control。

本发明实施例中，业务组件Component用来描述和实现需求的业务行为，页面Page则作为容器，即业务组件的载体，只是一个数据结构，用来承载业务组件Component的图形用户界面层的布局信息，如图3，商品四级页由4个业务组件组成，Page中的组件都以平铺管理，不支持组件之间嵌套。页面Page容器化，将业务组件之间路由的管理从页面中剥离，成为业务组件之间固有的关系，页面只管理业务组件摆放的前后次序，这样方便实现不同业务组件在不同页面中的灵活组合。

请参考图4，操作流是一组具有关联关系的业务组件Component的集合，通过数据结构定义业务组件Component之间的关联关系，通过这种方式将业务流触发条件和行为封装在操作流内部，通过定义每个组件的出口“goNext”，明确定义组件与组件之间的跳转关系，并提供js sdk来实现操作流元数据的解析，同时实现业务组件的跳转，不再受图形用户界面层UI变化的影响，也就规避了以往页面变化时，业务层、领域层和数据层的url和调用方式需要重新实现的问题。比如发布商品的场景：包括“选择sku(库存保有单位，Stockkeeping Unit，是对每一个产品和服务的唯一标示符)”->“新增商品基本信息”->“显示待上架商品列表”->“编辑商品详情”。无论页面发生什么变化，封装在操作流内部的业务组件Component之间的关联关系都不会改变，业务组件的业务层、领域层和数据层的url和调用方式不需要重新实现。

请参阅图5，根据功能ID查询功能仓库中是否已存在需要的目录项的方法包括：

调用功能仓库的查询接口，根据工程的功能ID查询功能仓库中是否已存在需要的工程；

如果功能仓库中存在需要的工程，则不再查询功能仓库中是否已存在构成工程的操作流；如果功能仓库中不存在需要的工程，则根据工程包含的操作流的功能ID逐一查询功能仓库中是否已存在需要的操作流；

如果功能仓库中存在需要的操作流，则获取操作流所在工程的功能ID，不再查询功能仓库中是否已存在构成操作流的业务组件；如果功能仓库中不存在需要的操作流，则根据操作流包含的业务组件的功能ID逐一查询功能仓库中是否已存在需要的业务组件；

如果功能仓库中存在需要的业务组件，则获取业务组件所在操作流的功能ID，进而获取操作流所在工程的功能ID；如果功能仓库中不存在需要的业务组件，则直接结束查询操作。

请继续参阅图5，本实施例提供的一种基于业务组件创建toB工程的方法中，如果在功能仓库中存在需要的工程，则获取工程的npm包、页面配置文件和工程菜单配置文件，利用npm包、页面配置文件和工程菜单配置文件直接创建生成新工程；如果在功能仓库中查询到需要的操作流或业务组件，则根据操作流或业务组件所在工程的功能ID获取工程的npm包，创建新工程并将npm包安装到新工程中。

其中，获取工程的npm包的方法包括：

根据工程的功能ID在功能仓库中获取工程的npm包名，或者同时获取工程的页面配置文件和工程菜单配置文件；

根据npm包名从npm仓库中查询并获取对应的npm包。

具体地，根据用户需求生成工程目录清单后，根据功能目录清单，查询可复用的目录项。请参阅表2～表4，功能仓库中存储了结构化的工程目录清单，包括各个目录项分表的数据结构，记录了各个目录项的功能ID(即BOMID)及对应的工程npm包名的关系，这个关系是采用关系型数据或key-value型的nosql进行存储，依次根据工程->操作流->业务组件的次序，分别调用功能仓库的接口进行查询，获取需要的工程的npm包名。

表2 Project table(工程表)数据结构示例

数据库ID	BOMID	npm包名	version	date
					1	BOM001	xxx	1.0.0	1970-01-01
…	…	…	…	…

表3 BU table(操作流表)数据结构示例

数据库ID	BOMID	projectid	name	version	date
						1	BOM001001	1	xxx	1.0.0	1970-01-01
…	…	…	…	…	…

表4 Component table(组件表)数据结构示例

数据库ID	BOMID	optid	name	version	date
						1	BOM001001001	1	xxx	1.0.0	1970-01-01
…	…	…	…	…	…

获取到npm包名之后，然后通过“Npm install npm包名”函数，从npm仓库下载工程的npm包并安装到node_modules或是其他类似的依赖目录中，已实现工程业务功能的复用。

若工程的功能ID匹配成功，则同时需要复用该工程的页面配置文件。页面配置文件是和工程强依赖的内容，以json描述的数据结构，可以采用独立数据文件，或是数据库存储。

该页面配置文件的数据结构主要包含4部分内容：页面的数据库ID、页面名称、页面与工程的映射关系，以及页面与业务组件数组的映射关系等页面属性。

表5工程project与页面page在数据层面的映射示例

页面的数据库ID	工程的数据库ID	language	name	date
					1	1	zh	xxx	1970-01-01
2	1	en	xxx	1970-01-01

表6页面与业务组件数组在数据层面的映射关系示例

页面的数据库ID	业务组件的数据库ID	order	name	date
					1	1	0	xxx	1970-01-01
1	2	1	xxx	1970-01-01

请参阅表2、表4、表5或表6，根据工程的功能ID(BOMID)，获取到工程的数据库ID后便可以轻松读取该工程所包含的所有页面的数据库ID，进而下载页面的配置文件，再循环遍历每一个页面配置文件，根据页面的配置文件中页面与业务组件数组在数据层面的映射关系，找到各个业务组件的数据库ID及页面平铺顺序(order)，依据表4对应获取业务组件的功能ID，将业务组件的功能ID对应的业务组件按照页面平铺顺序布局，从而完成工程的页面的复用。本领域技术人员应该明白的是，表2～表6中的数据库ID为对应的目录项在所存储的数据库中的存储ID，该数据库可以为功能仓库，也可以为功能仓库所包含的数据库单元。

若工程的功能ID查询匹配成功，还需要同时复用该工程的工程菜单配置文件。菜单在前端工程中的处理方式比较特殊，因为它涉及到布局样式layout。所以一般一个工程只会有一个layout及菜单配置文件。该文件一般保存在OSS中，若工程的功能ID被查询匹配成功，则下载该layout布局文件到本地工程中，利用npm包、页面配置文件和工程菜单配置文件直接创建生成新工程。

请参阅图6，本实施例提供的一种基于业务组件创建toB工程的方法中，按照工程目录清单创建新工程的方法包括：

创建工程的工程菜单配置文件、页面配置文件、操作流配置文件和业务组件配置文件，其中，业务组件配置文件包括业务组件的逻辑功能实现文件和配置信息；操作流配置文件包括业务组件之间的关联关系；页面配置文件包括页面所包含的业务组件的列表；工程菜单配置文件包括每个业务组件的布局信息。

例如，在具体实施过程中，创建工程，即创建前端工程，该前端工程核心包含三部分：.SDK文件、操作流配置文件和业务组件配置文件。

.SDK文件，包括页面配置文件和工程菜单配置文件，或者还包括npm包的依赖目录node_modules，其中node_modules用于管理从功能仓库复用的npm包。

操作流配置文件用于管理工程的所有操作流，具体结构例如：

·BOM001001：发布商品操作流BU；

·Json：定义该操作流内部组件之间的跳转关系。

业务组件配置文件用于管理工程所有的业务组件，具体结构例如：

·BOM001001001：选择SKU业务组件；

·jsx：逻辑、布局；

·json：属性，如绑定后端api、PMP Bom编码及描述；

·scss：样式。

·BOM001001002：新增商品基本信息业务组件。

·BOM0010010023：显示待上架产品列表业务组件。

例如，开发BOM001001001选择SKU业务组件，先完成该组件的逻辑功能，其中，BOM001001001.jsx是该组件的逻辑实现，选择BOM001001001.scss是其样式文件。然后定义业务组件属性文件BOM001001001.json，该文件主要定义该组件的属性信息，如绑定后端api、PMP Bom编码及描述。之后，定义操作流的配置文件BOM001001.json，该文件主要定义操作流内部组件之间的跳转关系。通过导出define BU类，将该操作流的组件之间关系导出，在实际使用过程中，通过将具体事件绑定行为(这里的行为如choise\create\view)，触发事件后，实现跳转行为。最后，在用户的图形操作界面上，将组件的UI“放置到”某个页面上，方法是在.sdk的pages目录下，新建一个比如pageA.json(文件名字自定义)，然后分别定义该Page在数据库中的主键id、该页面的中文名称和英文名称、该页面中所摆放业务组件的信息以及该组件在此页面上所绑定的后端接口，为了避免Page的结构描述过于复杂，Page中组件采用流式布局进行摆放，比如A工程的选择商品SKU页面，摆放了一个选择SKU组件，该组件由FORM表单构成，在该页面上，该组件调用后端/productCenter/chosesku.do接口获取并更新数据。

实际应用中，若功能仓库中仅有部分业务组件和/或操作流可以查询到，可以直接下载安装对应的npm包到新工程中，还需要按照工程目录清单在新工程中对没有查询到的业务组件和/或操作流进行开发，例如，在操作流A中新创建一个组件B这一目录项。若功能仓库中没有查询到所有的业务组件和操作流，则在工程建立完成后，按照工程目录清单在新工程中对所有的业务组件和操作流进行开发。

最后，将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将新工程的npm包存储到npm仓库中，以方便于下次进行迭代交付或相似场景的定制开发时，直接根据用户需求查询复用。具体方法包括：

将新工程通过npm工具进行打包并命名，得到npm包，npm包中包括操作流配置文件和业务组件配置文件；将npm包上传至npm仓库；将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件上传到功能仓库进行结构化存储。

实施例二

一种基于业务组件创建toB工程的系统，包括目录清单生成模块和工程创建模块，工程创建模块包括查询单元、复用单元、新建单元和沉淀单元，其中，目录清单生成模块用于根据用户需求生成工程目录清单，工程目录清单包括目录项的名称和功能ID，目录项按照层级从大到小依次包括工程、操作流和业务组件；查询单元用于按照层级从大到小的顺序，根据功能ID查询功能仓库中是否已存在需要的目录项，直至查询到需要的目录项或者查询完毕为止；复用单元用于在查询到需要的目录项时，获取目录项所在工程的npm包，或者同时获取目录项所在工程的页面配置文件和工程菜单配置文件；新建单元用于利用npm包、页面配置文件和工程菜单配置文件直接创建生成新工程，或者按照工程目录清单创建新工程并将npm包安装到新工程中；还用于在未查询到需要的目录项时，按照工程目录清单创建新工程；沉淀单元用于将新工程的npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将新工程的npm包存储到npm仓库中。

本发明提供的基于业务组件创建toB工程的系统，采用上述基于业务组件创建toB工程的方法，通过将业务需求与业务组件建立固定的联系，方便快捷的根据业务需求将业务组件的复用到新的项目工程中，降低了项目定制的成本，减少了开发的工作量。与现有技术相比，本发明实施例提供的基于业务组件创建toB工程的系统的有益效果与上述实施例一提供的基于业务组件创建toB工程的方法的有益效果相同，且该系统中的其他技术特征与上一实施例方法公开的特征相同，在此不做赘述。

实施例三

本发明实施例公开一种电子设备，该电子设备包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行前述实施例一提供的基于业务组件创建toB工程的方法。

下面参考图7，其示出了适于用来实现本公开实施例的电子设备的结构示意图。本公开实施例中的电子设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图7示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图7所示，电子设备可以包括处理装置(例如中央处理器、图形处理器等)，其可以根据存储在只读存储器(ROM)中的程序或者从存储装置加载到随机访问存储器(RAM)中的程序而执行各种适当的动作和处理。在RAM中，还存储有电子设备操作所需的各种程序和数据。处理装置、ROM以及RAM通过总线彼此相连。输入/输出(I/O)接口也连接至总线。

通常，以下系统可以连接至I/O接口：包括例如触摸屏、触摸板、键盘、鼠标、图像传感器、麦克风、加速度计、陀螺仪等的输入装置；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置；包括例如磁带、硬盘等的存储装置；以及通信装置。通信装置可以允许电子设备与其他设备进行无线或有线通信以交换数据。虽然图中示出了具有各种系统的电子设备，但是应理解的是，并不要求实施或具备所有示出的系统。可以替代地实施或具备更多或更少的系统。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置从网络上被下载和安装，或者从存储装置被安装，或者从ROM被安装。在该计算机程序被处理装置执行时，执行本公开实施例的方法中限定的上述功能。

本发明提供的电子设备，采用上述基于业务组件创建toB工程的方法，能够方便快捷的根据业务需求将已有的工程、操作流或者业务组件复用到新的项目工程中，降低了项目定制的成本，减少了开发的工作量。与现有技术相比，本发明实施例提供的电子设备的有益效果与上述实施例一提供的基于业务组件创建toB工程的方法的有益效果相同，且该电子设备中的其他技术特征与上述实施例一方法公开的特征相同，在此不做赘述。

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、系统或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、系统或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、系统或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：获取至少两个网际协议地址；向节点评价设备发送包括所述至少两个网际协议地址的节点评价请求，其中，所述节点评价设备从所述至少两个网际协议地址中，选取网际协议地址并返回；接收所述节点评价设备返回的网际协议地址；其中，所获取的网际协议地址指示内容分发网络中的边缘节点。

或者，上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：接收包括至少两个网际协议地址的节点评价请求；从所述至少两个网际协议地址中，选取网际协议地址；返回选取出的网际协议地址；其中，接收到的网际协议地址指示内容分发网络中的边缘节点。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定，例如，第一获取单元还可以被描述为“获取至少两个网际协议地址的单元”。

应当理解，本公开的各部分可以用硬件、软件、固件或它们的组合来实现。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种基于业务组件创建toB工程的方法，其特征在于，包括：

根据用户需求生成工程目录清单，所述工程目录清单包括目录项的名称和功能ID，所述目录项按照层级从大到小依次包括工程、操作流和业务组件；

按照层级从大到小的顺序，根据功能ID查询功能仓库中是否已存在需要的目录项，直至查询到需要的目录项或者查询完毕为止；

若查询到需要的目录项，则获取所述目录项所在工程的npm包，或者同时获取所述目录项所在工程的页面配置文件和工程菜单配置文件；利用所述npm包和所述页面配置文件直接创建生成新工程，或者按照所述工程目录清单创建新工程并将所述npm包安装到新工程中；若未查询到需要的目录项，则按照所述工程目录清单创建新工程；

将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将所述新工程的npm包存储到npm仓库中。

2.根据权利要求1所述的基于业务组件创建toB工程的方法，其特征在于，所述工程目录清单中，一个工程包括一个或多个操作流，一个操作流由一组具有关联关系的业务组件构成，一个业务组件对应一个用户需求点；

每个工程、操作流及业务组件分别对应唯一的功能ID。

3.根据权利要求1所述的基于业务组件创建toB工程的方法，其特征在于，根据功能ID查询功能仓库中是否已存在需要的目录项的方法包括：

调用功能仓库的查询接口，根据工程的功能ID查询所述功能仓库中是否已存在需要的工程；

如果所述功能仓库中存在需要的工程，则不再查询所述功能仓库中是否已存在构成所述工程的操作流；如果所述功能仓库中不存在需要的工程，则根据工程包含的操作流的功能ID逐一查询所述功能仓库中是否已存在需要的操作流；

如果所述功能仓库中存在需要的操作流，则获取所述操作流所在工程的功能ID，不再查询所述功能仓库中是否已存在构成所述操作流的业务组件；如果所述功能仓库中不存在需要的操作流，则根据所述操作流包含的业务组件的功能ID逐一查询所述功能仓库中是否已存在需要的业务组件；

如果所述功能仓库中存在需要的业务组件，则获取所述业务组件所在操作流的功能ID，进而获取所述操作流所在工程的功能ID；如果所述功能仓库中不存在需要的业务组件，则直接结束查询操作。

4.根据权利要求3所述的基于业务组件创建toB工程的方法，其特征在于，如果在所述功能仓库中存在需要的工程，则获取工程的npm包、页面配置文件和工程菜单配置文件，利用所述npm包、所述页面配置文件和工程菜单配置文件直接创建生成新工程；

如果在所述功能仓库中查询到需要的操作流或业务组件，则根据所述操作流或业务组件所在工程的功能ID获取工程的npm包，创建新工程并将所述npm包安装到新工程中。

5.根据权利要求4所述的基于业务组件创建toB工程的方法，其特征在于，获取工程的npm包的方法包括：

根据工程的功能ID在所述功能仓库中获取工程的npm包名，或者同时获取工程的页面配置文件；

根据所述npm包名从所述npm仓库中查询并获取对应的npm包。

6.根据权利要求3所述的基于业务组件创建toB工程的方法，其特征在于，按照所述工程目录清单创建新工程的方法包括：

创建工程的工程菜单配置文件、页面配置文件、操作流配置文件和业务组件配置文件，其中，

所述业务组件配置文件包括业务组件的逻辑功能实现文件和配置信息；

所述操作流配置文件包括业务组件之间的关联关系；

所述页面配置文件包括页面所包含的业务组件的列表；

所述工程菜单配置文件包括每个业务组件的布局信息。

7.根据权利要求6所述的基于业务组件创建toB工程的方法，其特征在于，将新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将所述新工程的npm包存储到npm仓库中的方法包括：

将所述新工程通过npm工具进行打包并命名，得到npm包；

将所述npm包上传至npm仓库；

将所述新工程的工程目录清单、npm包名、页面配置文件和工程菜单配置文件上传到功能仓库进行结构化存储。

8.根据权利要求7所述的基于业务组件创建toB工程的方法，其特征在于，所述npm包中包括所述操作流配置文件和所述业务组件配置文件。

9.一种基于业务组件创建toB工程的系统，其特征在于，包括目录清单生成模块和工程创建模块，所述工程创建模块包括查询单元、复用单元、新建单元和沉淀单元，其中，

所述目录清单生成模块用于根据用户需求生成工程目录清单，所述工程目录清单包括目录项的名称和功能ID，所述目录项按照层级从大到小依次包括工程、操作流和业务组件；

所述查询单元用于按照层级从大到小的顺序，根据功能ID查询功能仓库中是否已存在需要的目录项，直至查询到需要的目录项或者查询完毕为止；

所述复用单元用于在查询到需要的目录项时，获取所述目录项所在工程的npm包，或者同时获取所述目录项所在工程的页面配置文件和工程菜单配置文件；

所述新建单元用于利用所述npm包、所述页面配置文件和工程菜单配置文件直接创建生成新工程，或者按照所述工程目录清单创建新工程并将所述npm包安装到新工程中；还用于在未查询到需要的目录项时，按照所述工程目录清单创建新工程；

所述沉淀单元用于将新工程的npm包名、页面配置文件和工程菜单配置文件对应存储到功能仓库中，同时将所述新工程的npm包存储到npm仓库中。

10.一种电子设备，其特征在于，所述电子设备包括：

至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行前述权利要求1-7任一项所述的基于业务组件创建toB工程的方法。

Images