汽车业务管理系统的构建方法、装置及电子设备

摘要

本公开涉及汽车业务管理系统的构建方法、装置及电子设备，该响应于组件构建指令，基于Vue技术构建至少两个通用业务组件，不同通用业务组件可实现不同功能；响应于功能分析指令，获取所述汽车业务管理系统所需具备的至少两个功能，确定与所述至少两个功能对应的通用业务组件；响应于聚合指令，将与所述汽车业务管理系统所需具备的至少两个功能对应的通用业务组件进行聚合处理，得到所述汽车业务管理系统。本公开实施例提供的技术方案可以提高构建效率，所形成的通用业务组件可以重复使用，可以提升整个项目的可维护性。

说明书

技术领域

本公开涉及汽车业务管理系统构建技术领域，尤其涉及一种汽车业务管理系统的构建方法、装置及电子设备。

背景技术

目前，前端项目发展迅速，这使得大家用于进行汽车业务管理系统构建的框架五花八门，没有一个统一的标准。正是因为大家用于进行汽车业务管理系统构建的框架不同，在构建汽车业务管理系统时，不同人所编写的代码可能发生冲突。当代码发生冲突时，需要对代码进行修改，无疑这个过程会浪费非常多的时间，使得整个汽车业务管理系统构建效率低。

发明内容

为了解决上述技术问题，本公开提供了一种汽车业务管理系统的构建方法、装置及电子设备。

第一方面，本公开提供了一种汽车业务管理系统的构建方法，包括：

响应于组件构建指令，基于Vue技术构建至少两个通用业务组件，不同通用业务组件可实现不同功能；

响应于功能分析指令，获取所述汽车业务管理系统所需具备的至少两个功能，确定与所述至少两个功能对应的通用业务组件；

响应于聚合指令，将与所述汽车业务管理系统所需具备的至少两个功能对应的通用业务组件进行聚合处理，得到所述汽车业务管理系统。

进一步地，所述响应于组件构建指令，基于Vue技术构建至少两个通用业务组件，不同通用业务组件具备不同的功能，包括：

响应于脚手架安装指令，安装生成通用业务组件的脚手架；

响应于依赖安装指令，在通用业务组件根目录中安装通用业务组件所需要的依赖；

响应于地址配置指令，配置开发环境的接口地址；

接收基于所述通用业务组件根目录的目录结构编写的通用业务组件代码。

进一步地，所述接收基于所述通用业务组件根目录的目录结构编写的通用业务组件代码之后，还包括：

响应于测试指令，对通用业务组件测试处理；

若所述通用业务组件测试通过，对所述通用业务组件代码打包处理。

进一步地，所述对所述通用业务组件代码打包处理，包括：

利用webpack技术对所述通用业务组件代码打包处理。

进一步地，所述利用webpack技术对所述通用业务组件代码打包处理，包括：

利用webpack技术将所述通用业务组件代码打包为jar包。

进一步地，在所述接收基于所述通用业务组件根目录的目录结构编写的通用业务组件代码的过程中，包括：

在所述通用业务组件对应的库文件的后缀中添加时间戳。

进一步地，所述汽车业务管理系统部署在Nginx或者Tomcat中。

进一步地，所述汽车业务管理系统包括汽车零售管理系统、汽车交付系统、汽车客服管理系统或汽车售后服务系统。

进一步地，所述汽车业务管理系统包括下述通用业务组件中的至少两个：客户基础信息组件，客户订单列表组件，客户投诉记录组件，客户交付单组件，客户车辆告警组件、试驾记录组件、充电桩组件、咨询记录组件、满意度组件、车辆详情组件、销售订单组件、投诉记录组件、意向单组件以及任务管理组件。

第二方面，本公开还提供了一种汽车业务管理系统的构建装置，包括：

组件创建模块，用于响应于组件构建指令，基于Vue技术构建至少两个通用业务组件，不同通用业务组件可实现不同功能；

对应关系确定模块，用于响应于功能分析指令，获取所述汽车业务管理系统所需具备的至少两个功能，确定与所述至少两个功能对应的通用业务组件；

系统创建模块，用于响应于聚合指令，将与所述汽车业务管理系统所需具备的至少两个功能对应的通用业务组件进行聚合处理，得到所述汽车业务管理系统。

进一步地，所述组件创建模块具体用于：

响应于脚手架安装指令，安装生成通用业务组件的脚手架；

