Access control method, device, equipment and medium for target operating system

Abstract

The present application provides an access control method for a target operating system, comprising: receiving an API call request, and determining a target API based on a model identifier in the API call request, using a mapping relationship between a model established based on the operating system and reusable and the operating system's API, wherein the target API is used to access the target operating system. Once the model is defined, the model can be used directly thereafter. By using different model identifiers, the mapping relationship between the model and the API is utilized to automatically route to different APIs of the operating system, thereby achieving routing access to the operating system in a unified manner, without having to understand the input and output parameter definitions and calling methods of each API, simplifying the calling process and improving the access efficiency of the target operating system.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an access control method, apparatus, device, and computer-readable storage medium for a target operating system. Background Art

[0002] To improve development efficiency during application development, developers can create application programming interfaces (APIs) for certain functions. These APIs can be predefined functions or conventions for connecting different application components. By calling an API, developers can access a set of routines without having to access the source code or understand the underlying mechanisms.

[0003] In some scenarios, API callers (such as applications or application processes) need to call multiple different APIs. To address this, the industry has developed API routing mechanisms to facilitate calls to different APIs. For example, using an API gateway, API callers can implement protocol conversion and API routing forwarding.

[0004] However, the APIs provided by the API gateway cannot be called transparently. Calling the operating system's API requires understanding the definition and calling method of each API's input and output parameters (output and input parameters), and then developing specific calling code for joint debugging and testing. This cumbersome and inefficient calling process makes it difficult to meet business needs. Summary of the Invention

[0005] This application provides a method for access control of a target operating system, which solves the problem in related technologies that the API call process is cumbersome, the call efficiency is low, and it is difficult to meet business needs. This application also provides a device, equipment, computer-readable storage medium, and computer program product corresponding to the above method.

[0006] In the first aspect, the present application provides an access control method for a target operating system. The method can be executed by an access control system of the target operating system (hereinafter referred to as the access control system). Among them, the target operating system is one or more operating systems. The operating system specifically refers to a system that executes operations through computer programs. Depending on the type of operation, the operating system can be divided into many types. For example, the operating system can be a text editing system, a spreadsheet editing system, a production management system, and other systems used to assist office work. For another example, the operating system can also be an electronic store, an electronic payment system, and other systems used to complete transactions. The above are only some specific examples of the operating systems provided by this application, and the operating systems include but are not limited to the above examples.

[0007] Specifically, the access control system receives an API call request that includes at least one model ID. The model ID is the identifier of a model pre-established for the operating system. The ID can be a name, code, or other string that uniquely represents the model. The access control system then determines a target API based on the model ID using a mapping between the model and the operating system's API. This target API is used to access the target operating system.

[0008] In this approach, models can be reused. Once a model is defined, it can be used directly later. The access control system uses different model identifiers and the mapping relationship between the model and the operating system's API to automatically route to different operating system APIs, thereby achieving unified routing access to the operating system. API callers, such as developers, do not need to understand the input and output parameter definitions and calling methods of each API, nor do they need to write specific calling code for joint debugging and testing. This simplifies the calling process and improves calling efficiency, thereby improving the access efficiency and access experience of the operating system and meeting business needs.

[0009] In some possible implementations, a model can be represented by a model identifier and a model attribute, and a mapping relationship can be represented by a model attribute and an API attribute. Therefore, the corresponding API attribute can be determined based on the model identifier, and the target API can be determined based on the API attribute. This shields the differences in API attributes (such as API input and output parameters) and the complexity of calling each operating system, allowing access to operating systems in a unified manner, simplifying the access process and improving access efficiency.

[0010] Attributes specifically refer to the properties and / or relationships of objects. Based on this, model attributes refer to the properties and / or relationships of a model. Models are built based on data entities and their attributes within an operating system. Data entities are data objects managed by the operating system's software modules.

[0011] For example, in an operating system used to complete transactions, such as an e-commerce store, data entities can be data objects managed by software modules, such as products and orders. The attributes of data entities can be the properties and / or relationships of data objects. For example, product attributes can include name, style, color, size, price, etc. For another example, in an operating system that assists development, such as a requirements management system, data entities can be data objects such as requests, bugs, and test cases. The attributes of a defect data entity can include the defect ticket number, product, impact of the result, and the current person handling the issue.

[0012] In some possible implementations, API attributes refer to the properties and / or relationships of the API. For example, the API attributes may be one or more of the input parameters, output parameters, and operation types of the API. Thus, the access control system can determine one or more of the input parameters, output parameters, and operation types of the API based on the model identifier, and can determine the target API based on the input parameters, output parameters, and / or operation type of the API. For example, the access control system determines the target API for querying target data based on the input parameters and output parameters, or the access control system determines the API for performing the target operation based on the operation type.

[0013] In some possible implementations, an operating system can be used to provide data services. For example, an attendance management system or a payroll management system can provide query services for attendance, payroll, and other data. Correspondingly, a target API is used to query target data. Based on this, after the access control system determines the target API, it can also retrieve target data from the target operating system based on the target API. This target data includes the parameter values ​​of the target API's output parameters.

[0014] The following example is explained with reference to the attendance management system. In this example, the attendance management system includes a work-attendance module, based on which a model with a model identifier of work-attendance is established. After the access control system receives the API call request, it determines the target API based on the model identifier work-attendance and the mapping relationship between the model and the API of the operating system, for example, attendance-exception.Query(yyyy-mm, count). Among them, yyyy-mm represents a certain year and month, and count represents the number of attendance exceptions in a certain year and month. The target API is specifically used to query the number of attendance exceptions of employees in a certain year and month.

[0015] In some possible implementations, the API call request may include multiple model identifiers. Correspondingly, the access control system may determine the parameter value of the input parameter of the i+1th API based on the parameter value of the output parameter of the i-th API in the target API, where i is a positive integer. Specifically, the API call request may also carry the parameter value of the starting parameter. The access control system inputs the parameter value of the starting parameter into the first API in the target API to obtain the parameter value of the output parameter of the first API. Based on the parameter value of the output parameter of the first API, the parameter value of the input parameter of the second API may be obtained. Similarly, the access control system may obtain the parameter value of the input parameter of the last API in the target API. According to the parameter value of the input parameter of the last API in the target API, target data is obtained from the target operating system, and the target data includes the parameter value of the output parameter of the last API.

[0016] Among them, the models identified by multiple model identifiers can correspond to one operating system or multiple operating systems. When multiple model identifiers correspond to multiple operating systems (n model identifiers correspond to m operating systems, and n is greater than or equal to m), the access control system determines multiple associated target APIs based on the association relationship between different models, so that routing access to multiple operating system APIs can be achieved through a single interface call. The job caller does not need to connect to multiple operating systems to achieve routing access across operating systems, which improves access efficiency and enhances user experience.

[0017] The following example illustrates this using an attendance management system and a salary management system. In this example, the attendance management system includes an attendance module, based on which a model with the model identifier "work-attendance" is established. The salary management system includes a salary module, based on which a model with the model identifier "salary" is established. After receiving an API call request, the access control system determines the target API based on the model identifiers "work-attendance" and "salary," using the mapping relationship between the model and the operating system's API. For example, "attendance-exception.Query(yyyy-mm, count)" and "salarydetail.Query(count, base-reward-deductionofexception-tax-actualsalary)" are used. Here, "yyyy-mm" represents a specific month and year, and "count" represents the number of attendance exceptions in that specific month and year. "attendance-exception.Query()" is used to query the number of attendance exceptions an employee experienced in a specific month and year. "salarydetail.Query()" is used to query an employee's salary details, including base salary, bonuses, deductions due to attendance exceptions, taxes, and actual salary.

[0018] In some possible implementations, the operating system can also be used to provide operation services. Correspondingly, the target API is specifically used to perform the target operation. Based on this, the access control system can also perform the target operation based on the target API. In other words, accessing the target operating system can mean obtaining target data in the target operating system or performing the target operation through the target API.

[0019] For ease of understanding, the following is an example. In this example, the target operating system is an alarm system. When the monitoring system detects that a certain indicator reaches a threshold, it can access the alarm system through the access control system and execute an alarm operation based on the target API in the alarm system.

[0020] In some possible implementations, the access control system may further receive a user input of a starting model and an ending model via a first graphical user interface (GUI), and then generate at least one routing path from the starting model to the ending model based on the model relationship graph. The routing path is represented by a model identifier, and the routing path may be used to generate an API call request.

[0021] In this implementation, the access control system automatically recommends routing paths based on the model relationship diagram, such as through the shortest path algorithm of the graph database. There is no need for API callers to manually confirm the routing paths, which further simplifies the API call operation and improves the access efficiency of the target operation system.

