CN112506590A

CN112506590A - Interface calling method and device and electronic equipment

Info

Publication number: CN112506590A
Application number: CN202011485622.XA
Authority: CN
Inventors: 黄锡平; 王维
Original assignee: Ping An International Smart City Technology Co Ltd
Current assignee: Ping An International Smart City Technology Co Ltd
Priority date: 2020-12-16
Filing date: 2020-12-16
Publication date: 2021-03-16

Abstract

The embodiment of the application provides an interface calling method, an interface calling device and electronic equipment, wherein the method is applied to a service engine management end and comprises the following steps: receiving interface metadata of a target service sent by a middle station service device, wherein the interface metadata comprises an interface list and internal processing logic of each interface in a plurality of interfaces indicated by the interface list; loading the internal processing logic of each interface on an interface management interface; arranging internal processing logic of a target interface in the plurality of interfaces to obtain interface arrangement data, wherein the target interface is any one of the plurality of interfaces or a designated interface; and sending the interface arrangement data to the center service equipment so that the center service equipment realizes interface calling according to the interface arrangement data. By adopting the method and the device, the dynamic arrangement of the interfaces can be realized. The application relates to a block chain technology, for example, interface layout data can be written into a block chain after being encrypted.

Description

Interface calling method and device and electronic equipment

Technical Field

The application relates to the technical field of cloud deployment, in particular to an interface calling method and device and electronic equipment.

Background

The middle platform architecture is actually composed of several levels. The micro service technology middle platform is an important component for constructing a middle platform framework. SpringCloud and Kubernets are mainstream technology stacks adopted by the stations in the micro-service technology constructed by the Internet enterprises at present. At present, the IT construction in the industry adopts a middle strategy mode in a large quantity. The strategy mode of the middle desk mainly emphasizes abstract deposition, modularization and reuse of organizational business and technical capacity, so that strong support is formed for each foreground business, and the first-line foreground business can adapt to the market which is changing rapidly and more quickly. However, the ideal target (small foreground, large and medium desk) for realizing the medium desk strategic mode by actually landing encounters the difficulties of how to realize a set of medium desk service, and the dynamic arrangement of the interface can be carried out.

Disclosure of Invention

The embodiment of the application provides an interface scheduling method, an interface scheduling device and electronic equipment, which can realize dynamic arrangement of interfaces based on a set of middle station services.

In a first aspect, an embodiment of the present application provides an interface calling method, which is applied to a service engine management end, and includes:

receiving interface metadata of a target service sent by a middle station service device, wherein the interface metadata comprises an interface list and internal processing logic of each interface in a plurality of interfaces indicated by the interface list;

loading the internal processing logic of each interface on an interface management interface;

arranging internal processing logic of a target interface in the plurality of interfaces to obtain interface arrangement data, wherein the target interface is any one of the plurality of interfaces or a designated interface;

and sending the interface arrangement data to the center service equipment so that the center service equipment realizes interface calling according to the interface arrangement data.

Optionally, the interface metadata is obtained by querying, by the middle service device, according to identification information of a target service carried by the interface metadata query instruction after receiving the interface metadata query instruction sent by the service engine management end; or the like, or, alternatively,

and the interface metadata is obtained by the middle service equipment through a business engine client software development kit according to preset annotations in the target service when the target service runs.

Optionally, the interface list includes description information of each of the plurality of interfaces;

the internal processing logic of the interface comprises identification information of an event of the interface and identification information of a rule associated with the event; the events are divided into pre-events and post-events, and the rules are divided into pre-rules and post-rules.

Optionally, the performing an orchestration process on internal processing logic of a target interface of the plurality of interfaces includes at least one of:

performing rule sequence adjustment on internal processing logic of a target interface in the plurality of interfaces;

setting event start and stop for the internal processing logic of the target interface;

setting the regular start and stop of the internal processing logic of the target interface;

and carrying out rule change processing on the internal processing logic of the target interface.

In a second aspect, an embodiment of the present application further provides an interface calling method, which is applied to a middle station service device, and includes:

receiving an interface request of a requester for a target service;

when it is determined that updated interface metadata exists in a target service, loading the updated interface metadata in the target service; the updated interface metadata is obtained by updating the interface metadata of the target service by the middle service equipment by using interface arrangement data sent by a service engine management end;

starting to execute the method of the interface to which the interface request is directed;

during the execution of the interface method, if a call statement of a functional unit of an interface is detected, acquiring a start-stop state of the functional unit, and operating the functional unit when the start-stop state is determined to be enabled; the functional unit is an event or a rule related to the event;

and after the interface executing method is finished, response result data of the interface request is obtained, and the response result data is returned to the requester.