响应于依赖安装指令，在通用业务组件根目录中安装通用业务组件所需要的依赖；

响应于地址配置指令，配置开发环境的接口地址；

接收基于所述通用业务组件根目录的目录结构编写的通用业务组件代码。

进一步地，所述组件创建模块还用于在接收基于所述通用业务组件根目录的目录结构编写的通用业务组件代码之后，响应于测试指令，对通用业务组件测试处理；

若所述通用业务组件测试通过，对所述通用业务组件代码打包处理。

进一步地，所述组件创建模块在对所述通用业务组件代码打包处理时，利用webpack对所述通用业务组件代码打包。

进一步地，所述组件创建模块在利用webpack技术对所述通用业务组件代码打包处理时，利用webpack技术将所述通用业务组件代码打包为jar包。

第三方面，本公开还提供了一种电子设备，包括：处理器和存储器；

处理器通过调用存储器存储的程序或指令，用于执行上述任一方法的步骤。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

1、本公开实施例技术方案可以提高构建效率。本公开实施例技术方案的实质是将汽车业务管理系统组件化，这样在构建时，每个人都专注于自己的通用业务组件构建，完善自己的通用业务组件功能。并且由于通用业务组件均基于Vue技术构建得到，这使得所得到的通用业务组件一脉相承，可以减少和别人的代码发生冲突的可能性，可以缩减代码调试花费的时间，因此可以提高整个汽车业务管理系统构建的效率。

2、本公开实施例技术方案所构建的通用业务组件可以重复使用。由于汽车业务管理系统组件化，而各通用业务组件又具有通用性，可以与其他通用业务组件进行自由组合，可以实现各通用业务组件的重复使用。

3、本公开实施例技术方案可以提升整个项目的可维护性。由于汽车业务管理系统由各通用业务组件组合得到。若同时应用于不同汽车业务管理系统的某个通用业务组件存在缺陷时，对该通用业务组件进行修复，相当于对包括该通用业务组件的所有汽车业务管理系统进行修复，因此，可提升整个项目的可维护性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1是本公开实施例提供的一种汽车业务管理系统的构建方法的流程图；

图2为本公开实施例提供的一种汽车业务管理系统构建的示意图；

图3为本公开提供的一种实现S110的方法的流程图；

图4-图9均为本公开实施例提供的一种通用业务组件开发过程中的截图。

图10和图11为本公开实施例提供的两种汽车业务管理系统与服务器的连接关系图；

图12为本公开实施例提供的一种汽车业务管理系统的构建装置的结构框图；

图13为本公开实施例提供的电子设备的硬件结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

为了更好地理解本公开实施例中的技术方案，下面对以下名称进行解释：

Webpack:Webpack是一个前端项目资源打包工具。它可以根据项目依赖的模块进行静态分析，然后将这些模块按照指定的规则生成对应的静态资源。

Vue.js:Vue.js是一个javascript的框架。

Element-ui:element-ui是一个基于Vue.js封装的框架。它是一套Vue的组件库，提供了丰富的ui组件。

Nginx:Nginx是一个高性能的HTTP和反向代理WEB服务器。静态资源(html,js,css)等经常部署在nginx服务器里。它不能部署java开发的web项目。

Tomcat:Tomcat是一个Servlet容器，它经常用于部署java开发的web项目，也可以部署静态资源(html,js,css)等。

前后端不分离，是指前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示。

前后端分离，是指后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果，至于前端用户看到的什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App由App的处理方式，但无论哪种前端，所需要的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。

汽车业务管理系统为办公效率类软件，利用汽车业务管理系统可以提高员工的工作效率。示例性地，汽车业务管理系统可以进行汽车零售管理、汽车交付管理、汽车客户关系管理或汽车售后服务管理等。

图1是本公开实施例提供的一种汽车业务管理系统的构建方法的流程图。参见图1，该汽车业务管理系统的构建方法包括：

S110、响应于组件构建指令，基于Vue技术构建至少两个通用业务组件，不同通用业务组件可实现不同功能。

S120、响应于功能分析指令，获取汽车业务管理系统所需具备的至少两个功能，确定与至少两个功能对应的通用业务组件。

S130、响应于聚合指令，将与汽车业务管理系统所需具备的至少两个功能对应的通用业务组件进行聚合处理，得到汽车业务管理系统。

可选地，本公开所构建的汽车业务管理系统包括汽车零售管理系统、汽车交付系统、汽车客服管理系统或汽车售后服务系统。其中，汽车零售管理系统负责进行汽车零售管理，汽车交付系统负责进行汽车交付管理，汽车客户关系管理系统负责进行汽车客户关系管理，汽车售后服务系统负责进行汽车售后服务管理。

需要说明的是，对于一个企业，当需要对多个方面进行管理时，该企业可以重复使用上述技术方案构建多个汽车业务管理系统。如企业A可以根据其业务需求，仅构建汽车零售管理系统。企业A可以根据其业务需求，构建汽车零售管理系统和汽车交付系统。企业C可以根据其业务需求，同时构建汽车零售管理系统、汽车交付系统、汽车客服管理系统和汽车售后服务系统。

示例性地，图2为本公开实施例提供的一种汽车业务管理系统构建的示意图。在图2中，第一层面是指业务功能。其根据需要构建的汽车业务管理系统实际需要管理的内容确定，即根据开发目的确定。示例性地，业务功能包括任务管理、线索管理、试驾管理、交付接待、道路救援等等。

图2中，第二层面为对第一层面的进一步设计，第二层面中各项目是指本公开中执行S110后得到的通用业务组件。示例性地，通用业务组件包括但不限于下述中的至少一个：客户基础信息组件，客户订单列表组件，客户投诉记录组件，客户交付单组件，客户车辆告警组件、试驾记录组件、充电桩组件、咨询记录组件、满意度组件、车辆详情组件、销售订单组件、投诉记录组件、意向单组件以及任务管理组件。该通用业务组件用于基于业务数据实现业务功能。需要说明的是，不同的通用业务组件可以是并列关系，也可以是上下级关系，本公开对此不作限制。

图2中，第三层面为汽车业务管理系统，各汽车业务管理系统由第二层面中的通用业务组件聚合得到。其在聚合时，按照S120和S130的步骤进行聚合。

可选地，汽车业务管理系统包括汽车零售管理系统、汽车交付系统、汽车客服管理系统或汽车售后服务系统。

需要说明的是，在实际中，若需要构建的汽车业务管理系统为两个，分别汽车交付系统和汽车客服管理系统，经过分析发现这两个汽车业务管理系统均需要调用客户基础信息，则在执行S110时，并不是为汽车交付系统和汽车客服管理系统分别创建客户基础信息组件，而是仅创建一个客户基础信息组件，该客户基础信息组件既可以应用于汽车交付系统，也可以应用于汽车客服管理系统。

另外，需要说明的是，由于在执行S130时，是将与汽车业务管理系统所需具备的至少两个功能对应的通用业务组件进行聚合处理，得到汽车业务管理系统，因此，汽车业务管理系统包括下述通用业务组件中的至少两个：客户基础信息组件，客户订单列表组件，客户投诉记录组件，客户交付单组件，客户车辆告警组件、试驾记录组件、充电桩组件、咨询记录组件、满意度组件、车辆详情组件、销售订单组件、投诉记录组件、意向单组件以及任务管理组件。

在上述技术方案中，通用业务组件基于Vue技术得到。Vue可以理解为一个基础的工具，比如计算机就是一个基础的工具，大家可以用计算机做各种各样的事情，本公开中使用Vue这个基础的工具构建汽车业务管理系统的各个通用业务组件。此时，各个通用业务组件相当于“积木块”，通过将这些“积木块”进行组合，最终可以得到汽车零售管理系统、汽车交付系统、汽车客服管理系统和汽车售后服务系统等等。

需要强调的是，在本公开中，所提供的通用业务组件具有通用性。此处，“通用性”应当理解为，同一通用业务组件与其他不同的通用业务组件聚合，可以得到不同的汽车业务管理系统。即同一通用业务组件可应用于不同的汽车业务管理系统。例如，汽车零售管理系统的销售订单组件(该销售订单组件为通用业务组件)，可以无缝的运行在汽车客服管理系统中。可选地，为了使得通用业务组件具有通用性，在基于Vue对通用业务组件进行构建时，可以对webpack的源码配置进行修改，使webpack这个工具可以把编写好的具有业务含义的组件打包成标准组件，进而使得这个标准组件可以无缝的运行在各个汽车业务管理系统中。