[0022] In some possible implementations, the access control system may further receive, via the first GUI, information about the user's selection of the at least one routing path and generate the API call request based on the selection information. This allows access to the target operating system based on user needs, improving the user experience.

[0023] In some possible implementations, the access control system can also receive model definition information through a second GUI, and the model definition information includes at least the model identifier and the model attributes. The model definition information can be manually defined by a user such as an information architect based on the business logic and data of the operating system. In some cases, the access control system can also automatically extract relevant information from the business logic and data of the operating system, thereby automatically defining the model. Once the model is defined, it can be reused. That is, when subsequently using the defined model and the mapping relationship between the model and the operating system's API to determine the target API, there is no need to understand the input and output parameter definitions and calling methods of the operating system's API, nor is there any need to write specific calling code for joint debugging and testing, which simplifies the calling process and improves calling efficiency.

[0024] It should be noted that the second GUI and the first GUI may be GUIs presented by the same device, for example, the same GUI. In some implementations, the second GUI and the first GUI may also be GUIs presented by different devices.

[0025] In some possible implementations, the access control system may also receive model relationship information of different models through a second GUI. The model relationship information includes a model identifier. In some implementations, the model relationship information may also include a relationship identifier. As an example, the model relationship information may be expressed as "(Release)<-[belong to]-(TestCase)". The model identifier, such as the model name, is enclosed in parentheses, and the relationship identifier between the models, such as the relationship name, is enclosed in square brackets.

[0026] The model relationship information can be stored in the form of a model relationship graph. The model relationship graph uses models as nodes and model relationships as edges. This model relationship graph facilitates querying model relationships and allows for rapid path recommendations.

[0027] In some possible implementations, before receiving the API call request, the access control system may also obtain API properties of the API in the operating system, such as input parameters and output parameters. Specifically, the access control system may read the API document through swagger to obtain properties such as the input parameters and output parameters of the API. Then, the access control system may present the properties of the API through a third GUI, and then, the access control system may receive the correspondence between the model properties and the API properties through the third GUI, thereby obtaining a mapping relationship between the model and the API of the operating system. The correspondence between the model properties and the API properties may come from a connection operation by a user, such as an information architect. For example, the information architect may connect the model properties and the corresponding API properties by dragging and dropping.

[0028] In a second aspect, the present application provides an access control system for a target operating system. The access control system is used to execute an access control method for the target operating system. The access control system for the target operating system (hereinafter referred to as the access control system) includes multiple parts. For example, the access control system includes at least an API routing subsystem, and the API routing subsystem includes multiple units. Specifically, as shown below:

[0029] a communication unit, configured to receive an application programming interface (API) call request, wherein the API call request includes at least one model identifier;

[0030] The determination unit is used to determine the target API according to the model identifier and the mapping relationship between the model and the API of the operating system. The model is established according to the operating system and can be reused. The target API is used to access the target operating system.

[0031] The various units of the API routing subsystem can be deployed on the same device, for example, in a cloud environment, an edge environment, or on an end device. In some possible implementations, the various units of the API routing subsystem can also be deployed in a distributed manner on different devices, which is not limited in the embodiments of the present application.

[0032] In some possible implementations, the model is represented by the model identifier and model attributes, and the mapping relationship is represented by the model attributes and API attributes.

[0033] In some possible implementations, the API attributes include one or more of input parameters, output parameters, and operation types.

[0034] In some possible implementations, the operating system is used to provide data services, and the target API is used to query target data;

[0035] The API routing subsystem may further include:

[0036] The routing unit is configured to obtain the target data from the target operating system according to the target API, where the target data includes parameter values ​​of output parameters of the target API.

[0037] The routing unit and the determination unit may be deployed on the same device, or may be deployed in a distributed manner on different devices.

[0038] In some possible implementations, the API call request includes multiple model identifiers;

[0039] The routing unit is specifically configured to:

[0040] Determine the parameter value of the input parameter of the (i+1)th API according to the parameter value of the output parameter of the (i)th API in the target API, where (i) is a positive integer;

[0041] According to the parameter value of the input parameter of the last API in the target API, target data is obtained from the target operating system, where the target data includes the parameter value of the output parameter of the last API.

[0042] This allows the access control system to route access to multiple operating system APIs through a single interface call. The caller can achieve cross-operating system routing access without having to connect to multiple operating systems, improving access efficiency and enhancing the user experience.

[0043] In some possible implementations, the operating system is used to provide an operation service, and the target API is used to perform a target operation;

[0044] The API routing subsystem also includes:

[0045] A routing unit is configured to execute the target operation through the target operating system according to the target API.

[0046] In some possible implementations, the access control system may further include a path recommendation subsystem, which is specifically used to recommend routing paths. The path recommendation subsystem includes multiple units, as shown below:

[0047] A communication unit, configured to receive a starting model and an ending model input by a user through a first graphical user interface (GUI);

[0048] A recommendation unit is configured to generate at least one routing path from the starting model to the ending model according to the model relationship graph.

[0049] Among them, the path recommendation subsystem and the API routing subsystem can be deployed on the same device or on different devices. In addition, the path recommendation subsystem can also be merged with the API routing subsystem. In this way, the API routing subsystem can include a communication unit, a determination unit, and a recommendation unit. In this case, the API routing subsystem can be used not only to implement API routing, but also to implement path recommendation. Among them, when the API routing subsystem and the path recommendation subsystem are merged, the communication units of the two subsystems can be merged into one.

[0050] In some possible implementations, the route recommendation subsystem may further include a generation unit.

[0051] The communication unit of the path recommendation subsystem is further configured to receive, through the first GUI, selection information of the at least one routing path by the user;

[0052] The generating unit is configured to generate the API call request according to the selection information.

[0053] The generation unit and the recommendation unit may be deployed on the same device or on different devices, which is not limited in this embodiment of the present application.

[0054] In some possible implementations, the access control system may further include a model management subsystem. The model management subsystem is specifically used to build a model. Building a model refers to defining a model. Specifically, the model management subsystem includes:

[0055] The communication unit is configured to receive model definition information through a second GUI, where the model definition information at least includes the model identifier and the model attributes.

[0056] In some cases, the model management subsystem may further include a storage unit for storing the above-mentioned model definition information.

[0057] The model management subsystem can be deployed on the same device as the API routing subsystem and path recommendation subsystem, or it can be deployed in a distributed manner across different devices. When the model management subsystem and API routing subsystem are deployed on the same device, they can also be merged. Accordingly, the communication units of multiple subsystems can be merged into one communication unit.

[0058] When the model management subsystem and the route recommendation subsystem are deployed on the same device, the first GUI and the second GUI can be GUIs presented by the same device, for example, they can be the same GUI. When the model management subsystem and the route recommendation subsystem are deployed on different devices, the first GUI and the second GUI can be GUIs presented by different devices, that is, different GUIs.

[0059] In some possible implementations, different models may have association relationships. The model management subsystem may also be used to maintain model relationships between different models. Specifically, the communication unit of the model management subsystem is further used to receive model relationship information of different models through the second GUI. The model relationship information is stored in the form of a model relationship graph, where the model relationship graph uses models as nodes and model relationships as edges.

[0060] In some possible implementations, the access control system may further include an API mapping management subsystem. The API mapping management subsystem is specifically used to establish a mapping relationship between the model and the API of the operating system. The API mapping management subsystem includes:

[0061] A communication unit, configured to obtain API attributes of the API in the operating system;

[0062] The communication unit is further configured to receive the correspondence between the model attributes and the API attributes through a third GUI, and obtain a mapping relationship between the model and the API of the operating system.

[0063] The API mapping management subsystem can be deployed on the same device as the API routing subsystem, path recommendation subsystem, and model management subsystem, or distributed across different devices. The API mapping management subsystem can also be merged with other subsystems, such as the API routing subsystem. Accordingly, the communication units of these subsystems can be merged into one communication unit.

[0064] When the API mapping management subsystem and the path recommendation subsystem are deployed on the same device, the third GUI and the first GUI can be GUIs presented by the same device, and therefore, the third GUI and the first GUI can be the same GUI. When the API mapping management subsystem and the model management subsystem are deployed on the same device, the third GUI and the second GUI can be GUIs presented by the same device, and therefore, the third GUI and the second GUI can be the same GUI.

[0065] In some implementations, the first GUI, the second GUI, and the third GUI may also be different GUIs, which is not limited in this embodiment of the present application.

[0066] In a third aspect, the present application provides a computer cluster, comprising at least one computer device, wherein the at least one computer device includes a processor and a memory. The processor and the memory communicate with each other. The processor is configured to execute instructions stored in the memory, causing the device to perform the access control method for a target operating system as described in the first aspect or any implementation of the first aspect.

[0067] In a fourth aspect, the present application provides a computer-readable storage medium storing instructions, wherein the instructions instruct a computer cluster to execute the target operating system access control method described in the first aspect or any implementation of the first aspect.

[0068] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer cluster, enables the computer cluster to execute the target operating system access control method described in the first aspect or any one of the implementations of the first aspect.

[0069] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] In order to more clearly illustrate the technical methods of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments.

[0071] Figure 1 An architectural diagram of an access control system provided in an embodiment of the present application;

[0072] Figure 2 An architectural diagram of an access control system provided in an embodiment of the present application;

[0073] Figure 3 A schematic diagram of the structure of an access control system provided in an embodiment of the present application;

[0074] Figure 4 A schematic diagram of an interface provided in an embodiment of the present application;

[0075] Figure 5 A schematic diagram of an interface provided in an embodiment of the present application;

[0076] Figure 6 A schematic diagram of storing model definition information and model relationship information provided in an embodiment of the present application;

[0077] Figure 7 A model relationship diagram provided for an embodiment of the present application;

[0078] Figure 8A A schematic diagram of an interface provided in an embodiment of the present application;

[0079] Figure 8B A schematic diagram of an interface provided in an embodiment of the present application;

[0080] Figure 9 A schematic diagram of an interface provided in an embodiment of the present application;

[0081] Figure 10A schematic diagram of the structure of a computing cluster provided in an embodiment of the present application;

[0082] Figure 11 A flowchart of an access control method for an operating system provided in an embodiment of the present application;

[0083] Figure 12 A schematic diagram of the structure of a computer cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0084] The terms "first" and "second" in the embodiments of this application are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include one or more of the features.

[0085] First, some technical terms involved in the embodiments of this application are introduced.

[0086] An operating system is a system that executes tasks using computer programs. Depending on the type of task, operating systems can be categorized into various types. For example, operating systems can be used to assist with office tasks, such as text editing systems, spreadsheet editing systems, and production management systems. Alternatively, operating systems can be used to complete transactions, such as electronic stores and electronic payment systems.

[0087] An operating system consists of at least one functional module. Functions are often shared within the same module or across different modules. To streamline code and improve development efficiency, developers can provide application programming interfaces (APIs) for frequently used functions. By calling an API, developers can access a set of routines without having to access the source code or understand the underlying mechanisms.

[0088] An API Gateway aggregates multiple APIs. Service providers can register their services on the API Gateway, specifically the APIs corresponding to their services. The API Gateway provides a unified entry point, allowing service callers (i.e., service consumers) to call registered APIs across various operating systems through this unified entry point (which may include a unified protocol and domain name).

[0089] The current API gateways offer APIs that cannot be called transparently. Calling each API requires understanding the API documentation for its input and output parameters and calling methods, then writing different calling codes for joint debugging and testing. This makes it impossible to route access to different operating systems through a unified API. This cumbersome and inefficient calling process impacts the access efficiency and user experience of the operating systems, making it difficult to meet business needs.

[0090] In view of this, an embodiment of the present application provides an access control method for an operating system. The method is specifically executed by an access control system of the operating system (hereinafter referred to as the access control system). The business logic and data of the operating system can be presented through a table structure, and a model corresponding to each data entity can be defined based on the data entity (data entity, that is, the data object managed by the software module in the operating system) in the table structure and the attribute of the data entity. The access control system is based on a predefined, reusable model, as well as a mapping relationship between the model and the API, which shields the differences in the input and output parameters of each operating system API and the complexity of the call, and realizes routing access to the operating system in a unified manner.

[0091] Specifically, the access control system receives an API call request, which has a unified format, specifically carrying at least one model identifier in the API call request. The access control system can determine the target API based on the model identifier and the mapping relationship between the model and the API. The target API is used to access the target operating system.

[0092] In this approach, models can be reused; once a model is defined, it can be used directly later. When the access control system receives an API call request, it automatically routes it to the corresponding API in the operating system using the model identifier in the API call request. This enables unified routing access to the operating system, eliminating the need to write specific call code for joint debugging and testing. This simplifies the call process, improves call efficiency, and ultimately enhances the access efficiency and user experience of the operating system, meeting business needs.

[0093] Furthermore, based on the relationships between different models, the access control system can also identify multiple target APIs, enabling routed access to multiple operating system APIs through a single interface call. This eliminates the need for the caller to connect to multiple operating systems, enabling cross-operation system routed access, improving access efficiency and enhancing the user experience.

[0094] like Figure 1As shown, the access control system can be deployed in a cloud environment, specifically one or more computing devices (e.g., central servers) in the cloud environment. The access control system can also be deployed in an edge environment, specifically one or more computing devices (edge ​​computing devices) in the edge environment. The edge computing devices can be servers, computing boxes, etc. The cloud environment indicates a cluster of central computing devices owned by a cloud service provider for providing computing, storage, and communication resources; the edge environment indicates a cluster of edge computing devices that are geographically close to an end device (i.e., an end-side device) for providing computing, storage, and communication resources. In some implementations, the access control system can also be deployed on an end device. End devices include, but are not limited to, gateways, servers, and other devices.

[0095] When an access control system is deployed in a cloud or edge environment, it can be provided to users as a service. Specifically, users can access the cloud or edge environment through a browser, create an instance of the access control system in the cloud or edge environment, and then interact with the access control system instance through the browser to access the operating system.

[0096] An access control system can also be deployed on a terminal device and provided to users as a client. Specifically, the terminal device obtains the access control system installation package and runs it to install the access control system client on the terminal device. By running the client, the terminal device accesses the operating system.

[0097] like Figure 2 As shown, the access control system includes multiple parts (e.g., multiple subsystems, each subsystem including multiple units). Therefore, the various parts of the access control system can also be deployed in different environments in a distributed manner. For example, a part of the access control system can be deployed in the cloud environment, the edge environment, and the end device, or in any two of these environments.

[0098] It should also be noted that the access control system or part of the access control system can be deployed directly in a physical machine such as a central computing device, an edge computing device, or a terminal device, or it can be deployed in a virtual machine or container that uses the above physical machine as the host. Considering the ease of migration and maintenance of containers, the access control system or part of the access control system can be deployed in a container. For example, if the access control system or part of the access control system is developed based on Java, it can be deployed in a Java runtime container, such as Tomcat.

[0099] The access control system is used to implement routing access to different operating systems in a unified manner. The subsystems and units within the access control system can be divided in many ways, and this application does not limit them. Figure 3 An exemplary division method is as follows: Figure 3 As shown, the access control system 100 includes at least an API routing subsystem 120 . In some implementations, the access control system 100 further includes one or more of a model management subsystem 140 , an API mapping management subsystem 160 , and a path recommendation subsystem 180 .

[0100] For ease of description, the GUI provided by the path recommendation subsystem 180 may be referred to as the first GUI, the GUI provided by the model management subsystem 140 may be referred to as the second GUI, and the GUI provided by the API mapping management subsystem 160 may be referred to as the third GUI. When the path recommendation subsystem 180, the model management subsystem 140, and the API mapping management subsystem 160 are deployed on the same device, the first, second, and third GUIs may be the same GUI. In some implementations, for example, when the path recommendation subsystem 180, the model management subsystem 140, and the API mapping management subsystem 160 are deployed on different devices in a distributed manner, the first, second, and third GUIs may be different GUIs.

[0101] The functions of each subsystem and the functional units it includes are briefly described below.

[0102] The API routing subsystem 120 is configured to receive an API call request that carries at least one model identifier. The API routing subsystem 120 then determines a target API based on the model identifier and the mapping relationship between the model and the API. The target API is used to access the target operating system. The API routing subsystem 120 can route to different APIs based on different model identifiers, thereby enabling unified access to different operating systems.

[0103] In some implementations, a model can be represented by a model identifier and a model attribute, and a mapping relationship can be represented by a model attribute and an API attribute. Therefore, the API routing subsystem 120 can determine the corresponding API attribute based on the model identifier and determine the target API based on the API attribute. This shields the differences in API attributes (e.g., API input and output parameters) of various operating systems and the complexity of calling, allowing access to operating systems in a unified manner.

