CN114153626A

CN114153626A - Method and device for abstracting service integration process and computer equipment

Info

Publication number: CN114153626A
Application number: CN202111277479.XA
Authority: CN
Inventors: 刘俊楠
Original assignee: Shenzhen Kingdee Tianyanyun Computing Co ltd
Current assignee: Shenzhen Kingdee Tianyanyun Computing Co ltd
Priority date: 2021-10-29
Filing date: 2021-10-29
Publication date: 2022-03-08

Abstract

The application relates to a method, an apparatus, a computer device and a storage medium for service integration process abstraction. The method comprises the following steps: acquiring target API service data, and configuring and caching the target API service data; receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to a target API through the target service unique identifier when the call request passes through an ESB unified door entrance; finding a target protocol, target protocol information and a mapping relation in the cached target data through the target service unique identifier, and completing data mapping by using the mapping relation; and storing the mapped data into the target protocol, creating a corresponding protocol client by using the target service protocol information, sending a request through the protocol client, and completing the calling of the API.

Description

Method and device for abstracting service integration process and computer equipment

Technical Field

The present application relates to the field of network communication technologies, and in particular, to a method and an apparatus for abstracting a service integration process, a computer device, and a storage medium.

Background

With the development of network communication technology, the interaction of business data between enterprises becomes increasingly important. Generally, an enterprise opens its core service to a third party Application and a partner in the form of an API (Application Programming Interface) service Interface, so as to fulfill diversified service requirements together. As enterprises develop more and more businesses, more service providers and more service consumers, and when systems using the API interfaces are used, the services need to be managed effectively, instead of the interface docking of one-time customized development of two systems. In order to solve the scenario requirement, an Enterprise generally implements data integration, Service management, Service monitoring, and the like by using an ESB (Enterprise Service Bus) or an API gateway.

With the development and standardization of the internet, the API interface provided by the enterprise system is more and more standardized. For example, in the current common REST (Representational State Transfer, abbreviated as REST) style APIs, since the common protocols and specifications are used in the integration process, operations such as mapping, protocol conversion, Service routing, Service logic transformation, and the like are not required, so that the management directions of APIs such as API authorization, flow control, fusing, load balancing, and the like are mainly focused, the related specifications of the original SOA (Service-Oriented Architecture) are abandoned, and the product of the API gateway is formed.

However, a large number of legacy systems and heterogeneous systems exist in an enterprise, and are not suitable for the API gateway, and an ESB is required to complete enterprise service integration. Both traditional ESBs and API gateways use either adapter mode or proxy mode to enable mediation and integrated management between services.

Disclosure of Invention

In view of the above, there is a need to provide a method, apparatus, computer device and storage medium for service integration process abstraction to reduce business logic in a designer to improve implementation efficiency.

A method of service integration process abstraction, the method comprising:

and acquiring target API service data, and configuring and caching the target API service data.

And receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to the target API through the target service unique identifier when the call request passes through the ESB unified door entrance.

And finding a target protocol, target protocol information and a mapping relation in the cached target data through the unique target service identifier, and completing data mapping by using the mapping relation.

And storing the mapped data into the target protocol, creating a corresponding protocol client by using the target service protocol information, and sending a request through the protocol client to finish the calling of the API.

In one embodiment, after the obtaining the target API service data, and configuring and caching the target API service data, the method further includes:

and distinguishing protocol types, and issuing a uniform API (application program interface) inlet for each type of protocol, wherein the uniform API inlet is the ESB uniform door surface inlet.

And finding different business APIs through a service calling relation, and connecting the ESB unified portal to each API.

The APIs are mutually interconnected to form a network.

In one embodiment, the receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and after the call request passes through an ESB unified portal and is routed to a target API through the target service unique identifier, the method further includes:

and finding a target protocol in the cached target data through the target service unique identification, wherein the target service unique identification corresponds to a specific protocol type.