下面进一步举例说明如何将一个个具有业务功能的通用业务组件组合在一起形成不同的汽车业务管理系统。示例性地，各个汽车业务管理系统在实现其所具备的功能时需要调用客户的各种信息。因此，可以基于客户的各种信息设置多个通用业务组件，如客户基础信息组件，客户订单列表组件，客户投诉记录组件，客户交付单组件，客户车辆告警组件等组件。但是每个汽车业务管理系统所需要具有的功能不一样，因此其所需要的通用业务组件不一样，比如汽车零售管理系统需要客户订单列表组件和客户基础信息组件；汽车交付系统需要客户交付单组件和客户基础信息组件；汽车客服管理系统需要客户基础信息组件，客户订单列表组件，客户交付单组件，客户车辆告警组件等等。据此，对应任何一个汽车业务管理系统，将其所需要的各个通用业务组件进行组合，可以得到该汽车业务管理系统。

上述技术方案具有以下优势：

1、上述技术方案可以提高构建效率。上述技术方案的实质是将汽车业务管理系统组件化，这样在构建时，每个人都专注于自己的通用业务组件构建，完善自己的通用业务组件功能。并且由于通用业务组件均基于Vue技术构建得到，这使得所得到的通用业务组件一脉相承，可以减少和别人的代码发生冲突的可能性，可以缩减代码调试花费的时间，因此可以提高整个汽车业务管理系统构建的效率。

研究表明，对应同一规模的汽车业务管理系统，利用上述技术方案，比利用现有的构建方式，可以缩短2/5的构建时长。

2、上述技术方案所构建的通用业务组件可以重复使用。由于汽车业务管理系统组件化，而各通用业务组件又具有通用性，可以与其他通用业务组件进行自由组合，可以实现各通用业务组件的重复使用。

3、上述技术方案可以提升整个项目的可维护性。由于汽车业务管理系统由各通用业务组件组合得到。若同时应用于不同汽车业务管理系统的某个通用业务组件存在缺陷时，对该通用业务组件进行修复，相当于对包括该通用业务组件的所有汽车业务管理系统进行修复，因此，可提升整个项目的可维护性。

需要再次强调的是，在本公开中，所提及的通用业务组件与ui(用户界面，UserInterface)组件不同。ui组件是一个一个的ui元素，是形状和样式，没有功能和数据。如按钮组件是一个按钮的样子，表格组件是一个表格。而本公开提及的通用业务组件包含业务数据，是比ui组件更高一层的组件。例如，客户订单列表组件里包含表格组件，按钮组件等等各种ui组件。同时客户订单列表组件还有功能和数据，客户订单列表组件可以自动的查询出客户的订单列表信息。通用业务组件可以使用在汽车业务管理系统中。进一步地，可以设置通用业务组件的运行需要账号系统的支持，运维系统的支持等等。

在上述技术方案中，S110的具体实现方法有多种，本公开对此不作限制。图3为本公开提供的一种实现S110的方法的流程图。参见图3，该用于实现S110的方法包括：

S111、响应于脚手架安装指令，安装生成通用业务组件的脚手架。

其中，可选地，脚手架安装指令在某一预设条件满足后生成。示例性地，该预设条件可以为计算机接收到用户输入的某些预设操作(如点击某图标)。

示例性地，安装cnpm,，然后设置源https://npm.chehejia.com/；

安装脚手架cnpm install@chehejia/chj-cli-g。

可选地，在执行S111之后，还包括：生成通用业务组件名称。

示例性地，可以根据预设的通用业务组件名称命名规则，生成通用业务组件名称；或者，接收用户输入的字符串，基于用户输入的字符串生成通用业务组件名称。

示例性地，图4为本公开实施例提供的一种通用业务组件构建过程中的截图。参见图4创建通用业务组件chj-initui名称为chj-rb。

S112、响应于依赖安装指令，在通用业务组件根目录中安装通用业务组件所需要的依赖。

其中，可选地，依赖安装指令在某一预设条件满足后生成。示例性地，该预设条件可以为计算机接收到用户输入的某些预设操作(如点击某图标)，或者某个步骤(如步骤S111)已完成等。

示例性地，图5为本公开实施例提供的另一种通用业务组件构建过程中的截图。参见图5，进入通用业务组件根目录，安装通用业务组件所需要的依赖，cnpminstall。

S113、响应于地址配置指令，配置开发环境的接口地址。