[0104] Among them, attributes specifically refer to the properties and / or relationships of things. Based on this, model attributes refer to the properties and / or relationships of the model. The model is established based on the data entities (entity) and the attributes (attribute) of the data entities in the operating system. Data entities refer to the data objects managed by the software modules of the operating system. For example, in an operating system used to complete transactions such as an electronic store, data entities can be data objects such as goods and orders, and the attributes of data entities can be the properties and / or relationships of data objects. For example, the attributes of goods can include style, color, size, price, etc. For another example, in an auxiliary development operating system such as a demand management system, data entities can be data objects such as requirements (request), defects (bug), test cases (test case), etc. When the data entity is a defect, its attributes can include defect order number, product, result impact, current handler, etc.

[0105] In some possible implementations, API attributes refer to properties and / or relationships of the API. For example, API attributes can be one or more of the input parameters, output parameters, and operation types of the API. Thus, the API routing subsystem 120 can determine one or more of the input parameters, output parameters, and operation types of the API based on the model identifier, and can determine the target API based on the input parameters, output parameters, and / or operation type of the API. For example, the API routing subsystem 120 determines the target API for querying target data based on the input parameters and output parameters, or the API routing subsystem 120 determines the API for performing the target operation based on the operation type.

[0106] In some possible implementations, an operating system can be used to provide data services. For example, an operating system such as an attendance management system or a payroll management system can provide query services for attendance, payroll, and other data. Correspondingly, the target API is used to query target data. Based on this, after the API routing subsystem 120 determines the target API, it can also retrieve target data from the target operating system based on the target API. This target data includes the parameter values ​​of the target API's output parameters.

[0107] Take the attendance management system as an example. The attendance management system includes a work-attendance module, based on which a model with a model identifier of work-attendance is established. After receiving the API call request, the API routing subsystem 120 determines the target API based on the model identifier work-attendance and the mapping relationship between the model and the API of the operating system, for example, attendance-exception.Query(yyyy-mm, count). Among them, yyyy-mm represents a certain year and month, and count represents the number of attendance exceptions in a certain year and month. The target API is specifically used to query the number of attendance exceptions of employees in a certain year and month.

[0108] In some implementations, the API call request may include multiple model identifiers. Correspondingly, the API routing subsystem 120 may also determine multiple target APIs based on the multiple model identifiers. Each model identifier corresponds to a target API. Based on this, the access control system 100 can access the APIs of multiple operating systems through a single interface call. Specifically, the API routing subsystem 120 can determine the parameter value of the input parameter of the i+1th API based on the parameter value of the output parameter of the i-th API in the target API, where i is a positive integer. Similarly, the API routing subsystem 120 can obtain the parameter value of the output parameter of the last API in the target API based on the parameter value of the input parameter of the last API in the target API, thereby obtaining target data from the target operating system, where the target data includes the parameter value of the output parameter of the last API.

[0109] The models identified by the multiple model identifiers may correspond to one operating system or multiple operating systems. When multiple model identifiers correspond to multiple operating systems (specifically, n model identifiers correspond to m operating systems, where n is greater than or equal to m), the API routing subsystem 120 determines multiple associated target APIs based on the associations between the different models. In this way, the job caller can achieve routing access across operating systems without having to connect to multiple operating systems.

[0110] The API routing subsystem 120 includes multiple functional units, wherein the communication unit 122 is used to receive an API call request, and the determination unit 124 is used to determine a target API based on at least one model identifier carried in the API call request and a mapping relationship between the model and the API.

[0111] In some implementations, the operating system is used to provide data services, and the target API is used to query target data. Correspondingly, the API routing subsystem 120 may further include a routing unit 126. The routing unit 126 is used to obtain the target data from the target operating system according to the target API, where the target data includes parameter values ​​of output parameters of the target API.

[0112] When the API call request includes multiple model identifiers, the determination unit 124 uses the mapping relationship between models and APIs to determine that the target APIs include multiple ones. The routing unit 126 can determine the input parameters of the (i+1)th API based on the output parameters of the i-th API in the target APIs, and then obtain target data from the target operating system based on the parameter values ​​of the input parameters of the last API in the target APIs. The target data includes the parameter values ​​of the output parameters of the last API.

[0113] The model management subsystem 140 is specifically used to build a model. Building a model means defining a model. In specific implementation, the model management subsystem 140 receives model definition information through a graphical user interface (GUI), thereby defining the model. The model definition information includes at least a model identifier (modelID) and a model attribute (model attribute). The model is defined based on a data entity, and the model identifier can be the name of the data entity, the number of the data entity, or a unique value obtained by processing the name and number of the data entity. Model attributes refer to the properties and / or relationships of the model. In some implementations, the model definition information may also include the name (name), type (category), creation date (createDate), description (description) and other information related to the data entity.

[0114] Figure 4 A schematic diagram of a second GUI interface is provided, such as Figure 4 As shown, the interface 400 presents a model identification configuration component 402, a model attribute configuration component 404, and a submission management component 406. The model identification configuration component 402 includes a model identification configuration control, and the model management subsystem 140 can receive a model identification, such as "Offering," input by a user through the model identification configuration control to implement the model identification configuration.

[0115] The model attribute configuration component 404 includes a selection control for model attributes, as well as a new control, a delete control, an invalid control, and a valid control. Among them, the new control is used to add a new model attribute. After the new control is triggered, the user interface 400 presents a blank line, and the model management subsystem 140 receives the name, description, type, status, and whether the attribute is associated, etc. of the attribute entered by the user in the corresponding position of the blank line, so as to realize the addition of the new attribute. The delete control is used to delete the model attribute. Specifically, after the selection control of one or more model attributes is triggered, the model management subsystem 140 can select the model attribute corresponding to the above-mentioned selection control. When the delete control is triggered, the model management subsystem 140 can delete the selected attribute. The invalid control is specifically used to filter the model attributes whose status is invalid in the model attributes. Similarly, the valid control is specifically used to filter the model attributes whose status is valid in the model attributes.

[0116] The submission management component 406 includes a submit control and a cancel control. The submit control is used to submit the model definition information, that is, to submit the configured model identifier and the attribute values ​​of the model attributes. The cancel control is used to cancel the submission of the model definition information, that is, to cancel the submission of the model identifier and the attribute values ​​of the model attributes.

[0117] Furthermore, some models have relationships with each other, and the model management subsystem 140 can also be used to maintain the relationships between different models. Specifically, the model management subsystem 140 receives model relationship information of different models through the second GUI, thereby maintaining the relationships between different models. The relationships between models can include various types, such as invoking, relating, referencing, assembling, belonging to, and relying on.

[0118] Figure 5 A schematic diagram of a second GUI interface is provided, such as Figure 5 As shown, the interface 500 presents a model relationship addition and deletion component 502, a model relationship configuration component 504, and a submission management component 506. The model relationship addition and deletion component 502 includes a new control and a delete control.

[0119] The add control is used to add a new model relationship. Specifically, the model management subsystem 140 receives the source model identifier, source model associated attributes, relationship name, target model identifier, and target model associated attributes input by the user through the add control to add a new model relationship.

[0120] For example, when the Offering model and IndustryCategory model are associated through the source model's attribute IndustryCategoryID and the target model's attribute ID, as shown in Figure 5 As shown, the model management subsystem 140 can receive the user's input of Offering in the source model identification input field, IndustryCategoryID in the source model association attribute input field, reference in the relationship name input field, IndustryCategory in the target model identification input field, and ID in the target model association attribute input field through the editing control in the model relationship configuration component 504, so as to realize the addition of a new model relationship.

[0121] The target model's associated attribute is specifically an attribute that can uniquely identify the target model, i.e., the target model's primary key. The source model's associated attribute can be an attribute that can uniquely identify the source model, i.e., the source model's primary key. The source model's associated attribute can also be an attribute that cannot uniquely identify the source model, i.e., the source model's foreign key. When the target model and source model have a one-to-many association, the source model's associated attribute is the source model's foreign key. When the target model and source model have a many-to-many association, the source model's associated attribute is the source model's primary key.

[0122] For example, let's use the source model "user" and the target model "group". When a group includes multiple users, and each user belongs to only one group, the group and user relationships are one-to-many. In this case, the source model's associated attribute is the source model's foreign key, thus establishing a relationship between one group and multiple users. When a group includes multiple users, and each user can belong to multiple groups, the group and user relationships are many-to-many. In this case, the source model's associated attribute is the source model's primary key.

[0123] When the model management subsystem 140 stores model relationship information, it specifically uses a data table for storage. In some implementations, when the source model and the target model have a many-to-many relationship, the model management subsystem 140 may use a separate data table for storage.

