KR20240176104A - Cloud computing system and method of processing api using the same - Google Patents

Abstract

A cloud communication platform and a method for processing a REST API (Representational State Transfer Application Programming Interface) using the same may be disclosed. According to one embodiment, the cloud communication platform may include: a feature server that provides a voice service and a video communication service to a customer; an element management system (EMS) that provides a customer with an integrated management portal capable of integrally provisioning feature servers, generates a transaction code of a REST API for provisioning with the feature server, and transmits a request of a REST API including the transaction code; and an API relay server that is connected to the feature server and the EMS, receives a request of a REST API from the EMS, performs rerouting processing of the REST API and transmits it to the feature server, and determines whether transmission of the REST API has failed based on the transaction code and transmits a response to the request of the REST API to the EMS.

Description

Cloud computing system and API processing method using the same {CLOUD COMPUTING SYSTEM AND METHOD OF PROCESSING API USING THE SAME}

The present disclosure relates to a cloud computing system and an API (Application Programming Interface) processing method using the same.

The cloud communication platform provides voice and video communication services and includes multiple feature servers including a Unified Communications Manager (UCM) to provide these services. In addition, the cloud communication platform includes an integrated management portal server (Element Management System (EMS)) that provisions multiple feature servers.

Feature servers provide customers with an integrated management portal that can provision each server in an integrated manner to accommodate customers in a cloud environment. The EMS that performs this function is implemented to send requests for provisioning and receive responses using the REST (Representational State Transfer) API interface that is widely used in various feature servers and microservices that make up the communication service platform.

According to the conventional art, the provisioning block (business logic of web application) that processes customer requests such as addition, change, and deletion of various communication services as well as users or client devices through the cloud integrated management portal server (EMS) consists of logic for accessing a database, logic for processing a series of API requests and responses, and logic for processing rollback in the event of a failure during a series of APIs. This not only makes the maintenance of cloud communication services difficult, but also increases the complexity of the rollback processing of provisioning due to a failure of a REST API request in the event of a communication failure between the integrated management portal server and the feature server, so that the rollback may not be performed normally. In the worst case, a problem may arise where a professional server operator must manually perform database recovery.

According to the present disclosure, a cloud computing system that performs rollback processing of a REST API (Representational State Transfer Application Programming Interface) based on a transaction code of the REST API and an API processing method using the same can be provided.

According to one embodiment of the present disclosure, a cloud computing system may be disclosed. The cloud computing system according to one embodiment may include: a feature server that provides a voice service and a video communication service to a customer; an integrated management portal server (EMS) that provides the customer with an integrated management portal capable of integrally provisioning the feature server, generates a transaction code of a REST API (Representational State Transfer Application Programming Interface) for provisioning with the feature server, and transmits a request of the REST API including the transaction code; and an API relay server that is connected to the feature server and the EMS, receives a request of the REST API from the EMS, performs a rerouting process of the REST API and transmits it to the feature server, and determines whether transmission of the REST API has failed based on the transaction code and transmits a response to the request of the REST API to the EMS.

In one embodiment, the EMS may assign the same transaction code to a series of REST APIs constituting a single transaction unit so that the series of REST APIs constituting a single transaction unit are detected as the same transaction by the API relay server.

In one embodiment, the EMS may generate the transaction code by combining timestamp information and a randomly generated code.

In one embodiment, the EMS may generate the transaction code by combining timestamp information and an API sequence number.

In one embodiment, the API relay server includes a database storing feature server information about the feature server, and the API relay server can perform the rerouting processing for the REST API based on the feature server information.

In one embodiment, the API relay server may perform URL conversion processing to convert a URL of a request for the REST API into a URL of the feature server so that the feature server receives the REST API, and transmit the URL-converted REST API to the feature server.

In one embodiment, the API relay server includes a database storing API information including the transaction code, and the API relay server can search the database at preset intervals to detect a transaction code of a REST API in which an API failure has occurred, and perform rollback processing of the REST API based on the detected transaction code.

In one embodiment, the API relay server can detect a REST API assigned a transaction code identical to the detected transaction code from the database, detect a successful REST API from the detected REST API, and perform rollback processing of the REST API in reverse chronological order for the successful REST API.

In one embodiment, when an API failure occurs as a result of performing rollback processing of the REST API, the API relay server can display a failure in a rollback result column on an EMS provisioning API list query screen that can query a list of EMS provisioning APIs, and activate a rollback button for rollback processing of the REST API.

