WO2023038381A1 - Api 데이터 수집시스템 및 그에 관한 방법 - Google Patents

Api 데이터 수집시스템 및 그에 관한 방법 Download PDF

Info

Publication number
WO2023038381A1
WO2023038381A1 PCT/KR2022/013286 KR2022013286W WO2023038381A1 WO 2023038381 A1 WO2023038381 A1 WO 2023038381A1 KR 2022013286 W KR2022013286 W KR 2022013286W WO 2023038381 A1 WO2023038381 A1 WO 2023038381A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
data collection
batch
collection system
gateway
Prior art date
Application number
PCT/KR2022/013286
Other languages
English (en)
French (fr)
Inventor
강태욱
이종우
양윤모
Original Assignee
비엠텍시스템 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 비엠텍시스템 주식회사 filed Critical 비엠텍시스템 주식회사
Publication of WO2023038381A1 publication Critical patent/WO2023038381A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/906—Clustering; Classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • Embodiments disclosed in this document relate to an application programming interface (API) data collection system and a method related thereto.
  • API application programming interface
  • APIs for administrative data of the Ministry of Public Administration and Security, public data of public financial institutions, and Open DART (electronic disclosure information) provided by the Financial Services Commission can be collected.
  • customers can receive services by allowing My Data operators to aggregate their personal credit information from the information provider's financial services, with the consent of the customer.
  • the information providers will correspond to financial institutions that already hold personal credit information, and they are obliged to transmit customer information (My Data) to My Data providers if there is consent from the customer through the My Data Act 3. It is necessary to quickly secure a system to fulfill the obligation to provide My Data.
  • businesses licensed as My Data businesses through the Financial Services Commission can collect My Data from information providers under the consent of customers. Data flow between information provision and collection needs to be performed in compliance with the standard API specifications of My Data and the authentication method defined by the Financial Security Institute. That is, conventional data collection has been done through screen scraping, but screen scraping is prohibited for My Data providers, and My Data providers must provide and collect information through standard APIs.
  • Companies such as existing comprehensive data brokerage companies are providing services that enable fintech startups that provide loans or asset management services to search for account information by bringing together the financial networks of different individual financial companies scattered across the country. , This can cause security problems such as information leakage of customer data held by financial companies, and traffic safety problems as traffic to the bank's website can be congested because many services search for each bank account information. can cause
  • One object of the embodiments disclosed in this document is to provide an API data collection system and a method related thereto using an API management system.
  • An API data collection system includes a gateway for receiving an API call request; a mediation server that receives the API call request from the gateway and calls a call service; one or more databases; and a web server, wherein the gateway comprises: an API management unit that manages an API; a request processing unit that processes the API call request through a non-blocking method; an aggregator that registers a batch using the registered API and controls the batch to be executed at a designated period; and an authentication key management unit that stores and manages an authentication key for calling the paging service in advance, wherein the mediation server includes an interface management unit that manages call service information for the API; a routing unit providing the call service as an API based on HTTP (HyperText Transfer Protocol)/JSON (JavaScript Object Notation); a transaction tracking unit that assigns an individual transaction ID (identifier) to the API call request and logs the API for each predetermined interval based on the transaction ID; a custom conversion unit for generating a message conversion rule defined by a user
  • the aggregator may register a second API with a parameter of a call result of the first API registered in the batch with the batch.
  • the aggregator may register the batch using a data set.
  • the aggregator may perform date processing or array processing using the pattern.
  • the aggregator may register an API for calling a paging service in the batch.
  • An API collection method includes a gateway that receives an API call request and processes the API call request through a non-blocking method; a mediation server that manages call service information for the API, receives the API call request from the gateway, and calls the call service;
  • An API data collection method using an API data collection system including; and a web server, comprising: registering one or more databases in the API data collection system; the operation of managing the API; storing and managing an authentication key for calling the paging service; registering a batch using the registered API; performing an API call request in real time or executing the batch at a specified period; storing result data of the API call request or execution result data of the batch; providing the calling service as an API based on HTTP/JSON; assigning a transaction ID to each of the API call requests; logging the API for each preset interval based on the transaction ID; generating a message transformation rule defined by a user for the API; converting the message included in the API according to the message conversion rule; and generating each domain by grouping
  • the operation of registering the batch may be an operation of registering a first API in the batch and also registering a second API in the batch using a call result of the first API as a parameter.
  • the operation of registering the arrangement may be an operation of registering the arrangement using a data set.
  • an operation of performing date processing or array processing using the pattern may be further included.
  • the operation of registering the batch may be an operation of registering an API for calling a paging-processed paging service in the batch.
  • the API data collection system collects various types of data (e.g., data stored in DBMS (database management system), binary data, text data, scripts (HTML, XML, JSON format on the web), etc.) and easily converts them into APIs. can do.
  • data stored in DBMS (database management system)
  • binary data binary data
  • text data text data
  • scripts HTML, XML, JSON format on the web
  • the advantage of the web can be maximized by utilizing the existing technology provided by the web and the HTTP protocol as it is.
  • a call service can be called using another authentication key even when the number of traffic for a specific authentication key is limited.
  • the calling service can be called at specific intervals instead of real time, and multiple APIs can be called.
  • a preceding/following structure that can use the result of calling the preceding API as a parameter of the following API.
  • the response data of the preceding API included in the batch can be parsed and used as the request data of the following API, so that the request data of the following API can be input separately from the user. It is possible to eliminate the need, thereby further improving user convenience.
  • by registering a batch using a data set it is possible to set a plurality of parameter sets required for API call, thereby further improving user convenience.
  • dynamic parameters can be entered into the dataset through a date regular expression pattern.
  • the size of the dataset can be reduced by using the value declared in the array as a parameter value through an array regular expression pattern.
  • the result data of the entire page may be retrieved by using the paging processing function.
  • FIG. 1 is a block diagram showing the configuration of an API data collection system according to an embodiment disclosed in this document.
  • FIG. 2 is a block diagram showing the configuration of a gateway of an API data collection system according to an embodiment disclosed in this document.
  • FIG. 3 is a block diagram showing the configuration of a mediation server of an API data collection system according to an embodiment disclosed in this document.
  • FIG. 4 is a flowchart illustrating operations that can be performed in a method for collecting data using an API data collection system according to an embodiment disclosed in this document.
  • FIG. 5 is an operation flowchart of a method of registering a new API in the API data collection method using the API data collection system.
  • 6A is an operation flowchart of a data collection method using an API data collection system according to an embodiment disclosed in this document.
  • 6B is an operation flowchart of a data collection method using an API data collection system according to an embodiment disclosed in this document.
  • 6C is an operation flowchart of a data collection method using an API data collection system according to an embodiment disclosed in this document.
  • FIG. 7 is an operation flowchart of a data collection method using an API data collection system according to an embodiment disclosed in this document.
  • FIG. 8 is an operation flowchart of a data collection method using an API data collection system according to an embodiment disclosed in this document.
  • a (e.g., first) component is said to be “coupled” or “connected” to another (e.g., second) component, with or without the terms “functionally” or “communicatively.”
  • the certain component may be connected to the other component directly (eg by wire), wirelessly, or through a third component.
  • the method according to various embodiments disclosed in this document may be included and provided in a computer program product.
  • Computer program products may be traded between sellers and buyers as commodities.
  • a computer program product is distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)), or distributed online (e.g. via an application store or directly between two user devices). : can be downloaded or uploaded).
  • a machine-readable storage medium e.g. compact disc read only memory (CD-ROM)
  • CD-ROM compact disc read only memory
  • online e.g. via an application store or directly between two user devices.
  • at least part of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium such as a manufacturer's server, an application store server, or a relay server's memory.
  • each component (eg, module or program) of the above-described components may include a single object or a plurality of entities, and some of the plurality of entities may be separately disposed in other components. there is.
  • one or more components or operations among the aforementioned corresponding components may be omitted, or one or more other components or operations may be added.
  • a plurality of components eg modules or programs
  • the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by a corresponding component of the plurality of components prior to the integration. .
  • the actions performed by a module, program, or other component are executed sequentially, in parallel, iteratively, or heuristically, or one or more of the actions are executed in a different order, or omitted. or one or more other actions may be added.
  • FIG. 1 is a block diagram showing the configuration of an API data collection system 100 according to an embodiment disclosed in this document.
  • the API data collection system 100 may include a gateway 110, a brokerage server 120, a database 130, and a web server 140,
  • the gateway 110 may include an aggregator 113 .
  • the API data collection system 100 may receive an API call request from the user 10 and call the call service 20 by converting it. At this time, the gateway 110 can not only call the paging service 20 in real time, but also aggregate API data through the aggregator 113 and call the paging service 20 at specific intervals.
  • the API data collecting system 100 may call the paging service 20 by integrating data corresponding to the received API call request, and transmit the called service to the user 10 .
  • the API data collection system 100 can efficiently perform communication between different call services 20 .
  • the API data collection system 100 may standardize the API as an HTTP/JSON-based Representational State Transfer (REST) API in order to link each internal component or system with the calling service 20.
  • REST Representational State Transfer
  • the API data collection system 100 according to an embodiment disclosed in this document does not need to develop a separate resource in the user system, so that downtime provided to the users 10 does not occur, so that smooth service can be provided. .
  • the API data collection system 100 may perform API management, authentication key management, batch management, data storage, interface information management, transaction tracking, message conversion and analysis functions.
  • API management may include overall management functions such as registration, inquiry, modification, and deletion of APIs
  • authentication key management uses registered APIs to provide authentication keys for calling the calling service 20 in advance. It can include functions to register, view, modify, etc.
  • Batch management may include a function of registering, querying, and managing a batch using a registered API
  • data storage is a function of storing API call result data or batch execution result data in a database.
  • Interface information management may include a function of registering and managing interface information for calling the call service 20 .
  • Transaction tracking may include a function to check normal operation and usage of the overall flow and status of the API from API call request to response.
  • the API data collection system 100 assigns a transaction ID to each API call request received from the user 10, and logs the API for each predetermined section based on the transaction ID to process the message professionally. Time required and errors can be tracked.
  • the message conversion may include a function of converting communication of different services into a form that can be mutually linked, and the analysis function may include a function of collecting information of the call service 20 and allowing the manager to analyze it.
  • the gateway 110 may manage APIs received from the user 10 .
  • This gateway 110 may be middleware that integrates an endpoint for an API and provides additional functions.
  • the gateway 110 may perform a function of managing an API by registering, inquiring, modifying, or deleting an API, performing routing of an API call request received from the user 10, or providing information to the user. authentication and authorization can be performed.
  • the gateway 110 may include the aggregator 113, whereby the paging service can be called in real time as well as at specific intervals.
  • the gateway 110 may store and manage an authentication key required to call a paging service in advance. A specific function of the gateway 110 will be described later with reference to FIG. 2 .
  • the mediation server 120 may call the call service 20 by converting the API call request received from the gateway 110 .
  • the mediation server 120 may input and manage interface information for a call service, and may support various protocols such as HTTP, TCP/IP, and JDBC to enable linkage between different call services 20, , it can provide a message conversion solution that can be linked with various existing services.
  • a call service may be routed to an API based on HTTP/JSON according to an API call request received from the gateway 110 .
  • the mediation server 120 can track the overall flow and state of the API by assigning a transaction ID to each API call request, and can perform message conversion and user-defined conversion functions of the received API. Specific functions of the mediation server 120 will be described later in FIG. 3 .
  • the database 130 may store result data of calling a specific API according to the API call request of the user 10 and may store execution result data of batches registered in the aggregator.
  • the web server 140 can perform management and control functions of the gateway 110, the mediation server 120, and the database 130, and enables the user to easily use all functions of the API data collection system 100. can do. Specifically, the web server 140 provides data on the operation of the API data collection system 100 (eg, API, batch, data stored in the database 130, authentication key, and message conversion rules of the mediation server 120). It is possible to manage each domain by grouping each. In addition, the web server 140 can manage data on the state of the API data collection system 100 for each domain.
  • the API data collection system 100 eg, API, batch, data stored in the database 130, authentication key, and message conversion rules of the mediation server 120. It is possible to manage each domain by grouping each. In addition, the web server 140 can manage data on the state of the API data collection system 100 for each domain.
  • the web server 140 may create a specific domain by grouping data related to the operation or status of the API data collection system.
  • One or more tabs may be created on the domain created in the web server 140 .
  • an API tab may be created on the domain.
  • the API tab created according to an embodiment disclosed in this document can make it possible to check the list of APIs registered in the gateway 110 at a glance, make it possible to delete unused APIs, and enable details of the registered APIs. It is possible to inquire and modify information, and it is possible to register an API using information necessary for API registration (eg, request/response parameters, URL address of a calling service, etc.), stored in the database 130. It is possible to configure how to manage API call result data. A method of registering a new API using the API tab will be described later with reference to FIG. 5 .
  • a placement tab may be created on a domain created in the web server 140 .
  • the batch tab created according to an embodiment disclosed in this document can make it possible to check the list of batches registered in the aggregator 113 at a glance, make it possible to delete batches, and enable details of registered batches.
  • Information e.g. batch call cycle, APIs registered in batches, regular expression patterns of APIs registered in batches, etc.
  • the forced call function is used even when the preset batch call cycle is out of bounds.
  • To make the batch executable to stop the running batch, and to register the batch using information necessary for batch registration (eg, batch call cycle, batch type, API to be called, etc.) can do.
  • the batch tab created according to an embodiment may provide a form (eg, Excel, etc.) of information required for API call to the user, and the user may register one or more data sets through the form. It can be done, and the batch can be made executable using the registered dataset.
  • a form eg, Excel, etc.
  • a database tab may be created on a domain created in the web server 140 .
  • a database tab created according to an embodiment disclosed in this document may enable inquiry, modification, or deletion of data stored in the database 130 .
  • the API data collection system may receive a user's command to register a new database and register a new database in the API data collection system. In this case, the validity of the database to be registered can be tested.
  • a connection test can be performed through the drive name, URL address, user name, password, etc. of the new database to be registered. can
  • an authentication management tab may be created on a domain created in the web server 140 .
  • the authentication management tab created according to an embodiment disclosed in this document may enable registration, inquiry, modification, or deletion of authentication keys stored in the gateway 110 .
  • a parameter rule tab may be created on a domain created in the web server 140 .
  • the parameter rule tab created according to an embodiment disclosed in this document can define message conversion rules that reflect masking, padding, encoding, and decoding policies to parameters. can do
  • a dashboard tab may be created on a domain created in the web server 140 .
  • the dashboard tab created according to an embodiment disclosed in this document can check the current state of the API data collection system 100 (eg, the current state of the batch, the current state of data stored in the database, etc.) at a glance. can
  • an insight tab may be created on a domain created in the web server 140 .
  • the insight tab created enables the mediation server 120 to confirm that the API is logged for each predetermined section based on the transaction ID, thereby enabling the time required and errors in the message full text processing process. can be tracked.
  • the API data collection system 100 can enable a user to easily check in which part an error has occurred through a transaction ID, and can enable a quick response when a failure occurs.
  • FIG. 2 is a block diagram showing the configuration of a gateway of an API data collection system according to an embodiment disclosed in this document.
  • the gateway 110 of the API data collection system 100 performs functions of managing APIs and processing API call requests received from users, and is an API management unit. (111), a request processing unit 112, an aggregator 113, and an authentication key management unit 114.
  • the API management unit 111 may register an API so that a user can call a specific call service, and perform overall management functions for the API, such as searching, modifying, or deleting the registered API.
  • an API management operation may be an operation of registering a new API or an operation of inquiring, modifying, or deleting a registered API.
  • Each registered API can have an API ID, and can call a specific calling service through a route path. As an example, calling of a paging service may be performed in real time.
  • the request processing unit 112 may route the registered API according to the route requested by the user.
  • the request processing unit 112 may process the API call request from the user through a non-blocking method.
  • a thread is created at every request, and the requesting thread is maintained in a standby state when the thread is in use.
  • the server since the server has a limited number of request threads, if the server is processing requests as many as the maximum number of threads, other requests may not be processed, resulting in performance degradation and total utilization of server functions.
  • the request processing unit 112 of the gateway 110 disclosed in this document may asynchronously process the request through a non-blocking method. Through this, the delay of the request does not occur, and the gateway 110 processing numerous API call requests can operate smoothly.
  • the aggregator 113 may register batches using APIs registered in the gateway 110, and may call the paging service 20 at specific predetermined cycles by integrating API data. As an example according to the disclosure of this document, the aggregator 113 may execute a batch and call the paging service 20 when receiving a registered batch execution command from a user even if a predetermined period does not arrive. Aggregator 113 may call one or more APIs using batches. The aggregator 113 can also call a preceding/later structure that can use the call result of the first API registered in the batch as a parameter of the second API, and at this time, the first API and the second API are in the same batch. can be registered together.
  • an API that calls a list of student names can be registered as a first API, and an API that retrieves personal information of a student can be registered as a second API using the entire list of student names, which is a call result of the first API, as a parameter.
  • the aggregator 113 may register a plurality of batches in which the same API is registered when executing a plurality of parameter sets in a batch in which the same API is registered.
  • a plurality of parameter sets required to call a registered API may be set using a data set.
  • each parameter can be registered using a designated form (eg, Excel, etc.), thereby providing convenience to the user by eliminating the inconvenience of having to register each parameter directly.
  • the mediation server 120 may check the registered parameter information and perform a validation check.
  • the aggregator 113 may include a regular expression pattern function for handling dynamic parameter values.
  • the regular expression pattern function when a preset regular expression pattern exists in the parameter value included in the data set to be registered, uses the pattern to process the date (e.g. yyyy.mm.dd, yyyy-mm-dd etc.) or array processing can be performed.
  • a date regular expression pattern exists, a dynamic parameter can be input to the dataset.
  • a value declared in an array may be used as a parameter value.
  • the aggregator 113 may register a batch using an API that calls a paging service. At this time, the final number of pages can be checked using the total number of pages or the number of result data checked when the API is first called, and using this, the corresponding API can be called as many as the total number of pages to retrieve all data.
  • the authentication key management unit 114 may store and manage an authentication key for calling a paging service using a registered API in advance.
  • the authentication key management unit 114 may store an authentication key required to call a paging service when registering an API. Accordingly, the authentication key may not be considered when calling the paging service.
  • an authentication key group may be used in case an error occurs due to a limited number of traffic assigned to the authentication key.
  • a plurality of authentication keys may be registered as an authentication key group, and a paging service may be called using the authentication key group.
  • the authentication key management unit 114 may store and manage one or more authentication key groups.
  • FIG. 3 is a block diagram showing the configuration of a mediation server of an API data collection system according to an embodiment disclosed in this document.
  • the mediation server 120 of the API data collection system performs communication between the gateway 110 and the call service 20, and includes an interface management unit 121, It may include a routing unit 122, a transaction tracking unit 123, a custom conversion unit 124, and a message conversion unit 125.
  • the interface manager 121 may register and manage interface information (eg, request/response parameters, authentication method required for service call, etc.) for calling a call service.
  • the authentication method stored in the interface manager 121 may support Hash-based Message Authentication Code (HMAC), OAuth2.0, or other authentication methods.
  • HMAC Hash-based Message Authentication Code
  • OAuth2.0 Hash-based Message Authentication Code
  • a protocol and/or parameters may be set based on information stored in the interface management unit 121, and a message may be converted to call a call service.
  • the routing unit 122 may provide a call service as an API based on HTTP/JSON.
  • the transaction tracking unit 123 may track the state of the API. Specifically, the transaction tracking unit 123 may assign a transaction ID to each API call request to track the overall flow and status from the API request to the response. In this case, the transaction tracking unit 123 logs the API for each predetermined section so that it is possible to track the required time and errors in the message processing process, thereby enabling a more rapid response in the event of a failure. Meanwhile, the transaction tracking unit 123 may be included in the gateway 110 as well as the mediation server 120 . At this time, the function of the transaction tracking unit 123 included in the gateway 110 may be substantially the same.
  • the transaction tracking unit 123 assigns a separate transaction ID for each API call request to provide process data for each step between the user 10 - the gateway 110 - the intermediary server 120 - the calling service 20. can be made verifiable. If an internal error occurs in the API data collection system 100, it is possible to easily check in which part the error occurred through the transaction ID, so that a quick response is possible. Statistical data such as process time may be provided along with basic information such as success/failure for each API call request by using the data accumulated in this way.
  • the custom conversion unit 124 may define message conversion rules for the API.
  • the custom conversion unit 124 may define message conversion rules as a script. In this way, when message transformation rules are defined in script form, new rules can be applied without separate coding or service restart. In the conventional message conversion method, when message conversion logic is added, the program must be restarted after development separately.
  • the custom conversion unit 124 of the mediation server 120 according to an embodiment disclosed in this document defines a message conversion rule as a script, and can apply a new rule without separate development (coding) and service restart. .
  • the message conversion unit 125 may convert the message included in the API according to the message conversion rules defined in the custom conversion unit 124 .
  • the message conversion unit 125 may convert a message in at least one of the header and body of the API.
  • the message conversion unit 125 may perform a preset conversion for each message.
  • the message conversion unit 125 may reflect a masking, padding, encoding, and decoding policy for each parameter using a resolver.
  • a resolver may also be written based on a script, thereby providing a service without restarting the program.
  • the message conversion unit 125 may provide a plurality of communication protocols that can be linked with various call services.
  • the communication protocol provided by the message converter 125 may include HTTP, TCP/IP (Transmission Control Protocol/Internet Protocol), JDBC (Java Database Connectivity), and the like. That is, the message conversion unit 125 may perform communication protocol conversion while or after message conversion.
  • HTTP Transmission Control Protocol/Internet Protocol
  • JDBC Java Database Connectivity
  • FIG. 4 is an operational flowchart of a method for collecting data using an API data collection system according to an embodiment disclosed in this document. Referring to FIGS. 1 to 3 for a performer of each operation shown in FIG. 4 .
  • a specific domain for grouping data related to the operation or state of the API data collection system can be created and managed. Yes (S200). Operation S200 may be performed through the web server 140 . As an example, an API tab may be created on the domain created in operation S200 to allow overall management such as registering an API in the API data collection system and inquiring, modifying, or deleting the registered API. In the API tab according to an example disclosed in this document, a new API registration command may be received and stored in the gateway 110 . As an example according to the disclosure of this document, the process of registering a new API will be described later in detail with reference to FIG. 5 .
  • a database tab enabling overall management such as inquiry, modification, or deletion of data stored in the database of the API data collection system may be created.
  • an authentication key tab that enables overall management, such as registering an authentication key in the API data collection system and searching, modifying, or deleting the registered authentication key, can be created.
  • a parameter rule tab enabling message conversion rules to be defined may be created on the domain created in operation S200.
  • a dashboard tab that allows the current status of the API data collection system (eg, current status of batch, current status of data stored in the database, etc.) to be checked at a glance can be created.
  • the API data collection system e.g. current status of batch, current status of data stored in the database, etc.
  • an authentication key required to call a call service for a user's API call request may be registered (S210).
  • one or a plurality of authentication key groups may be registered in case an error occurs due to the limited number of traffic assigned to the authentication key.
  • the paging service can be called using another authentication key belonging to the authentication key group. can do
  • the API data collection system works to store (collect) API call result data or batch execution result data.
  • the above database can be registered (S220).
  • database registration may be performed through the web server 140 .
  • the validity of the database may be tested.
  • a connection test can be performed using the driver name, URL address, user name, password, etc. of the corresponding database.
  • message conversion rules for the API may be defined (S230).
  • message conversion rules may be defined in the form of a script. In this way, when message conversion rules are defined in script form, new rules can be applied without separate coding or service restart.
  • the API data collection system performs an API call request (S260) or a batch execution request (S265)
  • Messages (request data) included in the API or response data of call service calls can be converted.
  • the API data collection system may receive information about a new API from the user and register the new API in the gateway 110 ( S240).
  • a new API may be registered through the API tab on a specific domain created in the web server 140 of the API data collection system. A detailed description of a method of registering a new API will be described later with reference to FIG. 5 .
  • a batch may be registered using one or more APIs registered in the gateway 110 (S250).
  • the API data collection system may be set to perform a batch execution request when a specified period arrives.
  • the API data collection system can be configured to perform a request for batch execution when a period specified for batch execution arrives.
  • a plurality of APIs included in the batch may correspond to a structure in which result data of the first API configures parameter values of request data of the second API, that is, a structure that precedes and follows each other.
  • a description related to arrangement including an API of a leading/following structure will be described later in detail with reference to FIG. 7 .
  • a data set may be used.
  • date processing or array processing may be performed using the corresponding pattern.
  • a description of arrangement using a dataset will be described later in detail with reference to FIG. 8 .
  • the request processing unit 112 of the gateway may perform the API call request (S260).
  • S260 the API call request
  • the request processing unit 112 of the gateway may perform the API call request (S260).
  • S260 if there is a setting for using a batch, it may be determined whether a specified period for executing a batch is satisfied.
  • the request processing unit 112 of the gateway executes the registered batch and requests to call one or more APIs included in the batch. can be performed (S265).
  • the request processing unit 112 of the gateway executes the registered batch and requests to call one or more APIs included in the batch. can be performed (S265).
  • the corresponding batch execution request can be performed (S265). ).
  • the transaction tracking unit 123 of the API data collection system may assign a transaction ID to the API call request (S270). After assigning a transaction ID to each API call request in operation S270, the API may be logged for each preset section based on the transaction ID (S271). In this way, it is possible to trace the overall operation flow and status from API request to response. In this case, by making it possible to track the required time and errors in the message processing process, it is possible to respond more quickly in the event of a failure.
  • the API data collection system enables the user 10 to check result data according to an API call request or execution result data of a registered batch.
  • the API data collection system may allow the user 10 to check result data for an API call request or a batch execution request on a specific domain generated through the web server 140 .
  • the API data collection system may store corresponding result data of an API call request or batch execution result data in the database 130 of the API data collection system 100 (S280).
  • the API data collection system may perform an operation of storing result data only when a database use command is input from a user.
  • the API data collection system may allow the user 10 to check result data.
  • the calling service 20 can be provided as an API based on HTTP/JSON.
  • each operation may be executed sequentially, in parallel, repeatedly, or heuristically, or one or more of the above operations may be executed in a different order, may be omitted, Or one or more other actions may be added.
  • FIG. 5 is an operation flowchart of a new API registration method in the API data collection method using the API data collection system. For a subject performing the operations shown in FIG. 5 , reference may be made to FIGS. 1 to 3 .
  • the API data collection system receives parameters and API information (S300) and registers a new API. (S340).
  • the API data collection system receives a message conversion rule use command from the user (S310)
  • the message conversion rule according to the input command can be registered in the input parameters (S311).
  • the API data collection system receives an authentication key use command from the user (S320)
  • one of the authentication keys or authentication key groups stored in the authentication key management unit can be selected and registered as an authentication key for a new API. It can (S321).
  • the authentication key management unit 114 may correspond to one component included in the gateway of the API data collection system.
  • the API data collection system receives a database storage command (S330)
  • one of the previously registered databases may be designated to store data resulting from calling a new API (S331).
  • a new database may be registered in the API data collection system, and the newly registered database may store result data of the new API according to an example.
  • a connection test can be performed to check whether a drive name, URL address, user name, password, etc. are valid.
  • execution result data of the corresponding batch may be stored in a database designated by each registered API.
  • operations for receiving commands may be performed through the web server 140 of the API data collection system 100, and processing of the input commands may be performed through the API of the gateway 110. It can be performed by the management unit 111.
  • FIGS. 6A to 6C are operational flowcharts of a data collection method using the API data collection system 100 according to an embodiment disclosed in this document.
  • FIGS. 6A to 6C For a performer of the operations shown in FIGS. 6A to 6C , reference may be made to FIGS. 1 to 3 .
  • FIG. 6A is an operation flowchart of a data collection method using the API collection system 100, and shows an operation flowchart of a method of calling a call service (response data) in response to an API call request.
  • the operations shown in FIG. 6A may be an example of the operation S260 of FIG. 4 .
  • the operations shown in FIG. 6A may be an example of operation S265 of FIG. 4 , and may be an example of an operation of performing one or more API call requests included in a batch requested to be executed.
  • the API data collection system 100 when there is an API call request (ie, request data) from the user 10, the API data collection system 100 according to an embodiment disclosed in this document (S400), the request data of the API call , the call service 20 (that is, response data) can be called (S430), and the called result data can be confirmed by the user (S440).
  • the API data collection system 100 receives a user's API call request, the received call request may be performed using a parameter set as an essential parameter among one or more parameters.
  • the user may input an authentication key use command to the API data collection system 100, and the API data collection system 100 may determine whether the authentication key use command is input (S410).
  • the authentication key stored in the authentication key management unit 114 may be included in the requested data (S411). .
  • the user may input a message conversion rule use command to the API data collection system 100, and the API data collection system 100 may determine whether the corresponding command is input (S420).
  • the message conversion rule may correspond to the API message conversion rule defined in the custom conversion unit 124 .
  • the message in at least one of the header and body of the API may be converted.
  • a message conversion rule according to an example disclosed in this document a plurality of communication protocols that can be linked with various call services can be provided. Examples of communication protocols provided when performing message conversion according to an example disclosed in this document may include HTTP, TCP/IP, JDBC, and the like.
  • communication protocol conversion may be performed while performing message conversion or before and after message conversion. According to an embodiment disclosed in this document, operation S421 may be performed by the message conversion unit 125.
  • the API data collection system 100 can call a calling service (S430), and the user 10 can check the called response data (ie, result data). It can be indicated to do (S440).
  • the called response data ie, result data
  • S440 the called response data
  • the called response data is converted according to the preset message conversion rule. It can be converted (S422).
  • message conversion rules used in performing operations S421 and S422 may be mutually symmetrical rules.
  • FIG. 6B is an operation flowchart of a data collection method using an API collection system, and shows an operation flowchart for a method of executing a batch at a designated period when there is a setting for using a batch according to a period.
  • a user may set batch use settings in the API data collection system 100, and at this time, the API data collection system may determine whether batch use settings are set from the user ( S263).
  • the API data collection system 100 may check whether a predetermined period has arrived (S264).
  • a batch execution request may be performed (S265), and an API registered in the batch may be requested to be called.
  • the API call request of the user 10 may be processed in real time.
  • operation S265 of the operations illustrated in FIG. 6B may represent the same operation as operation S265 of FIG. 4 .
  • the operations shown in FIG. 6B may be performed before or after the operation S400 of FIG. 6A or concurrently with the operation S400.
  • 6C is an operation flow chart of a data collection method using an API collection system, and shows an operation flow chart for a method of storing result data of an API call request or result data of a batch execution request in a designated database when there is a database use command.
  • a user may input a database use command to the API data collection system 100, and at this time, the API data collection system may determine whether a database use command has been input from the user. (S279).
  • the API data collection system 100 may perform an operation of storing result data of an API call or batch execution in the database 130 only when a database use command is input (S280).
  • the operations shown in FIG. 6C may be performed after operation S440 of FIG. 6A or concurrently with operation S440.
  • FIG. 7 is an operation flowchart of a data collection method using an API data collection system according to an embodiment disclosed in this document.
  • the operations shown in FIG. 7 may be, for example, an example of operation S250 of FIG. 4 .
  • a first API may be registered in a specific batch (S251), and a second API having as a parameter a call result of the first API registered in the batch may be registered in the same batch. Yes (S252).
  • the response data of the preceding API may be parsed as request data of the following API and used.
  • an API that calls a list of student names is registered in a batch as the first API, and an API that searches personal information of a student is used as a parameter with the entire list of student names, which is the result of calling the first API, as the second API.
  • the second API that is, the first API, that is, Convenience can be provided because the response data of the previous API can be parsed and used.
  • FIG. 8 is an operation flowchart of a data collection method using an API data collection system according to an embodiment disclosed in this document.
  • the operations shown in FIG. 8 may be an embodiment of operation S265 of FIG. 4 .
  • a batch may be registered using a data set (S253).
  • the user 10 can register each parameter using a designated form (eg, Excel, etc.), thereby improving convenience by eliminating the inconvenience of having to register each parameter directly. can increase
  • batch may be executed using a registered dataset.
  • it may be determined whether a preset regular expression pattern exists in a parameter value included in a registered dataset (S266). If it is determined that a preset regular expression pattern exists, date processing or array processing may be performed using the corresponding pattern (S267).
  • a batch execution operation may be performed immediately. Operations S266 and S267 shown in FIG. 8 may be performed after operation S265 of FIG. 4 or concurrently with operation S265.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computer And Data Communications (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)