其中，可选地，响应于地址配置指令在某一预设条件满足后生成。示例性地，该预设条件可以为计算机接收到用户输入的某些预设操作(如点击某图标)，或者某个步骤(如步骤S112)已完成等。

示例性地，图6为本公开实施例提供的另一种通用业务组件构建过程中的截图。参见图6，配置开发环境的接口地址，以使得后续可以调用后端服务器。

可选地，可以直接在根目录下的dev.js中修改options参数，以达到配置开发环境的接口地址的目的。

例如，通过下述代码在根目录下的dev.js中修改options参数。

const option＝{

target:‘http://api-web-dev.chehejia.com’,

changeOrigin:true,

pathRewrite:{

‘^/component’:‘’

}

}

koaApp.use(k2c(proxy(‘/component/aisp-amp-api’,option)))；

S114、接收基于通用业务组件根目录的目录结构编写的通用业务组件代码。

示例性地，图7为本公开实施例提供的另一种通用业务组件构建过程中的截图。可选地，基于通用业务组件根目录的目录结构编写的通用业务组件代码如图7中所示。

在上述技术方案的基础上，继续参见图3，可选地，在S114之后，还包括：

S115、响应于测试指令，对通用业务组件测试处理。

其中，可选地，测试指令在某一预设条件满足后生成。示例性地，该预设条件可以为计算机接收到用户输入的某些预设操作(如点击某图标)，或者某个步骤(如步骤S114)已完成等。

示例性地，图8为本公开实施例提供的另一种通用业务组件构建过程中的截图。参见图8，可以利用图8中的代码测试通用业务组件。

S116、若通用业务组件测试通过，对通用业务组件代码打包处理。

示例性地，图9为本公开实施例提供的另一种通用业务组件构建过程中的截图。参见图9，可以使用“npm run build–rb”命令打包。

可选地，在执行本步骤时，利用webpack技术对通用业务组件代码打包处理。示例性地，利用webpack技术将通用业务组件代码打包为jar包。这样设置的实质是，将通过测试的前端业务组件js代码打为jar包，形成webjars，使用maven规范对webjars进行管理。这样设置可以保证这些Web资源版本唯一性，也便于升级。

可选地，在上述技术方案中，在执行S114的过程中，在通用业务组件对应的库文件的后缀中添加时间戳。这样在使用时，浏览器可以基于时间戳调用库文件，进而实现在后续基于通用业务组件形成的汽车业务管理系统的客户端在不清空浏览器缓存的情况下，就可以使得浏览器调用新发布的库文件。

图10和图11为本公开实施例提供的两种汽车业务管理系统与服务器的连接关系图。在图10中，汽车业务管理系统为前端系统，部署在Nginx。在图11中，汽车业务管理系统部署在Tomcat中。汽车业务管理系统部署在Nginx的方案，汽车业务管理系统结构复杂，部署难度大，适合需要访问人数多的情况。汽车业务管理系统部署在Tomcat中的方案，汽车业务管理系统结构简洁，部署难度小，适合需要访问人数少的情况。

需要说明的是，汽车业务管理系统为前端业务系统。在实际中，该汽车业务管理系统可以与后端服务器形成前后端分离式业务系统或前后端不分离式业务系统。示例性地，在实际构建的过程中，可以将图10中汽车业务管理系统构建为前后端分离式业务系统。而图11中汽车业务管理系统构建为前后端分离式业务系统或前后端不分离式业务系统。

前后端不分离式业务系统，前端与后端的耦合度很高，适用于体量小的汽车业务系统。

前后端分离式业务系统，前端与后端的耦合度相对较低，前端只需要更专注于样式，UI，交互、适配等。服务端更专注于业务逻辑，所有接口都是API微服务的方式提供服务，其可以更好的提供并发性能，可以减少由于职责不明确而产生互相扯皮现象出现。

基于相同的发明构思，本公开还提供一种汽车业务管理系统的构建装置。图12为本公开实施例提供的一种汽车业务管理系统的构建装置的结构框图。参见图12，该汽车业务管理系统的构建装置200包括：

组件创建模块210，用于响应于组件构建指令，基于Vue技术构建至少两个通用业务组件，不同通用业务组件可实现不同功能；

对应关系确定模块220，用于响应于功能分析指令，获取汽车业务管理系统所需具备的至少两个功能，确定与至少两个功能对应的通用业务组件；

系统创建模块230，用于响应于聚合指令，将与汽车业务管理系统所需具备的至少两个功能对应的通用业务组件进行聚合处理，得到汽车业务管理系统。

