Service calling method and device based on operation workbench

Abstract

The invention discloses a service calling method and device based on an operation workbench, which can be used in the financial field or other technical fields, and the service calling method based on the operation workbench comprises the following steps: registering a unified calling service interface to a service registration center; receiving a request parameter sent by the mobile terminal through the unified calling service interface; according to the request parameter, judging whether a service requested to be called by the mobile terminal is in a white list or not; when the service requested to be called by the mobile terminal is in the white list, judging whether the identity of the mobile terminal is legal or not and whether the mobile terminal has calling permission or not; when the identity of the mobile terminal is legal and has the calling permission, splicing a network link according to the request parameter and the attribute of the white list; otherwise, returning calling failure information to the mobile terminal; and according to the network link, remotely calling a corresponding service through a gateway. According to the method, the development workload can be reduced, and the flexibility and convenience of an internal operation workbench of an enterprise are improved.

Description

Technical Field

[0001] This invention relates to the field of computer service invocation technology, and can also be used in the financial field, particularly to a service invocation method and apparatus based on an operations workbench. Background Technology

[0002] The services currently available on the enterprise's internal LAN (internal network) operations platform are not exposed to the outside world. Directly accessing these services from external mobile devices poses security risks, such as URL exposure, access control issues, and data leaks. Furthermore, only a small number of existing operations platform services are accessible from external mobile devices. Transforming every required operational platform service into one accessible from external mobile devices would require a massive amount of development and modification, and would also hinder subsequent service maintenance. Summary of the Invention

[0003] This invention provides a service invocation method based on an operations workbench, which reduces development workload and improves the flexibility and convenience of the enterprise's internal operations workbench.

[0004] This invention provides a service invocation method based on an operations workbench, comprising:

[0005] Register the unified call service interface to the service registry center;

[0006] Receive request parameters sent by the mobile terminal through the unified call service interface;

[0007] Based on the request parameters, determine whether the service requested by the mobile device is in the whitelist;

[0008] If the service requested by the mobile device is in the whitelist, the system checks whether the mobile device is legitimate and has the necessary permissions; otherwise, it returns a call failure message to the mobile device.

[0009] If the mobile device's identity is valid and it has the necessary permissions, a network link is constructed based on the request parameters and the attributes of the whitelist; otherwise, a call failure message is returned to the mobile device.

[0010] Based on the network link, the corresponding service is remotely invoked through the gateway, and the invocation result is returned to the mobile device.

[0011] In one embodiment, concatenating network links based on the request parameters and the attributes of the whitelist includes:

[0012] Based on the service number in the request parameters, obtain the key network link information corresponding to the service number in the whitelist;

[0013] The first network link is obtained by concatenating the request path in the key information with the non-key information of the network link corresponding to the service number in the configuration file.

[0014] In one embodiment, when a preset symbol exists in the first network link, a regular expression is used to replace the preset symbol and its included preset fields with the values ​​of the corresponding preset fields in the request parameters to obtain the second network link.

[0015] In one embodiment, when there is no preset symbol in the first network link and when the request type in the key information is the first request type, the first parameter in the request parameters is appended to the first network link to obtain the third network link.

[0016] In one embodiment, remotely invoking the corresponding service via the gateway based on the network link includes:

[0017] When a preset symbol exists in the first network link, the corresponding service is remotely invoked through the gateway according to the second network link;

[0018] When there is no preset symbol in the first network link, and when the request type in the key information is the first request type, the corresponding service is remotely invoked through the gateway according to the third network link;

[0019] When there is no preset symbol in the first network link, and when the request type in the key information is the second request type, the corresponding service is remotely invoked through the gateway according to the first network link.

[0020] In one embodiment, the whitelist is stored in a database as an editable data table.

[0021] In one embodiment, the data table includes a service number, a service name, and key network link information corresponding to the service number.

[0022] In one embodiment, determining whether the service requested by the mobile device is in the whitelist based on the request parameters includes:

[0023] The service number in the request parameters is used to search the whitelist for a matching service number.

[0024] In one embodiment, the key information of the network link corresponding to the service number includes the request type and request path, while the non-key information of the network link corresponding to the service number is stored in an editable configuration file.

[0025] In one embodiment, returning the call result to the mobile device includes:

[0026] When the corresponding service is called remotely through the gateway and works normally, the call success information and service result will be returned to the mobile device.

[0027] If the corresponding service is not functioning properly when remotely called through the gateway, a call failure message will be returned to the mobile device.

[0028] In one embodiment, the system first verifies whether the service requested by the mobile device is in the whitelist, and then verifies whether the mobile device's identity is legitimate and whether it has the permission to call the service; or, it first verifies whether the mobile device's identity is legitimate and whether it has the permission to call the service, and then verifies whether the service requested by the mobile device is in the whitelist.

[0029] This invention also provides a service invocation device based on an operations workbench, comprising:

[0030] The registration module is used to register the unified call service interface with the service registry center;

