CN113760478A - 目标作业系统的访问控制方法、装置、设备及介质 - Google Patents

Abstract

本申请提供了一种目标作业系统的访问控制方法，包括：接收API调用请求，根据API调用请求中的模型标识，利用根据作业系统建立的，且能被重复使用的模型和作业系统的API的映射关系确定目标API，该目标API用于访问目标作业系统。其中，模型一旦定义完成，后续可以直接使用该模型。通过不同的模型标识，利用模型和API的映射关系自动路由到作业系统的不同API，从而实现了通过统一的方式对作业系统的路由访问，无需了解每一个API的出入参定义和调用方式，简化了调用过程，提高了目标作业系统的访问效率。

Description

目标作业系统的访问控制方法、装置、设备及介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种目标作业系统的访问控制方法、装置、设备以及计算机可读存储介质。

背景技术

在进行应用程序开发时，为了提高开发效率，开发人员可以针对一些功能提供对应的应用程序编程接口(application programming interface，API)。该API具体可以是预定义的函数或者应用程序不同组成部分衔接的约定。通过调用API可以使得开发人员无需访问源代码或者理解内部工作机制获得访问一组例程的能力。

在一些场景中，API调用方(例如应用程序或者应用程序的进程等)需要调用多个不同的API。为此，业界提出了API路由机制实现对不同API的调用。以API网关(APIgateway)为例，API调用方可以通过API网关实现协议转换以及API路由转发。

然而，API网关对外提供的API无法实现透明调用。在调用作业系统的API时，需要了解每一个API的出入参(输出参数和输入参数)定义和调用方式，然后开发特定的调用代码进行联调测试。调用过程繁琐，调用效率低下，难以满足业务需求。

发明内容

本申请提供了一种目标作业系统的访问控制方法，解决了相关技术中API调用过程繁琐，调用效率低下，难以满足业务需求的问题。本申请还提供了上述方法对应的装置、设备、计算机可读存储介质以及计算机程序产品。

第一方面，本申请提供了一种目标作业系统的访问控制方法。该方法可以由目标作业系统的访问控制系统(以下简称为访问控制系统)执行。其中，目标作业系统为作业系统中的一个或多个。作业系统具体是指通过计算机程序执行作业的系统。根据作业类型不同，作业系统可以分为多种。例如，作业系统可以是文字编辑系统、表格编辑系统、生产管理系统等用于辅助办公的系统。又例如，作业系统还可以是电子商店、电子支付系统等用于完成交易的系统。以上仅为本申请提供的作业系统的一些具体示例，作业系统包括但不限于上述示例。

具体地，访问控制系统接收API调用请求，该API调用请求包括至少一个模型标识(model ID)，该模型标识是根据作业系统预先建立的模型的标识，该标识可以是名称、编码或者其他能够唯一表征模型的字符串。然后访问控制系统根据模型标识，利用模型和作业系统的API的映射关系确定目标API，该目标API即用于访问所述目标作业系统。

在该方法中，模型能够被重复使用，一旦定义出模型，后续可以直接使用该模型，访问控制系统通过不同的模型标识，利用模型和作业系统的API的映射关系自动路由到作业系统的不同API，从而实现了通过统一的方式对作业系统的路由访问。API调用人员如开发人员无需了解每一个API的出入参定义和调用方式，也无需编写特定的调用代码进行联调测试，简化了调用过程，提高了调用效率，进而提高了作业系统的访问效率和访问体验，满足了业务的需求。

在一些可能的实现方式中，模型可以由模型标识和模型属性(model attribute)表征，映射关系可以由模型属性和API属性表征，因此，根据模型标识可以确定相应的API属性，基于该API属性可以确定目标API。如此实现了屏蔽各个作业系统API属性(例如API的出入参)的差异和调用的复杂性，通过统一的方式访问作业系统，简化了访问过程，提高了访问效率。

其中，属性具体是指事物的性质和/或关系。基于此，模型属性是指模型的性质和/或关系。模型是根据作业系统中数据实体(data entity)以及数据实体的属性(attribute)建立的。数据实体是指作业系统的软件模块所管理的数据对象。

例如，在电子商店等用于完成交易的作业系统中，数据实体可以是商品、订单等由软件模块管理的数据对象，数据实体的属性可以是数据对象的性质和/或关系，例如商品的属性可以包括名称、样式、颜色、尺寸、价格等等。又例如，在需求管理系统等辅助开发的作业系统中，数据实体可以是需求(request)、缺陷(bug)、测试用例(test case)等数据对象。缺陷这一数据实体的属性可以包括缺陷单号、产品、结果影响、当前处理人等等。

在一些可能的实现方式中，API属性是指API的性质和/或关系。例如，API属性可以是API的输入参数、输出参数、操作类型中的一种或多种。由此，访问控制系统可以根据模型标识确定API的输入参数、输出参数、操作类型中的一种或多种，基于API的输入参数、输出参数和/或操作类型可以确定出目标API。例如，访问控制系统根据输入参数和输出参数确定用于查询目标数据的目标API，或者访问控制系统根据操作类型确定用于执行目标操作的API。

在一些可能的实现方式中，作业系统可以用于提供数据服务，例如考勤管理系统、薪资管理系统等作业系统可以提供考勤、薪资等数据的查询服务。对应地，目标API用于查询目标数据。基于此，访问控制系统确定目标API后，还可以根据所述目标API，从目标作业系统获取目标数据，该目标数据包括目标API的输出参数的参数值。

下面结合考勤管理系统进行示例说明。在该示例中，考勤管理系统包括考勤(work-attendance)模块，基于该模块建立有模型标识为work-attendance的模型。访问控制系统接收API调用请求后，根据模型标识work-attendance，利用模型和作业系统的API的映射关系，确定目标API，例如，attendance-exception.Query(yyyy-mm，count)。其中，yyyy-mm表示某年某月，count表示某年某月考勤异常次数。该目标API具体用于查询员工在某年某月考勤异常次数。

在一些可能的实现方式中，所述API调用请求可以包括多个模型标识。对应地，访问控制系统可以根据目标API中第i个API的输出参数的参数值，确定第i+1个API的输入参数的参数值，所述i为正整数。具体地，API调用请求中还可以携带起始参数的参数值，访问控制系统将起始参数的参数值输入目标API中第一个API，获得第一个API的输出参数的参数值，基于第一个API的输出参数的参数值，可以获得第二个API的输入参数的参数值，以此类推，访问控制系统可以获得目标API中最后一个API的输入参数的参数值。根据所述目标API中最后一个API的输入参数的参数值，从所述目标作业系统获取目标数据，所述目标数据包括所述最后一个API的输出参数的参数值。

其中，多个模型标识所标识的模型可以对应一个作业系统，也可以对应多个作业系统。当多个模型标识对应多个作业系统(n个模型标识对应m个作业系统，n大于或等于m)时，访问控制系统基于不同模型之间的关联关系，确定多个相关联的目标API，如此可以通过一次接口调用实现对多个作业系统API的路由访问。作业调用方无需与多个作业系统对接，即可实现跨作业系统的路由访问，提高了访问效率，提升了用户体验。

下面结合考勤管理系统和薪资管理系统进行示例说明。在该示例中，考勤管理系统包括考勤模块，基于该模块建立有模型标识为work-attendance的模型。薪资管理系统包括薪资模块，基于该模块建立有模型标识为salary的模型。访问控制系统接收API调用请求后，根据模型标识work-attendance、salary，利用模型和作业系统的API的映射关系，确定目标API，例如，attendance-exception.Query(yyyy-mm，count)和salarydetail.Query(count，base-reward-deductionofexception-tax-actualsalary)。其中，yyyy-mm表示某年某月，count表示某年某月考勤异常次数。attendance-exception.Query()具体用于查询员工在某年某月考勤异常次数。salarydetail.Query()具体用于查询员工薪资明细，具体包括底薪、奖金、因考勤异常扣除额、税额和实发薪资等。

在一些可能的实现方式中，作业系统也可以用于提供操作服务。对应地，目标API具体用于执行目标操作。基于此，访问控制系统还可以根据目标API，执行目标操作。也即访问目标作业系统可以是获取目标作业系统中的目标数据，也可以是通过目标API执行目标操作。