[0124] The delete control is used to delete a model relationship. Specifically, the model management subsystem 140 receives one or more model relationships selected by the user via the model relationship selection control in the model relationship configuration component 504 to select the one or more model relationships. When the delete control is triggered, the model management subsystem 140 deletes the selected model relationships in response to the triggering operation.

[0125] The submission management component 506 includes a submit control and a cancel control. The submit control is used to submit model relationship information. Each piece of relationship information includes at least the model identifiers of two models with a relationship. In some implementations, the relationship information also includes one or more of a relationship name and associated attributes. The cancel control is used to cancel the submission of model relationship information.

[0126] In some implementations, the model management subsystem 140 may store one or more of the model definition information and the model relationship information in a database. Considering the structure of the model definition information and the model relationship information, the model management subsystem 140 may store this information in a relational database, such as MySQL.

[0127] Figure 6 The figure shows the storage structure of model definition information and model relationship information in the database. Figure 6 As shown, the model definition information mainly includes two parts, namely the data entity and the attributes of the data entity. The model is determined based on the data entity, and the data entity part at least includes a model identifier determined based on information such as the name or number of the data entity. In some implementations, the data entity part may also include one or more of the model's name, type, creation date, description, and other information. The attribute part of the data entity includes the name of the attribute. In some implementations, the attribute part of the data entity also includes one or more of the attribute's description, data type, importance, and other information. It should be noted that the attribute part of the data entity also includes a model identifier for association with the corresponding data entity.

[0128] The model relationship information includes at least a source model identifier and a target model identifier. When a model relationship describes a relationship between the same model, the source model identifier and the target model identifier are the same. When a model relationship describes a relationship between different models, the source model identifier and the target model identifier are different. Furthermore, the model relationship information also includes a relationship name, which is used to describe the relationship between the source model and the target model. In some implementations, the model relationship information may also include one or more of a source attribute name and a target attribute name, which are used to describe which attribute or attributes of the source model or target model the source model and the target model are associated with.

[0129] To facilitate intuitive presentation of model relationships, in some implementations, the model management subsystem 140 is further configured to construct a model relationship graph based on the model relationship information, wherein the model relationship graph uses models as nodes and model relationships as edges. Figure 7 A schematic diagram of the model relationship diagram is shown, Figure 6 As shown, models such as Offering serve as nodes of the model relationship graph, and models with associated relationships form edges of the model relationship graph.

[0130] The model relationship graph constructed by the model management subsystem 140 can be stored in a graph database, such as Neo4j, TigerGraph, ArangoDB, JanusGraph, or Dgraph. Based on the model relationship graph, path recommendation and routing can be implemented.

[0131] Model management subsystem 140 includes a communication unit 142 configured to receive model definition information via a second GUI. In some implementations, model management subsystem 140 also includes a storage unit 144 configured to store the model definition information. Furthermore, communication unit 142 is further configured to receive model relationship information via the second GUI, and storage unit 144 is further configured to store the model relationship information. Storage unit 144 is specifically configured to store the model definition information and model relationship information in a relational database, such as MySQL.

[0132] In some implementations, the model management subsystem 140 may further include a graphing unit 146 for constructing a model relationship graph based on the model relationship information. Based on this, the storage unit 144 is further configured to store the model relationship graph in a graph database, such as Neo4j.

[0133] The API mapping management subsystem 160 is specifically used to establish a mapping relationship between the model and the API of the operating system. Specifically, the API mapping management subsystem 160 can receive a mapping relationship between model attributes and API attributes (such as output parameters and input parameters of the API) through the third GUI.

[0134] In some implementations, the API mapping management subsystem 160 may first obtain the output and input parameters of the API. For example, it may obtain the API's input and output parameters by reading the JavaScript object notation (JSON) field structure corresponding to the input and output parameters in the API documentation through Swagger. Next, the API mapping management subsystem 160 presents the model identifier and the API's input and output parameters using a third GUI. The third GUI then receives the correspondence between the model attributes and the input and output parameters, thereby obtaining a mapping between the model and the operating system's API. This mapping can be manually configured by a user (e.g., an information architect) through the third GUI.

[0135] Figure 8A and Figure 8B An interface diagram is provided respectively. Figure 8A As shown, the interface 800 is used to map model attributes and API input parameters, such as Figure 8BAs shown, the interface 800 is used to map model attributes and API output parameters. The left side of the interface 800 is the input parameters or output parameters, and the right side of the interface 800 is the name of the model attribute.

[0136] In some implementations, the API mapping management subsystem 160 receives the user's Figure 8A The interface 800 connects the name of the input parameter and the model attribute to realize the mapping between the model attribute and the input parameter. Figure 8B The interface 800 pairs the connection information of the output parameter and the model attribute name to realize the mapping between the model attribute and the output parameter. According to the mapping between the model attribute and the input parameter and the mapping between the model attribute and the output parameter, the mapping between the model and the API of the operation system is realized.

[0137] The connection information between the input parameter and the model attribute name, or the connection information between the output parameter and the model attribute name, may specifically be derived from a user drag operation, for example, an operation of dragging an input parameter or an output parameter to the right side of interface 800. In some implementations, the connection information may also be derived from other user operations, such as an operation of directly connecting with a line.

[0138] Input parameters and output parameters can be JSON fields expressed using JSONPath. After connecting an input parameter to a model attribute, or connecting an output parameter to a model attribute, API mapping management subsystem 160 can also present the JSONPath corresponding to the JSON field. In one example, the JSONPath can be $['data']['Name'], where the JSON field expressed using this JSONPath includes the Name field. JSONPath can be used to facilitate access to corresponding JSON fields and obtain their values.

[0139] When establishing a mapping relationship, a model can be mapped to multiple APIs, but the input parameter fields of different APIs must be mapped to different attribute fields of the model. That is, when an attribute field is used as an input parameter, it can only be mapped by one API. When multiple different attribute fields are used as input parameters, they can be mapped by multiple different APIs. Based on this, the access control system 100 can route to different APIs based on different attribute fields.

[0140] Model attributes can be divided into primary keys and foreign keys based on whether they can uniquely identify the model. When establishing a mapping between model attributes and API input parameters, you can also establish a mapping between primary keys and API input parameters, and between foreign keys and API input parameters.

[0141] API mapping management subsystem 160 includes a communication unit 162. Communication unit 162 is configured to obtain API attributes of the operating system's API, such as API input and output parameters. In some implementations, API mapping management subsystem 160 may further include a display unit 164. Display unit 164 is configured to present model attributes and API attributes using a third GUI. Communication unit 162 is further configured to receive the correspondence between model attributes and API attributes via the third GUI, thereby obtaining a mapping between the model and the operating system's API.

[0142] In some possible implementations, the API mapping management subsystem 160 further includes a storage unit 166, which is configured to store a mapping relationship between a model and an API. Specifically, the storage unit 166 may store the mapping relationship in a relational database.

[0143] The path recommendation subsystem 180 is used to recommend routing paths. Specifically, the path recommendation subsystem 180 is used to receive the starting model and the ending model input by the user through the first GUI, and then generate at least one routing path from the starting model to the ending model based on the model relationship information, such as the model relationship diagram. The graph data structure in the graph database, such as the model relationship diagram, can effectively express the data entities, attributes and relationships of the model. The path recommendation subsystem 180 can use the path algorithm of the graph database to realize path query and recommendation. Taking the open source graph database Neo4j as an example, Neo4j provides a graph query language similar to the structured query language (SQL) (such as Cypher), and also provides algorithm packages such as apoc and algo, which can realize path recommendation, graph search and other functions.

[0144] At least one routing path generated by route recommendation system 180 can be expressed using at least one model identifier. Based on this, the routing path can be used to generate an API call request. It should be noted that the API call request can be generated by a separate user device, such as a browser, or by route recommendation subsystem 180.

[0145] Furthermore, route recommendation subsystem 180 is further configured to present the at least one routing path, allowing the user to select a routing path for API call. Specifically, route recommendation subsystem 180 receives user selection information regarding the at least one routing path input via the first GUI. Route recommendation subsystem 180 may then generate the API call request based on the selection information.

[0146] In some implementations, the route recommendation subsystem 180 may also return at least one routing path to the user device, which then presents the at least one routing path via its own GUI (referred to as a fourth GUI for ease of description). The user device receives user selection information regarding the at least one routing path via the fourth GUI and generates the API call request based on the selection information.

[0147] The following is an example of the route recommendation subsystem 180 generating an API call request. Figure 9 A schematic diagram of a first GUI is provided. Figure 9 As shown, the interface 900 includes a start and end model configuration component 902, a path display component 904, and an input parameter generation component 906. The start and end model configuration component 902 includes a start model configuration control and a stop model configuration control. The path recommendation subsystem 180 receives the start model configured by the user through the start model configuration control, such as Offering, and receives the stop model configured by the user through the stop model configuration control, such as TestCase. The path recommendation subsystem 180 can then use the shortest path (kShortestPaths) function in the algo algorithm package of the Neo4j graph database to use the shortest path graph algorithm to calculate the shortest path from the start model to the stop model. The path recommendation subsystem 180 displays the above shortest path through the path display component 904 of the interface 900.

[0148] The shortest path can be specifically represented by a model identifier (such as a model name). In some implementations, such as Figure 9 As shown in , paths can also be represented by model identifiers and relationship identifiers. Figure 9 In the example, the path can be expressed as "(Offering)<-[belong to]-(Release)<-[belong to]-(TestCase)". The model names are in parentheses, and the relationship identifiers between models are in square brackets.

[0149] Path display component 904 includes a path selection control. Each path selection control corresponds to a routing path. When a path selection control is triggered, the corresponding path is selected to generate an API routing request. A key to generating an API routing request is to generate API input parameters in a unified format. These input parameters include at least one model identifier. The at least one model identifier is specifically the model identifier included in the routing path. In some implementations, the API input parameters also include a starting parameter, which refers to the input parameters of the starting model.

[0150] The input parameter generation component 906 includes a starting model instance configuration control and an input parameter generation control. A model can include multiple instances; for example, an order model can include multiple order instances. The starting model instance configuration control is used to specify the starting model instance on which the current access operation depends. The input parameter generation control is used to generate the input parameters for the API.

[0151] Specifically, the routing recommendation subsystem 180 receives the identifier startmodelinstanceID of the starting model instance configured by the user through the starting model instance configuration control, for example, 22823749. When the input parameter generation control is triggered, the routing recommendation subsystem 180 can generate input parameters based on the identifier of the starting model instance and the model identifier included in the selected routing path. Specifically, the routing recommendation subsystem 180 first obtains the starting parameters based on the identifier of the starting model instance. In this example, the starting parameters are "pageSize" = 100 and "pageNumber" = 1. The routing recommendation subsystem generates the input parameters of the API based on the starting parameters and the model identifier included in the selected routing path. Figure 9 An example of input parameters is also provided in . In this example, the input parameters also include the relationship identifier of the model.

[0152] It should be noted that the path recommendation subsystem 180 includes multiple functional units. The communication unit 182 is used to receive the starting model and the ending model input by the user through the first GUI. The recommendation unit 184 is used to generate at least one routing path from the starting model to the ending model based on the model relationship graph.

[0153] In some implementations, the route recommendation subsystem 180 further includes a display unit 186. The display unit 186 is configured to present at least one routing path via a first GUI, allowing the user to select one of the routing paths. Correspondingly, the communication unit 182 is further configured to receive user selection information regarding the at least one routing path. The route recommendation subsystem 180 may further include a request generation unit 188, configured to generate the API call request based on the selection information.

[0154] The above-mentioned access control system 100 is mainly used to provide API calling services, specifically to provide an operating system with services for calling the API in the operating system or the API of other operating systems. The access control system 100 is not for end users, so it can be deployed in the middle platform. The middle platform is an abstract layer between the foreground and the background. The so-called front desk is a front-end platform composed of various front-end systems, such as websites, mobile applications (applications, apps), etc. visited by end users. The so-called background is a back-end platform composed of back-end systems, such as financial systems, customer management systems, etc. form the background. In order to maintain the stability of the background system and be able to respond to the continuous needs of end users, the business capabilities that need to change frequently in the background system and need to be directly used by the front desk can be transplanted to the middle platform. In some implementations, the access control system 100 can also be deployed in the background or the front desk.

[0155] The above describes the subsystems and units within the access control system 100 . Next, the devices for deploying the access control system 100 will be introduced from a hardware perspective. Figure 10 FIG1 shows a schematic diagram of the structure of the computing cluster 1000. It should be understood that Figure 10 Only part of the hardware structure and part of the software modules in the computing cluster are shown. In specific implementation, the computing cluster 1000 may also include more hardware structures, such as speakers, displays, etc., and more software modules, such as various application programs.

[0156] like Figure 10 As shown, computing cluster 1000 includes at least one computer device, each of which includes a bus 1001 , a processor 1002 , a communication interface 1003 , and a memory 1004 . Processor 1002 , memory 1004 , and communication interface 1003 communicate with each other via bus 1001 .

[0157] The bus 1001 may be a peripheral component interconnect (PCI) bus, a peripheral component interconnect express (PCIe) bus, or an extended industry standard architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 10 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0158] The processor 1002 may be any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0159] Communication interface 1003 is used for external communication, such as receiving API call requests, receiving user input of start and end models through the GUI, and so on. Communication interface 1403 may include a display. A display is an input / output (I / O) device. This device can display electronic files such as images and text on a screen for user viewing. Depending on the manufacturing material, displays can be divided into liquid crystal displays (LCDs), organic light emitting diode (OLED) displays, etc.

[0160] The memory 1004 may include volatile memory, such as random access memory (RAM). The memory 1004 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0161] Memory 1004 stores programs or instructions, such as those required to implement the functions of determination unit 124 and routing unit 126, or those required to implement the functions of composition unit 146, or those required to implement the functions of recommendation unit 184. Processor 1002 executes these programs or instructions to implement the aforementioned operating system access control method.

[0162] In order to make the technical solution of the present application clearer and easier to understand, the access control method of the embodiment of the present application will be described in detail below from the perspective of the API routing subsystem 120, model management subsystem 140, API mapping management subsystem 160 and path recommendation subsystem 180 being deployed on the same device, such as the same cloud computing device.

[0163] See also Figure 11 The access control method shown is a flowchart, the method comprising:

[0164] S1102: The access control system 100 receives an API call request.

[0165] The API call request includes at least one model identifier. A model is defined based on a data entity, and the model identifier can be the data entity's name, data entity number, or a unique value derived by processing the data entity's name or number. For ease of understanding, the following examples assume that the model identifier is the data entity's name.

[0166] Furthermore, when the API call request includes multiple model identifiers, the API call request may also include a relationship identifier for describing the model relationship. The relationship identifier may be a relationship name, such as belong to, reference, invoking, relate, assemble, and rely on.

[0167] To facilitate understanding, the following describes the at least one model identifier included in an API routing request using a specific example. In this example, the at least one model identifier included in an API routing request can be expressed as (Offering)<-[belong to]-(Release)<-[belong to]-(TestCase). The "Offering," "Release," and "TestCase" in parentheses are model identifiers, and the "belong to" in square brackets is a relationship identifier. The model identifiers and relationship identifiers in this example represent a routing path; specifically, a test case (TestCase) belongs to a Release version, and a Release version belongs to an Offering.

[0168] The API call request is generated according to a unified API call format. For example, when accessing an operating system that provides data services, the API call format includes API input parameters (i.e., API input parameters) and API output parameters (API output parameters). The API output parameters are the expected return values, and the API input parameters include at least one model identifier.

[0169] Considering that a model can have multiple instances, the starting model can have different starting model instances. The parameter values ​​of the API input parameters corresponding to different starting model instances can be different. Therefore, the unified format of API input parameters can also include the parameter values ​​of the starting parameters. See Figure 9The API input parameters can include the parameter values ​​of the starting parameters, such as pagesize (value is 100), pageNumber (value is 1), and at least one model identifier and relationship identifiers of different models, such as (Offering)<-[belong to]-(Release)<-[belong to]-(TestCase).

[0170] The at least one model identifier can be specifically determined by the access control system 100 based on at least one routing path generated by the starting model and the ending model. Specifically, the access control system 100 receives the starting model and the ending model input by the user through the first GUI, and then generates at least one routing path from the starting model to the ending model based on the model relationship graph. The at least one model identifier can be obtained based on the routing path.

[0171] In some implementations, the access control system 100 may present at least one routing path through a first GUI, and then receive user selection information of the at least one routing path through the GUI, and obtain at least one model identifier according to the selection information.

[0172] S1104: The access control system 100 determines the target API according to the model identifier and the mapping relationship between the model and the API.

[0173] Each model has model definition information, which includes a model identifier and model attributes. Based on the mapping relationship between models and APIs, the access control system 100 can match an API that matches the model identifier in the API call request, and then determine the target API from the APIs that match the model identifier.

[0174] Specifically, when the API call request includes a model identifier for a model, the access control system 100 can determine the target API based on the starting parameters and the API output parameters. When the routing path parameters included in the API call request include model identifiers for multiple models, the access control system 100 can determine multiple target APIs based on the starting parameters, the API output parameters, and the associations between the models.

