CN1967560A - 业务操作权限控制方法、关系数据库的生成方法 - Google Patents

Abstract

本发明涉及计算机领域，本发明公开了一种业务操作权限控制方法、关系数据库的生成方法，本发明的业务操作权限控制方法包括：确定用户的业务操作、业务操作对象；根据所述用户、所述业务操作对象的信息，判断所述用户是否拥有所述业务操作对象的操作权限，如果拥有，则根据所述操作权限的语义信息执行所述业务操作；否则，拒绝执行所述业务操作。本发明不但实现了对用户的业务操作的细粒度的权限控制，还使得权限控制更具灵活性。

Description

业务操作权限控制方法、关系数据库的生成方法

技术领域

本发明涉及计算机领域，特别的涉及一种业务操作权限控制方法以及用于权限控制的关系数据库的生成方法。

背景技术

为了保证业务系统的安全性，通常采用权限管理来控制用户在业务系统可执行的业务操作。通过权限控制策略，对可操作的系统进行相应的权限配置、鉴权，并对不同类型的用户进行相应的授权，通过鉴权确保用户只能执行被授权的操作，访问授权的数据。

目前绝大部分的业务系统采用基于角色的权限控制(Role Base AccessControl，简称RBAC)策略，该策略通过角色对权限进行收敛，即首先按照角色进行权限的分配和管理，以便于权限的配置；然后通过对用户进行角色授予，使用户获得相应角色的权限；如果需要取消某用户所获得的相应的角色的权限时，只需要撤消该用户的角色授予即可。

RBAC策略的基本原理具体是：首先根据不同的职责定义不同的角色，确定该角色需要执行的业务操作范围，把相应的权限集配置给角色；然后为承担相应职责的用户配置角色。通过该权限与角色的配置，在用户执行操作时，根据该配置，判断该用户是否拥有该业务操作权限的角色，如果拥有则允许执行该业务操作；否则，拒绝该业务操作。

目前通常采用以下的实现方案实现利用RBAC策略对业务系统进行权限控制，具体如下：

预先定义业务操作权限信息、相应的需要控制的业务操作功能，并建立业务操作功能与权限的匹配关系，然后通过定义角色、分配角色权限、分配操作人员角色完成人员的权限配置；将上述的定义和配置情况存储在关系数据库管理系统(Relational Data Base Management System，简称RDBMS)中。

在用户执行业务操作前，系统根据RDBMS进行相应的鉴权操作，查询获取该业务操作关联的权限信息；然后查询该操作员对应的角色的权限是否包含有该业务操作的权限，如果有，则执行业务操作；否则，不允许执行。

由上可见，由于通过对访问对象进行权限的预先静态绑定，在业务操作时，根据在进行相应的鉴权操作。特别的适合于菜单、按钮等界面静态对象的权限控制。

但是，由于业务的日趋复杂，权限控制粒度需要细化，很多业务操作相同，但是对于不同的操作人员，允许访问的数据对象有严格、细粒度的权限控制。即权限不仅仅需要控制关键、重要的业务操作或系统功能，还需要对数据记录范围进行权限控制。最常见的例子如：级别不同的人员所允许查询的数据记录范围不同，主管可查询整个部门的数据，而普通人员则只允许查询本人创建的记录数据。

对于数据类集合，即记录级的访问控制，由于记录一般需要动态、增量的变化，通过对访问对象进行权限的预先静态绑定实现RBAC策略方法，无法预先对记录进行权限资源分配、存储，因此该权限的预先静态绑定方法已不能满足日益发展的业务的权限控制需要，特别是不能够满足业务对于数据记录级的权限控制需要。

为了实现数据记录的权限控制，提出了一种采用业务应用自行进行控制的技术方案。该方案是，当操作员拥有相应的权限后，需要由业务应用对操作员进一步可操作的访问对象范围(包括数据记录)进行控制。

使用该技术方案执行数据记录级的访问对象范围控制，既可以在数据库端(比如将数据存储到数据库过程中)进行相应的业务逻辑控制，返回可操作的数据记录集合；也可以在业务侧对返回的数据集进行过滤、控制、显示可操作的数据记录集合。