According to one embodiment of the present disclosure, an API (Application Programming Interface) processing method using a cloud computing system may be disclosed. The API processing method according to one embodiment may include: a step of generating a transaction code of a REST (Representational State Transfer) API for provisioning and a feature server providing a voice service and a video communication service to a customer in an EMS of the cloud computing system; a step of transmitting, in the EMS, a REST API including the transaction code; a step of receiving, in an API relay server of the cloud computing system, a request of the REST API; a step of performing rerouting processing of the REST API in the API relay server and transmitting the rerouting processing to the feature server; and a step of determining, in the API relay server, whether transmission of the REST API has failed based on the transaction code and transmitting, to the EMS, a response to the request of the REST API.

In one embodiment, the step of generating a transaction code of the REST API may include the step of assigning the same transaction code to a series of REST APIs constituting one transaction unit so that the series of REST APIs constituting one transaction unit are detected as the same transaction by the API relay server.

In one embodiment, the step of generating a transaction code of the REST API may include a step of generating the transaction code by combining timestamp information and a randomly generated code.

In one embodiment, the step of generating a transaction code of the REST API may include the step of generating the transaction code by combining timestamp information and an API sequence number.

In one embodiment, the API relay server includes a database storing feature server information about the feature server, and the step of performing rerouting processing of the REST API and transmitting it to the feature server may include a step of performing the rerouting processing for the REST API based on the feature server information.

In one embodiment, the step of performing rerouting processing of the REST API and transmitting it to the feature server may include the step of performing URL conversion processing to convert a URL of a request of the REST API into a URL of the feature server so that the feature server receives the REST API; and the step of transmitting the REST API, which has been subject to URL conversion processing, to the feature server.

In one embodiment, the API relay server includes a database storing API information including the transaction code, and the step of determining whether transmission of the REST API has failed based on the transaction code and transmitting a response to a request of the REST API to the EMS may include the step of searching the database at preset intervals to detect a transaction code of a REST API in which an API failure has occurred; and the step of performing rollback processing of the REST API based on the detected transaction code.

In one embodiment, the step of performing rollback processing of the REST API based on the detected transaction code may include the steps of: detecting a REST API to which a transaction code identical to the detected transaction code is assigned from the database; detecting a successful REST API from the detected REST API; and performing rollback processing of the REST API in reverse chronological order for the successful REST API.

In one embodiment, the step of performing rollback processing of the REST API based on the detected transaction code may include the step of the API relay server, when an API failure occurs as a result of performing the rollback processing of the REST API, displaying a failure in a rollback result column on an EMS provisioning API list query screen capable of querying a list of EMS provisioning APIs; and the step of activating a rollback button for the rollback processing of the REST API.

According to various embodiments of the present disclosure, when a failure occurs among a series of API requests constituting one transaction due to a network error or other causes, a rollback of the previously executed API requests can be processed in real time.

In addition, in cases where the rollback of an executed API request cannot be processed in real time, a stable rollback processing of the API can be performed using an asynchronous scheduler that stores API information in a database and can process the rollback of the API request in the background, thereby ensuring data integrity between the EMS and the Feature server.

Figure 1 is an interface configuration diagram between an integrated management portal server (Element Management System, EMS) and a feature server in a general cloud communication platform.
Figure 2 is a diagram showing an API processing routine in EMS of a general cloud communication platform.
FIG. 3 is a block diagram illustrating a cloud computing system according to one embodiment of the present disclosure.
FIG. 4 is an exemplary diagram showing API information stored in an API rollback table of a database of an API relay server according to one embodiment of the present disclosure.
FIG. 5 is a diagram illustrating an EMS provisioning API list query screen according to one embodiment of the present disclosure.
FIG. 6 is an example diagram illustrating rerouting of a REST API according to one embodiment of the present disclosure.
FIG. 7 is a diagram illustrating an API processing routine in an EMS according to one embodiment of the present disclosure.
FIG. 8 is a flowchart illustrating the operation of an API relay server according to one embodiment of the present disclosure.

The embodiments of the present disclosure are provided for the purpose of explaining the technical idea of the present disclosure. The scope of rights according to the present disclosure is not limited to the embodiments presented below or the specific description of these embodiments.

All technical and scientific terms used in this disclosure, unless otherwise defined, have the meaning commonly understood by one of ordinary skill in the art to which this disclosure belongs. All terms used in this disclosure have been selected for the purpose of more clearly describing this disclosure and are not selected to limit the scope of rights under this disclosure.

The expressions “including,” “comprising,” “having,” and the like, used in this disclosure, should be understood as open-ended terms implying the possibility of including other embodiments, unless otherwise stated in the phrase or sentence in which the expression is included.

The singular forms described in this disclosure may include plural meanings unless otherwise stated, and the same applies to the singular forms recited in the claims.

The expressions “first,” “second,” etc. used in this disclosure are used to distinguish between multiple components, and do not limit the order or importance of the components.

The expression "based on" as used in this disclosure is used to describe one or more factors affecting an act or action of making a decision, judgment, or action described in a phrase or sentence containing the expression, and this expression does not exclude additional factors affecting the act or action of making a decision, judgment, or action.

In this disclosure, when a component is referred to as being "connected" or "connected" to another component, it should be understood that the component can be directly connected or connected to the other component, or can be connected or connected via a new other component.

Hereinafter, embodiments of the present disclosure will be described with reference to the attached drawings. In the attached drawings, identical or corresponding components are given the same reference numerals. In addition, in the description of the embodiments below, redundant description of identical or corresponding components may be omitted. However, even if the description of a component is omitted, it is not intended that such a component is not included in any embodiment.

Fig. 1 shows an interface configuration diagram between an integrated management portal server and a feature server in a general cloud communication platform. Referring to Fig. 1, the cloud communication platform includes a feature server (110) and an EMS (120). The feature server (110) may include a UCM server (111), a tone server (112), a call recording server (113), a voice mail server (114), and a web fax server (115). TCP (Transmission Control Protocol) is used between the feature servers (110). Data can be transmitted and received using a socket. That is, data is transmitted and received between the UCM (111), tone server (112), call recording server (113), voice mail server (114), and web fax server (115) through a TCP socket.

EMS (120) performs a function of providing a customer with an integrated management portal that can comprehensively provision the feature server (110) so that the feature server (110) can accommodate customers in a cloud environment. EMS (120) transmits a request for provisioning to the feature server (110) and receives a response thereto using a REST API interface that is widely used in microservices that constitute a communication service platform. That is, EMS (120) performs data transmission and reception with the UCM (111), tone server (112), call recording server (113), voice mail server (114), and web fax server (115) of the feature server (110) using the REST API interface.

EMS (120) includes a provisioning block (business logic of a web application) that processes not only users and client devices but also customer requests (e.g., adding, changing, or deleting multiple communication services). In addition, the provisioning block is mixed with logic for accessing a database, logic for processing a series of API requests and responses, and logic for performing rollback processing when a failure occurs during a series of APIs. For example, as shown in FIG. 2, EMS (120) stores data for rollback processing and performs rollback processing of previously successful APIs when a failure occurs during a series of APIs. This makes it difficult to maintain the cloud communication service, and in addition, when a communication failure occurs between EMS (120) and the feature server (110), the complexity of the rollback processing of provisioning due to the transmission failure of the REST API increases, so that the rollback may not be performed normally. Therefore, a method for performing stable rollback of the API is urgently required even when some failures occur during a series of API requests.

FIG. 3 is a block diagram illustrating a cloud computing system according to one embodiment of the present disclosure. The communication platform (Cloud Unified Communications (UC) Platform) of the cloud computing system according to the present disclosure may include a feature server (310), an Element Management System (EMS) (320), and an Application Programming Interface (API) relay server (330).

The feature server (310) can provide voice services and video communication services to customers. In one embodiment, the feature server (310) can include a plurality of servers for providing voice services and video communication services. For example, the feature server (310) can include a UCM (Unified Communications Manager) server (311), a Tone server (312), a Call Recording server (313), a Voice Mail server (314), and a Web FAX server (315), as illustrated in FIG. 3.

In one embodiment, the feature server (310) can send and receive data using a TCP socket. For example, data can be sent and received between the UCM server (311), the tone server (312), the call recording server (313), the voice mail server (314), and the web fax server (315) through the TCP socket.

The EMS (320) may perform a function of providing a customer with an integrated management portal that can comprehensively provision the feature server (310) so that the feature server (310) can accommodate the customer in a cloud environment. In one embodiment, the EMS (320) may transmit a request for provisioning to the feature server (310) and receive a response thereto using a REST API (Representational State Transfer Application Programming Interface) that is widely used in microservices that constitute a communication service platform.

According to various embodiments, the EMS (320) may generate a transaction code for transmitting a REST API. In one embodiment, the EMS (320) may generate a transaction code for transmitting a REST API to an API relay server (330), and transmit a request for a REST API including the generated transaction code to the API relay server (330).

According to various embodiments, the EMS (320) may assign the same transaction code to a series of REST APIs constituting one transaction unit. In one embodiment, the EMS (320) may assign the same transaction code to a series of REST APIs constituting one transaction unit so that the series of REST APIs constituting one transaction unit are detected as the same transaction by the API relay server (330).

According to various embodiments, the EMS (320) may generate a transaction code by combining time stamp information and an API sequence number. In one embodiment, the EMS (320) may generate a transaction code by combining time stamp information and an API sequence number so that a background rollback scheduler (not shown) of the API relay server (330) can query a REST API constituting one transaction unit.

For example, if three REST APIs constitute one transaction unit, EMS (320) can generate a transaction code by combining timestamp information and API sequence numbers as shown below.

(1) Transaction code of the 1st REST API: 2022-10-18 17:33:30.975 000

(2) Transaction code of the 2nd REST API: 2022-10-18 17:33:30.975 001

(3) Transaction code of the 3rd REST API: 2022-10-18 17:33:30.975 002

Here, "2022-10-18 17:33:30.975" represents timestamp information. In addition, "000", "001", and "002" are API sequence numbers, which are information to prevent duplication of transaction codes used as index keys when storing REST API information in a database (not shown).

In the above example, it has been described that the transaction code is generated by combining the timestamp information and the API sequence number, but it is not necessarily limited to this, and when storing REST API information in a database (not shown), the transaction code may be generated by combining a randomly generated code to prevent duplication of the transaction code.

The API relay server (330) may be connected to the feature server (310) and the EMS (320). The API relay server (330) may process a task related to rollback based on a request for a REST API provided from the EMS (320). In addition, the API relay server (330) may perform an operation for rerouting a REST API to the feature server (310) based on a request for a REST API provided from the EMS (320).

According to various embodiments, the API relay server (330) may include a database (not shown) for storing information related to the REST API (hereinafter, “API information”) and information related to the feature server (310) (hereinafter, “feature server information”).

According to various embodiments, the API relay server (330) may store API information for rollback processing in a database based on the REST API provided from the EMS (320). In one embodiment, the API information may include a transaction code, an API type, a receiving API URL of the API relay server (330), a transmitting API URL of the API relay server (330), a feature server name, "Request Body", "Request Time", "Request Result", "Rollback Request", and "Rollback Try Count".

According to various embodiments, the API relay server (330) may include a background rollback scheduler (not shown). In one embodiment, the background rollback scheduler of the API relay server (330) may store API information in an API rollback table of a database, as shown in FIG. 4, based on a REST API provided from the EMS (320).

According to various embodiments, the API relay server (330) may receive a request for a REST API from the EMS (320) and process a series of tasks related to a rollback in response to the received request for the REST API. In one embodiment, the background rollback scheduler of the API relay server (330) may process a series of tasks related to a rollback by using a transaction code assigned to the REST API. For example, the API relay server (330) may process a series of tasks related to a rollback in batches by using a transaction code assigned to an http message body of the REST API.

According to various embodiments, the API relay server (330) may store API information including a transaction code in a database for rollback processing, and store a REST API response result, which is converted into a URL and transmitted to the feature server (310), in a Request Result column of a previously added API information record. In one embodiment, the Request Result column may be used as a search condition when the background rollback scheduler of the API relay server (330) searches the API rollback table of the database, and when an "API Fail" occurs, the transaction code of the API where the failure occurred may be used to search a list of previously successful APIs so that a rollback API suitable for each API can be transmitted to the corresponding feature server.

According to various embodiments, the background rollback scheduler of the API relay server (330) can check the REST API transmitted from the API relay server (330) to the feature server (310), determine whether a failure in API transmission (“API Fail”) has occurred, and perform rollback processing of the REST API.

According to various embodiments, the background rollback scheduler of the API relay server (330) may search the API rollback table of the database at preset intervals to detect a transaction code of a REST API in which an API failure has occurred, and perform rollback processing based on the detected transaction code. In one embodiment, the background rollback scheduler may detect, from the API rollback table of the database, a REST API to which a transaction code identical to the transaction code of a REST API in which an API failure has occurred, detect a successful REST API (i.e., a REST API in which an API failure has not occurred) from the detected REST APIs, and perform rollback processing in reverse chronological order for the successful REST APIs.

According to various embodiments, the background rollback scheduler of the API relay server (330) may provide a screen (hereinafter, referred to as “EMS provisioning API list query screen”) for querying a list of EMS provisioning APIs when “API Fail” occurs as a result of performing rollback processing of a REST API. In one embodiment, the background rollback scheduler of the API relay server (330) may display “Fail” in the rollback result column on the EMS provisioning API list query screen, as illustrated in FIG. 5, and activate the rollback button under the Operation column. Accordingly, the EMS web administrator may manually perform rollback processing through the EMS provisioning API list query screen.

According to various embodiments, the search cycle of the background rollback scheduler of the API relay server (330) and the setting value of the rollback try count of the API can be set by the user. In one embodiment, the search cycle of the background rollback scheduler and the setting value of the rollback try count of the API can be set in a configuration file or database stored locally in the API relay server (330).

According to various embodiments, if the background rollback scheduler of the API relay server (330) transmits a rollback API as many times as the number of rollback attempts of the API and the rollback is not successful, the rollback result column may be displayed as "Fail" on the EMS provisioning API list query screen and the rollback button may be activated. Accordingly, the EMS web administrator can view the API list through the EMS provisioning API list query screen, and after eliminating the cause of the failure of the API, click the transmission button of the corresponding API to process the rollback API to be transmitted. At this time, a new API for the same resource waiting for the rollback may be prohibited until the rollback is successful.

According to various embodiments, the background rollback scheduler of the API relay server (330) can activate an API Resend button in the operation column for retransmitting an API in which a single API transmission has failed or a rollback has succeeded. Accordingly, the EMS web administrator can execute an API in which a failure has occurred by inputting an activated API Resend button.

According to various embodiments, the API relay server (330) may store feature server information regarding the feature server (310) in a database. For example, the feature server information may include the name, IP address, Uniform Resource Locator (URL), etc. of the feature server (310).

According to various embodiments, the API relay server (330) may receive a request for a REST API for provisioning from the feature server (310) and the EMS (320), perform rerouting processing on the received REST API, and transmit it to the feature server (310). In one embodiment, the API relay server (330) may perform rerouting processing to transmit the REST API to at least one of the feature servers (310), and transmit it to at least one server.

For example, as illustrated in FIG. 6, when a request for a REST API is received from an EMS (320), the API relay server (330) may perform URL conversion processing to convert (translate) the URL of the REST API request into the URL of the corresponding feature server so that the corresponding specific server can receive the REST API, and transmit the URL-converted REST API to the corresponding feature server.

FIG. 7 is a diagram showing an API processing routine in an EMS according to one embodiment of the present disclosure. In FIG. 7, processing related to rollback processed before transmission and reception of the REST API illustrated in FIG. 2 is eliminated, and processing related to rollback can be performed in the API relay server (330). Through this, not only is maintenance of the cloud communication service easy, but also the complexity of the rollback processing of provisioning due to a request failure of the REST API can be simplified when a communication failure occurs between the EMS (320) and the feature server (310).

In this way, according to the above-described embodiment, when some of the failures occur among a series of API requests constituting one transaction due to a network error or other causes, the rollback of the previously executed API requests can be processed in real time. Meanwhile, when the rollback of the previously executed API requests cannot be processed in real time, the API information is stored in the database, and an asynchronous scheduler that can process the rollback of the API requests in the background can be used to perform stable rollback processing of the API. Accordingly, data integrity between the EMS (320) and the feature server (310) can be guaranteed.

Although the process steps, method steps, algorithms, etc., are described in a sequential order in the flowcharts illustrated in the present disclosure, such processes, methods, and algorithms may be configured to operate in any suitable order. In other words, the steps of the processes, methods, and algorithms described in various embodiments of the present disclosure need not be performed in the order described in the present disclosure. Furthermore, even if some steps are described as being performed asynchronously, in other embodiments such some steps may be performed concurrently. Furthermore, the illustration of a process by depiction in the drawings does not imply that the illustrated process is exclusive of other changes and modifications thereto, nor does it imply that the illustrated process or any of its steps is essential to one or more of the various embodiments of the present disclosure, nor does it imply that the illustrated process is preferred.