Abstract

본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템은, API 호출 요청을 수신하는 게이트웨이; 상기 API 호출 요청을 전달받고, 호출 서비스를 호출하는 중개서버; 일 이상의 데이터베이스; 및 웹서버;를 포함하고, 상기 게이트웨이는, API 관리부; 애그리게이터; 인증키 관리부;를 포함하고, 상기 중개서버는, 인터페이스 관리부; 라우팅부; 거래추적부; 커스텀 변환부; 및 메시지 변환부;를 포함할 수 있다.

Description

API 데이터 수집시스템 및 그에 관한 방법
본 문서에 개시된 실시예들은 API(Application Programming Interface) 데이터 수집시스템 및 그에 관한 방법에 대한 것이다.
Open API 기반의 API 데이터 수집시스템에 대한 본 발명을 통해, 외부 데이터를 활용한 신규 비즈니스 니즈(needs) 확대 및 데이터 중심의 패러다임 변화에 대응할 수 있으며, 데이터댐 등 디지털 뉴딜 정책의 핵심사업에 따른 공공기관 및 민간기업의 데이터를 수집할 수 있다. 특히, 행정안전부의 행정데이터, 공금융기관의 공공데이터, 금융위원회에서 제공하는 Open DART(전자공시정보) 등에 대한 API가 수집의 대상이 될 수 있다.
최근 개인의 금융정보 자기결정권, 증권, 데이터 이동권의 확립 등을 목적으로 하는 마이데이터 시대가 도래하였다. 이로 인해, 금융사가 오픈 API를 활용함에 따라 핀테크 업체는 이를 플러그인(Plug-in) 형태로 활용할 수 있는 금융 인프라를 원하기 시작하였다. 오픈 API를 플러그인(Plug-in) 형태로 제공하면, 핀테크 업체 입장에서는 새로운 서비스를 쉽게 개발할 수 있고, 금융사도 핀테크 기업의 서비스와 연계하여 신규 고객 확보를 통한 새로운 수익원을 창출할 수 있다. 이는 은행 간 소프트웨어 경쟁력 강화로 인해, 로컬 국가에서만 API 인프라가 구축되는 것이 아니라 전세계적으로 확장이 가능하므로 새로운 성장 동력으로 이어질 수 있다. 이와 같은 이유로 종합 중개 및 수집 기술 관련 서비스에 대한 니즈(needs)가 발생하였다. 미국의 경우, 스크래핑 기반 PFM(Personal Financial Management)이 출몰하였고, 오픈 API 기반의 서비스들이 활성화되었으며, 이 과정에서 API 수집(API aggregation) 사업이 등장하였다.
금융분야의 마이데이터 서비스의 생태계에 따르면 고객은, 본인의 동의 하에, 마이데이터 사업자가 정보제공자의 금융서비스에 있는 본인의 개인신용정보를 종합할 수 있게 하여 서비스를 제공받을 수 있다. 정보제공자는 기존에 개인신용정보를 보유하고 있는 금융기관 등에 해당할 것이며, 이들은 마이데이터 3법을 통해 고객의 동의가 있는 경우 고객의 정보(마이데이터)를 마이데이터 사업자에게 전송할 의무가 부여되었고, 마이데이터 제공 의무를 수행하기 위한 시스템을 빠르게 확보할 필요가 있다. 또한, 금융위원회를 통해 마이데이터 사업자로 허가받은 사업자들은 고객의 동의 하에 정보제공자로부터 마이데이터를 수집할 수 있다. 정보 제공 및 수집 간의 데이터 흐름은 금융보안원에서 정의한 마이데이터의 표준 API 규격과 본인인증방식을 준수하여 수행될 필요가 있다. 즉, 기존의 데이터 수집은 스크린 스크래핑을 통하여 이루어졌으나, 마이데이터 사업자에 대해서는 스크린 스크래핑 방식이 금지되고, 마이데이터 사업자는 표준 API를 통해 정보를 제공 및 수집해야 한다.
기존 데이터 종합 중개 사업자와 같은 기업들은, 대출이나 자산관리서비스를 제공하는 핀테크 스타트업들이 전국 각지에 흩어져 있는 서로 다른 개별 금융사의 금융망을 하나로 모아 계좌 정보를 조회할 수 있게 하는 서비스를 제공 중이지만, 이는 금융사가 자사가 보유한 고객 데이터의 정보 유출과 같은 보안성 문제를 야기할 수 있으며, 다수 서비스들이 각 은행 계좌 정보를 조회하기 때문에 은행의 웹사이트에 대한 트래픽이 폭주할 수 있으므로 트래픽 안전성의 문제를 야기할 수 있다.
본 문서에 개시되는 실시예들의 일 목적은 API 관리시스템을 이용하여 API 데이터 수집시스템 및 그에 관한 방법을 제공하는 데 있다.
본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템은, API 호출 요청을 수신하는 게이트웨이; 상기 게이트웨이로부터 상기 API 호출 요청을 전달받고, 및 호출 서비스를 호출하는 중개서버(mediation server); 일 이상의 데이터베이스; 및 웹서버;를 포함하는 API 데이터 수집시스템으로서, 상기 게이트웨이는, API를 관리하는 API 관리부; 논블로킹(non-blocking) 방식을 통해 상기 API 호출 요청에 대한 처리를 수행하는 요청 처리부; 등록된 상기 API를 이용하여 배치(batch)를 등록하고, 지정된 주기(period)로 상기 배치를 실행하도록 제어하는 애그리게이터(aggregator); 상기 호출 서비스를 호출하기 위한 인증키를 사전에 저장하고 관리하는 인증키 관리부;를 포함하고, 상기 중개서버는, 상기 API에 대한 호출 서비스 정보를 관리하는 인터페이스 관리부; 상기 호출 서비스를 HTTP(HyperText Transfer Protocol)/JSON(JavaScript Object Notation) 기반의 API로 제공하는 라우팅부; 상기 API 호출 요청에 대한 개별적인 트랜잭션 ID(identifier)를 부여하고, 및 상기 트랜잭션 ID에 기초하여 상기 API를 기설정된 구간마다 로깅하는 거래추적부; 상기 API에 대하여 사용자에 의해 정의된 메시지 변환 규칙을 생성하는 커스텀 변환부; 및 상기 메시지 변환 규칙에 따라 상기 API에 포함된 메시지를 변환하는 메시지 변환부;를 포함하고, 상기 데이터베이스는, 상기 API 호출 요청의 결과 데이터 또는 상기 배치의 실행 결과 데이터를 더 저장하도록 설정되고, 상기 웹서버는, 상기 API 데이터 수집시스템의 동작 또는 상태와 관련한 데이터를 그룹핑하여 특정 도메인을 생성하여 관리하도록 설정될 수 있다.
일 실시예에 따라, 상기 애그리게이터는 상기 배치에 등록된 제1 API의 호출 결과를 파라미터로 하는 제2 API를 상기 배치에 함께 등록할 수 있다.
일 실시예에 따라, 상기 애그리게이터는 데이터셋(data set)을 이용하여 상기 배치를 등록할 수 있다.
일 실시예에 따라, 상기 애그리게이터는 상기 데이터셋(data set)에 포함된 파라미터 값에 기설정된 정규식 패턴이 존재하는 경우, 상기 패턴을 이용하여 날짜처리 또는 배열처리를 수행할 수 있다.
일 실시예에 따라, 상기 애그리게이터는 상기 배치에 페이징 처리가 된 호출 서비스를 호출하는 API를 등록할 수 있다.
본 문서에 개시된 일 실시예에 따른 API 수집 방법은 API 호출 요청을 수신하고, 및 논블로킹(non-blocking) 방식을 통해 상기 API 호출 요청에 대한 처리를 수행하는 게이트웨이; 상기 API에 대한 호출 서비스 정보를 관리하고, 상기 게이트웨이로부터 상기 API 호출 요청을 전달받고, 및 호출 서비스를 호출하는 중개서버(mediation server); 및 웹서버;를 포함하는 API 데이터 수집시스템을 이용한 API 데이터 수집 방법으로서, 상기 API 데이터 수집시스템에 일 이상의 데이터베이스를 등록하는 동작; API를 관리하는 동작; 상기 호출 서비스를 호출하기 위한 인증키를 저장하고 관리하는 동작; 등록된 상기 API를 이용하여 배치(batch)를 등록하는 동작; 실시간으로 API 호출 요청을 수행하거나 지정된 주기(period)로 상기 배치를 실행하는 동작; 상기 API 호출 요청의 결과 데이터 또는 상기 배치의 실행 결과 데이터를 저장하는 동작; 상기 호출 서비스를 HTTP/JSON 기반의 API로 제공하는 동작; 각각의 상기 API 호출 요청에 대한 트랜잭션 ID를 부여하는 동작; 상기 트랜잭션 ID에 기초하여 상기 API를 기설정된 구간마다 로깅하는 동작; 상기 API에 대하여 사용자에 의해 정의된 메시지 변환 규칙을 생성하는 동작; 상기 메시지 변환 규칙에 따라 상기 API에 포함된 메시지를 변환하는 동작; 및 상기 API 데이터 수집시스템의 동작 또는 상태와 관련한 데이터를 그룹핑하여 각 도메인을 생성하는 동작;을 포함할 수 있다.
일 실시예에 따라, 상기 배치를 등록하는 동작은 상기 배치에 제1 API를 등록하고, 상기 제1 API의 호출 결과를 파라미터로 하여 제2 API를 상기 배치에 함께 등록하는 동작일 수 있다.
일 실시예에 따라, 상기 배치를 등록하는 동작은 데이터셋(data set)을 이용하여 상기 배치를 등록하는 동작일 수 있다.
일 실시예에 따라, 데이터셋(data set)에 포함된 파라미터 값에 기설정된 정규식 패턴이 존재하는 경우, 상기 패턴을 이용하여 날짜처리 또는 배열처리를 수행하는 동작을 더 포함할 수 있다.
일 실시예에 따라, 상기 배치를 등록하는 동작은, 페이징 처리가 된 호출 서비스를 호출하는 API를 상기 배치에 등록하는 동작일 수 있다.
API 데이터 수집시스템은 다양한 종류의 데이터(예: DBMS(database management system)에 저장된 데이터, 바이너리 데이터, 텍스트 데이터, 스크립트(웹 상의 HTML, XML, JSON 형태) 등)를 수집하고, 이를 API로 쉽게 전환할 수 있다.
기존에 수집 데이터의 종류 및 프로토콜 방법에 따라 수집 프로세스를 작성해야 했던 방식과는 달리, 간단히 파라미터 규칙 등을 등록하는 방식으로 별도의 개발 또는 시스템의 재가동 없이도 서비스 제공이 가능하다.
웹이 제공하는 기존 기술과 HTTP 프로토콜을 그대로 활용하여 웹의 장점을 최대한 나타낼 수 있다.
일 이상의 인증키를 그룹핑하여 인증키 그룹을 생성하고 활용함으로써, 특정 인증키에 대한 트래픽 수 제한이 걸리는 경우에도, 다른 인증키를 사용하여 호출 서비스를 호출할 수 있다.
배치(batch)를 등록함으로써 호출 서비스를 실시간이 아닌 특정 주기마다 호출할 수 있으며, 여러 건의 API를 호출할 수 있다. 배치에서는 선행 API의 호출 결과를 후행 API의 파라미터로 사용할 수 있는 선·후행 구조 또한 호출할 수 있다. 선·후행 구조의 API가 저장된 배치를 실행하는 경우, 배치에 포함된 선행 API의 응답 데이터를 후행 API의 요청 데이터로 파싱(parsing)하여 사용할 수 있으므로, 후행 API의 요청 데이터를 사용자로부터 별도로 입력받을 필요가 없게 할 수 있고, 이로써 사용자의 편의성을 보다 향상시킬 수 있다. 또한, 데이터셋(data set)을 이용하여 배치를 등록함으로써 API 호출에 필요한 파라미터 셋을 복수 개 설정할 수 있고, 이로써, 사용자의 편의성을 보다 향상시킬 수 있다. 데이터셋을 이용하는 경우, 날짜 정규식 패턴을 통해 데이터셋에 동적인 파라미터를 입력할 수 있다. 또, 데이터셋을 이용하는 경우, 배열 정규식 패턴을 통해 배열에 선언된 값을 파라미터 값으로 사용함으로써 데이터셋의 크기를 줄일 수 있다. 또한, 페이징 처리 기능을 이용하여 전체 페이지의 결과 데이터를 조회할 수도 있다.
도 1는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템의 구성을 나타내는 블록도이다.
도 2은 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템의 게이트웨이의 구성을 나타내는 블록도이다.
도 3는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템의 중개서버(mediation server)의 구성을 나타내는 블록도이다.
도 4는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용하여 데이터를 수집하는 방법에 있어서, 수행할 수 있는 동작들을 나타내는 흐름도이다.
도 5은 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, 신규 API를 등록하는 방법의 동작 흐름도이다.
도 6a는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도이다.
도 6b는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도이다.
도 6c는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도이다.
도 7은 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도이다.
도 8은 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도이다.
도면의 설명과 관련하여, 동일 또는 유사한 구성요소에 대해서는 동일 또는 유사한 참조 부호가 사용될 수 있다.
이하, 본 발명의 다양한 실시 예가 첨부된 도면을 참조하여 기재된다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 실시 예의 다양한 변경(modification), 균등물(equivalent), 및/또는 대체물(alternative)을 포함하는 것으로 이해되어야 한다.
본 문서의 다양한 실시예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다.
본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", "A 또는 B 중 적어도 하나", "A, B 또는 C", "A, B 및 C 중 적어도 하나", 및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제 1", "제 2", "첫째", "둘째", "A", "B", "(a)" 또는 "(b)"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 특별히 반대되는 기재가 없는 한, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제 1) 구성요소가 다른(예: 제 2) 구성요소에, "기능적으로" 또는 "통신적으로"라는 용어와 함께 또는 이런 용어 없이, "커플드" 또는 "커넥티드"라고 언급된 경우, 그것은 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제 3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.
일실시예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory(CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어를 통해 또는 두 개의 사용자 장치들 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시예들에 따르면, 상기 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있으며, 복수의 개체 중 일부는 다른 구성요소에 분리 배치될 수도 있다. 다양한 실시예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 상기 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.
도 1은 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템(100)의 구성을 나타내는 블록도이다.
도 1을 참조하면, 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템(100)은 게이트웨이(110), 중개서버(120), 데이터베이스(130) 및 웹서버(140)를 포함할 수 있고, 게이트웨이(110)는 애그리게이터(113)를 포함할 수 있다. API 데이터 수집시스템(100)은 사용자(10)로부터 API 호출 요청을 수신하고, 이를 변환하여 호출 서비스(20)를 호출할 수 있다. 이 때, 게이트웨이(110)는 실시간으로 호출 서비스(20)를 호출할 수 있을 뿐만 아니라, 애그리게이터(113)를 통해 API 데이터를 종합하여 특정 주기마다 호출 서비스(20)를 호출할 수 있다. API 데이터 수집시스템(100)은 수신된 API 호출 요청에 대응하는 데이터를 종합하여 호출 서비스(20)를 호출할 수 있으며, 호출된 서비스를 사용자(10)에게 전송할 수 있다.
API 데이터 수집시스템(100)은 서로 다른 호출 서비스(20) 사이의 커뮤니케이션을 효율적으로 수행하도록 할 수 있다. 이 때, API 데이터 수집시스템(100)은 내부의 각 구성 또는 시스템과 호출 서비스(20)를 연계하기 위해 API를 HTTP/JSON 기반의 REST(Representational state transfer) API로 표준화할 수 있다. 이를 통해, 연계 대상의 구현 방식을 알지 못하더라도 상호 커뮤니케이션이 가능하고, 불필요한 개발을 줄여 비용과 시간을 절약할 수 있다. 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템(100)은 사용자 시스템에서 별도의 리소스를 개발할 필요가 없어, 사용자(10)들에게 제공하는 다운타임이 발생하지 않으므로 원활한 서비스를 제공할 수 있다. 또한, 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템(100)은 하나의 서버가 다운되더라도 다운된 서버의 헬스체크를 지속적으로 수행하는 서버의 이중화 기능으로 인해 서브서버(Sub-server)가 동작하여 다운타임이 발생하지 않게 할 수 있다.
API 데이터 수집시스템(100)은 API 관리, 인증키 관리, 배치(batch) 관리, 데이터 저장, 인터페이스 정보 관리, 거래추적, 메시지 변환 및 분석 기능을 수행할 수 있다. 예를 들면, API 관리는 API의 등록, 조회, 수정, 삭제 등 전반적인 관리 기능을 포함할 수 있고, 인증키 관리는 등록된 API를 이용하여, 호출 서비스(20)를 호출하기 위한 인증키를 사전에 등록하고 조회, 수정하는 등으로 관리하는 기능을 포함할 수 있다. 배치(batch) 관리는 등록된 API를 이용하여 배치를 등록하고 조회, 수정하는 등으로 관리하는 기능을 포함할 수 있고, 데이터 저장은 API 호출 결과 데이터나 배치의 실행 결과 데이터를 데이터베이스에 저장하는 기능을 포함할 수 있다. 인터페이스 정보 관리는 호출 서비스(20)를 호출하기 위한 인터페이스 정보를 등록하고 관리하는 기능을 포함할 수 있다. 거래추적은 API 호출 요청부터 응답까지 API의 전체적인 흐름과 상태에 대한 정상 동작 여부 및 사용량 등을 확인하는 기능을 포함할 수 있다. 예를 들어, API 데이터 수집시스템(100)은 사용자(10)로부터 수신되는 API 호출 요청 별로 트랜잭션(transaction) ID를 부여하고, 트랜잭션 ID에 기초하여 API를 기설정된 구간마다 로깅하여 메시지 전문처리 과정에 대한 소요시간 및 오류를 추적가능하게 할 수 있다. 메시지 변환은 서로 다른 서비스의 통신을 상호 연계가 가능한 형태로 변환하는 기능을 포함하고, 분석 기능은 호출 서비스(20)의 정보를 수집하여 관리자가 분석하도록 하는 기능을 포함할 수 있다.
게이트웨이(110)는 사용자(10)로부터 수신한 API에 대한 관리를 수행할 수 있다. 이러한 게이트웨이(110)는 API에 대한 엔드포인트(end point)를 통합하고, 추가적인 기능을 제공하는 미들웨어일 수 있다. 예를 들면, 게이트웨이(110)는 API를 등록, 조회, 수정 또는 삭제하는 등으로 API를 관리하는 기능을 수행할 수 있고, 사용자(10)로부터 수신한 API 호출 요청의 라우팅을 수행하거나, 사용자에 대한 인증 및 인가를 수행할 수 있다. 또한, 게이트웨이(110)는 애그리게이터(113)를 포함할 수 있고, 이로써 실시간으로 호출 서비스를 호출할 수 있을 뿐만 아니라 특정 주기마다 호출 서비스를 호출할 수 있다. 게이트웨이(110)는 호출 서비스를 호출하는데 필요한 인증키를 사전에 저장하고 관리할 수 있다. 이러한 게이트웨이(110)의 구체적인 기능에 관해서는 도 2에서 후술한다.
중개서버(120)는 게이트웨이(110)로부터 수신한 API 호출 요청을 변환하여 호출 서비스(20)를 호출할 수 있다. 구체적으로, 중개서버(120)는 호출 서비스에 대한 인터페이스 정보를 입력 및 관리할 수 있고, 서로 다른 호출 서비스(20) 사이의 연계가 가능하도록 HTTP, TCP/IP, JDBC 등 다양한 프로토콜을 지원할 수 있고, 기존의 여러 서비스들과 연계할 수 있는 메시지 변환 솔루션을 제공할 수 있다. 예를 들면, 게이트웨이(110)로부터 전달받은 API 호출 요청에 따라 호출 서비스를 HTTP/JSON 기반의 API로 라우팅을 수행할 수 있다. 또한, 중개서버(120)는 API 호출 요청마다 트랜잭션 ID를 부여하여 API의 전체적인 흐름과 상태를 추적 할 수 있고, 수신한 API의 메시지 변환과 사용자 정의 변환 기능을 수행할 수 있다. 이러한 중개서버(120)의 구체적인 기능에 관해서는 도 3에서 후술한다.
데이터베이스(130)는 사용자(10)의 API 호출 요청에 따라 특정 API가 호출된 결과 데이터를 저장할 수 있고, 애그리게이터에 등록된 배치의 실행 결과 데이터를 저장할 수 있다.
웹서버(140)는 게이트웨이(110), 중개서버(120) 및 데이터베이스(130)의 관리 및 제어 기능을 수행할 수 있고, API 데이터 수집시스템(100)의 전체 기능을 사용자가 용이하게 사용가능하게 할 수 있다. 구체적으로, 웹서버(140)는 API 데이터 수집시스템(100)의 동작에 대한 데이터(예: API, 배치, 데이터베이스(130)에 저장된 데이터, 인증키, 및 중개서버(120)의 메시지 변환 규칙)를 각각 그룹핑(grouping)하여 도메인별로 관리가능하게 할 수 있다. 또한, 웹서버(140)는 API 데이터 수집시스템(100)의 상태에 대한 데이터를 도메인별로 관리가능하게 할 수 있다.
일예로서, 웹서버(140)는 API 데이터 수집시스템의 동작 또는 상태와 관련한 데이터를 그룹핑하여 특정 도메인을 생성할 수 있다. 웹서버(140)에서 생성된 도메인 상에는 일 이상의 탭이 생성될 수 있다. 일예로서, 상기 도메인 상에는 API 탭이 생성될 수 있다. 본 문서에 개시된 일실시예에 따라 생성된 API 탭은, 게이트웨이(110)에 등록된 API의 리스트를 일견에 확인가능하게 할 수 있고, 미사용 API를 삭제가능하게 할 수 있고, 등록된 API의 세부정보를 조회 및 수정가능하게 할 수 있고, API 등록에 필요한 정보(예: 요청/응답 파라미터, 호출 서비스의 URL 주소 등)를 이용하여 API를 등록가능하게 할 수 있고, 데이터베이스(130)에 저장되는 API 호출 결과 데이터를 관리하는 방법을 설정가능하게 할 수 있다. API 탭을 이용하여 신규 API를 등록하는 방법에 관해서는 도5에서 후술한다.
다른 예로서, 웹서버(140)에서 생성된 도메인 상에는 배치 탭이 생성될 수 있다. 본 문서에 개시된 일실시예에 따라 생성된 배치 탭은, 애그리게이터(113)에 등록된 배치의 리스트를 일견에 확인가능하게 할 수 있고, 배치를 삭제가능하게 할 수 있고, 등록된 배치의 세부정보(예: 배치의 호출주기, 배치에 등록된 API, 배치에 등록된 API의 정규식 패턴 등)를 조회 및 수정가능하게 할 수 있고, 기설정된 배치의 호출 주기를 벗어난 시점에도 강제호출 기능을 이용하여 배치를 실행가능하게 할 수 있고, 실행 중인 배치를 정지하게 할 수 있고, 배치 등록에 필요한 정보(예: 배치의 호출 주기, 배치의 유형, 호출할 API 등)를 이용하여 배치를 등록가능하게 할 수 있다. 또, 일실시예에 따라 생성된 배치 탭은, API 호출에 필요한 정보의 양식(예: 엑셀 등)을 사용자에게 제공할 수 있고, 사용자가 해당 양식을 통해 일 이상의 데이터셋(data set) 등록가능하게 할 수 있고, 등록된 데이터셋을 이용하여 배치를 실행가능하게 할 수 있다.
일예로서, 웹서버(140)에서 생성된 도메인 상에는 데이터베이스 탭이 생성될 수 있다. 본 문서에 개시된 일실시예에 따라 생성된 데이터베이스 탭은, 데이터베이스(130)에 저장된 데이터를 조회, 수정, 또는 삭제 가능하게 할 수 있다. 본 문서의 개시에 따른 일예에 따르면 데이터베이스 탭을 통해, API 데이터 수집시스템은 사용자의 신규 데이터베이스 등록 명령을 수신하여 API 데이터 수집시스템에 신규 데이터베이스를 등록할 수 있다. 이 경우, 등록하고자 하는 데이터베이스의 유효성 여부를 테스트할 수 있다. 본 문서의 개시에 따른 일예로서, API 데이터 수집시스템에 신규 데이터베이스 등록을 위한 유효성 여부를 테스트하는 경우, 등록하고자 하는 신규 데이터베이스의 드라이브 명칭, URL주소, 유저이름, 비밀번호 등을 통해 커넥션테스트를 수행할 수 있다.
일예로서, 웹서버(140)에서 생성된 도메인 상에는 인증관리 탭이 생성될 수 있다. 본 문서에 개시된 일실시예에 따라 생성된 인증관리 탭은, 게이트웨이(110)에 저장된 인증키를 등록, 조회, 수정, 또는 삭제 가능하게 할 수 있다.
일예로서, 웹서버(140)에서 생성된 도메인 상에는 파라미터 규칙 탭이 생성될 수 있다. 본 문서에 개시된 일실시예에 따라 생성된 파라미터 규칙 탭은, 파라미터에 마스킹(masking), 패딩(padding), 인코딩(encoding), 디코딩(decoding) 정책(policy)을 반영하는 메시지 변환 규칙을 정의가능하게 할 수 있다.
일예로서, 웹서버(140)에서 생성된 도메인 상에는 대시보드 탭이 생성될 수 있다. 본 문서에 개시된 일실시예에 따라 생성된 대시보드 탭은, API 데이터 수집시스템(100)의 현재 상태(예: 배치의 현재 상태, 데이터베이스에 저장된 데이터의 현재 상태 등)를 일견에 확인 가능하게 할 수 있다.
일예로서, 웹서버(140)에서 생성된 도메인 상에는 인사이트 탭이 생성될 수 있다. 본 문서에 개시된 일실시예에 따라 생성된 인사이트 탭은, 중개서버(120)가 트랜잭션 ID에 기초하여 API를 기설정된 구간마다 로깅하는 것을 확인 가능하게 함으로써, 메시지 전문처리 과정에 대한 소요시간 및 오류를 추적 가능하게 할 수 있다. 본 문서에 개시된 일 실시예에 따라 API 데이터 수집시스템(100)은 트랜잭션 ID를 통해 어느 부분에서 오류가 발생하였는지 사용자가 용이하게 확인가능하게 할 수 있고, 장애 발생시 신속한 대응이 가능하게 할 수 있다.
도 2는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템의 게이트웨이의 구성을 나타내는 블록도이다.
도 2를 참조하면, 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템(100)의 게이트웨이(110)는 API를 관리하고 사용자로부터 수신한 API 호출 요청을 처리하는 기능을 수행하는 것으로서, API 관리부(111), 요청 처리부(112), 애그리게이터(113), 및 인증키 관리부(114)를 포함할 수 있다.
API 관리부(111)는 사용자가 특정 호출 서비스를 호출할 수 있도록 API를 등록하고, 등록된 API를 조회, 수정, 또는 삭제하는 등으로 API에 대한 전반적인 관리 기능을 수행할 수 있다. 본 문서에 개시된 일실시예에 따라, API의 관리 동작은 신규 API를 등록하는 동작이거나, 등록된 API를 조회, 수정, 또는 삭제하는 동작일 수 있다. 등록된 API는 각자 API ID를 가질 수 있고, 라우트 경로를 통해 특정 호출 서비스를 호출할 수 있다. 일예로서, 호출 서비스의 호출은 실시간으로 수행될 수 있다.
요청 처리부(112)는 사용자로부터 요청된 경로에 따라 등록된 API를 라우팅할 수 있다. 이 경우, 요청 처리부(112)는 논블로킹(non-blocking) 방식을 통해 사용자로부터의 API 호출 요청에 대한 처리를 수행할 수 있다. 기존의 블로킹(blocking) 방식의 경우, 매 요청 시 스레드(thread)를 생성하고, 스레드가 사용 중일 경우 요청 스레드는 대기 상태로 유지하도록 하였다. 이 경우, 서버는 제한된 수의 요청 스레드를 가지고 있기 때문에, 서버의 최대 스레드 수만큼 요청을 수행 중인 경우에는 다른 요청을 처리하지 못하여 성능저하 및 서버 기능의 전체 활용이 제한 될 수 있다. 그러나, 본 문서에 개시된 게이트웨이(110)의 요청 처리부(112)는 논블로킹 방식을 통해 비동기적으로 요청을 처리할 수 있다. 이를 통해, 요청의 딜레이가 발생하지 않으며, 수많은 API 호출 요청을 처리하는 게이트웨이(110)가 원활하게 동작하도록 할 수 있다.
애그리게이터(113)는 게이트웨이(110)에 등록된 API를 이용하여 배치(batch)를 등록할 수 있고, API 데이터를 종합하여 기설정된 특정 주기마다 호출 서비스(20)를 호출할 수 있다. 본 문서의 개시에 따른 일예로서, 애그리게이터(113)는 기설정된 특정 주기가 도래하지 않더라도 사용자로부터 등록된 배치 실행 명령을 수신하는 경우, 배치를 실행하여 호출 서비스(20)를 호출할 수 있다. 애그리게이터(113)는 배치를 이용하여 일 이상의 API를 호출할 수 있다. 애그리게이터(113)는 배치에 등록된 제1 API의 호출 결과를 제2 API의 파라미터로 사용할 수 있는 선·후행 구조도 호출할 수 있고, 이 때, 제1 API와 제2 API는 동일한 배치에 함께 등록될 수 있다. 일예로서, 학생 이름 리스트를 호출하는 API를 제1 API로 등록하고, 제1 API의 호출 결과인 학생 이름 전체 리스트를 파라미터로 하여 학생의 신상정보를 조회하는 API를 제2 API로 등록할 수 있다. 일예로서, 애그리게이터(113)는 같은 API가 등록된 배치에서 복수개의 파라미터 셋을 실행하는 경우, 같은 API가 등록된 배치를 복수개 등록할 수 있다. 다른 예로서, 배치 등록시 데이터셋(data set)을 이용하여, 등록된 API를 호출하는 데 필요한 파라미터 셋을 복수개 설정할 수 있다. 데이터셋을 등록하는 경우 지정된 양식(예: 엑셀 등)을 이용해 각 파라미터를 등록할 수 있고, 이로써, 각 파라미터를 직접 등록해야하는 불편함을 해소하여 사용자에게 편의성을 제공할 수 있다. 파라미터를 등록하는 경우, 중개서버(120)에서 등록된 파라미터의 정보를 확인하고 유효성 검사(validation check)를 할 수 있다.
애그리게이터(113)는 동적인 파라미터 값을 처리하기 위한 정규식 패턴 기능을 포함할 수 있다. 정규식 패턴 기능은, 등록하고자 하는 데이터셋(data set)에 포함된 파라미터 값에 기설정된 정규식 패턴이 존재하는 경우, 해당 패턴을 이용하여 날짜처리(예: yyyy.mm.dd, yyyy-mm-dd 등) 또는 배열처리를 수행할 수 있다. 본 문서의 개시에 따른 일예로서, 날짜 정규식 패턴이 존재하는 경우, 데이터셋에 동적인 파라미터를 입력할 수 있다. 본 문서의 개시에 따른 일예로서, 배열처리를 수행하는 경우에는, 배열에 선언된 값을 파라미터 값으로 사용할 수 있다. 본 문서의 개시에 따른 일예에 따라 배열처리를 수행하는 경우, 배열에 선언된 값을 각 파라미터 값으로 하는 데이터셋을 등록할 수 있으므로, 전체 데이터셋의 크기를 줄일 수 있다. 본 문서의 개시에 따른 일예로서, 배열처리를 수행하는 경우에는 배열에 입력된 데이터를 이용하여 API를 여러 번 호출할 수 있다.
애그리게이터(113)는 페이징 처리가 된 호출 서비스를 호출하는 API를 이용하여 배치를 등록할 수 있다. 이 때, API의 최초 호출 시 확인되는 전체 페이지 수 또는 결과 데이터 수를 이용하여 최종 페이지 수를 확인할 수 있고, 이를 이용하여 해당 API를 총 페이지 수만큼 호출하여 모든 데이터를 조회할 수 있다.
인증키 관리부(114)는, 등록된 API를 이용하여 호출 서비스를 호출하기 위한 인증키를 사전에 저장하고 관리할 수 있다. 일예로서, 인증키 관리부(114)는 호출 서비스를 호출하기 위해 필요한 인증키를 API 등록 시에 저장할 수 있다. 이로써, 호출 서비스를 호출하는 때에 인증키를 고려하지 않을 수 있다. 일예로서, 인증키를 이용하여 호출 서비스를 호출하는 경우, 인증키에 부여된 제한된 트래픽 수에 의해 오류가 발생할 경우를 대비하여 인증키 그룹을 이용할 수 있다. 일예로서, 복수개의 인증키를 인증키 그룹으로 등록하고, 인증키 그룹을 이용하여 호출 서비스를 호출할 수 있다. 구체적으로, 인증키 그룹에 등록된 하나의 인증키에 트래픽 수 제한이 걸리면 해당 인증키 그룹에 속한 다른 인증키를 이용하여 호출 서비스를 호출할 수 있다. 일예로서, 인증키 관리부(114)는 일 이상의 인증키 그룹을 저장하고 관리할 수 있다.
도 3은 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템의 중개서버(mediation server)의 구성을 나타내는 블록도이다.
도 3을 참조하면, 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템의 중개서버(120)는 게이트웨이(110)와 호출 서비스(20) 사이에서 통신을 수행하는 것으로서, 인터페이스 관리부(121), 라우팅부(122), 거래추적부(123), 커스텀 변환부(124), 및 메시지 변환부(125)를 포함할 수 있다.
인터페이스 관리부(121)는 호출 서비스를 호출하기 위한 인터페이스 정보(예: 요청/응답 파라미터, 서비스 호출에 필요한 인증방식 등)를 등록하고 관리할 수 있다. 인터페이스 관리부(121)에 저장되는 인증방식은 HMAC(Hash-based Message Authentication Code), OAuth2.0, 또는 기타 인증방식을 지원할 수 있다. API 호출 요청이 있는 경우, 인터페이스 관리부(121)에 저장된 정보를 기반으로, 프로토콜 및/또는 파라미터를 설정하고 메시지를 변환하여 호출 서비스를 호출할 수 있다.
라우팅부(122)는 호출 서비스를 HTTP/JSON 기반의 API로 제공할 수 있다.
거래추적부(123)는 API의 상태를 추적할 수 있다. 구체적으로, 거래추적부(123)는 API 호출 요청 각각에 대해 트랜잭션 ID를 부여하여 API의 요청부터 응답까지 전체적인 흐름과 상태에 대한 추적을 수행할 수 있다. 이 경우, 거래추적부(123)는 API를 기설정된 구간마다 로깅하여 메시지 처리 과정에 대한 소요 시간 및 오류를 추적가능하도록 함으로써, 장애 발생시 보다 신속한 대응이 가능하도록 할 수 있다. 한편, 거래추적부(123)는 중개서버(120) 외에 게이트웨이(110)에도 포함될 수 있다. 이 때, 게이트웨이(110)에 포함된 거래추적부(123)의 기능은 실질적으로 동일할 수 있다. 구체적으로, 거래추적부(123)는 각 API 호출 요청마다 별도의 트랜잭션 ID를 부여하여 사용자(10)-게이트웨이(110)-중개서버(120)-호출 서비스(20) 사이의 각 단계별 프로세스 데이터를 확인 가능하게 할 수 있다. 만약, API 데이터 수집시스템(100)에서 내부적인 오류가 발생한 경우, 트랜잭션 ID를 통해 어느 부분에서 오류가 발생하였는지 용이하게 확인할 수 있어 신속한 대처가 가능하다. 이와 같은 방식으로 축적된 데이터를 이용하여 API 호출 요청마다 성공/실패 등의 기본 정보와 함께 프로세스 시간 등의 통계 데이터도 제공할 수 있다.
커스텀 변환부(124)는 API에 대한 메시지 변환 규칙을 정의할 수 있다. 예를 들면, 커스텀 변환부(124)는 메시지 변환 규칙을 스크립트(script)로 정의할 수 있다. 이처럼, 스크립트 형태로 메시지 변환 규칙을 정의하는 경우에는 별도의 코딩이나 서비스의 재시작 없이 새로운 규칙을 적용할 수 있다. 종래의 메시지 변환 방식은 메시지 변환 로직을 추가할 경우 별도로 개발 후 프로그램을 재가동해야 하였다. 반면, 본 문서에 개시된 일 실시예에 따른 중개서버(120)의 커스텀 변환부(124)는 메시지 변환규칙을 스크립트로 정의하여, 별도의 개발(코딩) 및 서비스 재가동 없이도 새로운 규칙을 적용할 수 있다.
메시지 변환부(125)는 커스텀 변환부(124)에서 정의된 메시지 변환 규칙에 따라 API에 포함된 메시지를 변환할 수 있다. 예를 들면, 메시지 변환부(125)는 API의 헤더 및 바디 중 적어도 하나에 있는 메시지를 변환할 수 있다. 또한, 메시지 변환부(125)는 메시지마다 기설정된 변환을 수행할 수 있다. 예를 들면, 메시지 변환부(125)는 리졸버(resolver)를 이용하여 파라미터마다 마스킹(masking), 패딩(padding), 인코딩(encoding), 디코딩(decoding) 정책(policy)을 반영할 수 있다. 일예로서, 리졸버 또한 스크립트(script) 기반으로 작성될 수 있고, 이로써 프로그램 재가동 없이도 서비스를 제공할 수 있다. 또한, 메시지 변환부(125)는 다양한 호출 서비스와 연계 가능한 복수의 통신 프로토콜을 제공할 수 있다. 예를 들면, 메시지 변환부(125)에서 제공하는 통신 프로토콜은 HTTP, TCP/IP(Transmission Control Protocol/Internet Protocol), JDBC(Java Database Connectivity) 등을 포함할 수 있다. 즉, 메시지 변환부(125)는 메시지 변환을 하면서 또는 메시지 변환 전후에 통신 프로토콜의 변환을 수행할 수 있다.
도 4는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용하여 데이터를 수집하는 방법에 있어서의 동작 흐름도이다. 도 4에 도시된 각 동작들의 수행 주체에 대해서는 도 1 내지 도 3을 참조할 수 있다.
도 4를 참조하면, 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, API 데이터 수집시스템의 동작 또는 상태와 관련한 데이터를 그룹핑하는 특정 도메인을 생성하여 관리할 수 있다(S200). S200 동작은 웹서버(140)를 통해 수행될 수 있다. 일예로서, S200 동작에서 생성된 도메인 상에는, API 데이터 수집시스템에 API를 등록하고 등록된 API를 조회, 수정, 또는 삭제하는 등의 전반적인 관리를 수행가능토록 하는 API 탭을 생성할 수 있다. 본 문서에 개시된 일예에 따른 API 탭에서는 신규 API를 등록의 명령을 입력받고, 이를 게이트웨이(110)에 저장할 수 있다. 본 문서의 개시에 따른 일예로서 신규 API를 등록하는 과정은 도 5에서 구체적으로 후술한다. 일예로서, S200 동작에서 생성된 도메인 상에는, API 데이터 수집시스템에 등록된 API를 이용하여 배치(batch)를 등록하고 등록된 배치를 조회, 수정, 삭제, 또는 실행하는 등의 전반적인 관리를 수행가능토록 하는 배치 탭을 생성할 수 있다. 본 문서의 개시에 따른 일예로서 등록된 API를 이용하여 배치를 등록하는 경우, 배치에 등록한 제1 API의 응답 데이터를 파싱(parsing)하여 요청 데이터의 파라미터로 하는 제2 API를 상기 제1 API와 동일한 배치에 함께 등록할 수 있다. 본 문서의 개시에 따른 일예에 따라, 제1 API의 응답 데이터를 제2 API의 요청 파라미터로 하는 선·후행 구조를 포함하는 배치에 대한 구체적인 설명은 도 7에서 후술한다. 일예로서, S200 동작에서 생성된 도메인 상에는, API 데이터 수집시스템의 데이터베이스에 저장된 데이터를 조회, 수정, 또는 삭제하는 등의 전반적인 관리를 수행가능토록 하는 데이터베이스 탭을 생성할 수 있다. 일예로서, S200 동작에서 생성된 도메인 상에는, API 데이터 수집시스템에 인증키를 등록하고 등록된 인증키를 조회, 수정, 또는 삭제하는 등의 전반적인 관리를 수행가능토록 하는 인증키 탭을 생성할 수 있다. 일예로서, S200 동작에서 생성된 도메인 상에는, 메시지 변환 규칙을 정의 가능하게 하는 파라미터 규칙 탭을 생성할 수 있다. 일예로서, S200 동작에서 생성된 도메인 상에는, API 데이터 수집시스템의 현재 상태(예: 배치의 현재 상태, 데이터베이스에 저장된 데이터의 현재 상태 등)를 일견에 확인가능토록 하는 대시보드 탭을 생성할 수 있다. 일예로서, S200 동작에서 생성된 도메인 상에는, 트랜잭션 ID에 기초하여 기설정된 구간마다 로깅되는 API를 확인가능토록 함으로써, 메시지 전문처리 과정에 대한 소요시간 및 오류를 추적가능토록 하는 인사이트 탭을 생성할 수 있다.
본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, 사용자의 API 호출 요청에 대한 호출 서비스를 호출하기 위해 필요한 인증키를 등록할 수 있다(S210). 일예로서, 인증키에 부여된 제한된 트래픽 수에 의해 오류가 발생할 경우를 대비하여 하나 또는 복수 개의 인증키 그룹을 등록할 수 있다. 본 문서에 개시된 일 실시예에 따라 인증키 그룹을 등록하는 경우, 인증키 그룹에 등록된 하나의 인증키에 트래픽 수 제한이 걸리면 해당 인증키 그룹에 속한 다른 인증키를 이용하여 호출 서비스를 호출가능하게 할 수 있다.
본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, API의 호출 결과 데이터 또는 배치(batch)의 실행 결과 데이터를 저장(수집)하기 위해, API 데이터 수집시스템에 일 이상의 데이터베이스를 등록할 수 있다(S220). 일예로서 데이터베이스의 등록은 웹서버(140)를 통해 수행될 수 있다. 일예로서 API 데이터 수집시스템에 신규 데이터베이스를 등록하는 경우, 데이터베이스의 유효성 여부를 테스트할 수 있다. 일예로서 API 데이터 수집시스템에 등록되는 신규 데이터베이스의 유효성 여부를 테스트하는 경우, 해당 데이터베이스의 드라이버 명칭, URL주소, 유저이름, 비밀번호 등을 이용하여 커넥션테스트를 수행할 수 있다.
본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, API에 대한 메시지 변환 규칙을 정의할 수 있다(S230). 일예로서, S230 동작에서는 메시지 변환 규칙을 스크립트(script) 형태로 정의할 수 있다. 이처럼, 스크립트 형태로 메시지 변환 규칙을 정의하는 경우에는 별도의 코딩이나 서비스의 재가동 없이 새로운 규칙을 적용할 수 있다. 본 문서의 개시에 따른 일예에 따르면, API 데이터 수집시스템이 API 호출 요청을 수행하거나(S260) 배치 실행 요청을 수행하는 경우(S265)에, 본 문서에 개시된 실시예에 따른 메시지 변환 규칙에 따라, API에 포함된 메시지(요청 데이터) 또는 호출 서비스 호출의 응답 데이터를 변환할 수 있다. 본 문서에 개시된 일예에 따라 요청 데이터 또는 응답 데이터를 메시지를 변환하는 동작과 관련한 구체적인 설명은 도 6a에서 후술한다.
본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, API 데이터 수집시스템은 사용자로부터 신규 API에 관한 정보를 입력받아 게이트웨이(110)에 신규 API를 등록할 수 있다(S240). 본 문서에 개시된 일 실시예에 따라, API 데이터 수집시스템의 웹서버(140)에서 생성된 특정 도메인 상의 API 탭을 통해 신규 API를 등록할 수 있다. 신규 API를 등록하는 방법에 대한 구체적인 설명은 도 5에서 후술한다.
본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, 게이트웨이(110)에 등록된 일 이상의 API를 이용하여 배치(batch)를 등록할 수 있다(S250). 일예로서 배치를 등록하는 경우, 배치 실행을 위해 지정된 특정 주기(period)의 정보를 함께 포함할 수 있다. 이 때, 지정된 주기가 도래하는 경우에 배치 실행 요청을 수행하도록 API 데이터 수집시스템을 셋팅(setting)할 수 있다. 일예로서 배치 사용의 셋팅이 존재하는 경우, API 데이터 수집시스템이 배치 실행을 위해 지정된 주기가 도래하는 경우에 배치 실행의 요청을 수행하도록 설정할 수 있다. 본 문서의 개시에 따른 일실시예에 따라 지정된 주기가 도래한 때 배치 실행 요청을 수행하는 과정에 대한 구체적인 설명은 도 6b에서 후술한다. 일예로서 배치를 등록하는 경우, 배치에 포함된 복수개의 API들은 제1 API의 결과 데이터가 제2 API의 요청 데이터의 파라미터 값을 구성하는 구조, 즉, 상호 선·후행의 구조에 해당할 수 있다. 본 문서의 개시에 따른 일실시예에 따라 선·후행 구조의 API를 포함하는 배치와 관련한 설명은 도 7에서 구체적으로 후술한다. 일예로서 배치를 등록하는 경우, 데이터셋(data set)을 이용할 수 있다. 본 문서의 개시에 따른 일예에 따라 데이터셋을 이용하는 경우, 데이터셋에 포함된 파라미터 값에 기설정된 정규식 패턴이 존재한다면 해당 패턴을 이용하여 날짜처리를 수행하거나 배열처리를 수행할 수 있다. 데이터셋을 이용하는 배치와 관련한 설명은 도 8에서 구체적으로 후술한다.
본 문서의 개시에 따른 일예로서, 웹서버(140)를 통해 게이트웨이가 사용자로부터 API 호출 요청 명령을 입력받은 경우에는 게이트웨이의 요청 처리부(112)에서 해당 API 호출 요청을 수행할 수 있다(S260). 일예로서, 배치 사용의 셋팅이 존재하는 경우, 배치를 실행하기 위해 지정된 특정 주기를 만족하는지 여부를 판단할 수 있다. 본 문서에 개시에 따른 일예에 따라, 배치 실행을 위해 지정된 특정 주기(period)가 도래한 경우, 게이트웨이의 요청 처리부(112)에서 등록된 배치를 실행하여, 배치에 포함된 일 이상의 API의 호출 요청을 수행할 수 있다(S265). 본 문서에 개시에 따른 일예로서, 배치 실행의 주기가 도래하지 않는 경우라도, 웹서버(140)를 통해 사용자로부터 배치 실행 명령이 직접 입력된 경우에는 해당 배치의 실행 요청을 수행할 수 있다(S265).
본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 따르면, API 데이터 수집시스템의 거래추적부(123)는 API 호출 요청에 대한 트랜잭션 ID를 부여할 수 있다(S270). S270 동작에서 각 API 호출 요청마다 트랜잭션 ID를 부여한 이후, 트랜잭션 ID에 기초하여 API를 기설정된 구간마다 로깅할 수 있다(S271). 이로써, API의 요청부터 응답까지 전체적인 동작의 흐름과 상태를 추적 가능하게 할 수 있다. 이 경우, 메시지 처리 과정에 대한 소요 시간 및 오류를 추적가능하게 함으로써, 장애 발생시 보다 신속한 대응이 가능하게 할 수 있다.
본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 따르면, API 데이터 수집시스템은 API 호출 요청에 따른 결과 데이터 또는 등록된 배치의 실행 결과 데이터를 사용자(10)가 확인가능하도록 할 수 있다. 일예로서, API 데이터 수집시스템은 사용자(10)가 API 호출 요청 또는 배치의 실행 요청에 대한 결과 데이터를 웹서버(140)를 통해 생성된 특정 도메인상에서 확인가능하도록 할 수 있다. 일예로서, API 데이터 수집시스템은 API 호출 요청의 해당 결과 데이터 또는 배치의 실행 결과 데이터를 API 데이터 수집시스템(100)의 데이터베이스(130)에 저장할 수 있다(S280). 일예로서, API 데이터 수집시스템이 사용자로부터 데이터베이스 사용 명령을 입력받은 경우에만 결과 데이터를 저장하는 동작을 수행하도록 할 수 있다. 일예로서, 사용자로부터 데이터베이스 사용 명령이 없는 경우라면 API 데이터 수집시스템은 사용자(10)가 결과 데이터를 확인가능하게 하는 데 그치게 할 수 있다. 또, 호출 서비스(20)를 HTTP/JSON 기반의 API로 제공할 수 있다.
도 4에 개시된 실시예들은 본 발명의 목적 범위 안에서라면, 각 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.
도 5는 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, 신규 API 등록 방법의 동작 흐름도이다. 도 5에 도시된 동작들의 수행 주체에 대해서는, 도 1 내지 도 3을 참조할 수 있다.
도 5를 참조하면, 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 API 데이터 수집 방법에 있어서, API 데이터 수집시스템은 파라미터 및 API 정보를 입력받아(S300) 신규 API를 등록할 수 있다(S340). 본 문서의 개시에 따른 일예로서 API 데이터 수집시스템이 사용자로부터 메시지 변환 규칙 사용 명령을 입력받는 경우(S310), 입력받은 명령에 따른 메시지 변환 규칙을 상기 입력받은 파라미터에 등록할 수 있다(S311). 본 문서의 개시에 따른 일예로서 API 데이터 수집시스템이 사용자로부터 인증키 사용 명령을 입력받는 경우(S320), 인증키 관리부에 저장된 인증키 또는 인증키 그룹 중 하나를 선택하여 신규 API의 인증키로 등록할 수 있다(S321). 신규 API의 인증키로서는 하나의 인증키가 등록될 수 있을 뿐만 아니라, 인증키 그룹도 신규 API의 인증키로 등록될 수도 있다. 이 때, 인증키 관리부(114)는 상기 API 데이터 수집시스템의 게이트웨이에 포함된 일 구성에 해당할 수 있다. 일예로서 API 데이터 수집시스템이 데이터베이스 저장 명령을 입력받는 경우(S330), 신규 API의 호출 결과 데이터를 저장하기 위하여 기등록된 데이터베이스 중 하나를 지정할 수 있다(S331). 다른 예로서, API 데이터 수집시스템에 등록된 API에 데이터베이스 사용 명령을 입력받는 경우, API 데이터 수집시스템에 신규 데이터베이스를 등록할 수 있고, 일예에 따라 신규 등록된 데이터베이스를 신규 API의 결과 데이터를 저장하기 위한 데이터베이스로 지정할 수 있다. 이와 같이 API 데이터 수집시스템에 신규 데이터베이스를 등록하는 경우에는 등록될 데이터베이스의 유효성을 테스트할 수 있다. 본 문서의 개시에 따른 일예에 따라 등록될 데이터베이스의 유효성을 검사하는 경우에는, 드라이브 명칭, URL 주소, 유저이름, 비밀번호 등이 유효한지 확인하기 위한 커넥션테스트를 수행할 수 있다. 본 문서의 개시에 따른 일예에 따라 등록된 API를 이용하여 배치를 등록 및 실행하는 경우라면, 등록된 각 API가 지정한 데이터베이스에 해당 배치의 실행 결과 데이터를 저장할 수 있다. 일예로서, 도 5에서 도시된 각 동작들 중 명령을 입력받는 동작들은 API 데이터 수집시스템(100)의 웹서버(140)를 통해 수행될 수 있고, 입력받은 명령의 처리는 게이트웨이(110)의 API 관리부(111)에서 수행할 수 있다.
도 6a 내지 도 6c는 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템(100)을 이용한 데이터 수집 방법의 동작 흐름도이다. 도 6a 내지 도 6c에 도시된 동작들의 수행 주체에 대해서는, 도 1 내지 도 3을 참조할 수 있다.
도 6a는 API 수집시스템(100)을 이용한 데이터 수집 방법의 동작 흐름도로서, API 호출 요청이 있는 경우 그에 대한 호출 서비스(응답 데이터)를 호출하는 방법에 대한 동작 흐름도를 도시한다. 도 6a에 도시된 동작들은 도4의 S260 동작의 일 예일 수 있다. 다른 예로서, 도 6a에 도시된 동작들은 도4의 S265 동작의 일 예로서, 실행 요청된 배치에 포함된 일 이상의 API 호출 요청을 수행하는 동작의 일 예일 수 있다.
도 6a를 참조하면, 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템(100)은 사용자(10)로부터 API 호출 요청(즉, 요청 데이터)이 있는 경우(S400), 해당 API 호출의 요청 데이터를 처리하여 그에 대한 호출 서비스(20)(즉, 응답 데이터)를 호출할 수 있고(S430), 호출된 결과 데이터를 사용자가 확인가능하게 할 수 있다(S440). 일예로서, API 데이터 수집시스템(100)이 사용자의 API 호출 요청을 수신하는 경우, 일 이상의 파라미터 중 필수 파라미터로 설정된 파라미터를 이용하여 수신된 호출 요청을 수행할 수 있다. 일예로서, 사용자는 API 데이터 수집시스템(100)에 인증키 사용 명령을 입력할 수 있고, API 데이터 수집시스템(100)은 인증키 사용 명령의 입력 여부를 판단할 수 있다(S410). 본 문서에 개시된 일 실시예에 따라, API 데이터 수집시스템(100)에 인증키 사용 명령이 입력되었다고 판단하는 경우, 인증키 관리부(114)에 저장된 인증키를 요청 데이터에 포함시킬 수 있다(S411). 일예로서, 사용자는 API 데이터 수집시스템(100)에 메시지 변환 규칙 사용 명령을 입력할 수 있고, API 데이터 수집시스템(100)은 해당 명령의 입력 여부를 판단할 수 있다(S420). 본 문서에 개시된 일 실시예에 따라 API 데이터 수집시스템에 메시지 변환 규칙의 사용 명령이 입력되었다고 판단한 경우, 호출 서비스(20)(즉, 응답 데이터)를 호출하기에 앞서, 기설정된 메시지 변환 규칙에 따라 요청 데이터를 변환할 수 있다(S421). 이 때, 메시지 변환 규칙은 커스텀 변환부(124)에서 정의된 API 메시지 변환 규칙에 해당할 수 있다. 본 문서에 개시된 일예에 따른 메시지 변환 규칙에 의해 API 메시지를 변환하는 경우(S421), API의 헤더 및 바디 중 적어도 하나에 있는 메시지를 변환할 수 있다. 또한, 본 문서의 개시에 따른 일예에 따른 메시지 변환 규칙에 의해 메시지를 변환하는 경우, 다양한 호출 서비스와 연계 가능한 복수의 통신 프로토콜을 제공할 수 있다. 본 문서의 개시에 따른 일예에 따른 메시지 변환을 수행하는 경우에 제공하는 통신 프로토콜의 예로서 HTTP, TCP/IP, JDBC 등을 포함할 수 있다. 본 문서의 개시에 따른 일예로서 메시지 변환을 수행하면서 또는 메시지 변환 전후에 통신 프로토콜의 변환을 수행할 수 있다. 본 문서에 개시된 일 실시예에 따라, S421 동작은 메시지 변환부(125)에서 수행할 수 있다. 일예로서, 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템(100)은, 호출 서비스를 호출할 수 있고(S430), 호출된 응답 데이터(즉, 결과 데이터)를 사용자(10)가 확인가능하도록 나타낼 수 있다(S440). 본 문서에 개시된 일 실시예에 따라, API 데이터 수집시스템(100)에 메시지 변환 규칙 사용 명령이 입력되는 경우(S420), 결과 데이터를 나타내기에 앞서, 호출된 응답 데이터를 기설정된 메시지 변환 규칙에 따라 변환할 수 있다(S422). 이 때, S421 동작 및 S422 동작을 수행하는 데 있어서 사용되는 메시지 변환 규칙은 상호 대칭되는 규칙일 수 있다.
도 6b는 API 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도로서, 주기에 따른 배치의 사용 셋팅(setting)이 있는 경우 지정된 주기로 배치를 실행하는 방법에 대한 동작 흐름도를 도시한다.
도 6b를 참조하면, 일예로서, 사용자는 API 데이터 수집시스템(100)에 배치 사용 셋팅을 설정할 수 있고, 이 때, API 데이터 수집시스템은 사용자로부터 배치 사용 셋팅이 설정되었는지 여부를 판단할 수 있다(S263). 일예로서 배치 사용 명령이 입력된 경우에는, API 데이터 수집시스템(100)은 미리 지정된 주기(period)가 도래하였는지 여부를 확인할 수 있다(S264). 본 문서에 개시된 일 실시예에 따라, 기설정된 주기가 도래한 것으로 판단한 경우에는 배치 실행 요청을 수행하여(S265), 배치에 등록된 API의 호출 요청을 할 수 있다. 다른 예로서, API 데이터 수집시스템(100)에 배치 사용 셋팅이 설정되지 않은 경우에는, 사용자(10)의 API 호출 요청을 실시간으로 처리할 수 있다. 다른 예로서, API 데이터 수집시스템(100)에 배치 사용 셋팅이 설정된 경우, 배치 실행을 위해 지정된 주기가 도래하지 않더라도, 사용자(10)로부터 배치 사용의 명령을 입력받은 경우에는 강제로 배치를 실행할 수 있다. 실시예에 따라, 도 6b에 도시된 동작 중 S265 동작은 도 4의 S265 동작과 동일한 동작을 나타낼 수 있다. 실시예에 따라, 도 6b에 도시된 동작들은 도 6a의 S400 동작 전후에 수행하거나 또는 S400 동작과 병행하여 수행할 수 있다.
도 6c는 API 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도로서, 데이터베이스 사용 명령이 있는 경우 지정된 데이터베이스에 API 호출 요청의 결과데이터 또는 배치 실행 요청의 결과데이터를 저장하는 방법에 대한 동작 흐름도를 도시한다.
도 6c를 참조하면, 일예로서, 사용자는 API 데이터 수집시스템(100)에 데이터베이스 사용 명령을 입력할 수 있고, 이 때, API 데이터 수집시스템은 사용자로부터 데이터베이스 사용 명령이 입력되었는지 여부를 판단할 수 있다(S279). 일예로서, API 데이터 수집시스템(100)은 데이터베이스 사용 명령이 입력된 경우에만 데이터베이스(130)에 API 호출 또는 배치 실행의 결과 데이터를 저장하는 동작(S280)을 수행하게 할 수 있다. 실시예에 따라, 도 6c에 도시된 동작들은 도 6a의 S440 동작 이후에 수행하거나 또는 S440 동작과 병행하여 수행할 수 있다.
도 7은 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도이다. 도 7에 도시된 동작들은 예를 들어 도 4의 S250 동작의 일 예일 수 있다.
도 7을 참조하면, 배치를 등록하는 경우, 제1 API를 특정 배치에 등록하고(S251), 배치에 등록된 제1 API의 호출 결과를 파라미터로 하는 제2 API를 같은 배치에 함께 등록할 수 있다(S252). 이로써, 선·후행 구조의 API를 배치에 등록하여 호출할 수 있다. 본 문서에 개시된 일예에 따라, 선·후행 구조의 API를 배치에 함께 등록하는 경우, 선행 API의 응답 데이터를 후행 API의 요청 데이터로 파싱(parsing)하여 사용할 수 있다. 구체적인 예로서, 학생 이름 리스트를 호출하는 API를 제1 API로 배치에 등록하고, 제1 API의 호출 결과인 학생 이름 전체 리스트를 파라미터로 하여 학생의 신상정보를 조회하는 API를 제2 API로 하여 같은 배치에 등록할 수 있다. 본 문서에 개시된 일예에 따른 선·후행 구조의 API를 포함하는 배치를 등록하는 경우, 제2 API, 즉, 후행 API의 요청 데이터에 대한 파라미터 값을 사용자로부터 일일이 입력받지 않더라도 제1 API, 즉, 선행 API의 응답 데이터를 파싱하여 사용할 수 있으므로, 편의성을 제공할 수 있다.
도 8은 본 문서에 개시된 일 실시예에 따른 API 데이터 수집시스템을 이용한 데이터 수집 방법의 동작 흐름도이다. 도 8에 도시된 동작들은, 도 4의 S265 동작에 대한 일 실시예일 수 있다.
도 8을 참조하면, 배치를 등록하는 S250 동작의 일예로서, 데이터셋(data set)을 이용하여 배치를 등록할 수 있다(S253). 데이터셋을 이용하여 배치를 등록하는 경우, 사용자(10)는 지정된 양식(예: 엑셀 등)을 이용하여 각 파라미터를 등록할 수 있고, 이로써, 각 파라미터를 직접 등록해야하는 불편함을 해소하여 편의성을 증가시킬 수 있다. 또한, 도 8을 참조하면, 배치를 실행하는 S265 동작의 일예로서, 등록된 데이터셋을 이용하여 배치를 실행할 수 있다. 본 문서에 개시된 일 실시예에 따라, 등록된 데이터셋에 포함된 파라미터 값에 기설정된 정규식 패턴이 존재하는지 여부를 판단할 수 있다(S266). 기설정된 정규식 패턴이 존재한다고 판단되는 경우에는, 해당 패턴을 이용하여 날짜처리를 수행하거나 배열처리를 수행할 수 있다(S267). 일예로서, 정규식 패턴이 존재하지 않는다고 판단되는 경우에는, 곧바로 배치의 실행 동작을 수행할 수 있다. 도 8에 도시된 S266 및 S267 동작들은 도 4의 S265 동작 이후에 수행하거나 또는 S265 동작과 병행하여 수행할 수 있다.
이상에서, 본 문서에 개시된 실시예를 구성하는 모든 구성 요소들이 하나로 결합하거나 결합하여 동작하는 것으로 설명되었다고 해서, 본 문서에 개시된 실시예들이 반드시 이러한 실시예에 한정되는 것은 아니다. 즉, 본 문서에 개시된 실시예들의 목적 범위 안에서라면, 그 모든 구성 요소들이 하나 이상으로 선택적으로 결합하여 동작할 수도 있다.
또한, 이상에서 기재된 "포함하다", "구성하다", 또는 "가지다" 등의 용어는, 특별히 반대되는 기재가 없는 한, 해당 구성 요소를 내재할 수 있음을 의미하는 것이므로, 다른 구성 요소를 제외하는 것이 아니라 다른 구성 요소를 더 포함할 수 있는 것으로 해석되어야 한다. 기술적이거나 과학적인 용어를 포함한 모든 용어들은, 다르게 정의되지 않는 한, 본 문서에 개시된 실시예들이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미가 있다. 사전에 정의된 용어와 같이 일반적으로 사용되는 용어들은 관련 기술의 문맥상의 의미와 일치하는 것으로 해석되어야 하며, 본 문서에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이상의 설명은 본 문서에 개시된 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 문서에 개시된 실시예들이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 문서에 개시된 실시예들의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 문서에 개시된 실시예들은 본 문서에 개시된 실시예들의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 문서에 개시된 기술 사상의 범위가 한정되는 것은 아니다. 본 문서에 개시된 기술사상의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술사상은 본 문서의 권리 범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (16)

  1. API 호출 요청을 수신하는 게이트웨이;
    상기 게이트웨이로부터 상기 API 호출 요청을 전달받고, 및 호출 서비스를 호출하는 중개서버(mediation server);
    일 이상의 데이터베이스; 및
    웹서버;를 포함하는 API 데이터 수집시스템으로서,
    상기 게이트웨이는,
    API를 관리하는 API 관리부;
    논블로킹(non-blocking) 방식을 통해 상기 API 호출 요청에 대한 처리를 수행하는 요청 처리부;
    등록된 상기 API를 이용하여 배치(batch)를 등록하고, 지정된 주기(period)로 상기 배치를 실행하도록 제어하는 애그리게이터(aggregator);
    상기 호출 서비스를 호출하기 위한 인증키를 사전에 저장하고 관리하는 인증키 관리부;를 포함하고,
    상기 중개서버는,
    상기 API에 대한 호출 서비스 정보를 관리하는 인터페이스 관리부;
    상기 호출 서비스를 HTTP/JSON 기반의 API로 제공하는 라우팅부;
    상기 API 호출 요청에 대한 개별적인 트랜잭션 ID를 부여하고, 및 상기 트랜잭션 ID에 기초하여 상기 API를 기설정된 구간마다 로깅하는 거래추적부;
    상기 API에 대하여 사용자에 의해 정의된 메시지 변환 규칙을 생성하는 커스텀 변환부; 및
    상기 메시지 변환 규칙에 따라 상기 API에 포함된 메시지를 변환하는 메시지 변환부;를 포함하고,
    상기 데이터베이스는, 상기 API 호출 요청의 결과 데이터 또는 상기 배치의 실행 결과 데이터를 더 저장하도록 설정되고,
    상기 웹서버는,
    상기 API 데이터 수집시스템의 동작 또는 상태와 관련한 데이터를 그룹핑하여 도메인을 생성하도록 설정된 것을 특징으로 하는 API 데이터 수집시스템.
  2. 청구항 1항에 있어서,
    상기 인증키 관리부는,
    상기 인증키를 복수개 포함하는 인증키 그룹을 일 이상 생성하고, 생성된 일 이상의 상기 인증키 그룹을 더 저장하도록 설정된 것을 특징으로 하는 API 데이터 수집시스템.
  3. 청구항 2항에 있어서,
    상기 애그리게이터는,
    상기 배치에 등록된 제1 API의 호출 결과를 파라미터로 하는 제2 API를 상기 배치에 함께 등록하도록 설정된 것을 특징으로 하는 API 데이터 수집시스템.
  4. 청구항 2항에 있어서,
    상기 애그리게이터는,
    데이터셋(data set)을 이용하여 상기 배치를 실행하도록 설정된 것을 특징으로 하는 API 데이터 수집시스템.
  5. 청구항 4항에 있어서,
    상기 애그리게이터는,
    상기 데이터셋(data set)에 포함된 파라미터 값에 기설정된 정규식 패턴이 존재하는 경우, 상기 패턴을 이용하여 날짜처리 또는 배열처리를 수행하도록 설정된 것을 특징으로 하는 API 데이터 수집시스템.
  6. 청구항 2항에 있어서,
    상기 애그리게이터는,
    상기 배치에 페이징 처리가 된 호출 서비스를 호출하는 API를 등록하는 것을 특징으로 하는 API 데이터 수집시스템.
  7. API 호출 요청을 수신하고, 및 논블로킹(non-blocking) 방식을 통해 상기 API 호출 요청에 대한 처리를 수행하는 게이트웨이;
    상기 API에 대한 호출 서비스 정보를 관리하고, 상기 게이트웨이로부터 상기 API 호출 요청을 전달받고, 및 호출 서비스를 호출하는 중개서버(mediation server);
    및
    웹서버;를 포함하는 API 데이터 수집시스템을 이용한 API 데이터 수집 방법으로서,
    상기 API 데이터 수집시스템에 일 이상의 데이터베이스를 등록하는 동작;
    상기 게이트웨이에서, API를 관리하는 동작;
    상기 게이트웨이에서, 상기 호출 서비스를 호출하기 위한 인증키를 저장하고 관리하는 동작;
    상기 게이트웨이에서, 등록된 상기 API를 이용하여 배치(batch)를 등록하는 동작;
    상기 게이트웨이에서, 실시간으로 API 호출 요청을 수행하거나 지정된 주기(period)로 상기 배치를 실행하는 동작;
    상기 데이터베이스에 상기 API 호출 요청의 결과 데이터 또는 상기 배치의 실행 결과 데이터를 저장하는 동작;
    상기 중개서버에서, 상기 호출 서비스를 HTTP/JSON 기반의 API로 제공하는 동작;
    상기 중개서버에서, 각각의 상기 API 호출 요청에 대한 트랜잭션 ID를 부여하는 동작;
    상기 중개서버에서, 상기 트랜잭션 ID에 기초하여 상기 API를 기설정된 구간마다 로깅하는 동작;
    상기 중개서버에서, 상기 API에 대하여 사용자에 의해 정의된 메시지 변환 규칙을 생성하는 동작;
    상기 중개서버에서, 상기 메시지 변환 규칙에 따라 상기 API에 포함된 메시지를 변환하는 동작; 및
    상기 웹서버에서, 상기 API 데이터 수집시스템의 동작 또는 상태와 관련한 데이터를 그룹핑하여 도메인을 생성하는 동작;을 포함하는 API 데이터 수집 방법.
  8. 청구항 7항에 있어서,
    상기 게이트웨이에서, 상기 인증키를 복수개 포함하는 인증키 그룹을 일 이상 생성하고, 생성된 일 이상의 상기 인증키 그룹을 저장하고 관리하는 동작;을 더 포함하는 API 데이터 수집 방법.
  9. 청구항 8항에 있어서,
    상기 배치를 등록하는 동작은,
    상기 배치에 제1 API를 등록하고, 상기 제1 API의 호출 결과를 파라미터로 하여 제2 API를 상기 배치에 함께 등록하는 동작;인 것을 특징으로 하는 API 데이터 수집 방법.
  10. 청구항 8항에 있어서,
    상기 게이트웨이에서, 데이터셋(data set)을 이용하여 상기 배치를 실행하는 동작;이 더 포함된 것을 특징으로 하는 API 데이터 수집 방법.
  11. 청구항 10항에 있어서,
    상기 게이트웨이에서, 상기 데이터셋(data set)에 포함된 파라미터 값에 기설정된 정규식 패턴이 존재하는 경우, 상기 패턴을 이용하여 날짜처리 또는 배열처리를 수행하는 동작;을 더 포함하는 것을 특징으로 하는 API 데이터 수집 방법.
  12. 청구항 8항에 있어서,
    상기 배치를 등록하는 동작은,
    페이징 처리가 된 호출 서비스를 호출하는 API를 상기 배치에 등록하는 동작;인 것을 특징으로 하는 API 데이터 수집 방법.
  13. 청구항 8항에 있어서,
    상기 배치를 실행하는 동작은,
    상기 API 데이터 수집시스템에 상기 배치의 사용 명령이 입력되고, 지정된 주기(period)를 만족한 경우에만 수행하는 것을 특징으로 하는 API 데이터 수집 방법.
  14. 청구항 8항에 있어서,
    상기 데이터베이스에 상기 API 호출 요청의 결과 데이터 또는 상기 배치의 실행 결과 데이터를 저장하는 동작은,
    상기 API 데이터 수집시스템에 상기 데이터베이스의 사용 명령이 입력된 경우에만 수행하는 것을 특징으로 하는 API 데이터 수집 방법.
  15. 청구항 8항에 있어서,
    상기 API 데이터 수집시스템에 신규 API를 등록하는 동작;을 더 포함하는 API 데이터 수집 방법으로서,
    상기 신규 API를 등록하는 동작은,
    상기 웹서버에서 파라미터 및 API 정보를 입력받아 상기 게이트웨이에 신규 API를 등록하는 동작;
    상기 웹서버에 메시지 변환 규칙 사용 명령이 입력된 경우, 상기 게이트웨이에서 상기 파라미터에 상기 명령에 따른 메시지 변환 규칙을 등록하는 동작;
    상기 웹서버에 인증키 사용 명령이 입력된 경우, 상기 게이트웨이가 상기 게이트웨이에 저장된 인증키 하나를 상기 API의 인증키로 등록하는 동작;
    상기 웹서버에 데이터베이스 등록 명령이 입력된 경우, 상기 게이트웨이가 상기 데이터베이스에 저장된 API 호출 결과 데이터 중 하나를 상기 API의 결과 데이터로 등록하는 동작;을 포함하는 것을 특징으로 하는 API 데이터 수집 방법.
  16. 청구항 15항에 있어서,
    상기 API의 인증키를 등록하는 동작은,
    상기 웹서버에 인증키 사용 명령이 입력된 경우, 상기 게이트웨이가 상기 게이트웨이에 저장된 상기 일 이상의 인증키 그룹 중 하나를 상기 API의 인증키로 등록하는 동작;인 것을 특징으로 하는 API 데이터 수집 방법.
PCT/KR2022/013286 2021-09-08 2022-09-05 Api 데이터 수집시스템 및 그에 관한 방법 WO2023038381A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2021-0120010 2021-09-08
KR1020210120010A KR102417742B1 (ko) 2021-09-08 2021-09-08 Api 데이터 수집시스템 및 그에 관한 방법

Publications (1)

Publication Number Publication Date
WO2023038381A1 true WO2023038381A1 (ko) 2023-03-16

Family

ID=82400330

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/013286 WO2023038381A1 (ko) 2021-09-08 2022-09-05 Api 데이터 수집시스템 및 그에 관한 방법

Country Status (2)

Country Link
KR (1) KR102417742B1 (ko)
WO (1) WO2023038381A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230359959A1 (en) * 2022-05-05 2023-11-09 Grokit Data, Inc. Distributed Actor-Based Information System and Method

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102417742B1 (ko) * 2021-09-08 2022-07-06 비엠텍시스템 주식회사 Api 데이터 수집시스템 및 그에 관한 방법
WO2024048858A1 (ko) * 2022-09-02 2024-03-07 주식회사 마이링크 분산 메시징 서버를 통한 데이터 처리 방법, 및 이를 포함하는 분산 메시징 시스템
KR102553672B1 (ko) * 2022-10-13 2023-07-10 주식회사 마이링크 분산 메시징 서버를 통한 데이터 처리 방법, 및 이를 포함하는 분산 메시징 시스템
KR102544008B1 (ko) * 2022-11-30 2023-06-15 주식회사 엔터프라이즈블록체인 복수의 어그리게이터들(aggregators)을 관리하는 어그리게이터 매니저를 포함하는 장치 및 그 동작 방법
KR102531860B1 (ko) 2022-12-20 2023-05-12 주식회사 위베어소프트 Api 설정을 동적으로 적용하는 게이트웨이 장치 및 방법
KR102563179B1 (ko) 2023-03-02 2023-08-03 브레인즈컴퍼니 주식회사 Rest api 클라이언트 개발을 위한 가상 rest api 서비스 자동 생성 서버 및 방법

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101653685B1 (ko) * 2015-11-27 2016-09-02 주식회사 비디 컴퓨터 수행 가능한 api 관리 방법
KR20190134135A (ko) * 2018-05-25 2019-12-04 삼성에스디에스 주식회사 클라우드 플랫폼에 기반한 서비스 제공 방법 및 그 시스템
KR20200122381A (ko) * 2019-04-16 2020-10-27 구글 엘엘씨 집계된 컨버전 측정
US20200374365A1 (en) * 2017-08-14 2020-11-26 Reliance Jio Infocomm Limited Systems and Methods for Controlling Real-time Traffic Surge of Application Programming Interfaces (APIs) at Server
KR102256736B1 (ko) * 2020-02-13 2021-05-27 비엠텍시스템 주식회사 Api 관리 시스템 및 그에 관한 방법
KR102417742B1 (ko) * 2021-09-08 2022-07-06 비엠텍시스템 주식회사 Api 데이터 수집시스템 및 그에 관한 방법

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101653685B1 (ko) * 2015-11-27 2016-09-02 주식회사 비디 컴퓨터 수행 가능한 api 관리 방법
US20200374365A1 (en) * 2017-08-14 2020-11-26 Reliance Jio Infocomm Limited Systems and Methods for Controlling Real-time Traffic Surge of Application Programming Interfaces (APIs) at Server
KR20190134135A (ko) * 2018-05-25 2019-12-04 삼성에스디에스 주식회사 클라우드 플랫폼에 기반한 서비스 제공 방법 및 그 시스템
KR20200122381A (ko) * 2019-04-16 2020-10-27 구글 엘엘씨 집계된 컨버전 측정
KR102256736B1 (ko) * 2020-02-13 2021-05-27 비엠텍시스템 주식회사 Api 관리 시스템 및 그에 관한 방법
KR102417742B1 (ko) * 2021-09-08 2022-07-06 비엠텍시스템 주식회사 Api 데이터 수집시스템 및 그에 관한 방법

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230359959A1 (en) * 2022-05-05 2023-11-09 Grokit Data, Inc. Distributed Actor-Based Information System and Method

Also Published As

Publication number Publication date
KR102417742B1 (ko) 2022-07-06

Similar Documents

Publication Publication Date Title
WO2023038381A1 (ko) Api 데이터 수집시스템 및 그에 관한 방법
US20070150584A1 (en) Apparatus, system, and method for determining server utilization in hosted computing infrastructure
CN112333290B (zh) 数据访问控制方法、装置、存储介质及内容分发网络系统
US8375360B2 (en) Provision of services over a common delivery platform such as a mobile telephony network
US7756944B2 (en) Information providing apparatus, information providing method, information providing program, and recording medium
CN111290865A (zh) 一种服务调用方法、装置、电子设备和存储介质
WO2020022760A1 (ko) 시스템에 포함되는 노드들에 대하여 그룹을 운영하는 분산 네트워크 시스템
WO2012169775A9 (ko) 오픈 ａｐｉ 기반 콘텐츠 서비스 인터페이스 제공 시스템 및 방법
US9294867B2 (en) Provision of services over a common delivery platform such as a mobile telephony network
WO2019198885A1 (ko) 블록체인 기반의 다수의 서비스 노드를 사용하는 탈중앙화 서비스 플랫폼
WO2019109957A1 (zh) 基于esb的服务提供方法、装置、设备及可读存储介质
US20060161991A1 (en) Provision of services over a common delivery platform such as a mobile telephony network
CN114172966B (zh) 单元化架构下的服务调用方法、服务处理方法及装置
EP1435719A2 (en) Request processing swtich
CN108427619B (zh) 日志管理方法、装置、计算设备及存储介质
CN112866379A (zh) 微服务的访问方法和装置
CN101202751A (zh) 为虚拟联网设备提供简单网络管理协议数据的系统和方法
WO2022108427A1 (ko) 5g 기반 iot 환경을 위한 지능형 트러스트 인에이블러 시스템
CN115334150B (zh) 一种数据转发的方法、装置、系统、电子设备及介质
WO2012141412A2 (ko) 웹 페이지를 제공하는 방법 및 서버
CN115378645A (zh) 一种基于电力营销管理系统统一认证的验证方法及系统
JP2020005020A (ja) 番号管理システム、番号管理方法および番号管理装置
WO2018008824A1 (ko) 인터랙티브 메시지 서비스 제공 장치 및 방법
CN114296985A (zh) 大规模微服务集群场景下的全局异常处理方法和平台
WO2019182345A1 (en) Method of automatically searching for and registering controlled application in distributed environment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22867650

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE