Service management method, device and terminal equipment based on public jar package

Abstract

This invention discloses a service management method, apparatus, and terminal device based on a common JAR package. The method involves acquiring a common JAR package to be imported into a service system, importing the JAR package into the service system, generating a corresponding backend management system based on the common JAR package, obtaining application information input through the backend management system, and invoking the service system's interfaces based on the application information. This approach not only reduces code redundancy and improves security, but also allows service providers to better understand interface call behavior. Furthermore, it provides developers with more convenient debugging tools, reduces repetitive maintenance costs for programmers, and thus improves work efficiency.

Description

Technical Field

[0001] This invention relates to the field of service management technology, and in particular to a service management method, apparatus, and terminal device based on a public JAR package. Background Technology

[0002] Currently, there are API maintenance tools on the market, such as Swagger. However, they are tightly coupled with the code, requiring developers to manually maintain them every time the contract is changed. This results in redundant code that is difficult to read. Furthermore, the API documentation generated by Swagger can be directly displayed and called on the server by users, which poses a security risk. Summary of the Invention

[0003] In a first aspect, the present invention provides a service management method based on a public JAR package, the method comprising:

[0004] Obtain the common JAR file of the service system to be imported;

[0005] The public JAR package is imported into the service system, and a corresponding backend management system is generated based on the public JAR package.

[0006] Obtain the application information entered through the backend management system;

[0007] The service system interface is invoked based on the application information.

[0008] In an optional implementation, the method further includes:

[0009] The public JAR package is imported into multiple service systems;

[0010] When the data sources configured in the multiple service systems are consistent, a single backend management system is generated.

[0011] In an optional implementation, the step of invoking the service system's interface based on the application information includes:

[0012] The application information is sent to the backend server so that the backend server can approve the application information.

[0013] When the application information is approved, the corresponding interface is called based on the application information.

[0014] In an optional implementation, the method further includes:

[0015] When the application information is modified, the modification application information input by the backend management system is obtained;

[0016] The modification request information is sent to the backend server so that the backend server can approve the modification request information;

[0017] When the modification application information is approved, the interface is called based on the modification application information.

[0018] In an optional implementation, the backend management system includes a contract document, and the step of generating the corresponding backend management system based on the public JAR package includes:

[0019] The public JAR package is invoked to generate multiple interfaces corresponding to the service system.

[0020] Based on the public JAR package, determine the interface path, interface request parameters, interface response parameters, and parameter comments corresponding to each interface;

[0021] Generate a corresponding contract document based on the interface path, the interface request parameters, the interface response parameters, and the parameter comments.

[0022] In an optional implementation, the application information includes a selected calling interface and interface calling information, wherein the selected calling interface is any one of the plurality of interfaces.

[0023] Secondly, the present invention provides a management device based on a public JAR package, the device comprising:

[0024] The acquisition module is used to obtain the common JAR packages of the service systems to be imported.

[0025] An import module is used to import the public JAR package into the service system and generate a corresponding backend management system based on the public JAR package.

[0026] The information input module is used to obtain application information input through the back-end management system;

[0027] The calling module is used to call the interface of the service system based on the application information.

[0028] In an optional implementation, the calling module includes:

[0029] An application sending unit is used to send the application information to the backend server so that the backend server can approve the application information.

[0030] The interface calling unit is used to call the corresponding interface based on the application information when the application information is approved.

[0031] Thirdly, the present invention provides a terminal device, including a memory and a processor, wherein the memory stores a computer program, and the computer program executes the service management method based on a public JAR package when it runs on the processor.

[0032] Fourthly, the present invention provides a readable storage medium storing a computer program that executes the service management method based on a public JAR package when run on a processor.

[0033] The embodiments of this application have the following beneficial effects:

[0034] This application provides a service management method based on a common JAR package. This method involves obtaining a common JAR package from a service system to be integrated, importing the common JAR package into the service system, generating a corresponding backend management system based on the common JAR package, obtaining application information input through the backend management system, and calling the service system's interfaces based on the application information. This method not only reduces code redundancy and improves security, but also allows service providers to better understand interface call behavior. Furthermore, it provides developers with more convenient debugging tools, reduces repetitive maintenance costs for programmers, and thus improves work efficiency.

[0035] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0036] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope of protection of the present invention. In the various drawings, similar components are numbered similarly.

[0037] Figure 1 This illustration shows a first flowchart of a service management method based on a public JAR package proposed in an embodiment of this application;

[0038] Figure 2 This illustration shows a flowchart of the process for generating a backend management system in a service management method based on a public JAR package, as proposed in an embodiment of this application.

[0039] Figure 3 This illustration shows a second flowchart of a service management method based on a public JAR package proposed in an embodiment of this application;

[0040] Figure 4This paper illustrates a flowchart of an interface call process in a service management method based on a public JAR package, as proposed in an embodiment of this application.

[0041] Figure 5 This illustration shows a third process diagram of a service management method based on a public JAR package proposed in an embodiment of this application;

[0042] Figure 6 This illustration shows a schematic diagram of a service management device based on a public JAR package according to an embodiment of this application;

[0043] Figure 7 This illustration shows a schematic diagram of the calling module in a service management device based on a public JAR package, as proposed in an embodiment of this application. Detailed Implementation

[0044] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0045] The components of the embodiments of the invention described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0046] In the following, the terms “comprising,” “having,” and their cognates, which may be used in various embodiments of the invention, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as excluding, firstly, the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more features, numbers, steps, operations, elements, components, or combinations thereof.

[0047] Furthermore, the terms "first," "second," and "third" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0048] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of the invention pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be interpreted as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of the invention.

[0049] Example 1

[0050] like Figure 1 As shown in the figure, this application provides a service management method based on a public JAR package. Exemplarily, the service management method based on a public JAR package specifically includes the following steps.

[0051] Step S100: Obtain the public JAR package of the service system to be imported.

[0052] It is understandable that a large company's system consists of multiple different sub-service systems. Each sub-service system has its own service architecture and corresponding technical solutions. When each sub-service system interacts with the outside world, it does so through corresponding interface documentation. In this embodiment, a corresponding public JAR file will be obtained to be imported into at least one corresponding service system. The interfaces of each service system will be invoked by calling the public JAR file. The public JAR file in this application is a developer-defined package, including all method class files, which can be imported by any service system to enable calls to the service system.

[0053] Step S200: Import the public JAR package into the service system and generate the corresponding backend management system based on the public JAR package.

[0054] In this embodiment, after the public JAR package is introduced into the service system, the service system will generate a corresponding backend management system. The generated backend management system not only provides administrator role permissions to manage the service information of the service system connected to the backend management system, but also provides requester permissions.

[0055] In one embodiment, such as Figure 2 As shown, generating the corresponding backend management system based on the public JAR package includes sub-steps S210 to S230.

[0056] Step S210: Call the public JAR package to generate multiple interfaces corresponding to the service system.

[0057] Understandably, the obtained public JAR file is imported into any service system, and the service system that has imported the public JAR file is started. After the service system starts, the interface method classes in the public JAR file are called to generate the interface corresponding to that service system.

[0058] Step S220: Determine the interface path, interface request parameters, interface response parameters, and parameter comments for each interface based on the common JAR package.

[0059] Understandably, the service system will scan public JAR files, traversing all paths to find JAR files containing method class files with annotations corresponding to the interfaces. These method class files contain all interface information, including the interface path, request parameters, response parameters, and corresponding parameter comments.

[0060] Step S230: Generate the corresponding contract document based on the interface path, interface request parameters, interface response parameters, and parameter comments.

[0061] In this embodiment, a corresponding contract document will be generated based on the interface path, interface request parameters, interface response parameters, and corresponding parameter annotations. This contract document includes the callable interfaces and their corresponding information. The generated contract document will be displayed in the backend management system for the caller to select the interface to invoke. Annotations include, but are not limited to, @RequestMapping, @GetMapping (for GET requests), @PostMapping (for POST requests), and @DeleteMapping (for delete requests). The generated contract document can be displayed in a browser, allowing users to view detailed interface information. Alternatively, staff can manually fill in the parameters to call the interface. It is understood that the generated contract document can be used by programmers to simulate service calls, similar to Swagger, or developers can customize specific environment domains or even local IP addresses to simulate service calls.

[0062] As an example, when a method uses the @GetMapping and @PostMapping annotations, it will be scanned by the service system, which will then obtain interface information such as the interface path, interface request parameters, interface response parameters, and parameter comments, and generate a contract document based on the interface information obtained from the two interface annotations.

[0063] As an alternative solution, such as Figure 3 As shown, when generating the corresponding backend management system based on the public JAR package in step S200 above, the service management method based on the public JAR package further includes steps S500 to S600:

[0064] Step S500: Import the common JAR package into multiple service systems.

[0065] It is understandable that when there are multiple service systems, and all of these service systems will import the same common JAR file, then that common JAR file will be imported into the corresponding multiple service systems.

[0066] Step S600: When multiple service systems have the same data source configuration, generate the same backend management system.

[0067] When multiple service systems import the same common JAR file, each service system will generate its own corresponding backend management system. However, if the data sources configured in multiple service systems are identical, only one corresponding backend management system will be generated. This backend management system is used to manage the service information of all service systems that have imported the common JAR file. Here, the data source refers to the database or database server used by the database application; it is the device or raw media that provides the required data. The data source stores all the information for establishing database connections. Just as you can find a file in the file system by specifying its name, you can find the corresponding database connection by providing the correct data source name.

[0068] As an example, when service system A and service system B are configured with the same data source, if a common JAR package is imported into service system A and service system B, only one backend management system will be generated to manage the service information of the connected service system A and service system B.

[0069] Step S300: Obtain the application information entered through the back-end management system.

[0070] In this implementation, after the corresponding backend management system is generated, the caller of the service system will call the service system through the backend management system. In other words, the caller can apply to call any one of the multiple interfaces through the backend management system.

[0071] Understandably, the backend management system includes a corresponding display page. This page receives application information input from the caller, including the selected API and API call information. The display page includes an API selection box and an input sub-box. The API selection box contains multiple APIs included in the service system that imports the common JAR package. The input sub-box is used to input the API call information. When the caller needs to invoke a service from the service system, it will invoke the corresponding API. First, the caller logs into the backend management system. After logging in, the caller selects the API to be invoked using the API selection box and then enters the corresponding API call information in the input sub-box. The API call information includes the service usage scenario, service usage fields, QPS (Queries per second), i.e., call frequency, and channel information, among other API call information.

[0072] In this embodiment of the application, by introducing a public JAR package, it is no longer necessary to use Swagger and Postman, nor is it necessary to blindly inject code annotations into the service system like Swagger, which can improve the security of the interface.

[0073] Furthermore, when the service system needs to be modified later, the public JAR package will inform the backend management system via email or message which channels the service is currently being used, the usage scenarios, and the specific fields used. This allows administrators to clearly understand the potential risks of modifications and promptly avoid situations where service changes go unnoticed by users in the test environment but cause production problems in the production environment.

[0074] The contract change impact notification function in this application can free programmers from the cost of contract maintenance and the time cost of assessing the impact during the development process, making development and debugging work simple and visual.

[0075] In this implementation, we can not only keep track of the service usage scenarios, API call frequency, and call exceptions, but also enable callers to be informed of service changes made by the service provider. This allows callers to respond promptly and quickly, effectively reducing communication costs and the workload of developers.

[0076] Step S400: Call the service system interface based on the application information.

[0077] After obtaining the input application information, the corresponding interface will be invoked based on the application information, that is, the corresponding service will be invoked. By filling in the application information, it is possible to clearly understand the specific interfaces called by the channel and the specific information used by the interface, thereby avoiding the inaccuracy problem of consulting the service system one by one every time the contract changes, reducing the time for information confirmation and reducing the workload.

[0078] In this embodiment, the introduction of this public JAR package can, to a certain extent, ensure that the service provider understands information such as the channels through which its interface is used, the frequency of calls, abnormal call situations, and service usage scenarios. If the interface needs to be adjusted later, each channel can be notified through the backend management system. Furthermore, when the interface logic changes, the impact of the logic change can be assessed through each channel.

[0079] In one embodiment, such as Figure 4 As shown, step S400 includes sub-steps S410 to S420.

[0080] Sub-step S410: Send the application information to the backend server so that the backend server can approve the application information.

[0081] After receiving the input application information, the application information will be sent to the backend server. After receiving the application information, the backend server can determine the interface to be called, the usage scenario of the service corresponding to the interface, and the calling channel based on the application information, and will display the application information so that the administrator can approve the corresponding interface call based on the obtained application information on the backend server.

[0082] Sub-step S420: When the application information is approved, the corresponding interface is called based on the application information.

[0083] When the entered application information is approved, the corresponding interface will be invoked based on the application information, meaning the channel will gain the appropriate permissions to invoke the service system corresponding to that interface. When the entered application information is not approved, an interface call failure will be displayed, and the channel will not be able to obtain the calling permission.

[0084] In this embodiment, when multiple callers request to invoke the same interface—in other words, when different callers request the same service—the common JAR package can personalize its output functionality for the same service requested by different callers. For example, if service system A requires ten return messages and service system B requires five, the common JAR package can personalize the return messages based on the fields requested by the callers. That is, it can return only the ten resources needed by service system A and the five fields requested by service system B. This embodiment returns control of the fields used by the callers to the service provider, which is beneficial for assessing the impact when the service system undergoes changes later.

[0085] Further optional, such as Figure 5 As shown, the service management method based on public JAR packages also includes steps S700 to S900.

[0086] Step S700: When modifying the application information, obtain the modification application information entered by the backend management system.

[0087] In this embodiment of the application, when the channel wants to modify the application information later, the caller will log in to the backend management system again and enter the corresponding modification information through the backend management system. For example, the modification information can be information such as increasing QPS, deleting interface calls, adding service use cases, and adding usage fields.

[0088] Step S800: Send the modification request information to the backend server so that the backend server can approve the modification request information.

[0089] After obtaining the relevant modification information, the modification request will be sent to the backend server. After receiving the modification request, the backend server will approve the modification request.

[0090] Step S900: When the modified application information is approved, the interface is called based on the modified application information.

[0091] If the modified application information is approved, the caller will gain the corresponding permissions, such as adding use cases for the service corresponding to the called interface. If the approval fails, the channel will not gain the permissions to modify the application information, such as adding use cases for the interface call.

[0092] It is understood that, in this embodiment, the administrator of the backend management system can also view the interface traffic call status of each channel in real time through the backend server. If abnormal traffic is detected, the caller can be notified in a timely manner. Furthermore, the backend management system can also be used for dynamic interface maintenance. For example, during database maintenance, the management system configuration interface can be set to an unavailable state. At this time, the channel call interface will automatically degrade, thereby avoiding a large number of errors. This embodiment also provides message templates for all services, avoiding the need for developers to manually simulate messages and call services; they only need to fill in the specific data, making debugging simple, convenient, and quick.

[0093] This application not only reduces code redundancy and improves security, but also enables service providers to have a clearer understanding of interface calls. It also provides developers with more convenient debugging methods, reduces the repeated maintenance costs for programmers, and thus improves work efficiency.

[0094] Based on the above embodiments, the service management method based on public JAR packages Figure 6 This illustration shows a structural diagram of a management device 10 based on a common JAR file, according to an embodiment of this application. The management device 10 based on a common JAR file includes:

[0095] Module 11 is used to obtain the public JAR package of the service system to be introduced.

[0096] Module 12 is used to import public JAR packages into the service system and generate the corresponding backend management system based on the public JAR packages.

[0097] The information input module 13 is used to obtain application information entered through the back-end management system.

[0098] Module 14 is invoked to call the service system's interface based on the application information.

[0099] In one implementation, such as Figure 7 As shown, module 14 includes the following.

[0100] Application sending unit 1 is used to send application information to the backend server so that the backend server can approve the application information.

[0101] Interface call unit 2 is used to call the corresponding interface based on the application information when the application information is approved.

[0102] This embodiment provides a management device 10 based on a public JAR package for executing the service management method based on a public JAR package described above. The implementation schemes and beneficial effects involved in the above embodiments are also applicable to this embodiment, and will not be repeated here.

[0103] This embodiment also provides a terminal device, including a memory and a processor. The memory stores a computer program, and the computer program executes the service management method based on a public JAR package described in the above embodiment when it is run on the processor.

[0104] This embodiment also provides a readable storage medium storing a computer program, which executes the service management method based on a public JAR package described above when run on a processor.

[0105] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, as an alternative implementation, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0106] In addition, the functional modules or units in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0107] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0108] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A service management method based on a public JAR package, characterized in that, The method includes: Obtain the common JAR file of the service system to be imported; The public JAR package is imported into the service system, and a corresponding backend management system is generated based on the public JAR package; the backend management system includes a contract document, and the generation of the corresponding backend management system based on the public JAR package includes: The public JAR package is invoked to generate multiple interfaces corresponding to the service system. Based on the public JAR package, determine the interface path, interface request parameters, interface response parameters, and parameter comments corresponding to each interface; Generate a corresponding contract document based on the interface path, the interface request parameters, the interface response parameters, and the parameter comments; Obtain the application information entered through the backend management system; The interface of the service system is called based on the application information; Also includes: The public JAR package is imported into multiple service systems; When the data sources configured in the multiple service systems are consistent, a single backend management system is generated.

2. The service management method based on a public JAR package according to claim 1, characterized in that, The invocation of the service system interface based on the application information includes: The application information is sent to the backend server so that the backend server can approve the application information. When the application information is approved, the corresponding interface is called based on the application information.

3. The service management method based on a public JAR package according to claim 1, characterized in that, Also includes: When the application information is modified, the modification application information input by the backend management system is obtained; The modification request information is sent to the backend server so that the backend server can approve the modification request information; When the modification application information is approved, the interface is called based on the modification application information.

4. The service management method based on a public JAR package according to claim 1, characterized in that, The application information includes the selected calling interface and the interface calling information, wherein the selected calling interface is any one of the plurality of interfaces.

5. A management device based on a common JAR package, characterized in that, The device includes: The acquisition module is used to obtain the common JAR packages of the service systems to be imported. An import module is used to import the public JAR package into the service system and generate a corresponding backend management system based on the public JAR package; the backend management system includes a contract document, and the generation of the corresponding backend management system based on the public JAR package includes: The public JAR package is invoked to generate multiple interfaces corresponding to the service system. Based on the public JAR package, determine the interface path, interface request parameters, interface response parameters, and parameter comments corresponding to each interface; Generate a corresponding contract document based on the interface path, the interface request parameters, the interface response parameters, and the parameter comments; The information input module is used to obtain application information input through the back-end management system; The calling module is used to call the interface of the service system based on the application information; Also includes: The public JAR package is imported into multiple service systems; When the data sources configured in the multiple service systems are consistent, a single backend management system is generated.

6. The management device based on a public JAR package according to claim 5, characterized in that, The calling module includes: An application sending unit is used to send the application information to a backend server so that the backend server can approve the application information. The interface calling unit is used to call the corresponding interface based on the application information when the application information is approved.

7. A terminal device, characterized in that, It includes a memory and a processor, the memory storing a computer program, which, when run on the processor, executes the service management method based on a public JAR package as described in any one of claims 1 to 4.

8. A readable storage medium, characterized in that, It stores a computer program that, when run on a processor, executes the service management method based on a public JAR package as described in any one of claims 1 to 4.

Images