FIG. 8 is a flowchart illustrating an operation of an API relay server according to an embodiment of the present disclosure. Referring to FIG. 8, the API relay server (330) may receive a request for a REST API from an EMS (320) and store the request in a database. In one embodiment, when a request for a REST API is received from the EMS (320), the API relay server (330) may verify the REST API (step S802). For example, the API relay server (330) may verify authentication information of the REST API. The API relay server (330) may determine whether the REST API is an accessible API based on the verified authentication information (step S804). If the API relay server (330) determines that the REST API is an accessible API in step S804, the API relay server (330) may verify a transaction code of the REST API (step S806). The API relay server (330) may store API information including the verified transaction code in a database (step S808).

Meanwhile, if it is determined in step S804 that the REST API is an inaccessible API, the API relay server (330) can transmit a failure response indicating a failure of the REST API to the EMS (320) as a response to the request of the REST API (step S820).

The API relay server (330) may transmit the REST API to the corresponding feature server (310) in response to a request for the REST API. In one embodiment, the API relay server (330) may perform rerouting processing of the REST API based on the feature server information stored in the database and transmit it to the feature server (310) (step S810). For example, the API relay server (330) may perform URL conversion processing that translates the URL of the REST API request into the URL of the corresponding feature server and transmit the URL-converted REST API to the corresponding feature server.

The API relay server (330) can determine whether an API failure has occurred and transmit a response to a request of the REST API to the EMS (320). In one embodiment, the API relay server (330) can determine whether an API failure has occurred (step S812). If the API relay server (330) determines in step 812 that an API failure has not occurred (i.e., that the REST API has been successfully transmitted to the corresponding feature server), the API relay server (330) can set the column value for the Request Result column of the corresponding REST API stored in the database to Success (S814). The API relay server (330) can transmit a success response indicating the success of the REST API to the EMS (320) as a response to the request of the REST API (step S816).

Meanwhile, if it is determined that an API failure has occurred in step 812 (i.e., it is determined that the REST API has not been successfully transmitted to the corresponding feature server), the API relay server (330) may set the column value of the Request Result column of the corresponding REST API stored in the database to Fail (S818). The API relay server (330) may transmit a failure response indicating the failure of the REST API to the EMS (320) as a response to the request of the REST API (step S820).

While the above method has been described through specific embodiments, the above method can also be implemented as computer-readable code on a computer-readable recording medium. The computer-readable recording medium includes all types of recording devices that store data that can be read by a computer system. Examples of the computer-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, etc. In addition, the computer-readable recording medium can be distributed over network-connected computer systems, so that the computer-readable code can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the above embodiments can be easily inferred by programmers in the technical field to which the present disclosure belongs.

Although the technical idea of the present disclosure has been described by the above-described embodiments and examples illustrated in the accompanying drawings, it should be understood that various substitutions, modifications, and changes may be made therein without departing from the technical idea and scope of the present disclosure as understood by those skilled in the art to which the present disclosure pertains. In addition, such substitutions, modifications, and changes should be considered to fall within the scope of the appended claims.

310: Feature Server, 311: UCM Server (311), 312: Tone Server, 313: Call Recording Server, 314: Voice Mail Server, 315: Web Fax Server, 320: EMS, 330: API Relay Server

Claims (18)