[0175] For example, if the starting parameter is A, the parameter the user expects to be returned is C, and the routing path parameters include the identifiers of Model 1 and Model 2, then the access control system 100 determines an API based on the starting parameter A and the associated attributes of Model 1 and Model 2. This API uses the starting parameter A as an input parameter and the associated attributes of Model 1 and Model 2 as output parameters. Next, the access control system 100 uses the associated attributes of Model 1 and Model 2 as input parameters and the parameter the user expects to be returned as an output parameter to determine another API. In this way, the access control system 100 determines the target API based on the model identifier and the mapping relationship between the model and the API.

[0176] Among them, the mapping relationship between the model and the API can be received in advance by the access control system 100. In some implementations, the access control system 100 can obtain the API properties of the API in the operating system, such as the input and output parameters or operation types of the API. Specifically, the access control system 100 can read the API document through swagger to obtain the input and output parameters of the API. Among them, the input and output parameters of the API obtained by the access control system 100 can specifically be a JSON field structure. The access control system 100 then receives the correspondence between the model attributes and the API attributes through the third GUI, such as the correspondence between the model attributes and the input and output parameters of the API, thereby obtaining the mapping relationship between the model and the API. The mapping relationship can be manually configured by the information architect, or it can be obtained through machine learning.

[0177] The following example illustrates the manual configuration of a model-API mapping relationship by an information architect. In some implementations, access control system 100 can categorize model attributes into different types, specifically primary keys and foreign keys. A primary key is an attribute that uniquely identifies the model, while a foreign key is an attribute that does not. Access control system 100 can then establish a mapping relationship between the model and the API based on the primary and foreign keys, respectively.

[0178] In some implementations, the access control system 100 may also receive model definition information via a second GUI, where the model definition information includes at least a model identifier and model attributes. Furthermore, the access control system 100 may also receive model relationship information for different models via the second GUI. This model relationship information may be stored in the form of a model relationship graph. The model relationship graph may use models as nodes and model relationships as edges.

[0179] In some implementations, an operating system can be used to provide data services. For example, an operating system such as an attendance management system or a payroll management system can provide query services for attendance, payroll, and other data. Correspondingly, the target API is used to query target data. Based on this, after the access control system 100 determines the target API, it can also retrieve target data from the target operating system based on the target API. This target data includes the parameter values ​​of the target API's output parameters.

[0180] Furthermore, the API call request may include multiple model identifiers. Correspondingly, the access control system 100 can determine the parameter value of the input parameter of the i+1th API based on the parameter value of the output parameter of the i-th API in the target API, where i is a positive integer. Specifically, the API call request can also carry the parameter value of the starting parameter. The access control system 100 inputs the parameter value of the starting parameter into the first API in the target API to obtain the parameter value of the output parameter of the first API. Based on the parameter value of the output parameter of the first API, the parameter value of the input parameter of the second API can be obtained. Similarly, the access control system 100 can obtain the parameter value of the input parameter of the last API in the target API. The access control system 100 obtains target data from the target operating system based on the parameter value of the input parameter of the last API in the target API, and the target data includes the parameter value of the output parameter of the last API.

[0181] To facilitate understanding, a specific example is provided below for explanation.

[0182] The Release model has an attribute called OfferingName, which is a foreign key to the Name attribute of the Offering model (Name is also a primary key of Offering). The TestCase model has an attribute called ReleaseId, which is a foreign key to the primary key ID of the Release model.

[0183] The API call process for obtaining a TestCase based on an OfferingID is as follows:

[0184] 1) Pass in the ID parameter to call the API mapped by Offering to obtain the detailed information of the Offering. The returned information contains the Name attribute value of the Offering.

[0185] 2) Based on the Name attribute value of the Offering returned in the previous step, call the API mapped to the Release. The API input parameter is OfferingName and returns detailed information about the Release, including the Release ID.

[0186] 3) Based on the ID attribute value of the Release returned in the previous step, call the API mapped to the TestCase. The API input parameter is ReleaseId and returns detailed information about the TestCase.

[0187] In some implementations, the operating system can also be used to provide operation services. Accordingly, the target API is specifically used to perform the target operation. Based on this, the access control system 100 can also perform the target operation based on the target API. In other words, accessing the target operating system can involve obtaining target data in the target operating system or performing the target operation through the target API.

[0188] This example uses the target operating system as the alarm system and the target operation as the alarm operation. In this example, when the monitoring system detects that a certain indicator has reached a threshold, the alarm system can be accessed through the access control system and the alarm operation can be executed based on the target API in the alarm system.

[0189] Based on the above description, an embodiment of the present application provides an access control method for a job system. This method provides a unified routing API based on the mapping relationship between models and APIs, supporting the invocation of job system APIs based on the primary or foreign key of a model. This eliminates the need for the caller to define the input and output parameters of different APIs, improving the efficiency of API call coordination.

[0190] Furthermore, the method also implements path recommendation based on the starting model and the ending model. Based on this path, routing access across multiple operating systems can be achieved without writing different routing call codes according to different routing scenarios, reducing the workload of the caller and improving the access efficiency between systems.

[0191] Combined with the above Figures 1 to 11 The access control method for the target operating system provided in the embodiment of the present application is introduced in detail. The system and device provided in the embodiment of the present application will be introduced in conjunction with the accompanying drawings.

[0192] See also Figure 3 The access control system shown in FIG. 1 includes an API routing subsystem 120 . The API routing subsystem 120 includes:

[0193] The communication unit 122 is configured to receive an application programming interface (API) call request, wherein the API call request includes at least one model identifier;

[0194] The determination unit 124 is configured to determine a target API based on the model identifier and a mapping relationship between the model and the API of the operating system. The model is established based on the operating system and can be reused. The target API is used to access the target operating system.

[0195] The various units of the API routing subsystem 120 can be deployed on the same device, for example, in a cloud environment, an edge environment, or on an end device. In some possible implementations, the various units of the API routing subsystem 120 can also be deployed in a distributed manner on different devices, which is not limited in the embodiments of the present application.

[0196] In some possible implementations, the model is represented by the model identifier and model attributes, and the mapping relationship is represented by the model attributes and API attributes.

[0197] In some possible implementations, the API attributes include one or more of input parameters, output parameters, and operation types.

[0198] In some possible implementations, the operating system is used to provide data services, and the target API is used to query target data;

[0199] The API routing subsystem 120 may further include:

[0200] The routing unit 126 is configured to obtain the target data from the target operating system according to the target API, where the target data includes parameter values ​​of output parameters of the target API.

[0201] The routing unit 126 and the determining unit 124 may be deployed on the same device, or may be deployed in a distributed manner on different devices.

[0202] In some possible implementations, the API call request includes multiple model identifiers;

[0203] The routing unit 126 is specifically configured to:

[0204] Determine the parameter value of the input parameter of the (i+1)th API according to the parameter value of the output parameter of the (i)th API in the target API, where (i) is a positive integer;

[0205] According to the parameter value of the input parameter of the last API in the target API, target data is obtained from the target operating system, where the target data includes the parameter value of the output parameter of the last API.

[0206] In this way, the access control system 100 can achieve routed access to multiple operating system APIs through a single interface call. The operation caller does not need to connect to multiple operating systems to achieve routed access across operating systems, improving access efficiency and enhancing user experience.

[0207] In some possible implementations, the operating system is used to provide an operation service, and the target API is used to perform a target operation;

[0208] The API routing subsystem 120 also includes:

[0209] The routing unit 126 is configured to execute the target operation through the target operating system according to the target API.

[0210] In some possible implementations, the access control system 100 may further include a path recommendation subsystem 180, which is specifically used to recommend a routing path. The path recommendation subsystem 180 includes multiple units, as shown below:

[0211] The communication unit 182 is configured to receive a start model and an end model input by a user through a first graphical user interface GUI;

[0212] The recommendation unit 184 is configured to generate at least one routing path from the starting model to the ending model according to the model relationship graph.

[0213] Among them, the path recommendation subsystem 180 and the API routing subsystem 120 can be deployed on the same device or on different devices. In addition, the path recommendation subsystem 180 can also be merged with the API routing subsystem 120. In this way, the API routing subsystem 120 can include a communication unit, a determination unit, and a recommendation unit. In this case, the API routing subsystem 120 can be used not only to implement API routing, but also to implement path recommendation. Among them, when the API routing subsystem 120 and the path recommendation subsystem 180 are merged, the communication units of the two subsystems can be merged into one.

[0214] In some possible implementations, the route recommendation subsystem 180 may further include a generation unit 186 .