And according to the type of the protocol, finding the position for storing the parameters in the protocol and extracting the parameters.

And storing the parameters to a new protocol parameter storage position according to preset service requirements to complete protocol conversion.

In one embodiment, the obtaining target API service data, and the configuring and caching the target API service data includes:

and performing service coding on the target API service data.

And determining the service address and the target protocol type of the target API service data.

Caching the target API service data.

In one embodiment, the finding of the target protocol, the target protocol information, and the mapping relationship in the cached target data through the target service unique identifier includes:

and reading the target service unique identification.

And comparing the target protocol, the target protocol information and the information of the mapping relation in the cache with the unique identification of the target service.

And extracting the matched target protocol, target protocol information and mapping relation after comparison, and mapping the target API service data into preset service requirement data according to the mapping relation.

In one embodiment, the storing the mapped data in the target protocol, creating a corresponding protocol client by using the target service protocol information, and sending a request through the protocol client to complete the API call includes:

and storing the mapped data into the parameters of the target protocol.

And extracting the address in the target protocol information, creating a corresponding protocol client by using the address, and sending a request through the protocol client to finish the calling of the API.

In one embodiment, after obtaining the mapping relationship between the target service data and the corresponding cache data through the service unique identifier and the corresponding API and completing data mapping, the method further includes:

respectively providing the logs of each step of completing API call to form a unified log record;

storing the log record.

An apparatus for service integration process abstraction, the apparatus comprising:

and the acquisition module is used for acquiring the target API service data and configuring and caching the target API service data.

And the receiving module is used for receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to the target API through the target service unique identifier when the call request passes through the ESB unified portal.

And the mapping module is used for finding a target protocol, target protocol information and a mapping relation in the cached target data through the unique target service identifier and finishing data mapping by utilizing the mapping relation.

And the sending module is used for storing the mapped data into the target protocol, creating a corresponding protocol client by using the target service protocol information, and sending a request through the protocol client to finish the calling of the API.

A computer device comprising a memory and a processor, the memory storing a computer program, the processor implementing the following steps when executing the computer program:

A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, carries out the steps of:

According to the method, the device, the computer equipment and the storage medium for abstracting the service integration process, the target API service data is firstly obtained, and the target API service data is configured and cached; then, receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to the target API through the target service unique identifier when the call request passes through an ESB unified portal; then, a target protocol, target protocol information and a mapping relation are found in the cached target data through the target service unique identifier, and data mapping is completed through the mapping relation; finally, the mapped data is stored in the target protocol, a corresponding protocol client is created by using the target service protocol information, the calling of the API is completed by sending a request through the protocol client, the API services of different services of the same protocol type are changed into a portal unified entry from independent one-to-one packaging proxy through the method, the reusability of the integration process is improved, the process of realizing the calling of the static API interface through logics such as branching and judging in an ESB (electronic service bus) designer is changed into the process of realizing the calling of the uniform entry dynamic routing, and the service logics in the designer are reduced, so that the implementation efficiency is improved.

Drawings

FIG. 1 is a diagram of an application environment for a method of service integration process abstraction in one embodiment;

FIG. 2 is a flow diagram that illustrates a method for service integration process abstraction in one embodiment;

FIG. 3 is a flowchart illustrating steps after obtaining target API service data, configuring and caching the target API service data, in one embodiment;

FIG. 4 is a flowchart that illustrates the steps that follow in one embodiment after routing to a target API through a target service unique identifier;

FIG. 5 is a flowchart illustrating steps of obtaining target API service data, configuring and caching the target API service data in one embodiment;

FIG. 6 is a flowchart illustrating steps for performing data mapping using mapping relationships, in one embodiment;

FIG. 7 is a flowchart illustrating steps performed to complete a call to an API in one embodiment;

FIG. 8 is a flowchart illustrating steps after data mapping is completed in one embodiment;

FIG. 9 is a block diagram of an apparatus that provides service integration process abstraction in one embodiment;