[0031] The receiving module is used to receive request parameters sent by the mobile terminal through the unified call service interface;

[0032] The first judgment module is used to determine whether the service requested by the mobile terminal is in the whitelist based on the request parameters.

[0033] The second judgment module is used to determine whether the mobile terminal's identity is legitimate and whether it has the right to call the service when the service requested by the mobile terminal is in the whitelist; otherwise, it returns an error message to the mobile terminal.

[0034] The third judgment module is used to construct a network link based on the request parameters and the attributes of the whitelist if the mobile terminal's identity is legitimate and it has calling permissions; otherwise, it returns an error message to the mobile terminal.

[0035] The calling module is used to remotely call the corresponding service through the gateway based on the network link and return the result to the mobile terminal.

[0036] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-described service invocation methods based on an operations workbench.

[0037] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the above-described service invocation methods based on an operations workbench.

[0038] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements any of the above-described service invocation methods based on an operations workbench.

[0039] This invention provides a service invocation method and apparatus based on an operations workbench. The invention uses a unified service invocation interface to enable external mobile terminals to call services on the internal operations workbench, reducing development workload; it uses a whitelist mechanism to achieve service maintenance and management, improving the flexibility and convenience of the enterprise's internal operations workbench; and it uses an identity authentication mechanism to improve security. Attached Figure Description

[0040] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0041] Figure 1 This is a schematic diagram illustrating the principle of a service invocation method based on an operation workbench according to an embodiment of the present invention.

[0042] Figure 2 A flowchart illustrating a service invocation method based on an operation workbench according to an embodiment of the present invention;

[0043] Figure 3 A flowchart of a service invocation method based on an operation workbench provided in another embodiment of the present invention;

[0044] Figure 4 This is a schematic diagram of a service invocation device based on an operation workbench according to an embodiment of the present invention;

[0045] Figure 5 This is a schematic diagram of the physical structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0047] The information collected in the technical solution of this invention is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of related data all comply with relevant standards, necessary confidentiality measures are taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse.

[0048] The acquisition, transmission, storage, use, and processing of data in the technical solution of this invention all comply with relevant regulations.

[0049] It should be noted that in the embodiments of the present invention, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of the present invention. However, they do not mean that the applicant has used or necessarily used the solution.

[0050] Currently, the internal network operations workbench services within enterprises are not publicly accessible and do not expose interfaces to the external network. External mobile devices cannot directly call internal network services to access these services; they typically need to use the company-wide unified outbound call framework, "P4 Service." However, most services on the current operations workbench lack P4 services. Therefore, it is necessary to design corresponding P4 services within the operations workbench to enable mobile devices to call services within the operations workbench.

[0051] like Figure 1 The diagram illustrates the principle of a service invocation method based on an operation workbench according to an embodiment of the present invention. Figure 1 shows the operation workbench registering the service interface with the P4 service registry. Figure 2 shows a user sending a use case name to the P4 service registry via an external mobile terminal to request access to the corresponding service. Figure 3 shows the P4 service registry returning the service information to the mobile terminal. Figure 4 shows the mobile terminal sending a request to the operation workbench using this service information to request access to the corresponding service. When a user invokes a service on the internal operation workbench via an external mobile terminal, the operation workbench first verifies whether the service invoked by the user is on the whitelist, whether the user's identity is legitimate, and whether they have the necessary permissions. If the operation workbench verifies that the service invoked via the external mobile terminal is on the whitelist, the user's identity is legitimate, and they have the necessary permissions, then the operation workbench allows the service invocation; otherwise, the operation workbench refuses the user's access to the service.

[0052] It's worth noting that the Operations Workbench can be understood as a platform within an enterprise's internal LAN (internal network). This platform aggregates many service interfaces, such as YYGZT001, YYGZT002, ..., YYGZT103, etc., where YYGZT001, YYGZT002, ..., YYGZT103 are the corresponding service names. However, because it's within the internal network, mobile devices on the external network cannot directly access the YYGZT001, YYGZT002, ..., YYGZT103 interfaces within the Operations Workbench. The P4 Service Framework can be understood as a service registry, and services registered in the service registry can be accessed from the external network. Therefore, mobile devices on the external network can access the P4YYGZT001, P4YYGZT002, ..., P4YYGZT103 interfaces of the Operations Workbench that have been registered with the P4 Service Registry through the P4 Service Framework.

[0053] Existing technology requires each of the P4YYGZT001, P4YYGZT002, ..., P4YYGZT103 interfaces of the operation workbench to be registered with the P4 service registry. This necessitates designing corresponding P4 services for each of these interfaces. Then, when a user accesses the YYGZT001 service via their mobile device, they call the P4YYGZT001 interface; to access the YYGZT002 service, they call the P4YYGZT002 interface; ...; and to access the YYGZT103 service, they call the P4YYGZT103 interface. This design approach involves a lot of repetitive work and is not very flexible. If it is necessary to call other operations workbench services, such as the YYGZT104 service, a new P4YYGZT104 interface needs to be developed, which will obviously increase the workload and make subsequent maintenance very troublesome.

[0054] like Figure 2 The diagram shows a flowchart of a service invocation method based on an operations workbench according to an embodiment of the present invention. One embodiment of the present invention provides a service invocation method based on an operations workbench, the service invocation method based on an operations workbench including:

[0055] S21. Register the unified call service interface to the service registry center.

[0056] S22. Receive request parameters sent by the mobile terminal through the unified call service interface.

[0057] S23. Based on the request parameters, determine whether the service requested by the mobile terminal is in the whitelist.

[0058] S24. If the service requested by the mobile device is in the whitelist, determine whether the mobile device's identity is legitimate and whether it has the permission to call; otherwise, return a call failure message to the mobile device.

[0059] S25. If the mobile device's identity is valid and it has the authority to make calls, then a network link is constructed based on the request parameters and the attributes of the whitelist; otherwise, a call failure message is returned to the mobile device.

[0060] S26. Based on the network link, remotely call the corresponding service through the gateway and return the call result to the mobile terminal.

[0061] Specifically, mobile devices cannot remotely access services deployed on the internal network environment of the operations workbench via the external network. They need to access multiple services on the operations workbench through a specific service call (such as P4TYDY001). This invention designs a unified service call interface, similar to a switch, based on the P4 service framework standard. This allows mobile devices on the external network to uniformly call any service from a specified service list on the operations workbench through this unified service call interface. Furthermore, the specified service list can be maintained and managed online through a whitelist. This is the unified service call mechanism for mobile devices on the operations workbench based on the P4 service framework. The unified call interface is designed so that different operations workbench services can be accessed by passing different parameters. This invention first requires the enterprise's internal LAN (internal network) operations workbench to register the unified call service interface with the service registry center. The operations workbench receives the request parameter `method_code` sent by an external mobile terminal through the unified call service interface. Here, the `method_code` parameter represents the specific operations workbench service to be accessed. For example, if `method_code = "TEST_XZD_001"`, it represents a GET request to access the operations workbench at the URL `http: / / ip:8000 / xzd / test / getInfo`. The corresponding request parameters for the GET request at the URL `http: / / ip:8000 / xzd / test / getInfo` can be placed in the `json_data` field, which can be set to `{'id': '38884888'}`. After preprocessing, the complete access address `http: / / ip:8000 / xzd / test / getInfo?id=38884888` will be obtained. Then, an HTTP request can be sent via Java to obtain the call result. Furthermore, this invention also incorporates a whitelist mechanism and an identity authentication mechanism. Specifically, the operations workbench needs to determine whether the service requested by the mobile terminal is in the whitelist based on the request parameter `method_code`. If the service requested by the mobile terminal is in the whitelist, it checks whether the mobile terminal's identity is legitimate and whether it has the necessary permissions to call the service; otherwise, it returns a call failure message to the mobile terminal. If the mobile terminal's identity is legitimate and it has the necessary permissions, it constructs a network link based on the request parameter and the attributes of the whitelist; otherwise, it returns a call failure message to the mobile terminal. Finally, the operations workbench uses the network link to remotely call the corresponding service through the gateway and returns the call result to the mobile terminal. This invention uses a unified service call interface to enable external mobile terminals to call services on the internal operations workbench, reducing development workload; it uses a whitelist mechanism to manage and maintain services, improving the flexibility and convenience of the enterprise's internal operations workbench; and it uses an identity authentication mechanism to enhance security.

[0062] In one embodiment, the operation workbench first needs to register the P4TYDY001 unified call interface with the P4 service registry center. Then, external mobile devices can access services such as YYGZT001, YYGZT002, ..., YYGZT103 through the P4TYDY001 unified call interface. The mobile device obtains relevant information about the P4TYDY001 service, such as IP address and network address, by accessing the P4 service registry center. By using the obtained relevant information about the P4TYDY001 service (the access address of the operation workbench in the P4 registry center is http: / / 10.10.10.1:8000 / http), and passing in the service ID: P4TYDY001, the mobile device can access the P4TYDY001 service of the operation workbench, thereby enabling the mobile device to call other services of the operation workbench through the P4TYDY001 service.

[0063] In one embodiment, concatenating network links based on the request parameters and the attributes of the whitelist includes: obtaining key information of network links corresponding to the service number in the whitelist based on the service number in the request parameters; and concatenating the request path in the key information with the non-key information of the network links corresponding to the service number in the configuration file to obtain a first network link.

[0064] Specifically, after receiving the request parameters sent by the mobile terminal through the unified service call interface, the operations workbench retrieves whitelist list data by calling the database query interface. Based on the service number in the request parameters, it obtains the network link key information corresponding to the service number in the whitelist list data. Then, it concatenates the request path in the key information with the non-key information of the network link corresponding to the service number in the configuration file to obtain the first network link. For example, first, based on the request parameters, it obtains the network link key information url_desc corresponding to the service number in the whitelist list data of the requested service. The url_desc field is separated by commas to obtain the request type and request path. For example, url_desc = "get, xzd / test / getInfo", after being separated by commas, it obtains two fields: request type httpMethod = "get" and request path urlSuffix = "zd / test / getInfo". Then, using the non-critical information of the network link corresponding to the service number in the configuration file, namely the configured urlPrefix="http: / / ip:8000 / ", it is concatenated with urlSuffix="xzd / test / getInfo" to obtain the first network link urlTemp="http: / / ip:8000 / xzd / test / getInfo".

[0065] In one embodiment, when a preset symbol exists in the first network link, a regular expression is used to replace the preset symbol and its included preset fields with the values ​​of the corresponding preset fields in the request parameters to obtain the second network link.

[0066] Specifically, when the url_desc key information of the network link corresponding to the service number in the whitelist list data contains unconventional preset symbols such as "{}", for example, url_desc = "get, xzd / test / getInfo / {id}", the first network link is urlTemp = "http: / / ip:8000 / xzd / test / getInfo / {id}". In this case, the regular expression "\{(.*?)\}" is used to match cases containing "{" and "}", and the id value 38884888 from the json_data in the request parameter "{id=38884888}" is used to replace "{id}" in urlTemp = "http: / / ip:8000 / xzd / test / getInfo / {id}", resulting in the second network link url = "http: / / ip:8000 / xzd / test / getInfo / 38884888". Regular expressions allow for flexible configuration of more network link URLs, improving the applicability of the unified API call.

[0067] In one embodiment, when there is no preset symbol in the first network link and when the request type in the key information is the first request type, the first parameter in the request parameters is appended to the first network link to obtain the third network link.

[0068] Specifically, when the first network link does not contain a preset symbol, and the request type `httpMethod` in the key information is a GET request, the `id=38884888` from the request parameter `json_data: "{id=38884888}"` is appended to the end of the first network link to obtain the third network link `url="http: / / ip:8000 / xzd / test / getInfo?id=38884888"`. It is worth noting that when the first network link does not contain a preset symbol, and the request type `httpMethod` in the key information is a POST request, `url=urlTemp="http: / / ip:8000 / xzd / test / updateInfo"`, the request parameter `json_data: "{id=38884888}"` can be directly constructed into the `httpEntity` of the POST request's HTTP request parameter body, and then the HTTP request can be called using a POST request.

[0069] In one embodiment, the step of remotely invoking the corresponding service through the gateway based on the network link includes: when a preset symbol exists in the first network link, remotely invoking the corresponding service through the gateway based on the second network link; when the preset symbol does not exist in the first network link, and when the request type in the key information is a first request type, remotely invoking the corresponding service through the gateway based on the third network link; when the preset symbol does not exist in the first network link, and when the request type in the key information is a second request type, remotely invoking the corresponding service through the gateway based on the first network link.

[0070] Specifically, when the first network link contains unconventional preset symbols such as "{}", the corresponding service is remotely invoked through the gateway according to the second network link url = "http: / / ip:8000 / xzd / test / getInfo / 38884888". When the first network link does not contain unconventional preset symbols such as "{}", and the request type in the key information is a first request type (GET request), the corresponding service is remotely invoked through the gateway according to the third network link url = "http: / / ip:8000 / xzd / test / getInfo?id=38884888". When the first network link does not contain unconventional preset symbols such as "{}", and the request type in the key information is a second request type (POST request), the corresponding service can be remotely invoked through the gateway according to the first network link url = urlTemp = "http: / / ip:8000 / xzd / test / updateInfo". This invention designs different network links to invoke corresponding services for different situations, thus improving the applicability of this invention.

[0071] In one embodiment, the whitelist is stored in a database as an editable data table.

[0072] Specifically, storing the whitelist in the database as an editable data table enables online maintenance and management of the operations platform, reducing development workload and improving the flexibility and convenience of the enterprise's internal operations platform.

[0073] In one embodiment, the data table includes a service number, a service name, and key network link information corresponding to the service number.

[0074] Specifically, the data table created by this invention mainly has four fields: id (primary key), method_code (service number), method_name (service name), and url_desc (key network link information corresponding to the service number).

[0075] Table 1 shows a whitelist data table structure design table provided by an embodiment of the present invention.

[0076] Table 1

[0077] field name type length Not null key Notes id int 11 √ Primary key Primary key, automatically generated by the system. method_code varchar 64 √ Method number method_name varchar 64 Method Name url_desc varchar 1024 √ URL calling methods and URL values

[0078] The id represents the primary key. As the primary key of the data table, it can be automatically generated by the system, i.e., generated in an auto-incrementing mode.

[0079] `method_code` represents the service ID (method ID), used to distinguish the services of the operations workbench on external mobile devices. One method ID corresponds to one service in the operations workbench. This parameter is required when a mobile device calls the unified service interface to identify the specific operations workbench service that the mobile device needs to access. The service ID should not be directly related to the actual network URL of the service or the meaning of the service content to protect the anonymity and security of the operations workbench services.