Optionally, the functional unit includes an event-related rule, where the rule includes a dynamic rule, and the dynamic rule is a rule newly added to the service engine management end or a rule of an interface of another service; the operating the functional unit includes:

and when the rule comprises a dynamic rule, initializing an object corresponding to the dynamic rule, and starting a script engine to run the dynamic rule.

Optionally, the method further comprises:

receiving an interface metadata query instruction sent by the service engine management end, querying interface metadata of a target service according to identification information of the target service carried by the interface metadata query instruction, and sending the interface metadata of the target service to the service engine management end; or the like, or, alternatively,

when the target service runs, scanning a preset annotation in the target service through a business engine client software development kit to obtain the target service interface metadata, and sending the interface metadata of the target service to the business engine management terminal.

In a third aspect, an embodiment of the present application provides an interface invoking device, which is applied to a service engine management end, and includes:

the communication module is used for receiving interface metadata of a target service sent by the middle station service equipment, wherein the interface metadata comprises an interface list and internal processing logic of each interface in a plurality of interfaces indicated by the interface list;

the display module is used for loading the internal processing logic of each interface on an interface management interface;

the processing module is used for performing arrangement processing on internal processing logic of a target interface in the plurality of interfaces to obtain interface arrangement data, wherein the target interface is any one of the plurality of interfaces or a designated interface;

the communication module is further configured to send the interface layout data to the central service device, so that the central service device realizes interface calling according to the interface layout data.

In a fourth aspect, an embodiment of the present application provides an interface invoking device, which is applied to a middle station service device, and includes:

the communication module is used for receiving an interface request of a requester for a target service;

the processing module is used for loading the updated interface metadata in the target service when the updated interface metadata of the target service is determined to exist; the updated interface metadata is obtained by updating the interface metadata of the target service by the middle service equipment by using interface arrangement data sent by a service engine management end;

the processing module is further configured to start executing the method of the interface to which the interface request is directed, and during the execution of the method of the interface, if a call statement to a functional unit of the interface is detected, obtain a start-stop state of the functional unit, and operate the functional unit when it is determined that the start-stop state is enabled; the functional unit is an event or a rule related to the event;

the communication module is further configured to obtain response result data of the interface request after the interface execution method is completed, and return the response result data to the requester.

In a fifth aspect, an embodiment of the present application provides an electronic device, including a processor, an input device, an output device, and a memory, where the processor and the memory are connected to each other, where the memory is used to store a computer program, and the computer program includes program instructions, and the processor is configured to call the program instructions, execute the method according to the first aspect, or execute the method according to the second aspect.

In a sixth aspect, the present application provides a computer-readable storage medium, which stores a computer program, where the computer program is executed by a processor to implement the method according to the first aspect, or to implement the method according to the second aspect.

To sum up, the service engine management end may receive interface metadata of the target service sent by the middlebox service device, and load internal processing logic of each interface in the plurality of interfaces included in the interface metadata on the interface management interface; the service engine management end can arrange and process internal processing logic of a target interface in the plurality of interfaces to obtain interface arrangement data, and send the interface arrangement data to the middle platform service equipment, so that the middle platform service equipment realizes interface calling according to the interface arrangement data, the purpose of dynamically arranging the interfaces is achieved, and the interface calling process is more flexible and is easy to control.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1a is a schematic network structure diagram of an interface scheduling system according to an embodiment of the present application;

fig. 1b is a schematic network structure diagram of another interface scheduling system provided in the embodiment of the present application;

FIG. 1c is a schematic diagram of a development model provided by an embodiment of the present application;

fig. 2 is a schematic flowchart of an interface scheduling method according to an embodiment of the present application;

FIG. 3a is a schematic view of a first interface provided by an embodiment of the present application;

FIG. 3b is a schematic view of a second interface provided by an embodiment of the present application;

FIG. 3c is a schematic diagram of an interface management interface according to an embodiment of the present disclosure;

fig. 4 is a schematic flowchart of another interface scheduling method according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of an interface invoking device according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of another interface invoking device provided in the embodiment of the present application;

fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

In this embodiment of the present application, the business engine may be a middleware Development framework, and the business engine may include a client Software Development Kit (SDK) function and a management side function. The business engine can develop interfaces that require dynamic orchestration rules. The business engine is expanded on the prior art stack, and the interface, the object, the event, the rule and the rule arrangement logic are identified by adding annotation, so that the modification and development of the code can be easily realized, and then the business engine can be driven by business operation to realize the execution of the business logic according to the dynamically adjusted rule.

In the embodiment of the application, the service engine is completely compatible with the prior art stack and can coexist. The method adopts the standard development of a business engine, is mainly used for meeting the business scene that business rules are possibly dynamically adjusted during operation, and has corresponding sacrifice in development workload and maintainability. Therefore, the interface development can adopt two development concurrent modes, namely a conventional mode and a business engine intervention mode. A conventional development mode, namely a normal development mode of the prior art stack; the business engine intervention mode is the development mode provided by the application. The method and the system can identify whether the interface of the corresponding service has a scene of dynamically adjusting the business rule or not by combining with the business characteristics during development, and adopt a business engine intervention mode for development after identifying the scene of the dynamically adjusting business rule (can combine with a product design suggestion).

According to the method and the device, the internal processing logic of the interface can be abstracted into a plurality of rules in the interface development stage, and the complete business processing logic of the interface is realized by assembling the rules. In addition, the method and the system can realize the dynamic arrangement and adjustment of the rules of the interface through the service engine management end in the interface management stage without restarting the system to finish the service processing logic thermal modification of the interface. In an actual application scenario, the application can introduce each service of the middle service device, such as each micro service, into the service engine client SDK. The SDK at the service engine client can realize the analysis annotation and can also realize the functions of obtaining corresponding interface metadata to send to the service engine management end when the service runs.

Referring to the interface call system shown in fig. 1a and 1b, a developer can introduce a service engine client SDK into a service when developing the service. Then, the interface of the service, the service logic unit of the interface and the initial arrangement configuration information of the interface are developed based on the SDK of the service engine client, and then the service can be deployed on the middle service device. The service logic unit may refer to a code of each rule in at least one rule corresponding to the interface. The initial orchestration configuration information may include identification information of objects of the interface, an event list of the objects (including identification information of the events), a rule list of the events (including identification information of the rules associated with the events), and orchestration logic between the rules. The foreground system may invoke a service of the middle service device, for example, may specifically perform an interface call to a service deployed on the middle service device through a Gateway device, such as an interface Gateway (API Gateway, APIG) device. In addition, the services operated by the middlebox service may be mutually interface-called, and a description thereof is not provided herein. The service of the middle service device, such as the project library service center, may have multiple interfaces, the service engine management end may obtain the service from the middle service device, such as the interface metadata of the project library service information, and perform arrangement processing on the internal processing logic of the interface included in the interface metadata, such as the internal processing logic newly added to a specific project, to obtain the interface arrangement data, and send the interface arrangement data to the middle service device, which may store the interface arrangement data, or update the interface metadata by using the interface arrangement data, to obtain the updated interface metadata.

In the actual development process, a developer can correspondingly develop the interface of the service, the business logic unit of the interface and the initial arrangement configuration information of the interface according to the development model. The development model here can be seen in fig. 1 c. The pre-rules shown in fig. 1c may include rule 1, rule 2, rule 3, and rule 4, where rule 1 is a rule that requires a rule engine to be invoked, and rule 2 is a rule that requires a data engine to be invoked. The postrule shown in fig. 1c includes rule 1 and rule 2, where rule 1 includes a rule that needs to invoke another tool or service, and rule 2 includes a rule that needs to invoke a data engine.

Referring to code examples 1-4, in the interface development phase, a developer may add annotations by: the developer may add annotations to the interface, such as @ BueApi. The @ buelapi may be used to identify the interface, and may be used to obtain information such as identification information of the interface. The developer may add annotations, such as @ BuePO, to the object and configure the list of events corresponding to the object. The @ BuePO can be used to identify the object and obtain information such as identification information of the object. Developers can add annotations to events, such as @ BueEvent, and add core business logic (standardized, productized) within the recipe body of the method of events. The annotation @ BueEvent may be used to identify an event, and may be used to obtain information such as identification information of the event. The developer may add annotations to the rules associated with the event, such as @ BueRule. The @ buedrile can be used for identifying the rule and acquiring information such as identification information of the rule. Further, referring to code example 5, the developer can also set initial orchestration configuration information for the interface.

Code example 1:

code example 2:

code example 3:

code example 4:

code example 5:

the following describes an interface calling method, an interface calling device and an electronic device provided by the embodiment of the application.

Please refer to fig. 2, which is a flowchart illustrating an interface invoking method according to an embodiment of the present disclosure. The method can be applied to a business engine management end. The method may comprise the steps of:

s201, receiving interface metadata of a target service sent by a middle station service device, wherein the interface metadata comprises an interface list and internal processing logic of each interface in a plurality of interfaces indicated by the interface list.

The interface may be an interface that can be arranged by the service engine management end, or an interface that has an arrangement authority by the service engine management end.

Wherein the referred interface list comprises description information of each interface in the plurality of interfaces. The description information of the interface may include at least one of: the name of the interface, the Uniform Resource Locator (URL) of the interface, the creation time of the interface, and the update time of the interface. In one embodiment, the list of referred interfaces may also include identification information of the service (e.g., name of the service).

The internal processing logic may include identification information of an event of the interface (e.g., name of the event), identification information of a rule associated with the event (e.g., name of the rule). Events can be divided into pre-events and post-events. Rules can be divided into pre-rules and post-rules. In one embodiment, the internal processing logic may further include a start-stop state of an event and/or a regular start-stop state.

In one embodiment, the internal processing logic may further include identification information of an object of the interface (e.g., name of the object), and the event may include an event corresponding to the object.

In one embodiment, the referred interface metadata may also include historical orchestration version information for each interface. The historical arrangement version information may include arrangement version information obtained by arranging the internal processing logic of the interface each time within a preset time range (e.g., within the last year).

In one embodiment, the interface metadata port may be obtained by the service engine client SDK when the target service is run by the middlebox service device according to a preset annotation in the target service, where the preset annotation may be set by a developer in the target service.

In an embodiment, the interface metadata is obtained by querying, by the middle station service device, according to identification information of a target service carried by the interface metadata query instruction after receiving the interface metadata query instruction sent by the service engine management end.

S202, loading the internal processing logic of each interface on the interface management interface.

S203, performing arrangement processing on internal processing logic of a target interface in the plurality of interfaces to obtain interface arrangement data, wherein the target interface is any one of the plurality of interfaces or a designated interface.

In step S202 and step S203, the service engine management end may load the internal processing logic of each interface on the interface management interface, and perform the arrangement processing on the internal processing logic of the target interface in the plurality of interfaces to obtain interface arrangement data, thereby achieving the purpose of dynamically arranging the interfaces. The target interface may be any one of the plurality of interfaces or a designated interface.

In one embodiment, the orchestration process performed by the service engine management end on the internal processing logic of the target interface of the plurality of interfaces may include at least one of: the service engine management end carries out rule sequence adjustment on the internal processing logic of a target interface in the plurality of interfaces; the service engine management end sets the event start and stop of the internal processing logic of the target interface; the service engine management end sets the internal processing logic of the target interface to start and stop regularly; and the service engine management end carries out rule change processing on the internal processing logic of the target interface. The referred rule changing process may include at least one of: adding rules, deleting rules and modifying rules.

In an application scenario, taking a rule start/stop setting as an example, an administrator may check a rule that is not enabled by the target interface, and the service engine management end may detect an operation of determining and checking the rule that is not enabled, and may set a start/stop state of the rule to be enabled. The administrator can cancel and check the rule which is enabled by the target interface, the service engine management end can detect the cancel and check operation of the enabled rule, and can set the start and stop state of the rule to be disabled. The above-described check-out process may be performed based on the interface shown in fig. 3 c. For another example, taking the new rule as an example, the administrator may click the new rule option for the target interface, the service engine management end may display an editing interface for the new rule when detecting the click operation on the new rule option, and then the administrator may edit the new rule on the editing interface, and then the service engine management end may obtain the new rule and generate interface layout data including the new rule.

In one embodiment, the business engine management side can display the interface list on the first interface.

In one embodiment, the business engine management terminal may display the historical orchestration version information of the target interface in the second interface when a version management instruction for the target interface of the plurality of interfaces is detected in the first interface.

In one application scenario, the first interface may be the interface shown in fig. 3a, and the second interface may be the interface shown in fig. 3 b. The interface shown in fig. 3a includes version options corresponding to each interface. The administrator may click the version option corresponding to the item addition interface in the interface shown in fig. 3a, and the service engine management end may generate a version management instruction for the item addition interface when detecting a click operation on the version option corresponding to the item addition interface in the interface shown in fig. 3 a. The service engine management end may detect a version management instruction for the newly added project interface, and display historical layout information of the newly added project interface, such as two pieces of layout version information in the interface shown in fig. 3b, where the layout version information may include at least one of the following: code version, interface state, service release version, version creation time, version update time, etc.

In an embodiment, when a rule editing instruction for the target interface is detected on the second interface, the service engine management end may display the internal processing logic arrangement of the target interface on the interface management interface, and then process the internal processing logic of the interface to obtain interface arrangement data. The interface management interface may be a second interface, or may not be, and the embodiment of the present application is not limited.

In an application scenario, the second interface is the interface shown in fig. 3b, and in the interface shown in fig. 3b, the option corresponding to the first version layout information includes a rule editing option. The service engine management end may display the internal processing logic of the newly added project interface and process the internal processing logic of the interface when detecting the click operation on the rule edit option corresponding to the first layout version information, as shown in the interface of fig. 3c