为了便于理解，下面结合具体示例说明。在该示例中，目标作业系统为报警系统，监控系统监控到某一指标达到阈值时，可以通过访问控制系统访问报警系统，基于报警系统中的目标API执行报警操作。

在一些可能的实现方式中，访问控制系统还可以通过第一图形用户界面(graphical user interface，GUI)接收用户输入的起始模型和终止模型，然后根据模型关系图生成由所述起始模型至所述终止模型的至少一条路由路径。其中，路由路径通过模型标识表征，该路由路径可以用于生成API调用请求。

在该实现方式中，访问控制系统根据模型关系图自动推荐路由路径，例如通过图数据库的最短路径算法等推荐路由路径，无需API调用人员手动确认路由路径，进一步简化了API调用操作，提高了目标作业系统的访问效率。

在一些可能的实现方式中，访问控制系统还可以通过所述第一GUI接收所述用户对所述至少一条路由路径的选择信息，根据所述选择信息生成所述API调用请求。如此，可以实现根据用户需求访问目标作业系统，提高用户体验。

在一些可能的实现方式中，访问控制系统还可以通过第二GUI接收模型定义信息，所述模型定义信息至少包括所述模型标识和所述模型属性。该模型定义信息可以是用户如信息架构师根据作业系统的业务逻辑和数据人工定义。在一些情况下，访问控制系统也可以自动从作业系统的业务逻辑和数据中提取相关信息，从而实现自动定义模型。模型一旦定义完成，可以被重复使用。也即后续在使用定义好的模型以及模型与作业系统的API的映射关系确定目标API时，无需了解作业系统的API的出入参定义以及调用方式，也无需编写特定的调用代码进行联调测试，简化了调用过程，提高了调用效率。

需要说明的是，上述第二GUI和第一GUI可以是同一设备呈现的GUI，例如可以是同一GUI。在一些实现方式中，第二GUI和第一GUI也可以是不同设备呈现的GUI。

在一些可能的实现方式中，访问控制系统还可以通过第二GUI接收不同模型的模型关系信息。该模型关系信息包括模型标识，在一些实现方式中，模型关系信息还可以包括关系标识。作为一个示例，模型关系信息可以表示为(Release)<-[belong to]-(TestCase)”。其中，小括号内是模型标识，例如模型名，模型之间用中括号包括的是模型之间的关系标识，例如关系名称。

上述模型关系信息具体可以以模型关系图的形式存储。其中，模型关系图以模型为节点，以模型关系为边。基于该模型关系图，一方面便于查询模型关系，另一方面可以快速进行路径推荐。

在一些可能的实现方式中，在接收API调用请求之前，访问控制系统还可以获取作业系统中API的API属性，例如输入参数和输出参数。具体地，访问控制系统可以通过swagger读取API文档获取API的输入参数和输出参数等属性。然后，访问控制系统可以通过第三GUI呈现API的属性，接着，访问控制系统可以通过第三GUI接收模型属性和API属性的对应关系，从而获得模型和作业系统的API之间的映射关系。其中，模型属性和API属性的对应关系可以来自于用户如信息架构师的连接操作，例如，信息架构师可以通过拖拽等方式将模型属性和对应的API属性连接。

第二方面，本申请提供了一种目标作业系统的访问控制系统。该访问控制系统用于执行目标作业系统的访问控制方法。其中，目标作业系统的访问控制系统(以下简称为访问控制系统)包括多个部分，例如访问控制系统至少包括API路由子系统，API路由子系统包括多个单元。具体如下所示：

通信单元，用于接收应用程序编程接口(API)调用请求，所述API调用请求包括至少一个模型标识；

确定单元，用于根据所述模型标识，利用模型和作业系统的API的映射关系确定目标API，所述模型根据所述作业系统建立，并且能够被重复使用，所述目标API用于访问所述目标作业系统。

其中，API路由子系统的各个单元可以部署在同一个设备，例如，部署在云环境、边缘环境的同一个设备中，或者部署在一个端设备中。在一些可能的实现方式中，API路由子系统的各个单元也可以分布式地部署在不同设备中，本申请实施例对此不作限定。

在一些可能的实现方式中，所述模型由所述模型标识和模型属性表征，所述映射关系由所述模型属性和API属性表征。

在一些可能的实现方式中，所述API属性包括输入参数、输出参数、操作类型中的一种或多种。

在一些可能的实现方式中，所述作业系统用于提供数据服务，所述目标API用于查询目标数据；

所述API路由子系统还可以包括：

路由单元，用于根据所述目标API，从所述目标作业系统获取所述目标数据，所述目标数据包括所述目标API的输出参数的参数值。

其中，路由单元可以与确定单元部署在同一设备，也可以分布式地部署在不同设备。

在一些可能的实现方式中，所述API调用请求包括多个模型标识；

所述路由单元具体用于：

根据所述目标API中第i个API的输出参数的参数值，确定第i+1个API的输入参数的参数值，所述i为正整数；

根据所述目标API中最后一个API的输入参数的参数值，从所述目标作业系统获取目标数据，所述目标数据包括所述最后一个API的输出参数的参数值。

如此，访问控制系统可以通过一次接口调用实现对多个作业系统API的路由访问。作业调用方无需与多个作业系统对接，即可实现跨作业系统的路由访问，提高了访问效率，提升了用户体验。

在一些可能的实现方式中，所述作业系统用于提供操作服务，所述目标API用于执行目标操作；

所述API路由子系统还包括：

路由单元，用于根据所述目标API，通过所述目标作业系统执行所述目标操作。

在一些可能的实现方式中，访问控制系统还可以包括路径推荐子系统，该路径推荐子系统具体用于推荐路由路径。该路径推荐子系统包括多个单元，具体如下所示：

通信单元，用于通过第一图形用户界面GUI接收用户输入的起始模型和终止模型；

推荐单元，用于根据模型关系图生成由所述起始模型至所述终止模型的至少一条路由路径。

其中，路径推荐子系统、API路由子系统可以部署在相同设备，也可以部署在不同设备。此外，路径推荐子系统也可以与API路由子系统合并，如此，API路由子系统可以包括通信单元、确定单元和推荐单元。此时，该API路由子系统不仅可以用于实现API路由，还可以用于实现路径推荐。其中，API路由子系统、路径推荐子系统合并时，这两个子系统的通信单元可以合并为一个。

在一些可能的实现方式中，路径推荐子系统还可以包括生成单元。

所述路径推荐子系统的通信单元，还用于通过所述第一GUI接收所述用户对所述至少一条路由路径的选择信息；

所述生成单元，用于根据所述选择信息生成所述API调用请求。

其中，生成单元与推荐单元可以部署在同一设备，也可以部署在不同设备。本申请实施例对此不作限定。

在一些可能的实现方式中，访问控制系统还可以包括模型管理子系统。模型管理子系统具体用于构建模型。其中，构建模型是指对模型进行定义。具体地，模型管理子系统包括：

通信单元，用于通过第二GUI接收模型定义信息，所述模型定义信息至少包括所述模型标识和所述模型属性。

在一些情况下，模型管理子系统还可以包括存储单元，用于存储上述模型定义信息。

其中，模型管理子系统可以与上述API路由子系统、路径推荐子系统部署在同一设备，也可以分布式部署在不同设备。当模型管理子系统和API路由子系统部署在同一设备时，还可以将模型管理子系统和API路由子系统进行合并，对应地，多个子系统的通信单元可以合并为一个通信单元。

当模型管理子系统和路径推荐子系统部署在同一设备时，第一GUI和第二GUI可以是同一设备呈现的GUI，例如可以是同一GUI。当模型管理子系统和路径推荐子系统部署在不同设备时，第一GUI和第二GUI可以是不同设备呈现的GUI，即不同GUI。

在一些可能的实现方式中，不同模型之间可以具有关联关系。模型管理子系统还可以用于维护不同模型的模型关系。具体地，模型管理子系统的通信单元还用于通过所述第二GUI接收不同模型的模型关系信息。其中，所述模型关系信息以模型关系图的形式存储，所述模型关系图以模型为节点，以模型关系为边。

在一些可能的实现方式中，访问控制系统还可以包括API映射管理子系统。该API映射管理子系统具体用于建立模型和作业系统的API的映射关系。该API映射管理子系统包括：

通信单元，用于获取所述作业系统中API的API属性；

所述通信单元，还用于通过第三GUI接收所述模型属性和所述API属性的对应关系，获得所述模型和所述作业系统的API之间的映射关系。

其中，API映射管理子系统和API路由子系统、路径推荐子系统、模型管理子系统部署在同一设备，也可以分布式地部署在不同设备。API映射管理子系统还可以和其他子系统合并，例如和API路由子系统合并，对应地，这些子系统的通信单元可以合并为一个通信单元。

当API映射管理子系统和路径推荐子系统部署在同一设备时，第三GUI和第一GUI可以是同一设备呈现的GUI，因此，第三GUI和第一GUI可以是同一GUI。当API映射管理子系统和模型管理子系统部署在同一设备时，第三GUI和第二GUI可以是同一设备呈现的GUI，因此，第三GUI和第二GUI可以是同一GUI。

在一些实现方式中，第一GUI、第二GUI、第三GUI也可以是不同GUI。本申请实施例对此不作限定。

第三方面，本申请提供一种计算机集群，所述计算机集群包括至少一台计算机设备，所述至少一台计算机设备包括处理器和存储器。所述处理器、所述存储器进行相互的通信。所述处理器用于执行所述存储器中存储的指令，以使得设备执行如第一方面或第一方面的任一种实现方式所述的目标作业系统的访问控制方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，所述指令指示计算机集群执行上述第一方面或第一方面的任一种实现方式所述的目标作业系统的访问控制方法。

第五方面，本申请提供了一种包含指令的计算机程序产品，当其在计算机集群上运行时，使得计算机集群执行上述第一方面或第一方面的任一种实现方式所述的目标作业系统的访问控制方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

为了更清楚地说明本申请实施例的技术方法，下面将对实施例中所需使用的附图作以简单地介绍。

图1为本申请实施例提供的一种访问控制系统的架构图；

图2为本申请实施例提供的一种访问控制系统的架构图；

图3为本申请实施例提供的一种访问控制系统的结构示意图；

图4为本申请实施例提供的一种界面示意图；

图5为本申请实施例提供的一种界面示意图；

图6为本申请实施例提供的一种模型定义信息和模型关系信息存储示意图；

图7为本申请实施例提供的一种模型关系图；

图8A为本申请实施例提供的一种界面示意图；

图8B为本申请实施例提供的一种界面示意图；

图9为本申请实施例提供的一种界面示意图；

图10为本申请实施例提供的一种计算集群的结构示意图；

图11为本申请实施例提供的一种作业系统的访问控制方法的流程图；

图12为本申请实施例提供的一种计算机集群的结构示意图。

具体实施方式

本申请实施例中的术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。

首先对本申请实施例中所涉及到的一些技术术语进行介绍。

作业系统是指通过计算机程序执行作业的系统。根据作业类型不同，作业系统可以分为多种。例如，作业系统可以是文字编辑系统、表格编辑系统、生产管理系统等用于辅助办公的系统。又例如，作业系统还可以是电子商店、电子支付系统等用于完成交易的系统。

作业系统包括至少一个功能模块，同一功能模块或者不同功能模块之间常常会使用相同的函数。为了精简代码量，提高开发效率，开发人员可以针对使用频率较高的函数提供对应的应用程序编程接口(application programming interface，API)。通过调用API可以使得开发人员无需访问源代码或者理解内部工作机制获得访问一组例程的能力。

API网关(API Gateway)是一个聚合多个不同API的网关。服务提供方可以在API网关上进行服务注册，具体是对服务对应的API进行注册。API网关提供有统一入口，使得服务调用方(即服务消费方)可以通过该统一入口(具体可以包括统一的协议和域名)调用各个作业系统中已注册的API。

当前API网关对外提供的API无法实现透明调用。调用API网关提供的每一个API都需要根据API文档了解该API的出入参定义和调用方式，然后编写不同的调用代码进行联调测试，无法通过一个统一的API对不同作业系统进行路由访问。调用过程繁琐，调用效率低下，进而影响了作业系统的访问效率和访问体验，难以满足业务需求。

有鉴于此，本申请实施例提供了一种作业系统的访问控制方法。该方法具体由作业系统的访问控制系统(以下简称为访问控制系统)执行。作业系统的业务逻辑和数据可以通过表结构呈现，基于该表结构中的数据实体(data entity，即作业系统中由软件模块管理的数据对象)以及数据实体的属性(attribute)可以定义出与各数据实体对应的模型(model)。访问控制系统基于预先定义的、可重复使用的模型，以及模型和API的映射关系，屏蔽各个作业系统API的出入参的差异和调用的复杂性，通过统一的方式实现对作业系统的路由访问。

具体地，访问控制系统接收API调用请求，所述API调用请求具有统一的格式，具体为API调用请求中携带至少一个模型标识，访问控制系统可以根据该模型标识，利用模型和API的映射关系确定目标API，该目标API用于访问目标作业系统。

在该方法中，模型能够被重复使用，一旦定义出模型，后续可以直接使用该模型。访问控制系统接收到API调用请求时，通过API调用请求中的模型标识自动路由到作业系统中相对应的API，从而实现了通过统一的方式对作业系统的路由访问，无需编写特定的调用代码进行联调测试，简化了调用过程，提高了调用效率，进而提高了作业系统的访问效率和访问体验，满足了业务的需求。

进一步地，基于不同模型之间的关联关系，访问控制系统还可以确定多个目标API，通过一次接口调用实现对多个作业系统API的路由访问。作业调用方无需与多个作业系统对接，即可实现跨作业系统的路由访问，提高了访问效率，提升了用户体验。

如图1所示，访问控制系统可以部署在云环境，具体为云环境上的一个或多个计算设备(例如：中心服务器)。该访问控制系统也可以部署在边缘环境中，具体为边缘环境中的一个或多个计算设备(边缘计算设备)上，边缘计算设备可以为服务器、计算盒子等。所述云环境指示云服务提供商拥有的，用于提供计算、存储、通信资源的中心计算设备集群；所述边缘环境指示在地理位置上距离端设备(即端侧设备)较近的，用于提供计算、存储、通信资源的边缘计算设备集群。在一些实现方式中，访问控制系统还可以部署在端设备上。端设备包括但不限于网关、服务器等设备。

访问控制系统部署在云环境或边缘环境时，访问控制系统可以以服务的形式提供给用户使用。具体地，用户可以通过浏览器访问云环境或边缘环境，在云环境或边缘环境中创建访问控制系统的实例，然后通过浏览器与访问控制系统的实例进行交互，实现作业系统的访问。

访问控制系统也可以部署在端设备，以客户端的形式提供给用户使用。具体地，端设备获取访问控制系统的安装包，通过运行该安装包，从而实现将访问控制系统的客户端安装在端设备中。端设备通过运行上述客户端，实现作业系统的访问。

如图2所示，访问控制系统包括多个部分(例如包括多个子系统，每个子系统包括多个单元)，因此，访问控制系统的各个部分也可以分布式地部署在不同环境中。例如，可以在云环境、边缘环境、端设备中的三个环境，或其中任意两个环境上分别部署访问控制系统的一部分。

还需要说明的是访问控制系统或者访问控制系统的部分可以直接部署在中心计算设备、边缘计算设备、端设备等物理机(physical machine)中，也可以部署在以上述物理机为宿主机的虚拟机(virtual machine)或容器(container)中。考虑到容器易于迁移、维护的特性，可以将访问控制系统或者访问控制系统的部分部署于容器中。例如，访问控制系统或访问控制系统的部分是基于Java开发时，可以将其部署于Java运行容器，如tomcat中。

访问控制系统用于以统一方式实现对不同作业系统的路由访问。访问控制系统内部的子系统和单元可有多种划分方式，本申请不对其进行限制，图3为一种示例性的划分方式，如图3所示，访问控制系统100至少包括API路由子系统120。在一些实现方式中，访问控制系统100还包括模型管理子系统140、API映射管理子系统160和路径推荐子系统180中的一种或多种。

为了便于描述，可以将路径推荐子系统180提供的GUI称之为第一GUI，模型管理子系统140提供的GUI称之为第二GUI，API映射管理子系统160提供的GUI称之为第三GUI。其中，路径推荐子系统180、模型管理子系统140、API映射管理子系统160部署在同一设备时，上述第一GUI、第二GUI、第三GUI可以是同一GUI。在一些实现方式中，例如，路径推荐子系统180、模型管理子系统140、API映射管理子系统160分布式地部署在不同设备时，上述第一GUI、第二GUI、第三GUI可以是不同GUI。

下面分别简述每个子系统及其包括的功能单元的功能。

API路由子系统120用于接收API调用请求，所述API调用请求中携带有至少一个模型标识，然后API路由子系统120根据所述模型标识，利用模型和API的映射关系确定目标API，该目标API用于实现访问所述目标作业系统。其中，该API路由子系统120可以通过不同的模型标识路由至不同的API，从而实现通过统一方式访问不同作业系统。

在一些实现方式中，模型可以由模型标识和模型属性(model attribute)表征，映射关系可以由模型属性和API属性表征，因此，API路由子系统120可以根据模型标识确定相应的API属性，基于该API属性确定目标API。如此实现了屏蔽各个作业系统API属性(例如API出入参)的差异和调用的复杂性，通过统一的方式访问作业系统。

其中，属性具体是指事物的性质和/或关系。基于此，模型属性是指模型的性质和/或关系。模型是根据作业系统中数据实体(entity)以及数据实体的属性(attribute)建立的。数据实体是指作业系统的软件模块所管理的数据对象。例如，在电子商店等用于完成交易的作业系统中，数据实体可以是商品、订单等数据对象，数据实体的属性可以是数据对象的性质和/或关系，例如商品的属性可以包括样式、颜色、尺寸、价格等等。又例如，在需求管理系统等辅助开发的作业系统中，数据实体可以是需求(request)、缺陷(bug)、测试用例(test case)等数据对象。当数据实体为缺陷时，其属性可以包括缺陷单号、产品、结果影响、当前处理人等等。

在一些可能的实现方式中，API属性是指API的性质和/或关系。例如，API属性可以是API的输入参数、输出参数、操作类型中的一种或多种。由此，API路由子系统120可以根据模型标识确定API的输入参数、输出参数、操作类型中的一种或多种，基于API的输入参数、输出参数和/或操作类型可以确定出目标API。例如，API路由子系统120根据输入参数和输出参数确定用于查询目标数据的目标API，或者API路由子系统120根据操作类型确定用于执行目标操作的API。

在一些可能的实现方式中，作业系统可以用于提供数据服务，例如考勤管理系统、薪资管理系统等作业系统可以提供考勤、薪资等数据的查询服务。对应地，目标API用于查询目标数据。基于此，API路由子系统120确定目标API后，还可以根据所述目标API，从目标作业系统获取目标数据，该目标数据包括目标API的输出参数的参数值。

以考勤管理系统进行示例说明。考勤管理系统包括考勤(work-attendance)模块，基于该模块建立有模型标识为work-attendance的模型。API路由子系统120接收API调用请求后，根据模型标识work-attendance，利用模型和作业系统的API的映射关系，确定目标API，例如，attendance-exception.Query(yyyy-mm，count)。其中，yyyy-mm表示某年某月，count表示某年某月考勤异常次数。该目标API具体用于查询员工在某年某月考勤异常次数。

在一些实现方式中，所述API调用请求可以包括多个模型标识。对应地，API路由子系统120还可以根据多个模型标识，确定多个目标API。其中，每一个模型标识对应一个目标API。基于此，访问控制系统100可以通过一次接口调用，实现对多个作业系统的API的访问。具体地，API路由子系统120可以根据目标API中第i个API的输出参数的参数值，确定第i+1个API的输入参数的参数值，所述i为正整数。以此类推，API路由子系统120可以根据目标API中最后一个API的输入参数的参数值，获得目标API中最后一个API的输出参数的参数值，从而实现从目标作业系统获取目标数据，该目标数据包括最后一个API的输出参数的参数值。

其中，多个模型标识所标识的模型可以对应一个作业系统，也可以对应多个作业系统。当多个模型标识对应多个作业系统(具体为n个模型标识对应m个作业系统，n大于或等于m)时，API路由子系统120基于不同模型之间的关联关系，确定多个相关联的目标API。如此，作业调用方无需与多个作业系统对接，即可实现跨作业系统的路由访问。

API路由子系统120包括多个功能单元。其中，通信单元122用于接收API调用请求，确定单元124用于根据API调用请求中携带的至少一个模型标识，利用模型和API的映射关系确定目标API。

在一些实现方式中，所述作业系统用于提供数据服务，所述目标API用于查询目标数据。对应地，所述API路由子系统120还可以包括路由单元126。该路由单元126用于根据目标API，从所述目标作业系统获取所述目标数据，所述目标数据包括所述目标API的输出参数的参数值。

其中，API调用请求包括多个模型标识时，确定单元124利用模型和API的映射关系确定的目标API包括多个。路由单元126可以根据目标API中第i个API的出参，确定第i+1个API的入参，然后根据所述目标API中最后一个API的输入参数的参数值，从所述目标作业系统获取目标数据。所述目标数据包括所述最后一个API的输出参数的参数值。

模型管理子系统140具体用于构建模型。其中，构建模型是指对模型进行定义。在具体实现时，模型管理子系统140通过图形用户界面(Graphical User Interface，GUI)接收模型定义信息，从而实现对模型的定义。所述模型定义信息至少包括模型标识(modelID)和模型属性(model attribute)。其中，模型是基于数据实体定义的，模型标识可以是数据实体的名称、数据实体的编号，或者根据数据实体的名称、编号进行处理所得的唯一值。模型属性是指模型的性质和/或关系。在一些实现方式中，模型定义信息还可以包括模型的名称(name)、类型(category)、创建日期(createDate)、描述(description)等与数据实体相关的信息。

图4提供了一种第二GUI的界面示意图，如图4所示，界面400中呈现了模型标识配置组件402、模型属性配置组件404和提交管理组件406。其中，模型标识配置组件402中包括模型标识配置控件，模型管理子系统140可以接收用户通过模型标识配置控件输入的模型标识，如“Offering”，以实现模型标识配置。

模型属性配置组件404中包括模型属性的选择控件，以及新增控件、删除控件、失效控件、有效控件。其中，新增控件用于新增模型属性。该新增控件被触发后，用户界面400呈现空行，模型管理子系统140接收用户在该空行的对应位置分别输入的属性的名称、描述、类型、状态以及是否关联属性等信息，以实现新增属性。删除控件用于删除模型属性。具体地，一种或多种模型属性的选择控件被触发后，模型管理子系统140可以选中上述选择控件对应的模型属性。当删除控件被触发时，模型管理子系统140可以删除选中的属性。失效控件具体用于筛选模型属性中状态为失效的模型属性，类似地，生效控件具体用于筛选模型属性中状态为生效的模型属性。

提交管理组件406中包括提交控件和取消控件。其中，提交控件用于提交模型定义信息，即提交配置的模型标识和模型属性的属性值。取消控件用于取消提交模型定义信息，即取消提交模型标识和模型属性的属性值。

进一步地，一些模型之间是具有关联关系的，模型管理子系统140还可以用于维护不同模型之间的关联关系。具体地，模型管理子系统140通过第二GUI接收不同模型的模型关系信息，由此实现对不同模型之间的关联关系的维护。其中，模型之间的关联关系可以包括多种类型，例如引用(invoking)、相关(relate)、参考(reference)、组装(assemble)、属于(belong to)和依赖(rely on)等等。

图5提供了一种第二GUI的界面示意图，如图5所示，界面500中呈现了模型关系增删组件502、模型关系配置组件504和提交管理组件506。其中，模型关系增删组件502中包括新增控件和删除控件。

新增控件用于新增模型关系。具体地，模型管理子系统140接收用户通过新增控件输入的源模型标识、源模型关联属性、关系名称、目标模型标识、目标模型关联属性，以新增一条模型关系。

例如，Offering模型和IndustryCategory模型通过源模型的属性IndustryCategoryID和目标模型的属性ID关联时，如图5所示，模型管理子系统140可以接收用户通过模型关系配置组件504中的编辑控件在源模型标识输入栏输入的Offering、在源模型关联属性输入栏输入的IndustryCategoryID、在关系名称输入栏输入的reference、在目标模型标识输入栏输入的IndustryCategory、在目标模型关联属性输入栏输入的ID，以实现新增一条模型关系。

其中，目标模型关联属性具体为能够唯一标识目标模型的属性，即目标模型的主键。源模型关联属性可以是能够唯一标识源模型的属性，即源模型的主键。源模型关联属性也可以是不能唯一标识源模型的属性，即源模型的外键。当目标模型和源模型一对多关联时，源模型关联属性为源模型的外键，当目标模型和源模型多对多关联时，源模型关联属性为源模型的主键。

以源模型为user，目标模型为group为例进行说明。当一个group包括多个user，每个user只属于一个group时，group和user即为一对多关联，此时，源模型的关联属性为源模型的外键，从而实现一个group和多个user关联。当一个group包括多个user，每个user可以属于多个group时，group和user即为多对多关联，此时，源模型的关联属性为源模型的主键。

模型管理子系统140存储模型关系信息时，具体采用数据表进行存储。在一些实现方式中，当源模型和目标模型多对多关联时，模型管理子系统140可以采用单独的数据表进行存储。

删除控件用于删除模型关系。具体地，模型管理子系统140接收用户通过模型关系配置组件504中的模型关系选择控件选择的一个或多个模型关系，以选中上述一个或多个模型关系，当删除控件被触发时，模型管理子系统140响应于该触发操作删除被选中的模型关系。

提交管理组件506中包括提交控件和取消控件。其中，提交控件用于提交模型关系信息。每条关系信息至少包括具有关联关系的两个模型的模型标识。在一些实现方式中，关系信息还包括关系名称和关联属性中的一种或多种。取消控件则用于取消提交模型关系信息。

在一些实现方式中，模型管理子系统140可以将模型定义信息、模型关系信息中的一种或多种存储到数据库中。考虑到模型定义信息、模型关系信息的结构，模型管理子系统140可以将这些信息存储至关系数据库，例如MySQL中。

图6示出了模型定义信息以及模型关系信息在数据库中的存储结构。如图6所示，模型定义信息主要包括两部分，即数据实体以及数据实体的属性。模型是基于数据实体确定的，数据实体部分至少包括根据数据实体的名称或编号等信息确定的模型标识。在一些实现方式中，数据实体部分还可以包括模型的名称、类型、创建日期、描述等信息中的一种或多种。数据实体的属性部分包括属性的名称。在一些实现方式中，数据实体的属性部分还包括属性的描述、数据类型、重要程度等信息中的一种或多种。需要说明的是，数据实体的属性部分还包括模型标识，以用于和对应的数据实体进行关联。

模型关系信息至少包括源模型标识和目标模型标识。当模型关系描述同一模型之间的关系时，源模型标识和目标模型标识相同。当模型关系描述不同模型之间的关系时，源模型标识和目标模型标识不同。进一步地，模型关系信息还包括关系名称，用于描述源模型和目标模型的关系。在一些实现方式中，模型关系信息中还可以包括源属性名称和目标属性名称的一种或多种，源属性名称和目标属性名称用于描述源模型和目标模型通过源模型或目标模型的哪一或哪些属性关联。

为了便于直观地呈现模型关系，在一些实现方式中，模型管理子系统140还用于根据所述模型关系信息，构建模型关系图。其中，所述模型关系图以模型为节点，以模型关系为边。图7示出了模型关系图的一个示意图，如图6所示，Offering等模型作为模型关系图的节点，具有关联关系的模型之间形成模型关系图的边。

其中，模型管理子系统140构建的模型关系图可以存储在图数据库中，例如可以存储在Neo4j、TigerGraph，ArangoDB、JanusGraph或者Dgraph等图数据库中。基于该模型关系图，可以实现路径推荐和路由。

模型管理子系统140包括通信单元142，该通信单元142用于通过第二GUI接收模型定义信息。在一些实现方式中，模型管理子系统140还包括存储单元144，该存储单元144用于存储所述模型定义信息。进一步地，通信单元142还用于通过第二GUI接收模型关系信息，存储单元144还用于存储模型关系信息。其中，存储单元144具体用于存储所述模型定义信息、模型关系信息至关系数据库，如MySQL中。

在一些实现方式中，模型管理子系统140还可以包括构图单元146，该构图单元146用于根据模型关系信息构建模型关系图。基于此，存储单元144还用于存储所述模型关系图至图数据库，如Neo4j中。

API映射管理子系统160具体用于建立模型和作业系统的API的映射关系。具体地，API映射管理子系统160可以通过第三GUI接收模型属性和API属性(例如API的输出参数和输入参数)之间的映射关系。

在一些实现方式中，API映射管理子系统160可以先获取API的输出参数和输入参数，例如可以通过swagger读取API文档中与出入参对应的JavaScript对象简谱(JavaScript object notation，JSON)字段结构，从而获得API的出入参。接着，API映射管理子系统160根据第三GUI呈现模型标识以及API的出入参，然后通过该第三GUI接收模型属性和出入参的对应关系，从而获得模型和作业系统的API的映射关系。该映射关系可以是用户(如信息架构师)通过第三GUI手动配置的。

图8A和图8B分别提供了一种界面示意图。如图8A所示，界面800用于对模型属性和API的输入参数进行映射，如图8B所示，界面800用于对模型属性和API的输出参数进行映射。界面800左侧为输入参数或输出参数，界面800右侧为模型属性的名称。

在一些实现方式中，API映射管理子系统160接收用户通过图8A的界面800对输入参数和模型属性的名称的连接信息，以实现模型属性和输入参数的映射。API映射管理子系统160接收用户通过图8B的界面800对输出参数和模型属性的名称的连接信息，以实现模型属性和输出参数的映射。根据模型属性和输入参数的映射以及模型属性和输出参数的映射，从而实现模型和作业系统的API的映射。

其中，输入参数和模型属性的名称的连接信息，或者输出参数和模型属性的名称的连接信息具体可以来源于用户的拖拽操作，例如，将输入参数或输出参数拖拽至界面800右侧的操作。在一些实现方式中，上述连接信息也可以来源于用户的其他操作，例如直接通过线条连接的操作。

其中，输入参数、输出参数可以是通过JSONPath表达的JSON字段。在连接输入参数和模型属性，或连接输出参数和模型属性后，API映射管理子系统160还可以呈现JSON字段对应的JSONPath。在一个示例中，JSONPath可以为$['data']['Name']，通过该JSONPath表达的JSON字段包括Name字段。其中，JSONPath可以用于辅助访问相应的JSON字段，获得相应的字段值。

在建立映射关系时，一个模型可以映射多个API，但是不同的API的入参字段必须映射到模型的不同属性字段。即一个属性字段作为入参时，只能被一个API映射。多个不同的属性字段作为入参时，可以被多个不同的API映射。基于此，访问控制系统100可以通过不同的属性字段路由至不同的API。

模型属性根据能否唯一标识该模型可以分为主键和外键。在建立模型属性和API的入参之间的映射关系时，还可以分别建立主键和API的入参之间的映射关系，以及外键和API的入参之间的映射关系。

API映射管理子系统160包括通信单元162。其中，通信单元162用于获取作业系统的API的API属性，例如获取API的出入参。在一些实现方式中，API映射管理子系统还可以包括显示单元164。该显示单元164用于根据第三GUI呈现模型属性和API属性，所述通信单元162还用于通过第三GUI接收模型属性和API属性的对应关系，从而获得模型和作业系统的API的映射关系。

在一些可能的实现方式中，API映射管理子系统160还包括存储单元166，所述存储单元166用于存储模型和API的映射关系。具体地，存储单元166可以存储所述映射关系至关系数据库中。

路径推荐子系统180用于推荐路由路径。具体地，路径推荐子系统180用于通过第一GUI接收用户输入的起始模型和终止模型，然后根据模型关系信息例如模型关系图生成由所述起始模型至所述终止模型的至少一条路由路径。图数据库中的图数据结构如模型关系图可以有效表达模型的数据实体、属性和关系，路径推荐子系统180可以利用图数据库的路径算法，实现路径查询和推荐。以图数据库为开源图数据库Neo4j为例，Neo4j提供了类似结构化查询语言(structured query language，SQL)的图查询语言(例如Cypher)，同时还提供了apoc、algo等算法包，可以实现路径推荐、图搜索等功能。

路径推荐系统180生成的至少一条路由路径可以通过至少一个模型标识进行表达。基于此，路由路径可以用于生成API调用请求。需要说明的是，API调用请求可以是单独的用户装置如浏览器生成，也可以是路径推荐子系统180生成。

进一步地，路径推荐子系统180还用于呈现上述至少一条路由路径，以供用户选择一条路由路径进行API调用。具体地，路径推荐子系统180接收用户通过第一GUI输入的、对所述至少一条路由路径的选择信息。然后，路径推荐子系统180可以根据选择信息生成所述API调用请求。

在一些实现方式中，路径推荐子系统180也可以返回至少一条路由路径至用户装置，由用户装置通过自身的GUI(为了便于描述，可以称之为第四GUI)呈现至少一条路由路径。用户装置通过该第四GUI接收用户对至少一条路由路径的选择信息，根据该选择信息生成所述API调用请求。

下面以路径推荐子系统180生成API调用请求进行示例说明。图9提供了一种第一GUI的示意图。如图9所示，界面900包括起止模型配置组件902、路径显示组件904和输入参数生成组件906。起止模型配置组件902包括起始模型配置控件和终止模型配置控件。路径推荐子系统180接收用户通过起始模型配置控件配置的起始模型，例如Offering，以及接收用户通过终止模型配置控件配置的终止模型，例如TestCase。然后路径推荐子系统180可以采用Neo4j图数据库的algo算法包中的最短路径(kShortestPaths)函数使用最短路径图算法计算得到起始模型至终止模型的最短路径。路径推荐子系统180通过界面900的路径显示组件904显示上述最短路径。

最短路径具体可以通过模型标识(如模型名称)进行表示。在一些实现方式中，如图9所示，路径还可以通过模型标识以及关系标识进行表示。在图9的示例中，路径可以表示为“(Offering)<-[belong to]-(Release)<-[belong to]-(TestCase)”。其中，小括号内是模型名，模型之间用中括号包括的是模型之间的关系标识。

路径显示组件904中包括路径选择控件，每个路径选择控件对应一条路由路径，当一个路径选择控件被触发时，其对应的路径即被选中用于生成API路由请求。生成API路由请求的一个关键即在于生成具有统一格式的API的输入参数。该输入参数包括至少一个模型标识。其中，至少一个模型标识具体是路由路径包括的模型标识。在一些实现方式中，API的输入参数还包括起始参数，起始参数是指起始模型的输入参数。

输入参数生成组件906包括起始模型实例配置控件和输入参数生成控件。一个模型可以包括多个实例，例如订单这一模型可以包括多个订单实例。起始模型实例配置控件即用于指定当前访问操作所依赖的起始模型实例。输入参数生成控件用于生成API的输入参数。

具体地，路由推荐子系统180接收用户通过起始模型实例配置控件配置的起始模型实例的标识startmodelinstanceID，例如为22823749。当输入参数生成控件被触发时，路由推荐子系统180可以根据起始模型实例的标识以及被选中的路由路径包括的模型标识生成输入参数。具体地，路由推荐子系统180先根据起始模型实例的标识获得起始参数，该示例中，起始参数为“pageSize”＝100、“pageNumber”＝1，路由推荐子系统根据该起始参数，以及被选中的路由路径包括的模型标识生成API的输入参数。图9中还提供了输入参数的一个实例。在该示例中，输入参数还包括模型的关系标识。

需要说明，路径推荐子系统180包括多个功能单元。通信单元182用于通过第一GUI接收用户输入的起始模型和终止模型。推荐单元184用于根据模型关系图生成由所述起始模型至所述终止模型的至少一条路由路径。

在一些实现方式中，所述路径推荐子系统180还包括显示单元186。该显示单元186用于通过第一GUI呈现至少一条路由路径，以便用户从中选择一条路由路径。对应地，通信单元182还用于接收用户对所述至少一条路由路径的选择信息。所述路径推荐子系统180还可以包括请求生成单元188，用于根据所述选择信息生成所述API调用请求。

上述访问控制系统100主要用于提供API调用服务，具体是为一个作业系统提供调用该作业系统中的API或者其他作业系统的API的服务，该访问控制系统100并不面向终端用户，因此可以将其部署在中台。中台是介于前台和后台之间的抽象层。所谓前台是由各类前台系统组成的前端平台，例如最终用户访问的网站、手机应用(application，app)等即为前台。所谓后台是由后台系统组成的后端平台，例如财务系统、客户管理系统等形成了后台。为了保持后台系统的稳定性，同时能够响应于最终用户持续不断的需求，可以将后台系统中需要频繁变化，且需要被前台直接使用的业务能力移植到中台。在一些实现方式中，访问控制系统100也可以部署在后台或者前台。

以上对访问控制系统100内部的子系统和单元进行了介绍，接下来，从硬件角度对部署访问控制系统100的设备进行介绍。图10示出了计算集群1000、的结构示意图。应理解，图10仅仅示出了上述计算集群中的部分硬件结构和部分软件模块，具体实现时，计算集群1000还可以包括更多的硬件结构，如扬声器、显示器等等，以及更多的软件模块，如各种应用程序等。

如图10所示，计算集群1000包括至少一台计算机设备，每台计算机设备包括总线1001、处理器1002、通信接口1003和存储器1004。处理器1002、存储器1004和通信接口1003之间通过总线1001通信。

总线1001可以是外设部件互连标准(peripheral component interconnect，PCI)总线、快捷外设部件互连标准(peripheral component interconnect express，PCIe)或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

处理器1002可以为中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)或者数字信号处理器(digital signal processor，DSP)等处理器中的任意一种或多种。

通信接口1003用于与外部通信，例如接收API调用请求、通过GUI接收用户输入的起始模型和终止模型等等。通信接口1403可以包括显示器。显示器是一种输入输出(input/output，I/O)设备。该设备可以将电子文件如图像、文字显示到屏幕上，以供用户查看。根据制造材料不同，显示器可以分为液晶显示器(liquid crystal display，LCD)、有机电激光(organic light emitting diode，OLED)显示器等。

存储器1004可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。存储器1004还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，硬盘驱动器(hard diskdrive，HDD)或固态硬盘驱动器(solid state drive，SSD)。

存储器1004中存储有程序或指令，例如实现确定单元124、路由单元126功能所需的程序或指令，或者构图单元146功能所需的程序或指令，或者推荐单元184功能所需的程序或指令。处理器1002执行该程序或指令以执行前述作业系统的访问控制方法。

为了使得本申请的技术方案更加清楚、易于理解，下面将以API路由子系统120、模型管理子系统140、API映射管理子系统160和路径推荐子系统180部署在同一设备，如同一云计算设备的角度，对本申请实施例的访问控制方法进行详细说明。

参见图11所示的访问控制方法的流程图，该方法包括：

S1102：访问控制系统100接收API调用请求。

所述API调用请求包括至少一个模型标识。其中，模型是基于数据实体定义的，模型标识可以是数据实体的名称、数据实体的编号或者根据数据实体的名称、编号进行处理所得的唯一值。为了便于理解，后文均以模型标识为数据实体的名称进行示例说明。

进一步地，当API调用请求包括多个模型标识时，该API调用请求还可以包括用于描述模型关系的关系标识。该关系标识可以是关系名称，例如belong to、reference、invoking、relate、assemble和依赖rely on等等。

为了便于理解，下面结合具体示例对API路由请求包括的至少一个模型标识进行说明。在该示例中，API路由请求包括的至少一个模型标识可以表示为(Offering)<-[belong to]-(Release)<-[belong to]-(TestCase)。其中，小括号里的Offering、Release、TestCase为模型标识，中括号里的belong to为关系标识。该示例中的模型标识和关系标识可以表征一条路由路径，具体为一个测试用例(TestCase)属于一个Release版本，一个Release版本属于一个Offering。

该API调用请求具体是根据统一的API调用格式生成的。例如，访问提供数据服务的作业系统时，API调用格式包括API输入参数(即API入参)和API输出参数(API出参)。其中，API出参是期望的返回值，API入参包括至少一个模型标识。

考虑到模型可以具有多个实例，起始模型可以具有不同的起始模型实例。不同起始模型实例对应的API的输入参数的参数值可以是不同的，为此，统一格式的API入参还可以包括起始参数的参数值。请参见图9，API入参可以包括起始参数的参数值，如pagesize(取值为100)、pageNumber(取值为1)，以及至少一个模型标识和不同模型的关系标识，如(Offering)<-[belong to]-(Release)<-[belong to]-(TestCase)。

其中，至少一个模型标识具体可以由访问控制系统100根据起始模型和终止模型生成的至少一条路由路径确定。具体地，访问控制系统100通过第一GUI接收用户输入的起始模型和终止模型，然后根据模型关系图生成由所述起始模型至所述终止模型的至少一条路由路径，基于该路由路径可以获得至少一个模型标识。

在一些实现方式中，访问控制系统100可以通过第一GUI呈现至少一条路由路径，然后通过GUI接收用户对至少一条路由路径的选择信息，根据该选择信息可以获得至少一个模型标识。

S1104：访问控制系统100根据所述模型标识，利用模型和API的映射关系确定目标API。

每个模型具有模型定义信息，该模型定义信息包括模型标识和模型属性。基于模型和API的映射关系，访问控制系统100可以匹配出与API调用请求中的模型标识相匹配的API，进而从与模型标识相匹配的API中确定目标API。

具体地，当API调用请求包括一个模型的模型标识时，访问控制系统100可以根据起始参数和API出参确定目标API。当API调用请求包括的路由路径参数包括多个模型的模型标识时，访问控制系统100根据起始参数、API出参以及模型之间的关联关系确定多个目标API。

例如，起始参数为A，用户期望返回的参数为C，路由路径参数中包括模型1和模型2的标识，则访问控制系统100根据起始参数A以及模型1与模型2关联属性确定一个API，该API以起始参数A为入参，以模型1、模型2的关联属性为出参，接着，访问控制系统100以模型1、模型2的关联属性为入参，以用户期望返回的参数为出参，确定另一个API。如此，访问控制系统100实现了根据模型标识，利用模型和API的映射关系确定目标API。

其中，模型和API的映射关系可以是访问控制系统100预先接收的。在一些实现方式中，访问控制系统100可以获取作业系统中API的API属性，例如API的出入参或者操作类型。具体地，访问控制系统100可以通过swagger读取API文档，获得API的出入参。其中，访问控制系统100获得的API的出入参具体可以是JSON字段结构。然后访问控制系统100通过第三GUI接收模型属性和API属性之间的对应关系，如模型属性和API的出入参之间的对应关系，从而获得模型和API的映射关系。该映射关系可以是信息架构师人工配置，也可以是通过机器学习得到。

下面以信息架构师人工配置模型和API的映射关系进行示例说明。在一些实现方式中，访问控制系统100可以将模型的属性分为不同类型，具体可以分为主键和外键，所谓主键是能够唯一标识该模型的属性，外键则是不能唯一标识该模型的属性。然后访问控制系统100可以分别根据主键和外键建立模型和API的映射关系。

在一些实现方式中，访问控制系统100还可以通过第二GUI接收模型定义信息，所述模型定义信息至少包括模型标识和模型属性。进一步地，访问控制系统100还可以通过所述第二GUI接收不同模型的模型关系信息。该模型关系信息能够以模型关系图的形式进行存储。然所述模型关系图以模型为节点，以模型关系为边。

在一些实现方式中，作业系统可以用于提供数据服务，例如考勤管理系统、薪资管理系统等作业系统可以提供考勤、薪资等数据的查询服务。对应地，目标API用于查询目标数据。基于此，访问控制系统100确定目标API后，还可以根据所述目标API，从目标作业系统获取目标数据，该目标数据包括目标API的输出参数的参数值。

进一步地，所述API调用请求可以包括多个模型标识。对应地，访问控制系统100可以根据目标API中第i个API的输出参数的参数值，确定第i+1个API的输入参数的参数值，所述i为正整数。具体地，API调用请求中还可以携带起始参数的参数值，访问控制系统100将起始参数的参数值输入目标API中第一个API，获得第一个API的输出参数的参数值，基于第一个API的输出参数的参数值，可以获得第二个API的输入参数的参数值，以此类推，访问控制系统100可以获得目标API中最后一个API的输入参数的参数值。访问控制系统100根据所述目标API中最后一个API的输入参数的参数值，从所述目标作业系统获取目标数据，所述目标数据包括所述最后一个API的输出参数的参数值。

为了便于理解，下面结合一具体示例进行说明。

Release模型上有个名叫OfferingName的属性，作为外键关联Offering模型的Name属性(Name也是Offering的一个主键)，TestCase模型上有一个名叫ReleaseId的属性，作为外键关联Release模型的主键ID。

根据OfferingID获取TestCase的API调用过程具体如下：

1)传入ID参数调用Offering映射的API获取Offering的详细信息，返回信息中含有Offering的Name属性值；

2)根据上一步返回的Offering的Name属性值，调用Release映射的API，API的入参是OfferingName，返回Release的详细信息，返回信息中含有Release的ID；

3)根据上一步返回的Release的ID属性值，调用TestCase映射的API，API的入参是ReleaseId，返回TestCase的详细信息。

在一些实现方式中，作业系统也可以用于提供操作服务。对应地，目标API具体用于执行目标操作。基于此，访问控制系统100还可以根据目标API，执行目标操作。也即访问目标作业系统可以是获取目标作业系统中的目标数据，也可以是通过目标API执行目标操作。

以目标作业系统为报警系统，目标操作为报警操作进行示例说明。在该示例中，监控系统监控到某一指标达到阈值时，可以通过访问控制系统访问报警系统，基于报警系统中的目标API执行报警操作。

基于上述内容描述，本申请实施例提供了一种作业系统的访问控制方法。该方法基于模型和API的映射关系提供统一格式的路由API，支持根据模型的主键或外键调用作业系统的API。调用方无需关注不同API的出入参定义，提高了API调用联调的效率。

进一步地，该方法还实现了基于起始模型和终止模型进行路径推荐，基于该路径可以实现跨多个作业系统的路由访问，无需根据不同的路由场景编写不同的路由调用代码，减少了调用方的工作量，提高了系统之间的访问效率。

上文结合图1至图11对本申请实施例提供的目标作业系统的访问控制方法进行了详细介绍，下面将结合附图对本申请实施例提供的系统、设备进行介绍。

参见图3所示的访问控制系统的结构示意图，该访问控制系统100包括API路由子系统120，该API路由子系统120包括：

通信单元122，用于接收应用程序编程接口(API)调用请求，所述API调用请求包括至少一个模型标识；

确定单元124，用于根据所述模型标识，利用模型和作业系统的API的映射关系确定目标API，所述模型根据所述作业系统建立，并且能够被重复使用，所述目标API用于访问所述目标作业系统。

其中，API路由子系统120的各个单元可以部署在同一个设备，例如，部署在云环境、边缘环境的同一个设备中，或者部署在一个端设备中。在一些可能的实现方式中，API路由子系统120的各个单元也可以分布式地部署在不同设备中，本申请实施例对此不作限定。

在一些可能的实现方式中，所述模型由所述模型标识和模型属性表征，所述映射关系由所述模型属性和API属性表征。

在一些可能的实现方式中，所述API属性包括输入参数、输出参数、操作类型中的一种或多种。

在一些可能的实现方式中，所述作业系统用于提供数据服务，所述目标API用于查询目标数据；

所述API路由子系统120还可以包括：

路由单元126，用于根据所述目标API，从所述目标作业系统获取所述目标数据，所述目标数据包括所述目标API的输出参数的参数值。

其中，路由单元126可以与确定单元124部署在同一设备，也可以分布式地部署在不同设备。

在一些可能的实现方式中，所述API调用请求包括多个模型标识；

所述路由单元126具体用于：

根据所述目标API中第i个API的输出参数的参数值，确定第i+1个API的输入参数的参数值，所述i为正整数；

根据所述目标API中最后一个API的输入参数的参数值，从所述目标作业系统获取目标数据，所述目标数据包括所述最后一个API的输出参数的参数值。