可见该方案虽然可以实现数据记录级的权限控制，但是使用该技术方案，对于不同的业务限制逻辑，需要独立实现，对于相同的业务应用点，也需要自行控制。当业务的数据权限变更时，需要修改系统代码，导致系统不得不面对巨大的修改工作量，无法及时快速的满足业务需要，同时还将给系统的稳定性带来极大的隐患。

发明内容

本发明提供了一种业务操作权限控制方法，实现对业务操作细粒度的权限控制。

本发明还提供了一种用于权限控制的关系数据库的生成方法，实现利用该系统，对业务操作细粒度的权限控制。

本发明提供的业务操作权限控制方法，包括：

确定用户的业务操作、业务操作对象；

根据所述用户、所述业务操作对象的信息，判断所述用户是否拥有所述业务操作对象的操作权限，如果拥有，则根据所述操作权限的语义信息执行所述业务操作；否则，拒绝执行所述业务操作。

本发明所述的业务操作权限控制方法中，可选地，所述操作权限的语义信息包含：用户和/或业务操作对象的属性。

本发明所述的业务操作权限控制方法中，可选地，所述操作权限的语义信息支持用户自定义输入。

本发明所述的业务操作权限控制方法中，可选地，所述业务操作为数据库操作，所述的根据所述操作权限的语义信息执行所述业务操作，具体包括：

根据所述操作权限的语义信息，构造结构化查询语言SQL；

根据所述SQL执行所述业务操作。

本发明所述的业务操作权限控制方法中，可选地，所述构造SQL，具体为：

将所述操作权限的语义信息的信息元素作为规则因子，根据所述操作权限的语义信息的逻辑规则，生成所述SQL。

本发明所述的业务操作权限控制方法中，可选地，采用面向对象语言定义所述操作权限的语义信息，在根据所述操作权限的语义信息执行所述业务操作步骤之前，进一步包括：

使用规则引擎解析所述操作权限的语义信息。

本发明所述的业务操作权限控制方法中，可选地，所述规则引擎支持用户自定义设置。

本发明提供的用于权限控制的关系数据库的生成方法，包括：

定义携带语义信息的权限；

配置所述操作权限与业务操作之间的关联关系、所述操作权限与角色的对应关系，并将所述角色分配给用户。

本发明所述的关系数据库的生成方法中，可选地，在所述定义携带语义信息的权限的步骤中，包括：

将用户和/或业务操作对象的属性，定义在所述操作权限的语义信息中。

本发明所述的关系数据库的生成方法中，可选地，所述操作权限的语义信息支持用户自定义输入。

本发明所述的关系数据库的生成方法中，可选地，采用面向对象语言定义所述操作权限的语义信息，所述方法进一步包括：

设置用于解析所述操作权限的语义信息的规则引擎。

本发明所述的关系数据库的生成方法中，可选地，所述规则引擎中的规则支持用户自定义输入。

由以上业务操作权限控制方法的技术方案可以看出，本发明在对用户的业务操作进行权限控制时，根据该用户以及操作对象的信息，判断用户是否拥有所述业务操作的权限，如果用户拥有该业务操作的权限，则根据所述操作权限的语义信息，执行相应的业务操作。可见在本发明中，由于根据操作权限的语义信息，确定用户对该业务操作的权限范围，根据权限范围执行相应的业务操作，丰富了权限控制策略，有利于满足不同的权限控制策略。本发明实现了更小粒度的权限控制，相对于现有技术，本发明方法实现了从操作/功能等静态对象级到数据记录字段级的细粒度的业务操作权限控制。

同时的，由于通过定义操作权限的语义信息定义权限的范围变更，当权限变更时，只需要变更操作权限的语义信息即可，而不需要修改系统代码，既有利于满足系统的业务动态性变更需要，还有利于保证系统的稳定性。

由以上用于权限控制的关系数据库的生成方法的技术方案可以看出，由于本发明用于权限的关系数据库的权限中包含语义信息的权限，由语义信息确定用户对该业务操作拥有的权限范围，而语义信息的定义可以根据实际各种因素，按照一定的规则结合来定义，权限定义更加灵活，有利于对用户对业务操作的权限控制更加细粒度化；并且，当权限变更时，只需要变更操作权限的语义信息即可，而不需要修改系统代码，既有利于满足系统的业务动态性变更需要，还有利于保证系统的稳定性。

附图说明