FIG. 10 is a schematic diagram of an embodiment;

FIG. 11 is a schematic view of another embodiment;

FIG. 12 is a schematic illustration of yet another embodiment;

FIG. 13 is a diagram illustrating an internal structure of a computer device according to an embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

The method for abstracting the service integration process can be applied to the application environment shown in fig. 1. Wherein the terminal 102 communicates with the server 104 via a network. The server 104 acquires target API service data, configures and caches the target API service data, receives a client API call request, analyzes the call request to obtain a target service unique identifier, and routes the call request to the target API through the target service unique identifier when the call request passes through an ESB unified portal; finding a target protocol, target protocol information and a mapping relation in the cached target data through the target service unique identifier, and completing data mapping by using the mapping relation; and storing the mapped data into the target protocol, creating a corresponding protocol client by using the target service protocol information, and sending a request through the protocol client to finish the calling of the API. The terminal 102 may be, but not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the server 104 may be implemented by an independent server or a server cluster formed by a plurality of servers.

In one embodiment, as shown in fig. 2, a method for abstracting a service integration process is provided, which is described by taking the method as an example applied to the server in fig. 1, and includes the following steps:

step 202, obtaining target API service data, and configuring and caching the target API service data.

The target API service data refers to data such as field mapping relations of integrated systems, API services, messages sent by clients, API service parameter messages, client messages and server messages.

Specifically, the server obtains target API service data, configures the target API service data, and then caches the target API service data.

And step 204, receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to the target API through the target service unique identifier when the call request passes through the ESB unified portal.

The ESB unified portal refers to issuing a unified API portal for each protocol through a portal mode.

Specifically, the server receives a client API call request, and analyzes the call request to obtain a target service unique identifier. When the call request passes through the ESB unified door entrance, the call request can be routed to a target API through the target service unique identifier and cache data is obtained.

And step 206, finding the target protocol, the target protocol information and the mapping relation in the cached target data through the unique target service identifier, and completing data mapping by using the mapping relation.

The target protocol may be HTTP, WEBSERVICE, EJB, MQ, etc.

Specifically, the server finds a target protocol, target protocol information and a mapping relation in the cached target data through the target service unique identifier, and then completes data mapping by using the mapping relation.

And 208, storing the mapped data into the target protocol, creating a corresponding protocol client by using the target service protocol information, and sending a request through the protocol client to finish the calling of the API.

The corresponding protocol client refers to a protocol client created through address information in a target service protocol.

Specifically, the server stores the mapped data into the target protocol, creates a corresponding protocol client by using the target service protocol information, and sends a request through the protocol client to complete the calling of the API.

The method, the device, the computer equipment and the storage medium for abstracting the service integration process acquire target API service data, and configure and cache the target API service data; receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to a target API through the target service unique identifier when the call request passes through an ESB unified door entrance; finding a target protocol, target protocol information and a mapping relation in the cached target data through the target service unique identifier, and completing data mapping by using the mapping relation; and storing the mapped data into the target protocol, creating a corresponding protocol client by using the target service protocol information, sending a request through the protocol client, and completing the calling of the API.

In an embodiment, as shown in fig. 3, after the obtaining target API service data, and configuring and caching the target API service data, the method further includes:

step 302, distinguishing protocol types, and issuing a uniform API entry for each type of protocol, where the uniform API entry is the ESB uniform portal.

Specifically, the server distinguishes protocol types, and issues a uniform API entry for each type of protocol, where the uniform API entry is the ESB uniform portal. For example, the server adapts different protocol accesses by issuing a uniform API entry for each of the HTTP, websevice, EJB, MQ, etc. protocols in the portal mode, these interfaces being the entries for all requests of the client.

And step 304, finding different business APIs through the service calling relation, and connecting the ESB unified portal to each API.

Wherein, the service API refers to an API corresponding to a specific service. The calling relation refers to the relation between the server and the terminal involved in calling the API.

Specifically, the server finds different business APIs through a service calling relation, and connects the ESB unified portal to each API.

And step 306, mutually interconnecting the APIs to form a network.

Specifically, the server interconnects each API to form a mesh structure.

In the embodiment, by distinguishing the protocol types, issuing a uniform API entry for each protocol and interconnecting APIs, the purpose of reducing designers can be achieved.

In an embodiment, as shown in fig. 4, the receiving a client API call request, parsing the call request to obtain a target service unique identifier, and after the call request passes through the ESB unified portal and is routed to the target API through the target service unique identifier, the method further includes:

step 402, finding a target protocol in the cached target data through the target service unique identifier, wherein the target service unique identifier corresponds to a specific protocol type.

The target service unique identifier corresponds to a specific protocol type, which means that the target service unique identifier can only correspond to one protocol type at present and cannot correspond to multiple protocol types at the same time. For example, the target service unique identifier may correspond to the HTTP protocol, but may not correspond to other types of protocols.

Specifically, the server finds a target protocol in the cached target data by using the unique target service identifier, wherein the target protocol contains information matched with the unique target service identifier. When the unique identification of the target service is consistent with the matching information, the target protocol can be found and confirmed.

And step 404, finding the position for storing the parameters in the protocol and extracting the parameters according to the type of the protocol.

The location of storing parameters in different protocols is not fixed, and can be anywhere in the protocol. Parameters refer to specific data or data relationships, etc.

Specifically, the server can distinguish the position of the parameter according to the type of the protocol. After the parameter is identified, the parameter of the position is extracted. The extraction parameter refers to extracting data or data relation through a server.

And step 406, storing the parameters to a new protocol parameter storage position according to preset service requirements, and completing protocol conversion.

The preset service requirement refers to a service requirement corresponding to the API, and here refers to a service requirement corresponding to the new protocol.

Specifically, the preset service requirement is a service requirement corresponding to the API, the content of the preset service requirement is acquired by the server, and then the extracted parameter is placed at a position where a new protocol parameter is stored. In the operation of this step, it is exactly the reverse operation of the previous step, and the purpose of extracting the parameters in the previous step is to put the parameters into the new protocol in this step, so that the protocol conversion is completed.

In this embodiment, the target protocol is found in the cached target data through the unique target service identifier, then the position for storing the parameter in the protocol is found and the parameter is extracted according to the type of the protocol, and finally the parameter is stored to the new protocol parameter storage position according to the preset service requirement, so as to complete the protocol conversion, and the efficiency of the protocol conversion can be improved.

In an embodiment, as shown in fig. 5, the obtaining target API service data, and the configuring and caching the target API service data includes:

step 502, performing service coding on the target API service data.

The service code refers to an information number of the target API service data, and the information number has uniqueness. For example, the information number may be encoded as fwbm03, here to distinguish different API service data in subsequent steps.

Specifically, the server distinguishes the service codes according to the protocol types to be used as the header of the codes, and then the numbers are used for calibrating the times, so that the services can be observed intuitively without disorder. For example: and carrying out service coding on the target API service data into fwbm03, wherein fwbm represents a protocol type, and 03 represents times.

Step 504, determine the service address and the target protocol type of the target API service data.

Service addresses refer to API addresses, such as: under the HTTP protocol, the address of the API may be HTTP:// ip/save or HTTP:// ip/del, etc. The target protocol type may be any type of protocol, such as: one of HTTP, WEBSERVICE, EJB, MQ and other protocols.

Specifically, the server obtains the encoded target API service data, finds out a service address and a target protocol type of the target API service data, and then determines a found result for the purpose of subsequent caching, and the like.

Step 506, caching the target API service data.

The cache is temporary storage, which is different from storage.

Specifically, after the server acquires the service address and the service type of the target API service data, the target API service data is cached for subsequent operations such as data mapping.

In this embodiment, the service address and the type of the target service data may be determined by obtaining the target API service data and then configuring and caching the target API service data.

In an embodiment, as shown in fig. 6, the finding, in the cached target data, the target protocol information, and the mapping relationship through the target service unique identifier includes:

step 602, reading the target service unique identifier.

Specifically, the target service unique identifier is a mark, and the server is required to read the mark first to confirm the correctness of the mark.

And step 604, comparing the target protocol, the target protocol information and the mapping relation information in the cache with the unique target service identifier.

The comparison refers to comparing the information, and when the information is consistent or can be matched, the comparison process is completed.

Specifically, since the target protocol, the target protocol information, and the mapping information are in the cache, the server needs to obtain the information from the cache and then compare the information with the target service unique identifier.

Step 606, extracting the matched target protocol, target protocol information and mapping relation after comparison, and mapping the target API service data into preset service demand data according to the mapping relation.

Wherein a mapping relationship refers to an inherent logical relationship of data transforming from one form to another. For example: and the object relation mapping is used for realizing the conversion between the data of different types of systems in the object-oriented programming language. For another example, data mapping of a database, data mapping into another form of data through logical connections between data.

Specifically, when the comparison result is that the information is consistent or can be matched, the server starts to extract the matched target protocol, the target protocol information and the mapping relation after the comparison. And then, mapping the target API service data into preset service demand data according to the mapping relation.

In this embodiment, the target protocol information, and the mapping relationship are found in the cached target data through the target service unique identifier, and the data mapping is completed by using the mapping relationship, so that the data mapping efficiency can be improved.

In an embodiment, as shown in fig. 7, the storing the mapped data in the target protocol, creating a corresponding protocol client using the target service protocol information, and sending a request through the protocol client to complete the API call includes:

step 702, storing the mapped data into the parameters of the target protocol;

specifically, the mapped data is preset service requirement data, and the data needs to be put into a protocol related to the preset service requirement. Therefore, the server stores the mapped data in the parameters of the target protocol, and the target protocol parameters refer to the relationship between the data and the data in the target protocol.

Step 704, extracting the address in the target protocol information, creating a corresponding protocol client by using the address, and sending a request through the protocol client to complete the calling of the API.

Specifically, the protocol client is created mainly by an address, and therefore the server needs to extract the address in the target protocol information first, and then create the corresponding protocol client by using the address. The success flag of the API call is that the request is sent by the protocol client, and therefore, the server needs to send the request by the protocol client to complete the API call.

In this embodiment, the mapped data is stored in the target protocol, the corresponding protocol client is created by using the target service protocol information, and the API call is completed by sending a request through the protocol client, so that the business logic in the designer can be reduced.

In an embodiment, as shown in fig. 8, after obtaining the mapping relationship between the target service data and the corresponding cache data through the service unique identifier and the corresponding API, and completing data mapping, the method further includes:

and step 802, respectively providing the logs of each step for completing the API call, and forming a unified log record.

The log record refers to an operation record generated in each operation step after the program, the application and the like are operated, and the record contains information such as an operation state, parameter change and the like.

Specifically, the server respectively provides logs of each step of completing the API call to form a unified log record, each step of completing the API call comprises all links and steps, and the generated log records are uniformly presented here.

Step 804, storing the log record.

Specifically, the server stores the log records for easy viewing at any time.

In this embodiment, by using the method of forming the log record, the log record can be conveniently searched.

It should be understood that although the various steps in the flow charts of fig. 1-8 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 1-8 may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed in turn or alternately with other steps or at least some of the other steps.

In one embodiment, as shown in FIG. 9, an apparatus for providing service integration process abstraction, comprises: the device comprises an acquisition module, a receiving module, a mapping module and a sending module, wherein:

the system comprises an acquisition module, a cache module and a processing module, wherein the acquisition module is used for acquiring target API service data and configuring and caching the target API service data;

the receiving module is used for receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to the target API through the target service unique identifier when the call request passes through the ESB unified portal;

the mapping module is used for finding a target protocol, target protocol information and a mapping relation in the cached target data through the target service unique identifier and finishing data mapping by utilizing the mapping relation;

In one embodiment, as shown in fig. 9, an apparatus for providing service integration process abstraction further comprises:

and the issuing module is used for distinguishing protocol types and issuing a uniform API (application program interface) inlet for each type of protocol, wherein the uniform API inlet is the ESB uniform door surface inlet.

And the connection module is used for finding different business APIs through a service calling relation and connecting the ESB unified portal to each API.

And the interconnection module is used for interconnecting the APIs to form a network.

the first searching module is used for finding a target protocol in the cached target data through the target service unique identifier, and the target service unique identifier corresponds to a specific protocol type;

the second searching module is used for finding the position of the stored parameter in the protocol and extracting the parameter according to the type of the protocol;

and the conversion module is used for storing the parameters to a new protocol parameter storage position according to the preset service requirement to complete protocol conversion.

the coding module is used for carrying out service coding on the target API service data;

the confirming module is used for determining the service address and the target protocol type of the target API service data;

and the cache module is used for caching the target API service data.

the reading module is used for reading the unique identification of the target service;

the comparison module is used for comparing the target protocol, the target protocol information and the mapping relation information in the cache with the unique target service identifier;

and the extraction module is used for extracting the matched target protocol, the target protocol information and the mapping relation after comparison, and mapping the target API service data into preset service requirement data according to the mapping relation.

the first storage module is used for storing the mapped data into the parameters of the target protocol;

and the creating module is used for extracting the address in the target protocol information, creating a corresponding protocol client by using the address, and sending a request through the protocol client to complete the calling of the API.

the recording module is used for respectively providing the logs of each step of completing API calling to form a unified log record;

and the second storage module is used for storing the log record.

In a specific embodiment, as shown in fig. 10, the ESB/API system obtains target API service data, and configures and caches the target API service data; then receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to the target API through the target service unique identifier when the call request passes through an ESB unified door entrance; then, a target protocol, target protocol information and a mapping relation are found in the cached target data through the target service unique identifier, and data mapping is completed through the mapping relation; and finally, storing the mapped data into the target protocol, creating a corresponding protocol client by using the target service protocol information, and sending a request through the protocol client to finish the calling of the API. The client side initiates a request call to an HTTP unified interface provided by the ESB, and introduces a unique identifier of a parameter call API, for example, an HTTP protocol can add a request parameter to middle params or headers, and the client side accesses the ESB/API system unified entry in an HTTP: ip: portAPI identifier-OA.

In a specific embodiment, as shown in fig. 11, the ESB/API system distinguishes protocol types, and issues a uniform API entry for each type of protocol, where the uniform API entry is the ESB uniform portal; then, different business APIs are found through a service calling relation, and the ESB unified portal is connected to each API; and finally, mutually interconnecting the APIs to form a network. For example, terminal 1, terminal 2, and terminal 3 may unify the door portals and then find the corresponding API. Among these, API1, API2, API3 and API4 are not only connected by a unified door facing portal, but are also interconnected with each other.

In one embodiment, as shown in FIG. 12, the ESB/API system reads the target service unique identifier; then comparing the target protocol, the target protocol information and the mapping relation information in the cache with the unique target service identifier; and finally, extracting the matched target protocol, target protocol information and mapping relation after comparison, and mapping the target API service data into preset service demand data according to the mapping relation. For example, the client sends an ESB/API system message "name: zhang III, age: 20 ', the ESB/API system obtains the data mapping relation between the client and the target service according to the unique identification of the API and the system to complete mapping, specifically, the mapping is realized by mapping ' name ' to ' name ', ' age ' to ' age ', and ' default value 1 ' to ' state 1 '. The message mapped by the ESB/API system is' name: zhang three, age: 20, state: 1 "and passed into the API server.