如此，访问控制系统100可以通过一次接口调用实现对多个作业系统API的路由访问。作业调用方无需与多个作业系统对接，即可实现跨作业系统的路由访问，提高了访问效率，提升了用户体验。

在一些可能的实现方式中，所述作业系统用于提供操作服务，所述目标API用于执行目标操作；

所述API路由子系统120还包括：

路由单元126，用于根据所述目标API，通过所述目标作业系统执行所述目标操作。

在一些可能的实现方式中，访问控制系统100还可以包括路径推荐子系统180，该路径推荐子系统180具体用于推荐路由路径。该路径推荐子系统180包括多个单元，具体如下所示：

通信单元182，用于通过第一图形用户界面GUI接收用户输入的起始模型和终止模型；

推荐单元184，用于根据模型关系图生成由所述起始模型至所述终止模型的至少一条路由路径。

其中，路径推荐子系统180、API路由子系统120可以部署在相同设备，也可以部署在不同设备。此外，路径推荐子系统180也可以与API路由子系统120合并，如此，API路由子系统120可以包括通信单元、确定单元和推荐单元。此时，该API路由子系统120不仅可以用于实现API路由，还可以用于实现路径推荐。其中，API路由子系统120、路径推荐子系统180合并时，这两个子系统的通信单元可以合并为一个。

在一些可能的实现方式中，路径推荐子系统180还可以包括生成单元186。

所述路径推荐子系统180的通信单元182，还用于通过所述第一GUI接收所述用户对所述至少一条路由路径的选择信息；

所述生成单元186，用于根据所述选择信息生成所述API调用请求。

其中，生成单元186与推荐单元184可以部署在同一设备，也可以部署在不同设备。本申请实施例对此不作限定。

在一些可能的实现方式中，访问控制系统100还可以包括模型管理子系统140。模型管理子系统140具体用于构建模型。其中，构建模型是指对模型进行定义。具体地，模型管理子系统包括：

通信单元142，用于通过第二GUI接收模型定义信息，所述模型定义信息至少包括所述模型标识和所述模型属性。

具体地，模型管理子系统140还可以包括存储单元144，用于存储上述模型定义信息。

其中，模型管理子系统140可以与上述API路由子系统120、路径推荐子系统180部署在同一设备，也可以分布式部署在不同设备。当模型管理子系统140和API路由子系统120部署在同一设备时，还可以将模型管理子系统140和API路由子系统120进行合并，对应地，多个子系统的通信单元可以合并为一个通信单元。

当模型管理子系统140和路径推荐子系统180部署在同一设备时，第一GUI和第二GUI可以是同一设备呈现的GUI，例如可以是同一GUI。当模型管理子系统120和路径推荐子系统180部署在不同设备时，第一GUI和第二GUI可以是不同设备呈现的GUI，即不同GUI。

在一些可能的实现方式中，不同模型之间可以具有关联关系。模型管理子系统140还可以用于维护不同模型的模型关系。具体地，模型管理子系统140的通信单元还用于通过所述第二GUI接收不同模型的模型关系信息。其中，所述模型关系信息以模型关系图的形式存储，所述模型关系图以模型为节点，以模型关系为边。

在一些可能的实现方式中，访问控制系统100还可以包括API映射管理子系统160。该API映射管理子系统160具体用于建立模型和作业系统的API的映射关系。该API映射管理子系统160包括：

通信单元162，用于获取所述作业系统中API的API属性；

所述通信单元162，还用于通过第三GUI接收所述模型属性和所述API属性的对应关系，获得所述模型和所述作业系统的API之间的映射关系。

在一些实现方式中，API映射管理子系统160还包括显示单元164，用于显示模型属性和API属性，以便用户连接模型属性及其对应的API属性。

其中，API映射管理子系统160和API路由子系统120、路径推荐子系统180、模型管理子系统140部署在同一设备，也可以分布式地部署在不同设备。API映射管理子系统160还可以和其他子系统合并，例如和API路由子系统120合并，对应地，这些子系统的通信单元可以合并为一个通信单元。

根据本申请实施例的访问控制系统100可对应于执行本申请实施例中描述的方法，并且访问控制系统100的各个模块/单元的上述和其它操作和/或功能分别为了实现图11所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。

本申请实施例还提供了一种计算机集群，该计算机集群用于实现如图3所示的访问控制系统100的功能。下面结合附图对该计算机集群进行详细说明。

图12提供了一种计算机集群1200的结构示意图，该计算机集群1200包括：

至少一台第一计算机设备1202、至少一台第二计算机设备1204、至少一台第三计算机设备1206以及至少一台第二计算机设备1208，每台计算机设备包括处理器和存储器。其中，第一计算机设备1202用于实现API路由子系统120的功能，第二计算机设备1204用于实现模型管理子系统140的功能，第三计算机设备1206用于实现API映射管理子系统160的功能，第四计算机设备用于实现路径推荐子系统180的功能。

图12是以访问控制系统100的各个子系统分别部署在不同计算机设备进行示例说明。在一些实现方式中，访问控制系统100的任意两个或两个以上的子系统可以部署在同一计算机设备，本申请实施例对此不作限定。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。

但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

Claims (14)

1.一种目标作业系统的访问控制方法，其特征在于，所述方法包括：

接收应用程序编程接口(API)调用请求，所述API调用请求包括至少一个模型标识；

根据所述模型标识，利用模型和作业系统的API的映射关系确定目标API，所述模型根据所述作业系统建立，并且能够被重复使用，所述目标API用于访问所述目标作业系统。

2.根据权利要求1所述的方法，其特征在于，所述模型由所述模型标识和模型属性表征，所述映射关系由所述模型属性和API属性表征。

3.根据权利要求2所述的方法，其特征在于，所述API属性包括输入参数、输出参数、操作类型中的一种或多种。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述作业系统用于提供数据服务，所述目标API用于查询目标数据；

所述方法还包括：

根据所述目标API，从所述目标作业系统获取所述目标数据，所述目标数据包括所述目标API的输出参数的参数值。

5.根据权利要求4所述的方法，其特征在于，所述API调用请求包括多个模型标识；

所述根据所述目标API，从所述目标作业系统获取所述目标数据，包括：

根据所述目标API中第i个API的输出参数的参数值，确定第i+1个API的输入参数的参数值，所述i为正整数；

根据所述目标API中最后一个API的输入参数的参数值，从所述目标作业系统获取目标数据，所述目标数据包括所述最后一个API的输出参数的参数值。

6.根据权利要求1至3任一项所述的方法，其特征在于，所述作业系统用于提供操作服务，所述目标API用于执行目标操作；

所述方法还包括：

根据所述目标API，通过所述目标作业系统执行所述目标操作。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

通过第一图形用户界面(GUI)接收用户输入的起始模型和终止模型；

根据模型关系图生成由所述起始模型至所述终止模型的至少一条路由路径。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

通过所述第一GUI接收所述用户对所述至少一条路由路径的选择信息；

根据所述选择信息生成所述API调用请求。

9.根据权利要求1至8任一项所述的方法，其特征在于，所述方法还包括：

通过第二GUI接收模型定义信息，所述模型定义信息至少包括所述模型标识和所述模型属性。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

通过所述第二GUI接收不同模型的模型关系信息，所述模型关系信息以模型关系图的形式存储，所述模型关系图以模型为节点，以模型关系为边。

11.根据权利要求1至10任一项所述的方法，其特征在于，在接收API调用请求之前，所述方法还包括：

获取所述作业系统中API的API属性；

通过第三GUI接收所述模型属性和所述API属性的对应关系，获得所述模型和所述作业系统的API之间的映射关系。

12.一种目标作业系统的访问控制系统，其特征在于，所述系统包括：

通信单元，用于接收应用程序编程接口(API)调用请求，所述API调用请求包括至少一个模型标识；

确定单元，用于根据所述模型标识，利用模型和作业系统的API的映射关系确定目标API，所述模型根据所述作业系统建立，并且能够被重复使用，所述目标API用于访问所述目标作业系统。

13.一种计算机集群，其特征在于，所述计算机集群包括至少一台计算机设备，所述至少一台计算机设备包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述计算机集群执行如权利要求1至11中任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，包括指令，所述指令指示计算机集群执行如权利要求1至11中任一项所述的方法。

Images