图1为实施例1的业务操作权限控制方法的流程示意图；

图2为实现图1所示方法的系统逻辑结构示意图；

图3为实施例2的用于权限控制的关系数据库的生成方法流程示意图；

图4为实施例2中的子系统信息注册表与公共权限表以及子系统的各权限表的相互关系示意图。

具体实施方式

本发明实施例的核心是，在进行业务操作权限控制时，根据用户、业务操作对象的信息，判断该用户是否拥有所述业务操作的权限，如果拥有，则根据操作权限的语义信息，确定用户拥有的权限范围，根据权限范围执行所述业务操作；否则，拒绝执行所述业务操作。

为了使本领域的技术人员更好的理解本发明内容，以下结合附图以及具体实施例对本发明内容进行详细的说明。

实施例1：

图1为本实施例的业务操作权限控制方法的流程示意图，如图示，本方法根据该关系数据库中的权限、业务操作对象(对应功能)、以及该业务操作对象所在的子系统、人员和角色的对应关系，进行权限控制，本方法包括以下步骤：

步骤101：开始。

业务系统处于等待状态，等待用户输入业务操作。

步骤102：用户申请执行业务操作。

用户向业务系统提交业务操作申请，该业务操作既可以是菜单、按钮的控制以及界面等静态对象的控制，亦可以是对业务系统数据的查询、删除、更新等数据记录级的操作。

步骤103：判断该业务操作是否为权限受控的业务操作，如果是，则执行步骤104；否则执行步骤108。

在设置了权限控制策略的业务系统中，根据实际要求，对某些业务操作设置了权限控制，只允许具备相应权限的用户才能执行，而对某些业务操作不设权限限制，允许任何用户执行。因此业务系统，在接收到用户申请业务操作后，执行相应操作前，需要判断该业务操作是否为权限受控的业务操作，如果是，则执行步骤104；否则执行步骤108。

步骤104：确定用户、业务操作对象信息。

如果该业务操作为权限受控的业务操作，则进一步确定用户、业务操作对象信息。

步骤105：查询用户是否拥有该业务操作的权限，如果该用户拥有该业务操作的权限，则执行步骤106；否则，执行步骤109。

在包含用户、业务操作对象属性作为语义信息的鉴权数据系统中，采用基于角色的权限控制策略，预先将各人员分别对应到各角色(角色与人员的对应关系如表一所示)，系统(各子系统)根据角色对各业务操作(对应功能)进行权限控制。因此，根据角色在子系统中的权限(该对应关系如表二的角色权限表结构所示)，以及相应的权限在该子系统中的具体业务操作(与功能相对应)的映射关系(该映射关系如表三的业务系统功能权限表结构)，确定用户是否具有该系统(子系统)中的该业务操作的权限。

          表一：人员角色配置表

序号	字段定义	数据类型	长度	说明
					1	人员账号	Varchar2	20
2	角色编号	Varchar2	20
					3	...

                          表二：角色权限表结构

序号	字段定义	数据类型	长度	说明
					1	角色编号	Varchar2	20
2	子系统编号	Varchar2	20
					3	权限编号	Varchar2	20	关联的权限，权限信息在子系统权限表中存储
4	...

                       表三：业务系统功能权限表结构

序号	字段定义	数据类型	长度	说明
					1	功能编号	Varchar2	20	系统自动生成
2	功能名称	Varchar2	50
					3	子系统编号	Varchar2	20
4	权限编号	Varchar2	20	关联的权限，权限信息在子系统权限表中存储
					5	...

首先，根据该用户的用户账号，查询如表一所示的人员角色配置表，确定该用户所对应的角色编号。

然后，根据该角色编号，该用户欲执行的业务操作所在的子系统的子系统编号，和该用户欲执行的业务操作的功能名称、功能编号，查询表二所示的角色权限配置表以及表三所示的业务系统功能权限表，确定对于当前业务操作(对应功能名称、功能编号)，该角色在当前业务系统(子系统)中是否能够找到相应的权限编号，如果能够找到，则该用户拥有该权限编号规定的权限，执行步骤106；否则，表明该用户并不拥有当前业务操作的权限，执行步骤109。

步骤106：确定该用户对该项业务操作所拥有的权限。