For a specific definition of the means for abstracting the service integration process, reference may be made to the above definition of the method for abstracting the service integration process, which is not described in detail herein. The various modules in the above-described apparatus for service integration process abstraction may be implemented in whole or in part by software, hardware, and combinations thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in fig. 13. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing data abstracted by a service integration process. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a method of service integration process abstraction.

Those skilled in the art will appreciate that the architecture shown in fig. 13 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, a computer device is provided, comprising a memory and a processor, the memory having a computer program stored therein, the processor implementing the following steps when executing the computer program:

In one embodiment, the processor, when executing the computer program, further performs the steps of:

The APIs are mutually interconnected to form a network.

and performing service coding on the target API service data.

Caching the target API service data.

and reading the target service unique identification.

and storing the mapped data into the parameters of the target protocol.

and respectively providing the logs of each step of completing the API call to form a unified log record.

Storing the log record.

In one embodiment, a computer-readable storage medium is provided, having a computer program stored thereon, which when executed by a processor, performs the steps of:

In one embodiment, the computer program when executed by the processor further performs the steps of:

The APIs are mutually interconnected to form a network.

and performing service coding on the target API service data.

Caching the target API service data.

and reading the target service unique identification.

and storing the mapped data into the parameters of the target protocol.

Storing the log record.

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 hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database or other medium used in the embodiments provided herein can include at least one of non-volatile and volatile memory. Non-volatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical storage, or the like. Volatile Memory can include Random Access Memory (RAM) or external cache Memory. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), among others.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A method of service integration process abstraction, the method comprising:

acquiring target API service data, and configuring and caching the target API service data;

receiving a client API call request, analyzing the call request to obtain a target service unique identifier, and routing the call request to a target API through the target service unique identifier when the call request passes through an ESB unified door entrance;

finding a target protocol, target protocol information and a mapping relation in the cached target data through the target service unique identifier, and completing data mapping by using the mapping relation;

2. The method of claim 1, wherein after obtaining the target API service data, configuring and caching the target API service data, the method further comprises:

distinguishing protocol types, and issuing a uniform API (application program interface) inlet for each type of protocol, wherein the uniform API inlet is the ESB uniform door surface inlet;

finding different business APIs through a service calling relation, and connecting the ESB unified portal to each API;

the APIs are mutually interconnected to form a network.

3. The method of claim 1, wherein the receiving a client API call request, parsing the call request to obtain a target service unique identifier, and after the call request is routed to a target API through the target service unique identifier when passing through an ESB unified portal, further comprises:

finding a target protocol in the cached target data through the target service unique identification, wherein the target service unique identification corresponds to a specific protocol type;

according to the type of the protocol, finding the position of the stored parameter in the protocol and extracting the parameter;

4. The method of claim 1, wherein the obtaining, configuring, and caching the target API service data comprises:

performing service coding on the target API service data;

determining a service address and a target protocol type of the target API service data;

caching the target API service data.

5. The method of claim 1, wherein the finding of the target protocol, the target protocol information, and the mapping relationship in the cached target data through the target service unique identifier, and the performing data mapping using the mapping relationship comprises:

reading the target service unique identification;

comparing the target protocol, the target protocol information and the mapping relation information in the cache with the unique target service identifier;

6. The method of claim 1, wherein the storing the mapped data into the target protocol, creating a corresponding protocol client using the target service protocol information, and sending a request through the protocol client to complete the API call comprises:

storing the mapped data into the parameters of the target protocol;

7. The method according to claim 1, wherein after obtaining the mapping relationship between the target service data and the corresponding cache data through the service unique identifier and the corresponding API and completing data mapping, the method further comprises:

storing the log record.

8. An apparatus for service integration process abstraction, the apparatus comprising:

9. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method of any of claims 1 to 7.

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.