[0215] The communication unit 182 of the path recommendation subsystem 180 is further configured to receive, through the first GUI, selection information of the at least one routing path by the user;

[0216] The generating unit 186 is configured to generate the API call request according to the selection information.

[0217] The generation unit 186 and the recommendation unit 184 may be deployed on the same device or on different devices, which is not limited in this embodiment of the present application.

[0218] In some possible implementations, the access control system 100 may further include a model management subsystem 140. The model management subsystem 140 is specifically used to build a model. Building a model means defining a model. Specifically, the model management subsystem includes:

[0219] The communication unit 142 is configured to receive model definition information through the second GUI, where the model definition information at least includes the model identifier and the model attributes.

[0220] Specifically, the model management subsystem 140 may further include a storage unit 144 for storing the above-mentioned model definition information.

[0221] The model management subsystem 140 can be deployed on the same device as the API routing subsystem 120 and the path recommendation subsystem 180, or can be deployed in a distributed manner on different devices. When the model management subsystem 140 and the API routing subsystem 120 are deployed on the same device, the model management subsystem 140 and the API routing subsystem 120 can also be merged. Accordingly, the communication units of the multiple subsystems can be merged into one communication unit.

[0222] When model management subsystem 140 and route recommendation subsystem 180 are deployed on the same device, the first GUI and the second GUI can be GUIs presented by the same device, for example, they can be the same GUI. When model management subsystem 120 and route recommendation subsystem 180 are deployed on different devices, the first GUI and the second GUI can be GUIs presented by different devices, i.e., different GUIs.

[0223] In some possible implementations, different models may have associations. The model management subsystem 140 may also be used to maintain model relationships between different models. Specifically, the communication unit of the model management subsystem 140 is further used to receive model relationship information between different models via the second GUI. The model relationship information is stored in the form of a model relationship graph, where the models are nodes and the model relationships are edges.

[0224] In some possible implementations, the access control system 100 may further include an API mapping management subsystem 160. The API mapping management subsystem 160 is specifically used to establish a mapping relationship between the model and the API of the operating system. The API mapping management subsystem 160 includes:

[0225] The communication unit 162 is used to obtain API attributes of the API in the operating system;

[0226] The communication unit 162 is further configured to receive the correspondence between the model attributes and the API attributes through a third GUI, and obtain a mapping relationship between the model and the API of the operating system.

[0227] In some implementations, the API mapping management subsystem 160 further includes a display unit 164 for displaying model attributes and API attributes so that a user can connect a model attribute with its corresponding API attribute.

[0228] The API mapping management subsystem 160, API routing subsystem 120, path recommendation subsystem 180, and model management subsystem 140 can be deployed on the same device or distributed across different devices. The API mapping management subsystem 160 can also be merged with other subsystems, such as the API routing subsystem 120. Accordingly, the communication units of these subsystems can be merged into one communication unit.

[0229] The access control system 100 according to the embodiment of the present application may correspond to executing the method described in the embodiment of the present application, and the above and other operations and / or functions of each module / unit of the access control system 100 are respectively to achieve Figure 11 For the sake of brevity, the corresponding processes of the various methods in the illustrated embodiments are not described again here.

[0230] The embodiment of the present application also provides a computer cluster, which is used to implement the following Figure 3 The functions of the access control system 100 are shown. The computer cluster will be described in detail below with reference to the accompanying drawings.

[0231] Figure 12 A schematic diagram of the structure of a computer cluster 1200 is provided. The computer cluster 1200 includes:

[0232] At least one first computer device 1202, at least one second computer device 1204, at least one third computer device 1206, and at least one second computer device 1208, each computer device including a processor and a memory. First computer device 1202 is used to implement the functions of API routing subsystem 120, second computer device 1204 is used to implement the functions of model management subsystem 140, third computer device 1206 is used to implement the functions of API mapping management subsystem 160, and fourth computer device is used to implement the functions of path recommendation subsystem 180.

[0233] Figure 12 The example description is given by assuming that each subsystem of the access control system 100 is deployed on different computer devices. In some implementations, any two or more subsystems of the access control system 100 can be deployed on the same computer device, which is not limited in the present embodiment.

[0234] Through the above description of the embodiments, those skilled in the art will clearly understand that the present application can be implemented by means of software plus necessary general-purpose hardware, and of course can also be implemented by means of dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. In general, any function performed by a computer program can be easily implemented by the corresponding hardware. Moreover, the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits, or dedicated circuits.

[0235] However, for this application, software program implementation is a better implementation method in most cases. Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk or optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, training device, or network device, etc.) to execute the methods described in each embodiment of this application.

[0236] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0237] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, they generate, in whole or in part, the processes or functions described in the embodiments of the present application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0238] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that can be stored by a computer or a data storage device such as a training device or data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

Claims

1. A method for controlling access to a target operating system, characterized in that: The method comprises: receiving an application programming interface (API) call request, the API call request including a plurality of model identifiers, the plurality of model identifiers corresponding to a plurality of operating systems, the number of the model identifiers being greater than or equal to the number of the operating systems; Determining a target API based on the model identifier and a mapping relationship between the model and an API of the operating system, wherein the model is established based on data entities and attributes of the data entities in the operating system and is reusable, the model is represented by the model identifier and model attributes, the mapping relationship is represented by the model attributes and API attributes, and the target API is used to access the target operating system; A plurality of associated target APIs are determined based on the association relationships between different models, and the plurality of associated target APIs are used to implement routing access to APIs of a plurality of operating systems.

2. The method according to claim 1, characterized in that The API attributes include one or more of input parameters, output parameters, and operation types.

3. The method according to claim 1 or 2, characterized in that The operating system is used to provide data services, and the target API is used to query target data; The method further comprises: The target data is obtained from the target operating system according to the target API, where the target data includes parameter values ​​of output parameters of the target API.

4. The method according to claim 3, characterized in that The API call request also carries a parameter value of a start parameter. Acquiring the target data from the target operating system according to the target API includes: Inputting the parameter value of the starting parameter into a first API among the multiple associated target APIs to obtain the parameter value of the output parameter of the first API; Determine the parameter value of the input parameter of the (i+1)th API according to the parameter value of the output parameter of the (i)th API in the target API, where (i) is a positive integer; Target data is obtained from the target operating system according to the parameter value of the input parameter of the last API in the target API.

5. The method according to claim 1 or 2, characterized in that The operating system is used to provide operation services, and the target API is used to execute target operations; The method further comprises: According to the target API, the target operation is performed.

6. The method according to claim 1 or 2, characterized in that The method further comprises: receiving a starting model and an ending model input by a user via a first graphical user interface (GUI); At least one routing path from the starting model to the ending model is generated according to the model relationship graph.

7. The method according to claim 6, characterized in that The method further comprises: receiving, through a first GUI, selection information of the at least one routing path by the user; The API call request is generated according to the selection information.

8. The method according to claim 1 or 2, characterized in that The method further comprises: Model definition information is received through the second GUI, where the model definition information at least includes the model identifier and the model attributes.

9. The method according to claim 8, characterized in that The method further comprises: Model relationship information of different models is received through the second GUI, and the model relationship information is stored in the form of a model relationship graph. The model relationship graph uses models as nodes and model relationships as edges.

10. The method according to claim 1 or 2, characterized in that Before receiving the API call request, the method further includes: Obtaining API attributes of the API in the operating system; The corresponding relationship between the model attributes and the API attributes is received through the third GUI, and the mapping relationship between the model and the API of the operating system is obtained.

11. An access control system for a target operating system, characterized in that: The system comprises: a communication unit, configured to receive an application programming interface (API) call request, the API call request including a plurality of model identifiers, the plurality of model identifiers corresponding to a plurality of operating systems, the number of the model identifiers being greater than or equal to the number of the operating systems; a determining unit, configured to determine a target API based on the model identifier and a mapping relationship between a model and an API of the operating system, wherein the model is established based on data entities and attributes of the data entities in the operating system and is reusable, the model is represented by the model identifier and model attributes, the mapping relationship is represented by the model attributes and API attributes, and the target API is used to access the target operating system; The determining unit is further configured to determine a plurality of associated target APIs based on the association relationships between different models, wherein the plurality of associated target APIs are used to implement routing access to APIs of a plurality of operating systems.

12. A computer cluster, characterized in that: The computer cluster includes at least one computer device, and the at least one computer device includes a processor and a memory; The processor is configured to execute instructions stored in the memory, so that the computer cluster performs the method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that The method comprises instructions for instructing a computer cluster to execute the method according to any one of claims 1 to 10.

Images