一般的，为了便于管理系统的权限控制信息的管理，针对系统(各子系统)预先建立权限表，在权限控制表中分别就各权限(权限编号)分别通过定义该操作权限的语义信息规定权限的具体权限内容，该权限表的结构可以采用表四的结构：

                      表四：权限表结构

序号	字段定义	数据类型	长度	说明
					1	权限编号	Varchar2	20	系统自动生成
2	权限名称	Varchar2	50
					3	语义信息	Varchar2	2000	用于构成权限控制项
4	描述	Varchar2	200	语义用途说明
					5	...

如果在步骤105中，能够找到匹配的权限编号，则根据权限编号，查找表四所示的权限表，确定该权限的语音信息，并按照预设的匹配规则，解析该业务操作对应的权限中的语义信息，该语义信息即为该权限的具体描述，即该用户对于当前操作具有怎样的权限。

步骤107：根据权限执行业务操作。

根据权限执行相应的业务操作，例如：

如果该业务操作为数据记录的查询操作，则系统根据解析的语义信息，构造结构化查询语言SQL，进行数据库查询操作。

一般的，语义信息通过定义用户和/或业务操作对象的属性构成语义信息的信息元素，以及各信息元素之间的逻辑规则关系(比如：与、非、if、Where等)，从而规定确切的权限范围。因此根据解析的语义信息，构造结构化查询语言SQL即是，将所述操作权限的语义信息的各信息元素作为规则因子，根据所述操作权限的语义信息的逻辑规则构造SQL。

SQL包括字段列表信息以及限制规则(比如where条件)信息，比如：

假设在语义信息中规定角色不同，可查看的字段信息不同，规定高级别人员可查看关键信息(比如薪酬等保密信息)，SQL的字段列表中包含“薪酬(Salary)”字段，而低级别则不允许查看该关键信息(比如薪酬等保密信息)，SQL的字段列表中不包含Salary字段。

假设语义信息规定高级别的人员可查看所有人的档案，而低级别的人员只允许查看本人信息，那么，对于低级别的用户的SQL，在SQL中的Where条件句中增加“档案表.档案所属人员账号＝“用户账号”条件，而对于高级别人员则无需此限制。

业务侧根据鉴权构造的SQL语句，构造相应的完整的业务应用SQL语句，可由鉴权服务器提供公共的鉴权包，并将该鉴权包发送给业务系统，由业务系统构造相应的业务应用SQL。

构造业务应用的SQL后，根据SQL中相应的字段信息以及匹配字段Title信息，构造完整地展示视图。

语义信息脚本中带有SQL语句的Select的字段信息，不同的权限策略对应不同的字段Title信息，构造不同的数据展示视图，假设管理员对应的角色为103，管理人员可查看“Salary”信息，而普通人员不能查看“Salary”信息。字段权限语义信息定义如下：

@Role.Value＝‘103’

   IF&StaffHaveRole($Staff.StaffNo，@Role.Value)THEN

   RENTURN(‘Salary’)

ELSE

    RENTURN(‘’)

END IF

相应的字段Title定义数据字段结构如表五所示：

           表五：数据字段结构

序号	字段定义	数据类型	长度	说明
					1	视图编号	Varchar2	20
2	字段名	Varchar2	100
					3	标题信息	Varchar2	200
4	...

解析字段列表，根据字段名，到相应的视图中查询字段标题Title定义信息，构造完成数据视图，即：

SELECT StaffNo，Salary，...FROM...

查询到Salay字段标题为“薪酬”，即则查询结构列表构造为表六所示的数据视图：

       表六：数据视图结构

序号	员工账号	薪酬	...
					1	1001	4500.00

步骤108：执行业务操作。

如果该业务操作没有权限限制，则直接根据用户操作执行相应的业务操作。

步骤109：拒绝该业务操作。

如果该用户不具备该业务操作的权限，则拒绝该业务操作，为了使得业务操作系统更加人性化，继续执行步骤110。

步骤110：向用户返回该业务操作决策，告知用户决策结果，或者同时告知决策原因。

本实施例中的业务操作权限控制方法可以采用如图2所示的系统逻辑结构框架来实现，如图示：

客户端202访问业务应用服务器上的服务，业务应用鉴权通过统一的鉴权服务器201进行，鉴权服务器201根据数据库服务器203进行鉴权服务。在鉴权服务器201中包括规则引擎2011，用于解析操作权限的语义信息。而对于权限定义信息2031、权限配置信息2032、字体Title定义信息2033、业务数据2034等基础数据存储在数据库服务器203中。权限配置信息2032包括权限业务操作对应关系(如表三所示、)、权限与角色的配置关系(如表二所示)以及角色与人员的配置关系(如表一所示)。

为了提高访问、解析、鉴权的效率，权限定义信息2031可通过XML文件存储在鉴权服务器201的本地，并且，为了减少数据读取时间，在鉴权服务器201上可以将权限配置信息2032的权限基础数据存储在内部变量数据副本2012中。

图2所示的系统结构只为实施本实施例的业务操作权限控制方法较优的一种系统结构，实现本发明的系统结构并不限于此。

实施例2：

本实施例对用于权限控制的关系数据库的生成方法作具体介绍，图3为本实施例的用于权限控制的关系数据库的生成方法流程示意图，如图示，本方法包括以下步骤：

步骤301：定义权限。

定义如表四所示的结构的权限，在权限中定义语义信息的域，将语义信息作为权限控制项，成为权限的固有属性，该语义信息包括常量、内部输入对象、外部输入对象、逻辑运算等自定义信息。

为了便于系统识别语义对象，针对各类型的语义对象作以下的预定义：