可选地，本公开所构建的汽车业务管理系统包括汽车零售管理系统、汽车交付系统、汽车客服管理系统或汽车售后服务系统。其中，汽车零售管理系统负责进行汽车零售管理，汽车交付系统负责进行汽车交付管理，汽车客户关系管理系统负责进行汽车客户关系管理，汽车售后服务系统负责进行汽车售后服务管理。

需要说明的是，对于一个企业，当需要对多个方面进行管理时，该企业可以重复使用上述技术方案构建多个汽车业务管理系统。如企业A可以根据其业务需求，仅构建汽车零售管理系统。企业A可以根据其业务需求，构建汽车零售管理系统和汽车交付系统。企业C可以根据其业务需求，同时构建汽车零售管理系统、汽车交付系统、汽车客服管理系统和汽车售后服务系统。

继续参见图2，在图2中，第一层面是指业务功能。其根据需要构建的汽车业务管理系统实际需要管理的内容确定，即根据开发目的确定。示例性地，业务功能包括任务管理、线索管理、试驾管理、交付接待、道路救援等等。

图2中，第二层面为对第一层面的进一步设计，第二层面中各项目是指本公开组件创建模块210所构建的通用业务组件。示例性地，通用业务组件包括但不限于下述中的至少一个：客户基础信息组件，客户订单列表组件，客户投诉记录组件，客户交付单组件，客户车辆告警组件、试驾记录组件、充电桩组件、咨询记录组件、满意度组件、车辆详情组件、销售订单组件、投诉记录组件、意向单组件以及任务管理组件。该通用业务组件用于基于业务数据实现业务功能。需要说明的是，不同的通用业务组件可以是并列关系，也可以是上下级关系，本公开对此不作限制。

图2中，第三层面为汽车业务管理系统，各汽车业务管理系统由第二层面中的通用业务组件聚合得到。其在聚合时，利用对应关系确定模块220和系统创建模块230进行聚合。

可选地，汽车业务管理系统包括汽车零售管理系统、汽车交付系统、汽车客服管理系统或汽车售后服务系统。

需要说明的是，在实际中，若需要构建的汽车业务管理系统为两个，分别汽车交付系统和汽车客服管理系统，经过分析发现这两个汽车业务管理系统均需要调用客户基础信息，则在利用组件创建模块210构建客户基础信息组件时，并不是为汽车交付系统和汽车客服管理系统分别创建客户基础信息组件，而是仅创建一个客户基础信息组件，该客户基础信息组件既可以应用于汽车交付系统，也可以应用于汽车客服管理系统。

另外，需要说明的是，由于系统创建模块230在进行聚合处理时，是将与汽车业务管理系统所需具备的至少两个功能对应的通用业务组件进行聚合处理，得到汽车业务管理系统，因此，汽车业务管理系统包括下述通用业务组件中的至少两个：客户基础信息组件，客户订单列表组件，客户投诉记录组件，客户交付单组件，客户车辆告警组件、试驾记录组件、充电桩组件、咨询记录组件、满意度组件、车辆详情组件、销售订单组件、投诉记录组件、意向单组件以及任务管理组件。

在上述技术方案中，通用业务组件基于Vue技术得到。Vue可以理解为一个基础的工具，比如计算机就是一个基础的工具，大家可以用计算机做各种各样的事情，本公开中使用Vue这个基础的工具构建汽车业务管理系统的各个通用业务组件。此时，各个通用业务组件相当于“积木块”，通过将这些“积木块”进行组合，最终可以得到汽车零售管理系统、汽车交付系统、汽车客服管理系统和汽车售后服务系统等等。

需要强调的是，在本公开中，所提供的通用业务组件具有通用性。此处，“通用性”应当理解为，同一通用业务组件与其他不同的通用业务组件聚合，可以得到不同的汽车业务管理系统。即同一通用业务组件可应用于不同的汽车业务管理系统。例如，汽车零售管理系统的销售订单组件(该销售订单组件为通用业务组件)，可以无缝的运行在汽车客服管理系统中。可选地，为了使得通用业务组件具有通用性，在基于Vue对通用业务组件进行构建时，可以对webpack的源码配置进行修改，使webpack这个工具可以把编写好的具有业务含义的组件打包成标准组件，进而使得这个标准组件可以无缝的运行在各个汽车业务管理系统中。

下面进一步举例说明如何将一个个具有业务功能的通用业务组件组合在一起形成不同的汽车业务管理系统。示例性地，各个汽车业务管理系统在实现其所具备的功能时需要调用客户的各种信息。因此，可以基于客户的各种信息设置多个通用业务组件，如客户基础信息组件，客户订单列表组件，客户投诉记录组件，客户交付单组件，客户车辆告警组件等组件。但是每个汽车业务管理系统所需要具有的功能不一样，因此其所需要的通用业务组件不一样，比如汽车零售管理系统需要客户订单列表组件和客户基础信息组件；汽车交付系统需要客户交付单组件和客户基础信息组件；汽车客服管理系统需要客户基础信息组件，客户订单列表组件，客户交付单组件，客户车辆告警组件等等。据此，对应任何一个汽车业务管理系统，将其所需要的各个通用业务组件进行组合，可以得到该汽车业务管理系统。

上述技术方案具有以下优势：

1、上述技术方案可以提高构建效率。上述技术方案的实质是将汽车业务管理系统组件化，这样在构建时，每个人都专注于自己的通用业务组件构建，完善自己的通用业务组件功能。并且由于通用业务组件均基于Vue技术构建得到，这使得所得到的通用业务组件一脉相承，可以减少和别人的代码发生冲突的可能性，可以缩减代码调试花费的时间，因此可以提高整个汽车业务管理系统构建的效率。

研究表明，对应同一规模的汽车业务管理系统，利用上述技术方案，比利用现有的构建方式，可以缩短2/5的构建时长。

2、上述技术方案所构建的通用业务组件可以重复使用。由于汽车业务管理系统组件化，而各通用业务组件又具有通用性，可以与其他通用业务组件进行自由组合，可以实现各通用业务组件的重复使用。

3、上述技术方案可以提升整个项目的可维护性。由于汽车业务管理系统由各通用业务组件组合得到。若同时应用于不同汽车业务管理系统的某个通用业务组件存在缺陷时，对该通用业务组件进行修复，相当于对包括该通用业务组件的所有汽车业务管理系统进行修复，因此，可提升整个项目的可维护性。

需要再次强调的是，在本公开中，所提及的通用业务组件与ui(用户界面，UserInterface)组件不同。ui组件是一个一个的ui元素，是形状和样式，没有功能和数据。如按钮组件是一个按钮的样子，表格组件是一个表格。而本公开提及的通用业务组件包含业务数据，是比ui组件更高一层的组件。例如，客户订单列表组件里包含表格组件，按钮组件等等各种ui组件。同时客户订单列表组件还有功能和数据，客户订单列表组件可以自动的查询出客户的订单列表信息。通用业务组件可以使用在汽车业务管理系统中。进一步地，可以设置通用业务组件的运行需要账号系统的支持，运维系统的支持等等。

在上述技术方案的基础上，可选地，组件创建模块110具体用于：

第一步，响应于脚手架安装指令，安装生成通用业务组件的脚手架。

其中，可选地，脚手架安装指令在某一预设条件满足后生成。示例性地，该预设条件可以为计算机接收到用户输入的某些预设操作(如点击某图标)。

示例性地，安装cnpm,，然后设置源https://npm.chehejia.com/；

安装脚手架cnpm install@chehejia/chj-cli-g。

可选地，在安装生成通用业务组件的脚手架之后，还包括：生成通用业务组件名称。

示例性地，可以根据预设的通用业务组件名称命名规则，生成通用业务组件名称；或者，接收用户输入的字符串，基于用户输入的字符串生成通用业务组件名称。示例性地，图4中创建的通用业务组件chj-initui名称为chj-rb。

第二步，响应于依赖安装指令，在通用业务组件根目录中安装通用业务组件所需要的依赖。

可选地，依赖安装指令在某一预设条件满足后生成。示例性地，该预设条件可以为计算机接收到用户输入的某些预设操作(如点击某图标)，或者某个步骤(如脚手架安装完成)已完成等。

示例性地，参见图5，进入通用业务组件根目录，安装通用业务组件所需要的依赖，cnpminstall。

第三步，响应于地址配置指令，配置开发环境的接口地址。

可选地，响应于地址配置指令在某一预设条件满足后生成。示例性地，该预设条件可以为计算机接收到用户输入的某些预设操作(如点击某图标)，或者某个步骤(如依赖安装完成)已完成等。

示例性地，参见图6，配置开发环境的接口地址，以使得后续可以调用后端服务器。

可选地，可以直接在根目录下的dev.js中修改options参数，以达到配置开发环境的接口地址的目的。

例如，通过下述代码在根目录下的dev.js中修改options参数。

const option＝{

target:‘http://api-web-dev.chehejia.com’,

changeOrigin:true,

pathRewrite:{

‘^/component’:‘’

}

}

koaApp.use(k2c(proxy(‘/component/aisp-amp-api’,option)))；

第四步，接收基于通用业务组件根目录的目录结构编写的通用业务组件代码。

示例性地，基于通用业务组件根目录的目录结构编写的通用业务组件代码如图7中所示。

可选地，组件创建模块210还用于在接收基于通用业务组件根目录的目录结构编写的通用业务组件代码之后，响应于测试指令，对通用业务组件测试处理；

若通用业务组件测试通过，对通用业务组件代码打包处理。

其中，可选地，测试指令在某一预设条件满足后生成。示例性地，该预设条件可以为计算机接收到用户输入的某些预设操作(如点击某图标)，或者某个步骤(如步骤四)已完成等。示例性地，参见图8，可以利用图8中的代码测试通用业务组件。参见图9，可以使用“npmrun build–rb”命令打包。

可选地，组件创建模块210在对通用业务组件代码打包处理时，利用webpack对通用业务组件代码打包。示例性地，利用webpack技术将通用业务组件代码打包为jar包。这样设置的实质是，将通过测试的前端业务组件js代码打为jar包，形成webjars，使用maven规范对webjars进行管理。这样设置可以保证这些Web资源版本唯一性，也便于升级。

可选地，在上述技术方案中，组件创建模块210在执行接收基于通用业务组件根目录的目录结构编写的通用业务组件代码的过程中，在通用业务组件对应的库文件的后缀中添加时间戳。这样在使用时，浏览器可以基于时间戳调用库文件，进而实现在后续基于通用业务组件形成的汽车业务管理系统的客户端在不清空浏览器缓存的情况下，就可以使得浏览器调用新发布的库文件。

继续参见图10和图11，汽车业务管理系统为前端系统，如图10所示，可以部署在Nginx中；或者如图11所示，汽车业务管理系统部署在Tomcat中。汽车业务管理系统部署在Nginx的方案，汽车业务管理系统结构复杂，部署难度大，适合需要访问人数多的情况。汽车业务管理系统部署在Tomcat中的方案，汽车业务管理系统结构简洁，部署难度小，适合需要访问人数少的情况。

需要说明的是，汽车业务管理系统为前端业务系统。在实际中，该汽车业务管理系统可以与后端服务器形成前后端分离式业务系统或前后端不分离式业务系统。示例性地，在实际构建的过程中，可以将图10中汽车业务管理系统构建为前后端分离式业务系统。而图11中汽车业务管理系统构建为前后端分离式业务系统或前后端不分离式业务系统。

前后端不分离式业务系统，前端与后端的耦合度很高，适用于体量小的汽车业务系统。

前后端分离式业务系统，前端与后端的耦合度相对较低，前端只需要更专注于样式，UI，交互、适配等。服务端更专注于业务逻辑，所有接口都是API微服务的方式提供服务，其可以更好的提供并发性能，可以减少由于职责不明确而产生互相扯皮现象出现。

图13为本公开实施例提供的电子设备的硬件结构示意图，如图13所示，电子设备300包括：

一个或多个处理器301，图13中以一个处理器301为例；

存储器302；

所述电子设备还可以包括：输入装置303和输出装置304。

所述电子设备中的处理器301、存储器302、输入装置303和输出装置304可以通过总线或者其他方式连接，图13中以通过总线连接为例。

存储器302作为一种非暂态计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本公开实施例中的适用于汽车业务管理系统的构建方法对应的程序指令/模块。处理器301通过运行存储在存储器302中的软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例的适用于汽车业务管理系统的构建方法。

存储器302可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据电子设备的使用所创建的数据等。此外，存储器302可以包括高速随机存取存储器，还可以包括非暂态性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态性固态存储器件。在一些实施例中，存储器302可选包括相对于处理器301远程设置的存储器，这些远程存储器可以通过网络连接至终端设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置303可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。输出装置304可包括显示屏等显示设备。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。