[0080] Table 2 shows a whitelist data table provided in an embodiment of the present invention.

[0081] Table 2

[0082] id method_code method_name url_desc 1 TSET_XZD_001 Test Link 1 get,xzd / test / getInfo 2 TSET_XZD_002 Test Link 1 post,xzd / test / updateInfo 3 TSET_XZD_003 Test Link 1 post,mall / test / addInfo

[0083] In the whitelist data table of this invention, the method_code represents the service to be requested. For example, when method_code = "TEST_XZD_001", it represents a GET request to access the operation workbench with the URL xzd / test / getInfo. In this way, the actual meaning of the exposed method_code cannot be guessed.

[0084] method_name represents the service name (method name), used to describe the name or meaning of the service so that the backend administrator knows the meaning of this service.

[0085] `url_desc` represents key information about the network link corresponding to the service number. It describes crucial information related to the network link URL and is a key element of this database table design. It records information related to the network link URL of the operation workbench service accessed by `method_code`, such as the service request type and request path.

[0086] In one embodiment, determining whether the service requested by the mobile terminal is in the whitelist based on the request parameters includes: searching the whitelist for a matching service number based on the service number in the request parameters.

[0087] Specifically, this invention verifies whether the called service is in a whitelist table by using the service ID in the `method` field of the request parameters. If a matching service ID exists in the whitelist table, the service requested by the mobile device is considered to be in the whitelist; otherwise, a call failure message is returned to the mobile device. By establishing a whitelist, this invention ensures that services in the whitelist will pass verification, while others will fail, thus improving the security, flexibility, and convenience of the operations workbench. Using service IDs facilitates searching and enhances the concealment and security of services on the operations workbench.

[0088] In one embodiment, the key information of the network link corresponding to the service number includes the request type and request path, while the non-key information of the network link corresponding to the service number is stored in an editable configuration file.

[0089] Specifically, the whitelist data table of this invention only stores the suffixes of the network links for each service. The prefixes of the network links for each service are set as configuration items in the configuration file for flexible configuration. For example, in Table 2, url_desc = "get, xzd / test / getInfo", while the prefix of the complete URL is configured in the configuration file. For example, if the prefix urlPrefix = "http: / / ip:8000 / ", it needs to be processed so that the GET request URL is http: / / ip:8000 / xzd / test / getInfo?id = 38884888 in order to perform a normal HTTP call using Java. Storing only critical information in the data table helps reduce storage space usage, and configuring non-critical information through the configuration file improves work efficiency.

[0090] In one embodiment, returning the call result to the mobile device includes: when the corresponding service is called remotely through the gateway and works normally, returning the call success information and service result to the mobile device; when the corresponding service is called remotely through the gateway and does not work normally, returning the call failure information to the mobile device.

[0091] Specifically, because the called service may malfunction, the operations workbench needs to determine whether the called service is functioning correctly in order to reduce unnecessary information interaction and improve work efficiency. If the operations workbench remotely calls the corresponding service through the gateway and it functions correctly, it returns a success message and service result to the mobile device. This can be further processed by uniformly packaging the success message from the unified API call and the obtained service result together before sending them to the mobile device, improving data transmission efficiency. Otherwise, it returns a failure message to the mobile device. In this case, it can also return information about the malfunctioning service to the operations and maintenance system for timely maintenance and handling.

[0092] In one embodiment, the system first verifies whether the service requested by the mobile device is in the whitelist, and then verifies whether the mobile device's identity is legitimate and whether it has the permission to call the service; or, it first verifies whether the mobile device's identity is legitimate and whether it has the permission to call the service, and then verifies whether the service requested by the mobile device is in the whitelist.

[0093] Specifically, this invention can, according to actual needs, first verify whether the service requested by the mobile terminal is in the whitelist, and then verify whether the mobile terminal's identity is legitimate and whether it has the calling permission; or, first verify whether the mobile terminal's identity is legitimate and whether it has the calling permission, and then verify whether the service requested by the mobile terminal is in the whitelist. To improve work efficiency or reduce workload, when the workload of verifying whether the mobile terminal's identity is legitimate and whether it has the calling permission is greater, the configuration is set to first verify whether the service requested by the mobile terminal is in the whitelist, and then verify whether the mobile terminal's identity is legitimate and whether it has the calling permission; when the workload of verifying whether the service requested by the mobile terminal is in the whitelist is greater, the configuration is set to first verify whether the mobile terminal's identity is legitimate and whether it has the calling permission, and then verify whether the service requested by the mobile terminal is in the whitelist.

[0094] In another embodiment, the service invocation method based on the operation workbench of the present invention includes the following steps.

[0095] Step 1: When a mobile device calls the Operations Workbench service, the mobile device first accesses the P4 service registry center based on the P4 service code (P4TYDY001).