As a cloud computing system,
Feature server that provides voice services and video communication services to customers;
An integrated management portal server (EMS) that provides the customer with an integrated management portal capable of provisioning the above-mentioned feature server in an integrated manner, generates a transaction code of a REST API (Representational State Transfer Application Programming Interface) for provisioning with the above-mentioned feature server, and transmits a request of the REST API including the transaction code; and
An API relay server connected to the above feature server and the EMS, receiving a request for the REST API from the EMS, performing rerouting processing of the REST API and transmitting it to the feature server, and determining whether transmission of the REST API has failed based on the transaction code and transmitting a response to the request for the REST API to the EMS
A cloud computing system comprising: A cloud computing system in claim 1, wherein the EMS assigns the same transaction code to a series of REST APIs constituting a single transaction unit so that the series of REST APIs constituting a single transaction unit are detected as the same transaction by the API relay server. A cloud computing system in the second paragraph, wherein the EMS generates the transaction code by combining timestamp information and a randomly generated code. A cloud computing system in the second paragraph, wherein the EMS generates the transaction code by combining time stamp information and an API sequence number. In the first paragraph, the API relay server includes a database storing feature server information about the feature server,
A cloud computing system, wherein the API relay server performs rerouting processing for the REST API based on the feature server information. In the fifth paragraph, the API relay server
The above feature server performs URL conversion processing to convert the URL of the request of the above REST API into the URL of the above feature server so that the above feature server receives the above REST API,
A cloud computing system that transmits the above URL converted REST API to the above feature server. In the first paragraph, the API relay server includes a database storing API information including the transaction code,
The above API relay server searches the database at preset intervals to detect the transaction code of the REST API where the API failure occurred.
A cloud computing system that performs rollback processing of the REST API based on the detected transaction code. In the 7th paragraph, the API relay server
Detect a REST API that is assigned the same transaction code as the transaction code detected in the above database,
Detect successful REST APIs from the above detected REST APIs,
A cloud computing system that performs rollback processing of the above REST API in reverse chronological order for the above successful REST API. In the 8th paragraph, the API relay server is a cloud computing system that, when an API failure occurs as a result of performing rollback processing of the REST API, displays a failure in the rollback result column on an EMS provisioning API list query screen capable of querying a list of EMS provisioning APIs, and activates a rollback button for rollback processing of the REST API. As a method of processing API (Application Programming Interface) using a cloud computing system,
In the EMS of the above cloud computing system, a step of generating a transaction code of a REST (Representational State Transfer) API for provisioning and a feature server that provides voice service and video communication service to a customer;
In the above EMS, a step of transmitting a REST API including the transaction code;
A step of receiving a request of the REST API in the API relay server of the cloud computing system;
In the above API relay server, a step of performing rerouting processing of the REST API and transmitting it to the feature server; and
In the above API relay server, a step of determining whether transmission of the REST API has failed based on the transaction code and transmitting a response to the request of the REST API to the EMS
API processing method including . In the 10th paragraph, the step of generating the transaction code of the REST API
A step of assigning the same transaction code to a series of REST APIs constituting a single transaction unit so that the series of REST APIs constituting a single transaction unit are detected as the same transaction by the API relay server.
API processing method including . In the 11th paragraph, the step of generating the transaction code of the REST API
A step for generating the above transaction code by combining timestamp information and a randomly generated code.
API processing method including . In the 11th paragraph, the step of generating the transaction code of the REST API
Step of generating the above transaction code by combining timestamp information and API sequence number
API processing method including . In the 10th paragraph, the API relay server includes a database storing feature server information about the feature server,
The step of performing rerouting processing of the above REST API and transmitting it to the feature server is
A step of performing the rerouting process for the REST API based on the above feature server information.
API processing method including . In the 14th paragraph, the step of performing rerouting processing of the REST API and transmitting it to the feature server is
A step of performing URL conversion processing to convert the URL of the request of the REST API into the URL of the feature server so that the feature server receives the REST API; and
Step of transmitting the above URL converted REST API to the above feature server
API processing method including . In the 10th paragraph, the API relay server includes a database storing API information including the transaction code,
The step of determining whether transmission of the REST API has failed based on the transaction code and transmitting a response to the request of the REST API to the EMS
A step of searching the database at preset intervals to detect the transaction code of the REST API in which an API failure occurred; and
A step for performing rollback processing of the REST API based on the detected transaction code.
API processing method including . In the 16th paragraph, the step of performing rollback processing of the REST API based on the detected transaction code
A step of detecting a REST API assigned a transaction code identical to the transaction code detected in the above database;
A step of detecting a successful REST API from the above detected REST API; and
Step for performing rollback processing of the above REST API in reverse chronological order for the above successful REST API.
API processing method including . In the 17th paragraph, the step of performing rollback processing of the REST API based on the detected transaction code
The above API relay server performs rollback processing of the above REST API, and, if an API failure occurs, displays a failure in the rollback result column on the EMS provisioning API list query screen that can query the list of EMS provisioning APIs; and
Steps to activate the rollback button for rollback processing of the above REST API
API processing method that includes more.