In one embodiment, the business engine management terminal may further perform a version copy operation based on the second interface. The version arrangement information included in the second interface may correspond to a copy button. In an application scenario, referring to fig. 3b, when a click operation on a copy button corresponding to the second version layout information is detected, the service engine may copy the second version layout information, thereby achieving the purpose of version copy.

In one embodiment, the business engine management side may further perform a version rollback operation based on the second interface. For example, an administrator may select one of the version layout information of the second interface through the service engine management end, the service engine management end may obtain the interface layout data corresponding to the selected version layout information to send to the middle service device, and the interface layout data corresponding to the selected version layout information may be used to update the corresponding interface metadata in the middle service device, thereby achieving the purpose of version rollback.

And S204, sending the interface arrangement data to the middle service equipment so that the middle service equipment can realize interface calling according to the interface arrangement data.

In the embodiment of the application, the service engine management end can send the interface layout data to the middle service equipment, and the middle service equipment can receive the interface layout data and store the interface layout data, or update the interface metadata by using the interface layout data to obtain updated interface metadata for a calling process of a target interface.

In one embodiment, the business engine management side opens a rule management interface. The rule management interface may include information such as identification information of each of at least one rule corresponding to each of the plurality of services. The business engine management side can perform rule resetting processing on the first service in the plurality of services based on the rule management interface. In one application scenario, an administrator may open a rule management interface through a business engine management side. The administrator can execute a rule resetting operation based on the rule management interface, and the business engine management terminal can perform resetting processing on a certain rule of a certain service in the plurality of services according to the rule resetting operation.

In one embodiment, the business engine management terminal may identify a type of each rule of at least one rule corresponding to each service of the plurality of services; and when the service engine management end determines that the rule is the rule newly added by the service engine management end according to the type of the rule, the service engine management end endows the rule with a rule change authority. After the rule is given with the rule change authority, the business engine management end can execute addition/deletion/change operation on the rule.

In one embodiment, the business engine management side can further open a service management interface, and the service management interface comprises identification information of each service in the plurality of services, a code version of each service, a release version of each service, and state information of each service. In one embodiment, a service in the service management interface with an enabled state may correspond to one metadata option and a remark option, and a service in a disabled state may correspond to one metadata option, an enabled option and a remark option. When the business engine management terminal detects click operation on a metadata option corresponding to a second service in the service management interface, the business engine management terminal can check the interface metadata of the second service. When a click operation of an enabling option corresponding to a disabled service in the service management interface is detected, the disabled service can be started. In one embodiment, the business engine management side can also execute version rollback operation based on the service management interface.

In an embodiment, the service engine management end may further monitor an operation state of each interface of the plurality of interfaces of the target service in the middle service device, and output an operation failure alarm message to the specified device for alarm when the operation failure interface is detected.

It can be seen that, in the embodiment shown in fig. 2, the service engine management end may receive the interface metadata of the target service sent by the middlebox service device, and load, on the interface management interface, the internal processing logic of each interface in the plurality of interfaces included in the interface metadata; the service engine management end can perform arrangement processing on the internal processing logic of the target interface in the plurality of interfaces to obtain interface arrangement data, and send the interface arrangement data to the middle service equipment, so that the middle service equipment realizes interface calling according to the interface arrangement data, and the purpose of dynamically arranging the interfaces is achieved.

The application relates to a block chain technology, for example, interface layout data can be written into a block chain after being encrypted.

Please refer to fig. 4, which is a flowchart illustrating another interface invoking method according to an embodiment of the present disclosure. The method can be applied to the middle station service equipment. The method may comprise the steps of:

s401, receiving an interface request of a requester to a target service.

In this embodiment, the requester may send an interface request for the target service to the middlebox service device, and the middlebox service device may receive the interface request for the target service from the requester.

In one embodiment, the requester may send an interface request for the target service through the gateway device, and the middlebox service device may receive the interface request for the target service sent by the requester through the gateway device. Specifically, the requester may send an interface request for the target service to the gateway device, and the gateway device checks whether the requester has an access right to the central service device, and if so, the gateway device converts an interface input parameter carried by the interface request to obtain a converted interface input parameter, and the converted interface input parameter can be processed by the interface of the target service. The safety and the effectiveness of the interface calling process can be improved through the gateway equipment.

S402, when the target service is determined to have the updated interface metadata, loading the updated interface metadata in the target service.

And the updated interface metadata is obtained by updating the interface metadata of the target service by the middle service equipment by using the interface arrangement data sent by the service engine management end. The interface arrangement data is obtained by arranging and processing the interface included in the interface metadata, such as the internal processing logic of the target interface, by the service engine management end.

In one embodiment, the middlebox service device may obtain historical editing version information of each interface of the target service, and determine whether the target service has updated interface metadata according to the historical editing version information. The historical arrangement version information may include arrangement version information obtained by arranging the internal processing logic of the interface each time within a preset time range (e.g., within the last year).

In one embodiment, the middlebox service device may obtain the currently enabled interface version information, compare the currently enabled interface version information with the historical orchestration version information to determine whether the currently enabled orchestration version information is the latest interface version information to be enabled, and if not, determine whether updated interface metadata exists for the target service.

S403, starting to execute the interface method pointed by the interface request.

In this embodiment, the middlebox service device may start to execute a method of an interface to which an interface request is directed.

In one embodiment, the middlebox service device may start executing the method body of the method of the interface to which the interface request is directed according to the converted access input parameters.

S404, during the execution of the interface method, if a call statement of a functional unit of the interface is detected, acquiring a start-stop state of the functional unit, and operating the functional unit when the start-stop state is determined to be enabled; the functional unit is an event or a rule associated with the event.

In the embodiment of the application, when the functional unit is an event, the middlebox service device acquires the start-stop state of the event when detecting a call statement of the event during the execution of the method of the interface, and executes the method of the event when determining that the start-stop state of the event is enabled. When the functional unit is the rule associated with the event, the middle station service equipment acquires the start-stop state of the rule if detecting a call statement of the rule associated with the event during the execution of the method of the interface. If the start-stop status is enabled, the rule is executed.

In an embodiment, the middlebox service device may further determine whether a dynamic rule is added to the rule, and if so, initialize an object corresponding to the dynamic rule and start the script engine to execute the dynamic rule. The dynamic rule may be a rule added by the service engine management side, or may be a rule of an interface of another service.

S405, after the interface executing method is finished, response result data of the interface request are obtained, and the response result data are returned to the requesting party.

In one embodiment, the middlebox service device may execute the static code of the target service to obtain response result data for the interface request and send the response result data to the requester, in case that it is determined that the target service does not have the updated interface metadata.

In one embodiment, in the case that the requester sends the interface request to the middlebox service device through the gateway device, the middlebox service device may send the response result data to the requester through the gateway device. Specifically, the middle station service device may send the response result data to the gateway device, and the gateway device converts the response result data to obtain converted response result data to send to the requesting party, where the converted response result data can be processed by the requesting party.

In an embodiment, the middlebox service device may further send, when the target service runs, the interface metadata of the target service to the business engine management end, so that the business engine management end performs an orchestration process according to internal processing logic of the interface included in the interface metadata. Specifically, the middle service device may specifically scan the interface metadata of the target service through the service engine client SDK when the target service runs, and then send the interface metadata of the target service to the service engine management end. More specifically, when the target service runs, the middlebox service device may scan out interface metadata of the target service according to a preset annotation in the target service through the service engine client SDK, and then send the interface metadata of the target service to the service engine management side. Or, the middle service equipment can also receive an interface metadata query instruction sent by the service engine management end, query the interface metadata of the target service according to the identification information of the target service carried by the interface metadata query instruction, and then send the interface metadata of the target service to the service engine management end;

in one embodiment, the business engine operation may be provided with an intervention switch. The intervention switch is used to decide whether to initialize the business engine while the target service is running. And if the intervention development is closed, the target service runs according to a default display code sequence, and if the intervention switch is opened, the service engine runs normally. The middlebox service device may, upon determining that the intervention switch of the business engine is open and upon determining that the target service has updated interface metadata, load the updated interface metadata in the target service,

it can be seen that in the embodiment shown in fig. 4, the middlebox service device may receive an interface request of a requester for a target service, and load updated interface metadata in the target service when it is determined that the updated interface metadata exists in the target service; then, the middle station service device may start to execute the method of the interface to which the interface request is directed, and during the execution of the method of the interface, if a call statement to the functional unit of the interface is detected, obtain a start-stop state of the functional unit, and operate the functional unit after determining that the start-stop state is enabled, thereby obtaining response result data to the interface request after the execution of the method of the interface is completed, and returning the response result data to the requesting party, so that the call process of the interface is more flexible and easy to control.

Please refer to fig. 5, which is a schematic structural diagram of an interface invoking device according to an embodiment of the present disclosure. The interface calling device can be applied to a business engine management end. Specifically, the interface calling device may include:

a communication module 501, configured to receive interface metadata of a target service sent by a middlebox service device, where the interface metadata includes an interface list and internal processing logic of each interface in multiple interfaces indicated by the interface list.

And a display module 502, configured to load the internal processing logic of each interface in the interface management interface.

The processing module 503 is configured to perform arrangement processing on an internal processing logic of a target interface in the plurality of interfaces to obtain interface arrangement data, where the target interface is any one of the plurality of interfaces or a designated interface.

The communication module 501 is further configured to send the interface layout data to the middle station service device, so that the middle station service device realizes interface calling according to the interface layout data.

In an optional implementation manner, the interface metadata is obtained by querying, by the middle service device, according to identification information of a target service carried by the interface metadata query instruction after receiving the interface metadata query instruction sent by the service engine management end; or, the interface metadata is obtained by the middle service equipment according to a preset annotation in the target service through a business engine client software development kit when the target service runs.

In an alternative embodiment, the interface list includes description information of each of the plurality of interfaces; the internal processing logic of the interface comprises identification information of an event of the interface and identification information of a rule associated with the event; the events are divided into pre-events and post-events, and the rules are divided into pre-rules and post-rules.

In an optional embodiment, the processing module 503 is configured to perform an orchestration process on internal processing logic of a target interface in the plurality of interfaces, and includes at least one of: performing rule sequence adjustment on internal processing logic of a target interface in the plurality of interfaces; setting event start and stop for the internal processing logic of the target interface; setting the regular start and stop of the internal processing logic of the target interface; and carrying out rule change processing on the internal processing logic of the target interface.

It can be seen that, in the embodiment shown in fig. 5, the interface calling device may receive the interface metadata of the target service sent by the middlebox service equipment, and load the internal processing logic of each interface in the plurality of interfaces included in the interface metadata on the interface management interface; the interface calling device can perform arrangement processing on internal processing logic of a target interface in the plurality of interfaces to obtain interface arrangement data, and send the interface arrangement data to the middle platform service equipment, so that the middle platform service equipment realizes interface calling according to the interface arrangement data, and the purpose of dynamically arranging the interfaces is achieved.

Please refer to fig. 6, which is a schematic structural diagram of another interface invoking device according to an embodiment of the present disclosure. The interface calling device can be applied to a business engine management end. Specifically, the interface calling device may include:

the communication module 601 is configured to receive an interface request of a requester for a target service.

A processing module 602, configured to load updated interface metadata in a target service when it is determined that the updated interface metadata exists in the target service; and the updated interface metadata is obtained by updating the interface metadata of the target service by the middle service equipment by using the interface arrangement data sent by the service engine management end.

The processing module 602 is further configured to start executing the method of the interface to which the interface request is directed, and during the execution of the method of the interface, if a statement for calling a functional unit of the interface is detected, obtain a start-stop state of the functional unit, and operate the functional unit when it is determined that the start-stop state is enabled; the functional unit is an event or a rule associated with the event.

The communication module 601 is further configured to obtain response result data of the interface request after the interface execution method is completed, and return the response result data to the requester.

In an optional implementation manner, the functional unit includes rules related to events, where the rules include dynamic rules, and the dynamic rules are rules newly added to the service engine management end or rules of interfaces of other services; the processing module 602 runs the functional unit, specifically, when the rule includes a dynamic rule, initializes an object corresponding to the dynamic rule, and starts a script engine to run the dynamic rule.

In an optional implementation manner, the processing module 602 is further configured to receive an interface metadata query instruction sent by the service engine management end through the communication module 601, query the interface metadata of the target service according to identification information of the target service carried by the interface metadata query instruction, and send the interface metadata of the target service to the service engine management end through the communication module 601; or, when the target service runs, scanning a preset annotation in the target service through a service engine client software development kit to obtain the target service interface metadata, and sending the interface metadata of the target service to the service engine management end through a communication module 601.

It can be seen that, in the embodiment shown in fig. 6, the interface calling device may receive an interface request of a requester for a target service, and load updated interface metadata in the target service when it is determined that the updated interface metadata exists in the target service; then, the interface calling device may start to execute the method of the interface to which the interface request is directed, and during the execution of the method of the interface, if a call statement to the functional unit of the interface is detected, obtain a start-stop state of the functional unit, and operate the functional unit after determining that the start-stop state is enabled, thereby obtaining response result data to the interface request after the execution of the method of the interface is completed, and returning the response result data to the requesting party, so that the calling process of the interface is more flexible and easy to control.

Please refer to fig. 7, which is a schematic structural diagram of an electronic device according to the present application. The electronic device may be a service engine management terminal or a central service device as mentioned in the foregoing embodiments. The electronic device described in the embodiment of the present application may include: one or more processors 1000, one or more input devices 2000, one or more output devices 3000, and memory 4000. The processor 1000, the input device 2000, the output device 3000, and the memory 4000 may be connected by a bus. The input device 2000, the output device 3000 may include standard wired or wireless communication interfaces. The input device 2000 may further include a touch screen or a touch display screen, and the output device 3000 may further include a display screen or a touch display screen, which are not limited in this embodiment.