第一：对于自定义常量对象、内部对象，分别使用特定的前缀标识(比如可以分别使用“@”、“#”前缀标识)区分，常量对象属性值可直接引用，内部对象可指定为对象属性值，对象包括数据库数据对象、系统会话期间的数据对象、或业务对象等，该内部对象可在运行期间动态解析、取值、读取。

第二：对于自定义外部输入对象，同理使用特定的前缀标识(比如可以使用“$”作为前缀标识)比如，外部输入定义当前操作人员的所属地市(使用Staff.CityId变量定义)，可以表达为：$Staff.CityId。

第三：语义信息可支持面向对象方法，比如支持Java脚本定义方法，并可调用已有函数，比如，对于字符串比较、数据库存储等的过程，可以通过调用已有的相应函数来实现。

在定义语义信息时，最直接的方法是直接将语义定义成计算机可以直接读取的语义信息，但是，为了方便用户定义语义信息方便，准确，实现权限修改的灵活性，因此最好在定义语义时可以采用用户易于理解的、接近自然语言的面向对象语言，来定义语义信息，比如java、XML等。为达到该目的，可以引进规则引擎，使用规则引擎将用户使用面向对象语言来定义的语义信息，解析成计算机能够读取的信息。

为了进一步方便权限修改操作，使得规则引擎相应的根据权限的修改，动态的匹配解析规则，还可以将规则引擎的解析规则属性设置为可动态修改。

第四：支持逻辑运算符号，比如：＜、＞、＜＞、＝、IN等逻辑运算符号。

第五：支持If-Then、When、Where等规则。

以定义档案查看权限为例，需要定义的规则是：档案管理员可查看所有档案信息，而普通人员只能够查看自己档案信息，假定档案管理员对应的角色为101，利用Java脚本定义该语义如下：

@Role.Value＝‘101’

IF@Role.Value IN$Staff.Roles THEN

  RENTURN(‘’)

ELSE

  #retStr＝‘T_MIS_DOC.BelongStaffNo＝“’+$Staff.StaffNo+‘”’

  RENTURN(retStr)

  END IF

可见，在定义权限语义时，受控的访问对象属性可以作为规则因子在语义信息定义中进行相应的逻辑控制，并且由于该因子支持外部输入、内部对象、自定义常量，因此该因子可以根据实际需要景象相应的动态配置，从而使得各权限可以根据实际需要，动态调整配置。

在业务系统中，为了方便系统的权限管理，将权限分为公有权限和各业务子系统的私有权限，各业务子系统的私有的权限可以存储在各子系统自建的权限表中。

为了统一管理权限，将各子系统统一到“子系统信息注册表”中登记注册系统信息(包括相应的存储私有权限的表名)。如表七所示为该子系统信息注册表结构示意，在该子系统信息注册表中，包含子系统编号、该编号对应的子系统、以及该子系统的权限存储表等信息。

                        表七：子系统信息注册表结构

序号	字段定义	数据类型	长度	说明
					1	子系统编号	Varchar2	20	系统自动生成
2	子系统名称	Varchar2	50
					3	权限存储表	Varchar2	100	存储私有权限的表，该表结构与表四所示的权限表相同
4	描述	Varchar2	200	子系统说明

5

...

图4为子系统信息注册表与公共权限表、工作流权限表、知识库权限表、人力资源权限表的相互关系示意图。由图可见，子系统信息注册表实现了业务系统内的各子系统的权限的统筹管理，同时也有利于各子系统的各私有权限的独立管理。

步骤302：配置权限与业务操作的关联。

根据权限与业务系统功能(对应业务操作)的关联，建立如表三所示的业务系统功能权限表，指定业务操作需要的权限，由于权限可以动态调整，因此权限与业务操作的关联相应的可以动态调整。

步骤303：定义角色，并将权限分配给角色。

根据业务需要，定义角色，并且，在设置好权限与业务操作的关联后，分别对于各业务子系统，将系统内的权限分别分配给相应的角色，建立如表二所示的角色权限表。

步骤304：将角色分配给用户。

将权限分配至角色后，进一步根据实际情况，将各角色分配给业务操作的相应用户，建立如表一所示的人员角色配置表，将各人员对应到相应的角色。通过角色对应人员的分配，能够使的权限的分配更加清洗和易于维护，而避免权限直接与人员相关联而导致的由于人员变动频繁引起权限维护混乱的问题。完成上述的配置后，当用户执行业务操作时，利用该配置执行鉴权操作。

以上对本发明实施例所提供的一种业务操作权限控制方法以及用于业务操作权限控制的关系数据库的生成方法，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心；同时，对于本领域的一般技术人员，依据本发明的核心，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (12)

1、一种业务操作权限控制方法，其特征是，包括：

确定用户的业务操作、业务操作对象；

根据所述用户、所述业务操作对象的信息，判断所述用户是否拥有所述业务操作对象的操作权限，如果拥有，则根据所述操作权限的语义信息执行所述业务操作；否则，拒绝执行所述业务操作。

2、根据权利要求1所述的业务操作权限控制方法，其特征是，所述操作权限的语义信息包含：用户和/或业务操作对象的属性。

3、根据权利要求1或2所述的业务操作权限控制方法，其特征是，所述操作权限的语义信息支持用户自定义输入。

4、根据权利要求1或2所述的业务操作权限控制方法，其特征是，所述业务操作为数据库操作，所述的根据所述操作权限的语义信息执行所述业务操作，具体包括：

根据所述操作权限的语义信息，构造结构化查询语言SQL；

根据所述SQL执行所述业务操作。

5、根据权利要求4所述的业务操作权限控制方法，其特征是，所述构造SQL，具体为：

将所述操作权限的语义信息的信息元素作为规则因子，根据所述操作权限的语义信息的逻辑规则，生成所述SQL。

6、根据权利要求1或2所述的业务操作权限控制方法，其特征是，采用面向对象语言定义所述操作权限的语义信息，在根据所述操作权限的语义信息执行所述业务操作步骤之前，进一步包括：

使用规则引擎解析所述操作权限的语义信息。

7、根据权利要求6所述的业务操作权限控制方法，其特征是，所述规则引擎支持用户自定义设置。

8、一种用于权限控制的关系数据库的生成方法，其特征是，包括：

定义携带语义信息的权限；

配置所述操作权限与业务操作之间的关联关系、所述操作权限与角色的对应关系，并将所述角色分配给用户。

9、根据权利要求8所述的用于权限控制的关系数据库的生成方法，其特征是，在所述定义携带语义信息的权限的步骤中，包括：

将用户和/或业务操作对象的属性，定义在所述操作权限的语义信息中。

10、根据权利要求8或9所述的用于权限控制的关系数据库的生成方法，其特征是，所述操作权限的语义信息支持用户自定义输入。

11、根据权利要求8或9所述的用于权限控制的关系数据库的生成方法，其特征是，采用面向对象语言定义所述操作权限的语义信息，所述方法进一步包括：

设置用于解析所述操作权限的语义信息的规则引擎。

12、根据权利要求11所述的用于权限控制的关系数据库的生成方法，其特征是，所述规则引擎中的规则支持用户自定义输入。

Images