[0096] Step 2: The P4 service registration center uses the P4 service code (P4TYDY001) to locate the address and sends the call address of the P4 service code (P4TYDY001) to the mobile terminal.

[0097] Step 3: The mobile device accesses the unified call service of the operation workbench based on the call address of the P4 service code (P4TYDY001).

[0098] Step 4: Start the unified call service on the operation workbench.

[0099] Step 5: Obtain the token value from the mobile request parameters, verify that the token value is the correct user login token, and verify the user's identity.

[0100] Step 6: Verify whether the method name (method_code) of the transfer service in the request parameters is correct. If the method_code is empty, return a call failure message to the mobile device.

[0101] Step 7: Query the service whitelist. Each line of data in the service whitelist represents a service in the operations workbench. Only services that are in the service whitelist can be accessed normally.

[0102] Step 8: Verify the request parameter `method_code`. Check if the service to be transferred to the operations workbench is in the service whitelist. Each line in the service whitelist represents a service in the operations workbench. Only services in the service whitelist can be accessed normally. If `method_code` is `TEST_XZD_101`, and the service whitelist does not contain a value with `method_code` of `TEST_XZD_101`, a call failure message will be returned to the mobile device.

[0103] Step 9: If the request parameter method_code is verified, the corresponding url_desc can be obtained from the service whitelist based on the value of the request parameter method_code, and the HTTP request method of the transfer service can be obtained, such as GET request or POST request, as well as the suffix of the HTTP request URL, such as xzd / test / getInfo.

[0104] Step 10: Process the URL prefix and suffix of the forwarding service, as well as the request parameters of the forwarding service. This step yields the final HTTP request URL value of the forwarding service and the format of the HTTP request parameter body. For example, the URL of the GET request for the forwarding service is http: / / ip:8000 / xzd / test / getInfo?id=38884888; and this HTTP request can be called through a Java microservice.

[0105] Step 11: Enter the internal processing flow of the transfer service and return the result of the transfer service to the mobile device.

[0106] Step 12: Encapsulate the results of the unified call service of the operation workbench, such as whether the call to the unified call service failed or succeeded, whether the call to the transfer service failed or succeeded, and encapsulate the result data obtained from the transfer service.

[0107] Step 13: The unified call service of the operation workbench returns the encapsulated result to the mobile terminal.

[0108] This invention first requires the mobile client to send service call request parameters to the P4 service registry. The P4 service registry returns service-related information to the mobile client based on the request parameters. Then, the mobile client requests the service from the operations workbench based on the service-related information. Subsequently, the operations workbench initiates a unified service call process for the mobile client. The mobile client uniformly calls the service to verify whether the caller meets the security requirements based on the service-related information. If not, a call failure message is returned to the mobile client, and the call ends. If the caller meets the requirements, the call parameters are verified to be normal. If the call parameters are abnormal, a call failure message is returned to the mobile client, and the call ends. If the call parameters are normal, a service whitelist is obtained. Only services maintained in the service whitelist can be accessed by the mobile client. The system checks whether the service being called is in the whitelist. If not, it returns a call failure message to the mobile device and terminates the call. If it is in the whitelist, it retrieves the request path and HTTP call method of the service on the operations workbench, concatenates them into a network link, and then initiates a remote call request to access other services on the operations workbench, such as YYGZT001, YYGZT002, ..., YYGZT103, etc. The system returns the call result to the mobile device and terminates the call.

[0109] like Figure 3 The diagram shows a flowchart of a service invocation method based on an operations workbench according to another embodiment of the present invention. In one embodiment, after the operations workbench receives request parameters sent by the mobile terminal through the unified service invocation interface, S31 obtains whitelist list data by invoking the database query interface. S32 determines whether the method value in the request parameters is in the whitelist; if not, the invocation ends; if it is, S33 determines whether identity authentication is successful. If identity authentication is successful, S34 reassembles the corresponding service network link URL in the whitelist and the request parameters to obtain the final network link. Based on the final network link, S35 the service is invoked through the gateway. S36 the invocation ends after returning the transfer result.

[0110] This invention enables external mobile users to access internal network operation workbench services through a unified calling interface, reducing development and maintenance workload. It maintains and manages services through a whitelist mechanism, providing mobile users with access to any one or more operation workbench services without requiring additional interface development for each service, thus improving the flexibility and convenience of the enterprise's internal operation workbench. Furthermore, the whitelist mechanism allows for the disabling or switching of specific services, facilitating subsequent maintenance and improving service call efficiency.

[0111] This invention also provides a service invocation device based on an operations workbench, as described in the following embodiments. Since the principle by which the service invocation device based on an operations workbench solves the problem is similar to the aforementioned service invocation method based on an operations workbench, the implementation of the service invocation device based on an operations workbench can refer to the implementation of the aforementioned service invocation method based on an operations workbench; repeated details will not be elaborated further.

[0112] like Figure 4 The diagram shows a service invocation device based on an operation workbench according to an embodiment of the present invention. The present invention also provides a service invocation device based on an operation workbench, which includes a registration module 41, a receiving module 42, a first judgment module 43, a second judgment module 44, a third judgment module 45, and an invocation module 46.

[0113] The registration module 41 is used to register the unified call service interface to the service registry center.

[0114] The receiving module 42 is used to receive request parameters sent by the mobile terminal through the unified call service interface.

[0115] The first judgment module 43 is used to determine whether the service requested by the mobile terminal is in the whitelist based on the request parameters.

[0116] The second judgment module 44 is used to determine whether the mobile terminal's identity is legitimate and whether it has the right to call the service when the service requested by the mobile terminal is in the whitelist; otherwise, it returns an error message to the mobile terminal.

[0117] The third judgment module 45 is used to construct a network link based on the request parameters and the attributes of the whitelist if the mobile terminal's identity is legitimate and it has calling permissions; otherwise, it returns an error message to the mobile terminal.

[0118] The calling module 46 is used to remotely call the corresponding service through the gateway based on the network link and return the result to the mobile terminal.

[0119] This invention first requires the enterprise's internal LAN (internal network) operations platform to register the unified service call interface with the service registry center. Then, the operations platform receives request parameters sent by an external mobile terminal through the unified service call interface and determines whether the service requested by the mobile terminal is in the whitelist. If the service requested by the mobile terminal is in the whitelist, it determines whether the mobile terminal's identity is legitimate and whether it has the necessary calling permissions; otherwise, it returns a call failure message to the mobile terminal. If the mobile terminal's identity is legitimate and it has the necessary calling permissions, it constructs a network link based on the request parameters and the attributes of the whitelist; otherwise, it returns a call failure message to the mobile terminal. Finally, the operations platform remotely calls the corresponding service through the gateway based on the network link and returns the call result to the mobile terminal. This invention enables external mobile users to access internal network operation workbench services through a unified calling interface, reducing development and maintenance workload. It maintains and manages services through a whitelist mechanism, providing mobile users with access to any one or more operation workbench services without requiring additional interface development for each service, thus improving the flexibility and convenience of the enterprise's internal operation workbench. Furthermore, the whitelist mechanism allows for the disabling or switching of specific services, facilitating subsequent maintenance and improving service call efficiency.

[0120] In one embodiment, concatenating network links based on the request parameters and the attributes of the whitelist includes: obtaining key information of network links corresponding to the service number in the whitelist based on the service number in the request parameters; and concatenating the request path in the key information with the non-key information of the network links corresponding to the service number in the configuration file to obtain a first network link.

[0121] In one embodiment, when a preset symbol exists in the first network link, a regular expression is used to replace the preset symbol and its included preset fields with the values ​​of the corresponding preset fields in the request parameters to obtain the second network link.

[0122] In one embodiment, when there is no preset symbol in the first network link and when the request type in the key information is the first request type, the first parameter in the request parameters is appended to the first network link to obtain the third network link.

[0123] In one embodiment, the step of remotely invoking the corresponding service through the gateway based on the network link includes: when a preset symbol exists in the first network link, remotely invoking the corresponding service through the gateway based on the second network link; when no preset symbol exists in the first network link, and the request type in the key information is a first request type, remotely invoking the corresponding service through the gateway based on the third network link; and when no preset symbol exists in the first network link, and the request type in the key information is a second request type, remotely invoking the corresponding service through the gateway based on the first network link.

[0124] In one embodiment, the whitelist is stored in a database as an editable data table.

[0125] In one embodiment, the data table includes a service number, a service name, and key network link information corresponding to the service number.

[0126] In one embodiment, determining whether the service requested by the mobile terminal is in the whitelist based on the request parameters includes: searching the whitelist for a matching service number based on the service number in the request parameters.

[0127] In one embodiment, the key information of the network link corresponding to the service number includes the request type and request path, while the non-key information of the network link corresponding to the service number is stored in an editable configuration file.

[0128] In one embodiment, returning the call result to the mobile device includes: when the corresponding service is called remotely through the gateway and works normally, returning the call success information and service result to the mobile device; when the corresponding service is called remotely through the gateway and does not work normally, returning the call failure information to the mobile device.

[0129] In one embodiment, the system first verifies whether the service requested by the mobile device is in the whitelist, and then verifies whether the mobile device's identity is legitimate and whether it has the permission to call the service; or, it first verifies whether the mobile device's identity is legitimate and whether it has the permission to call the service, and then verifies whether the service requested by the mobile device is in the whitelist.

[0130] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the methods described above.

[0131] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the methods described above.

[0132] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements any of the methods described above.

[0133] It should be noted that the service invocation method and apparatus based on the operation workbench provided in this embodiment of the invention can be used in the financial field, or in any technical field other than the financial field. This embodiment of the invention does not limit the application field of the service invocation method and apparatus based on the operation workbench.