The Processor 1000 may be a Central Processing Unit (CPU), and may be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 4000 may be a high-speed RAM memory or a non-volatile memory (e.g., a magnetic disk memory). The memory 4000 is used to store a computer program comprising program instructions.

In this embodiment, when the electronic device is a service engine management end, the processor 1000 is configured to invoke the program instruction, and execute the following steps:

receiving, by an input device 2000, interface metadata of a target service sent by a middlebox service device, where the interface metadata includes an interface list and internal processing logic of each of a plurality of interfaces indicated by the interface list;

loading the internal processing logic of each interface on an interface management interface through the output device 3000;

and sending the interface arrangement data to the center service equipment through the output equipment 3000, so that the center service equipment realizes interface calling according to the interface arrangement data.

In one embodiment, the interface metadata is obtained by querying, by the middle station service device, according to identification information of a target service carried by the interface metadata query instruction after receiving the interface metadata query instruction sent by the service engine management end; or, the interface metadata is obtained by the middle service equipment according to a preset annotation in the target service through a business engine client software development kit when the target service runs.

In one embodiment, the interface list includes description information of each of the plurality of interfaces; the internal processing logic of the interface comprises identification information of an event of the interface and identification information of a rule associated with the event; the events are divided into pre-events and post-events, and the rules are divided into pre-rules and post-rules.

In one embodiment, in orchestrating the processing of internal processing logic of a target interface of the plurality of interfaces, processor 1000 is configured to invoke the program instructions to perform at least one of:

In this embodiment, when the electronic device is a middle service device, the processor 1000 is configured to invoke the program instruction, and perform the following steps:

receiving an interface request for a target service from a requester through the input device 2000;

after the method of executing the interface is completed, response result data to the interface request is obtained, and the response result data is returned to the requester through the output device 3000.

In one embodiment, the functional unit includes rules related to events, and the rules include dynamic rules, where the dynamic rules are rules added by the service engine management end or rules of interfaces of other services; in executing the functional units, the processor 1000 is configured to call the program instructions to perform the following steps:

In one embodiment, the processor 1000 is configured to invoke the program instructions and further perform the steps of:

receiving an interface metadata query instruction sent by the service engine management end through an input device 2000, querying interface metadata of a target service according to identification information of the target service carried by the interface metadata query instruction, and sending the interface metadata of the target service to the service engine management end; or the like, or, alternatively,

when the target service runs, scanning a preset annotation in the target service through a business engine client software development kit to obtain the target service interface metadata, and sending the interface metadata of the target service to the business engine management end through the output device 3000.

In a specific implementation, the processor 1000, the input device 2000, and the output device 3000 described in this embodiment of the application may execute the implementation described in the embodiment of fig. 2 or the embodiment of fig. 4, and may also execute the implementation described in this embodiment of the application, which is not described herein again.

The functional modules in the embodiments of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules are integrated into one module. The integrated module can be realized in a form of sampling hardware, and can also be realized in a form of sampling software functional modules.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The computer readable storage medium may be volatile or nonvolatile. For example, the computer storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like. The computer-readable storage medium may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function, and the like; the storage data area may store data created according to the use of the blockchain node, and the like.

The block chain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product service layer, an application service layer, and the like.

While the invention has been described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

1. An interface calling method is applied to a service engine management end and comprises the following steps:

2. The method of claim 1,

the interface metadata is obtained by inquiring according to identification information of a target service carried by the interface metadata inquiry instruction after the interface metadata inquiry instruction sent by the service engine management end is received by the middle service equipment; or the like, or, alternatively,

3. The method of claim 1,

the interface list includes description information of each of the plurality of interfaces;

4. The method according to any of claims 1-3, wherein said performing orchestration processing on internal processing logic of a target interface of said plurality of interfaces comprises at least one of:

5. An interface calling method is applied to a middle station service device, and comprises the following steps:

receiving an interface request of a requester for a target service;

6. The method of claim 5, wherein the functional unit comprises rules associated with events, and the rules comprise dynamic rules, and the dynamic rules are rules added by the service engine management side or rules of interfaces of other services; the operating the functional unit includes:

7. The method of claim 5 or 6, further comprising:

8. An interface calling device, applied to a service engine management end, includes:

9. An interface calling device, which is applied to a middle station service device, includes:

10. An electronic device comprising a processor, an input device, an output device, and a memory, the processor and the memory being interconnected, wherein the memory is configured to store a computer program comprising program instructions, the processor being configured to invoke the program instructions, to perform the method of any of claims 1-4, or to perform the method of any of claims 5-7.