[0134] like Figure 5 The diagram shown is a schematic representation of the physical structure of a computer device according to an embodiment of the present invention. The computer device 005 includes a processor 51, a memory 52, and a bus 53. The processor 51 and the memory 52 communicate with each other via the bus 53.

[0135] The processor 51 is used to call program instructions in the memory 52 to execute the service invocation method based on the operation workbench provided in the above method embodiments.

[0136] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the above-described service invocation methods based on an operations workbench.

[0137] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements any of the above-described service invocation methods based on an operations workbench.

[0138] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0139] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0140] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0141] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0142] The specific embodiments described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A service invocation method based on an operations workbench, characterized in that, include: Register the unified call service interface to the service registry center; Receive request parameters sent by the mobile terminal through the unified call service interface; Based on the request parameters, determine whether the service requested by the mobile device is in the whitelist; If the service requested by the mobile device is in the whitelist, then it is determined whether the mobile device's identity is legitimate and whether it has the permission to call the service. Otherwise, return a call failure message to the mobile device; When the mobile device's identity is legitimate and it has the authority to call, a network link is constructed based on the request parameters and the attributes of the whitelist. Otherwise, return a call failure message to the mobile device; Based on the network link, the corresponding service is remotely invoked through the gateway, and the invocation result is returned to the mobile device.

2. The service invocation method based on the operation workbench as described in claim 1, characterized in that, The process of constructing network links based on the request parameters and the attributes of the whitelist includes: Based on the service number in the request parameters, obtain the key network link information corresponding to the service number in the whitelist; The first network link is obtained by concatenating the request path in the key information with the non-key information of the network link corresponding to the service number in the configuration file.

3. The service invocation method based on the operation workbench as described in claim 2, characterized in that, When a preset symbol exists in the first network link, a regular expression is used to replace the preset symbol and its included preset fields with the values ​​of the corresponding preset fields in the request parameters to obtain the second network link.

4. The service invocation method based on the operation workbench as described in claim 3, characterized in that, When there is no preset symbol in the first network link, and when the request type in the key information is the first request type, the first parameter in the request parameters is appended to the first network link to obtain the third network link.

5. The service invocation method based on the operation workbench as described in claim 4, characterized in that, The step of remotely invoking the corresponding service through the gateway based on the network link includes: When a preset symbol exists in the first network link, the corresponding service is remotely invoked through the gateway according to the second network link; When there is no preset symbol in the first network link, and when the request type in the key information is the first request type, the corresponding service is remotely invoked through the gateway according to the third network link; When there is no preset symbol in the first network link, and when the request type in the key information is the second request type, the corresponding service is remotely invoked through the gateway according to the first network link.

6. The service invocation method based on the operation workbench as described in any one of claims 1-5, characterized in that, The whitelist is stored in the database as an editable data table.

7. The service invocation method based on the operation workbench as described in claim 6, characterized in that, The data table includes the service number, service name, and key information about the network link corresponding to the service number.

8. The service invocation method based on the operation workbench as described in claim 7, characterized in that, The step of determining whether the service requested by the mobile device is in the whitelist based on the request parameters includes: The service number in the request parameters is used to search the whitelist for a matching service number.

9. The service invocation method based on the operation workbench as described in claim 8, characterized in that, The key information of the network link corresponding to the service number includes the request type and request path, while the non-key information of the network link corresponding to the service number is stored in an editable configuration file.

10. The service invocation method based on the operation workbench as described in claim 1, characterized in that, The process of returning the call result to the mobile device includes: When the corresponding service is called remotely through the gateway and works normally, the call success information and service result will be returned to the mobile device. If the corresponding service is not functioning properly when remotely called through the gateway, a call failure message will be returned to the mobile device.

11. The service invocation method based on the operation workbench as described in claim 1, characterized in that, First, verify whether the service requested by the mobile device is in the whitelist, and then verify whether the mobile device's identity is legitimate and whether it has the permission to call the service. Alternatively, first verify whether the mobile device's identity is legitimate and whether it has the necessary permissions, and then verify whether the service requested by the mobile device is on the whitelist.

12. A service invocation device based on an operations workbench, characterized in that, include: The registration module is used to register the unified call service interface with the service registry center; The receiving module is used to receive request parameters sent by the mobile terminal through the unified call service interface; The first judgment module is used to determine whether the service requested by the mobile terminal is in the whitelist based on the request parameters. The second judgment module is used to determine whether the mobile terminal's identity is legitimate and whether it has the right to call the service when the mobile terminal requests to call the service is in the whitelist; Otherwise, return an error message to the mobile device; The third judgment module is used to construct a network link based on the request parameters and the attributes of the whitelist when the mobile terminal's identity is legitimate and it has calling permissions. Otherwise, return an error message to the mobile device; The calling module is used to remotely call the corresponding service through the gateway based on the network link and return the result to the mobile terminal.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the service invocation method based on the operation workbench as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the service invocation method based on an operation workbench as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the service invocation method based on an operation workbench as described in any one of claims 1 to 11.

Images