System and method for automated assessment and migration of application programming interfaces

Abstract

The present application relates to a system and method for automatically evaluating and migrating application programming interfaces. The system includes a memory storing instructions and a processor configured to execute the instructions to perform operations, the operations including dividing client accounts into three groups, allocating a first API for communicating with the first group and a second API for communicating with the second group, and allocating the first API for communicating with a first portion of the third group and allocating the second API for communicating with a second portion of the third group. The operations may also include collecting communications from the groups and generating metrics associated with each group, and generating a comparison report and a compatibility report. The operations may also include sending at least one of an alert or a recommendation based on the comparison report and the compatibility report.

Description

Technical Field

[0001] The present disclosure generally relates to computerized systems and methods for upgrading or migrating application programming interfaces (APIs) in a cloud environment. In particular, embodiments of the present disclosure relate to systems and methods for automatically and comparatively evaluating API performance using bucketed testing or split-run testing during API modification, upgrade, or migration. Background Art

[0002] APIs are computing interfaces that allow communication between different technologies and applications to work together by defining interaction methods, regardless of language or platform. APIs specify a set of routines and protocols that support communicating data, accessing information, and building applications. APIs are currently essential in cloud computing environments because they have become the main point of interaction between clients and data providers. In particular, APIs allow clients to access information from business systems in a stable, organized, and secure manner as needed. In fact, APIs are very beneficial in the transition of enterprises to cloud environments because they allow customized and secure interactions. For example, APIs can manage the security of business resources while the server communicates with external clients, and monitor and analyze interactions. Overall, using API cloud services can create communication bridges and develop architectures that serve different types of clients.

[0003] Once an API is deployed, clients of the system can use the API to access information and / or communicate with the service provider. However, in some cases, it may be necessary to modify, update, or upgrade the API. For example, a service provider may decide to modify the functions or protocols in an API to improve the way classes, functions, and properties work. These changes may be introduced to make communication more efficient (for example, to minimize network congestion) or to prevent errors. Transitioning or migrating from one API to another or between different versions of an API may cause problems and result in delays or unexpected results, as client systems may not be able to adapt to the updated API or the API may behave differently. For example, in an updated API, some scripting commands used by clients may be modified or removed. These changes may create compatibility errors during API migration. At the same time, given the complexity of some APIs and the complex interactions that may exist between clients and servers, incompatibilities may be difficult to identify and correct.

[0004] The systems and methods for API migration disclosed herein solve one or more of the above-mentioned problems and / or other problems in the prior art. Summary of the invention

[0005] One aspect of the present disclosure is directed to a computerized system for API migration. The system may include at least one memory storing instructions and at least one processor configured to execute instructions to perform operations. The operations may include dividing client accounts into a first group, a second group, and a third group (each group having different members); allocating a first API for communicating with the first group and a second API for communicating with the second group; and allocating the first API for communicating with a first portion of the third group and allocating the second API for communicating with a second portion of the third group. The operations may also include collecting communications from the first group, the second group, and the third group (over a time interval) and generating indicators associated with each group. In addition, the operations may also include generating a comparison report, comparing indicators associated with the first group with indicators associated with the second group, and generating a compatibility report based on indicators associated with the third group. In some embodiments, the operations may also include transmitting at least one of an alert or a suggestion based on the comparison report and the compatibility report.

[0006] Another aspect of the present disclosure is directed to a computer-implemented method for API migration. The method may include dividing client accounts into a first group, a second group, and a third group (each group having different members); allocating a first API for communicating with the first group and a second API for communicating with the second group; and allocating the first API for communicating with a first portion of the third group and allocating the second API for communicating with a second portion of the third group. The method may also include collecting communications from the first group, the second group, and the third group (over a time interval) and generating metrics associated with each group. In addition, the method may also include generating a comparison report, comparing the metrics associated with the first group with the metrics associated with the second group, and generating a compatibility report based on the metrics associated with the third group. In some embodiments, the method may also include transmitting at least one of an alert or a recommendation based on the comparison report and the compatibility report.

[0007] Another aspect of the present disclosure is directed to a system, comprising one or more processors and one or more storage devices storing instructions. The instructions, when executed by the one or more processors, configure the one or more processors to divide client accounts into a first group, a second group, and a third group (each group having different members); allocate a first API for communicating with the first group and a second API for communicating with the second group (the first API is a legacy API, and the second API is an updated API), wherein the first API and the second API include an integration extension that connects an online store to an e-commerce data center. The instructions may also configure the one or more processors to allocate the first API for communicating with a first portion of the third group and allocate the second API for communicating with a second portion of the third group, and collect communications from the first group, the second group, and the third group (within a time interval). The instructions may also configure the one or more processors to determine indicators associated with each group, generate a comparison report, compare the indicators associated with the first group with the indicators associated with the second group (the comparison report includes the difference between the API indicators associated with the first group and the API indicators associated with the second group), and generate a compatibility report based on the API indicators associated with the third group. In addition, the instructions can also configure one or more processors to determine whether the difference is below a viability threshold, determine whether the API indicator associated with the third group is below a compatibility threshold, and in response to determining that the difference is below the viability threshold and the API indicator associated with the third group is above the compatibility threshold, transmit a recommendation including an updated API mapping table and a migration API plug-in. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1A is a schematic block diagram illustrating an exemplary embodiment of a network including a computerized system for communications that enable delivery, transportation, and logistics operations consistent with the disclosed embodiments.

[0009] Figure 1B An example search results page (SRP) consistent with the disclosed embodiments is described that includes one or more search results that satisfy a search request and interactive user interface elements.

[0010] Figure 1C An example single display page (SDP) consistent with the disclosed embodiments is described that includes a product and information about the product as well as interactive user interface elements.

[0011] Figure 1DAn example shopping cart page including items in a virtual shopping cart and interactive user interface elements consistent with the disclosed embodiments is depicted.

[0012] Figure 1E An example order page consistent with the disclosed embodiments is depicted that includes items from a virtual shopping cart and information regarding purchase and shipping, as well as interactive user interface elements.

[0013] Figure 2 is a schematic diagram of an exemplary fulfillment center consistent with the disclosed embodiments, the fulfillment center being configured to utilize the disclosed computerized system.

[0014] Figure 3 is a schematic block diagram of an exemplary system consistent with the disclosed embodiments.

[0015] Figure 4 is a block diagram of an exemplary client device consistent with the disclosed embodiments.

[0016] Figure 5 is a block diagram of an exemplary database consistent with the disclosed embodiments.

[0017] Figure 6 is a block diagram of an exemplary API migration system consistent with the disclosed embodiments.

[0018] Figure 7 is a block diagram of an exemplary API routing system consistent with the disclosed embodiments.

[0019] Figure 8 is a block diagram of an exemplary API call processing flow consistent with the disclosed embodiments.

[0020] Fig. 9 is a block diagram of an exemplary system for analyzing and comparing API calls consistent with the disclosed embodiments.

[0021] Fig.10 is a block diagram of an exemplary batch run testing system for API migration consistent with the disclosed embodiments.

[0022] Fig.11 is an exemplary API mapping table for running tests in batches consistent with the disclosed embodiments.

[0023] Fig.12 is a flow chart of an exemplary API migration testing process consistent with the disclosed embodiments.

[0024] Fig.13 is a flow chart of an exemplary API difference evaluation process consistent with the disclosed embodiments.

[0025] Fig.14is a flow chart of an exemplary process for determining API metrics consistent with the disclosed embodiments.

[0026] Fig.15 is a flow diagram of an exemplary process for performing API migration recommendations consistent with the disclosed embodiments.

[0027] Fig.16 An exemplary graphical user interface showing alerts and / or notifications generated during API evaluation consistent with the disclosed embodiments. DETAILED DESCRIPTION

[0028] The following is a detailed description with reference to the accompanying drawings. Where possible, the same reference numerals are used in the drawings and the following description to refer to the same or similar parts. Although several exemplary embodiments are described herein, modifications, adjustments and other implementations are possible. For example, the components and steps shown in the drawings may be replaced, added or modified, and the exemplary methods described herein may be modified by replacing, reordering, removing or adding steps to the disclosed methods. Therefore, the following detailed description is not limited to the disclosed embodiments and examples. On the contrary, the proper scope of the present invention is defined by the appended claims.

[0029] Embodiments of the present disclosure are directed to systems and methods for facilitating and / or automating API migration, which may include modification, upgrades, and / or updates of APIs. In particular, the disclosed systems and methods may provide tools to perform bucket testing or batch run testing of multiple APIs to evaluate their performance and identify issues and / or incompatibilities during migration. In some embodiments, the disclosed systems and methods may improve the technical field of website maintenance and updates by providing tools to automatically verify or convert functionality between different API systems. For example, the disclosed systems and methods may improve website debugging during API migration by providing tools to perform automatic comparative API testing. In addition, the disclosed systems and methods may improve the field of website maintenance by automatically maintaining API mapping tables and flow paths.

[0030] In addition, the disclosed systems and methods can improve the technical field of website debugging by providing tools to perform automatic bucket testing or batch running of APIs. Such tools may identify API incompatibilities and low performance through comparative analysis, and automatically reconfigure the API system and / or generate notifications. For example, the disclosed systems and methods can be configured to detect the use of obsolete code or old versions of code in API scripts, make modification suggestions and / or automatically update. In addition, the disclosed systems and methods can facilitate API version control by generating comparison reports that point out difficulties. In addition, in addition to evaluating incompatibility issues, the disclosed systems and methods can also perform quantitative performance evaluation by generating comparative indicators based on API performance.

[0031] In addition, the disclosed systems and methods can improve network monitoring operations by using API functions to trigger monitoring functions. For example, in some embodiments of the present disclosure, the system can monitor only the portion of network communications involving API functions or routines. For example, by programming certain functions in the data collection tool to start and stop packet capture to filter interactions of interest and facilitate API performance analysis as part of the API, the disclosed systems and methods can improve network management during API transitions.

[0032] Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings.

[0033] Figure 1A is a schematic block diagram of a system 100 illustrating an exemplary embodiment of a system including a computerized system for communications that enables delivery, transportation, and logistics operations. Figure 1A As shown, system 100 may include multiple systems, each of which may be connected to each other via one or more networks. These systems may also be connected to each other via direct connections such as using cables. The systems described include a shipment authority technology (SAT) system 101, an external front-end system 103, an internal front-end system 105, a transportation system 107, mobile devices 107A, 107B and 107C, a seller portal 109, a shipment and order tracking (SOT) system 111, a fulfillment optimization (FO) system 113, a fulfillment messaging gateway (FMG) 115, a supply chain management (SCM) system 117, a labor management system 119, mobile devices 119A, 119B and 119C (shown in a fulfillment center (FC) 200), third-party fulfillment systems 121A, 121B and 121C, a fulfillment center authorization system (FCAuth) 123 and a labor management system (LMS) 125.

[0034] In some embodiments, the SAT system 101 can be implemented as a computer system that monitors the order status and delivery status. For example, the SAT system 101 can determine whether an order exceeds its promised delivery date (Promised Delivery Date, PDD), and can take appropriate actions, including initiating a new order, reshipping the goods in the undelivered order, canceling the undelivered order, initiating contact with the ordering customer, etc. The SAT system 101 can also monitor other data, including output (such as the number of packages shipped within a specific time period) and input (such as the number of empty cardboard boxes received for use in shipping). The SAT system 101 can also act as a gateway between different devices in the system 100, enabling communication between devices such as the external front-end system 103 and the FO system 113 (for example, using storage and forwarding technology or other technologies).

[0035] In some embodiments, the external front-end system 103 can be implemented as a computer system that enables external users to interact with one or more systems in the system 100. For example, in an embodiment where the system 100 enables the system to be presented so that users can order goods, the external front-end system 103 can be implemented as a network server that receives search requests, presents product pages, and requests payment information. For example, the external front-end system 103 can be implemented as a computer or multiple computers running software, such as Apache HTTP server, Microsoft Internet Information Services (IIS), or NGINX, etc. In other embodiments, the external front-end system 103 can run customized web server software that is designed to receive and process requests from external devices (e.g., mobile devices 102A or computers 102B), obtain information from databases and other data stores based on those requests, and provide responses to the received requests based on the information obtained.

[0036] In some embodiments, the external front-end system 103 may include one or more of a web cache system, a database, a search system, or a payment system. In one aspect, the external front-end system 103 may include one or more of these systems, and in another aspect, the external front-end system 103 may include an interface (e.g., server to server, database to database, or other network connection) connected to one or more of these systems.

[0037] Figure 1B , 1C, 1D, and 1E will help describe some operations of the external front-end system 103. The external front-end system 103 can receive information from systems or devices in the system 100 for presentation and / or display. For example, the external front-end system 103 can host or provide one or more web pages, including a search result page (Search Result Page, SRP) (e.g., Figure 1B ), Single Display Page (SDP) (for example, Figure 1C ), shopping cart pages (e.g. Figure 1D ) or order pages (e.g. Figure 1E ). A user device (e.g., using mobile device 102A or computer 102B) can navigate to the external front-end system 103 and request a search by entering information in a search box. The external front-end system 103 can request information from one or more systems in the system 100. For example, the external front-end system 103 can request information from the FO system 113 that satisfies the search request. The external front-end system 103 can also request and receive (from the FO system 113) a promised delivery date or "PDD" for each product included in the search results. In some embodiments, the PDD can represent an estimate of the time a package containing the product will arrive at the user's desired location, or if the product is ordered within a specific time period, such as by the end of the day (11:59 p.m.), the date the product is promised to be delivered to the user's desired location (the PDD will be further described below for the FO system 113).

[0038] The external headend system 103 may prepare an SRP based on this information (e.g., Figure 1B ). The SRP may include information that satisfies the search request. For example, it may include pictures of products that satisfy the search request. The SRP may also include the price of each product, or information about enhanced delivery options for each product, PDD, weight, size, quotes, discounts, etc. The external front-end system 103 may send the SRP to the user device that issued the request (e.g., via a network).

[0039] The user device may then select a product from the SRP, such as by clicking or tapping a user interface, or using another input device to select a product represented on the SRP. The user device may formulate a request for information about the selected product and send it to the external front-end system 103. In response, the external front-end system 103 may request information related to the selected product. For example, the information may include additional information beyond the product information presented by the respective SRP. For example, this may include a shelf life, place of origin, weight, size, number of items in a package, operating instructions, or other information about the product. The information may also include suggestions for similar products (e.g., based on big data and / or machine learning analysis of customers who purchased the product and at least one other product), answers to common questions, customer reviews, manufacturer information, or pictures, etc.

[0040] The external front-end system 103 may prepare an SDP (Single Display Page) (eg, Figure 1C ). The SDP may also include other interactive elements, such as a "buy now" button, an "add to cart" button, a quantity field, or a picture of the product. The SDP may also include a list of sellers that offer the product. The list may be sorted according to the price offered by each seller, so that the sellers that sell the product at the lowest price may be listed at the top. The list may also be sorted according to the ranking of the sellers, so that the highest ranked sellers may be listed at the top. The ranking of the sellers may be formulated based on a variety of factors, for example, including the seller's past history of delivering on the promised PDD. The external front-end system 103 may transmit the SDP to the requesting user device (e.g., over a network).

[0041] The requesting user device may receive the SDP listing the product information. Once the SDP is received, the user device may interact with the SDP. For example, a user of the requesting user device may click or interact with an "add to cart" button on the SDP. This adds the product to a shopping cart associated with the user. Alternatively or additionally, the user may interact with the SDP by providing instructions for delivery. The user device may send a request to the external front-end system 103 to add the product to the shopping cart.

[0042] The external front-end system 103 may generate a shopping cart page (e.g., Figure 1D). In some embodiments, the shopping cart page lists the products that the user has added to the virtual "shopping cart". The user device can request the shopping cart page by clicking on an icon on the SRP, SDP or other page, or interacting with it. In some embodiments, the shopping cart page can list all the products that the user has added to the shopping cart, as well as information about the products in the shopping cart, such as the quantity of each product, the price of each product of each commodity, the price of each product based on the associated quantity, information about the PDD, the delivery method, the shipping cost, the user interface element for modifying the products in the shopping cart (e.g., deleting or modifying the quantity), the option to order other products or set the regular delivery of the product, the option to set interest payments, the user interface element for continuing to buy, etc. The user at the user device can click on the user interface element (e.g., a button that reads "Buy Now") or otherwise interact with the user interface element to initiate the purchase of the products in the shopping cart. After doing so, the user device can send this request to initiate the purchase to the external front-end system 103. In some embodiments, the shopping cart page can include a text box input, an interactive icon, or a suggestion message for the delivery of each product.

[0043] The external front-end system 103 may generate an order page (eg, Figure 1E ). In some embodiments, the order page re-lists the items from the shopping cart and requests entry of payment and shipping information. For example, the order page may include: requesting information about the purchaser of the items in the shopping cart (e.g., name, address, email address, phone number), information about the recipient (e.g., name, address, phone number, delivery information), shipping information (e.g., speed / method of delivery and / or pickup), payment information (e.g., credit card, bank transfer, check, stored credit), and user interface elements requesting a cash receipt (e.g., for tax purposes), etc. The external front-end system 103 may send the order page to the user settings.

[0044] The user device may enter information on the order page and click on or otherwise interact with user interface elements that send information to the external front-end system 103. From there, the external front-end system 103 may send information to different systems in the system 100 to enable a new order for the products in the shopping cart to be created and processed. In some embodiments, the external front-end system 103 may be further configured to enable the seller to send and receive information related to the order.

[0045] In some embodiments, the internal front-end system 105 can be implemented as a computer system that enables internal users (e.g., employees of an organization that owns, operates, or leases the system 100) to interact with one or more systems in the system 100. For example, in an embodiment where the SAT network 101 enables the presentation of the system to allow users to place orders for merchandise, the internal front-end system 105 can be implemented as a web server that enables internal users to view diagnostic and statistical information about orders, modify merchandise information, or review statistics related to orders. For example, the internal front-end system 105 can be implemented as a computer or multiple computers running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), or NGINX, etc. In other embodiments, the internal front-end system 105 can run customized web server software that is designed to receive and process requests from the systems or devices described in the system 100 (as well as other devices not described), obtain information from databases and other data stores based on those requests, and provide responses to the received requests based on the information obtained.

[0046] In some embodiments, the internal front-end system 105 may include one or more of a web cache system, a database, a search system, a payment system, an analysis system, an order monitoring system, etc. In one aspect, the internal front-end system 105 may include one or more of these systems, while in another aspect, the internal front-end system 105 may include an interface (e.g., server-to-server, database-to-database, or other network connection) connected to one or more of these systems.

[0047] In some embodiments, the transportation system 107 can be implemented as a computer system that can communicate between the system or device in the system 100 and the mobile device 107A-107C. In some embodiments, the transportation system 107 can receive information from one or more mobile devices 107A-107C (e.g., mobile phones, smart phones, or PDAs, etc.). For example, in some embodiments, the mobile devices 107A-107C may include devices operated by delivery employees. The delivery employees may be permanent, temporary, or shift employees, and can use mobile devices 107A-107C to deliver packages containing user-ordered products. For example, in order to deliver a package, the delivery employee can receive a notification on a mobile device that indicates the package to be delivered and the location to be delivered. After arriving at the delivery location, the delivery employee can use a mobile device to locate the package (e.g., behind a truck or in a package box), scan or otherwise obtain data related to an identifier on the package (e.g., a barcode, image, text string, or RFID tag, etc.), and deliver the package (e.g., leave it at the front door, give it to a security guard, or give it to a recipient, etc.). In some embodiments, the delivery employee can use a mobile device to obtain a photo of the package and / or obtain a signature. The mobile device can send information to the transportation system 107, including information about the delivery, including, for example, the time, date, GPS location, a photo, an identifier associated with the delivery employee, or an identifier associated with the mobile device, etc. The transportation system 107 can store this information in a database (not shown) for access by other systems in the system 100. In some embodiments, the transportation system 107 can use this information to prepare and send tracking data to other systems indicating the location of a particular package.

[0048] In some embodiments, certain users may use one type of mobile device (e.g., permanent employees may use a dedicated PDA with customized hardware such as a barcode scanner, stylus, and other devices) while other users may use other types of mobile devices (e.g., temporary or shift workers may use existing mobile phones and / or smartphones).

[0049] In some embodiments, the transportation system 107 may associate a user with each device. For example, the transportation system 107 may store an association between a user (e.g., represented by a user identifier, an employee identifier, or a phone number) and a mobile device (e.g., represented by an International Mobile Equipment Identity (IMEI), an International Mobile Subscription Identifier (IMSI), a phone number, a Universal Unique Identifier (UUID), or a Globally Unique Identifier (GUID)). The transportation system 107 may combine this association with data received at the time of delivery to analyze the data stored in the database to determine, among other things, the location of the employee, the efficiency of the employee, or the speed of the employee.

[0050] In some embodiments, seller portal 109 may be implemented as a computer system that enables sellers or other external entities to electronically communicate with one or more systems in system 100. For example, a seller may use a computer system (not shown) to upload or provide product information, order information, contact information, etc. for products that the seller wishes to sell through system 100 using seller portal 109.

[0051] In some embodiments, the shipping and order tracking system 111 may be implemented as a computer system that receives, stores, and forwards location information about packages containing products ordered by customers (e.g., by users using devices 102A-102B). In some embodiments, the shipping and order tracking system 111 may request or store information from a web server (not shown) operated by a shipping company that delivers packages containing products ordered by customers.

[0052] In some embodiments, the shipping and order tracking system 111 can request and store information from the systems described in the system 100. For example, the shipping and order tracking system 111 can request information from the transportation system 107. As described above, the transportation system 107 can receive information from one or more mobile devices 107A-107C (e.g., mobile phones, smart phones, PDAs, etc.) associated with one or more users (e.g., delivery employees) or vehicles (e.g., delivery trucks). In some embodiments, the shipping and order tracking system 111 can also request information from a workforce management system (WMS) 119 to determine the location of individual products within a fulfillment center (e.g., fulfillment center 200). The shipping and order tracking system 111 can request data from one or more transportation systems 107 or WMS 119, process the data, and provide the data to devices (e.g., user devices 102A and 102B) based on the request.

[0053] In some embodiments, the fulfillment optimization (FO) system 113 can be implemented as a computer system that stores information about customer orders from other systems (e.g., external front-end system 103 and / or shipping and order tracking system 111). The FO system 113 can also store information describing where specific items are held or stored. For example, certain items ordered by customers may be stored in only one fulfillment center, while certain other items may be stored in multiple fulfillment centers. In other embodiments, certain fulfillment centers may be designed to store only a specific set of items (e.g., fresh products or frozen products). The FO system 113 stores this information as well as associated information (e.g., quantity, size, receipt date, expiration date, etc.).

[0054] FO system 113 may also calculate a corresponding promised delivery date (PDD) for each product. In some embodiments, the FDD may be based on one or more factors. For example, FO system 113 may calculate the FDD of a product based on past demand for the product (e.g., how many times the product has been ordered in a period of time), expected demand for the product (e.g., how many customers are predicted to order the product in an upcoming period of time), past network-wide demand indicating how many products have been ordered in a period of time, expected network-wide demand indicating how many products are expected to be ordered in an upcoming period of time, one or more counts of products stored in each fulfillment center 200, which fulfillment center each product is stored in, expected or current orders for the product, etc.

[0055] In some embodiments, the fulfillment message gateway (FMG) 115 can be implemented as a computer system that receives a request or response from one or more systems in the system 100 (e.g., the FO system 113) in one format or protocol, converts the request or response to another format or protocol, and forwards the request or response to other systems, such as the WMS 119 or the third-party fulfillment system 121A, 121B, or 121C, in the converted format or protocol, or vice versa.

[0056] In some embodiments, supply chain management (SCM) system 117 may be implemented as a computer system that performs forecasting functions. For example, supply chain management system 117 may forecast the demand level for a particular product based on, for example, past demand for the product, expected demand for the product, past demand across the network, expected demand across the network, counted products stored in each fulfillment center 200, or expected or current orders for each product, etc. In response to the forecasted level and the quantity of each product across all fulfillment centers, SCM system 117 may generate one or more purchase orders to purchase and store sufficient quantities to meet the forecasted demand for the particular product.

[0057] In some embodiments, a workforce management system (WMS) 119 may be implemented as a computer system that monitors workflow. For example, WMS 119 may receive event data indicating discrete events from various devices (e.g., devices 107A-107C or devices 119A-119C). For example, WMS 119 may receive event data indicating that a package was scanned using one of the devices. As described below with respect to fulfillment center 200 and Figure 2 As described, during the fulfillment process, a package identifier (e.g., barcode or RFID tag data) may be scanned or read at a particular stage by a machine (e.g., an automatic or handheld barcode scanner, RFID reader, high-speed camera, or a device such as tablet 119A, mobile device / PDA 119B, computer 119C, etc.). WMS 119 may store each event indicating a scan or read of a package identifier in a corresponding database (not shown) together with the package identifier, time, date, location, user identifier, or other information, and may provide this information to other systems (e.g., shipping and order tracking system 111).

[0058] In some embodiments, the WMS 119 may store information associating one or more devices (e.g., devices 107A-107C or devices 119A-119C) with one or more users associated with the system 100. For example, in some cases, a user (e.g., a part-time or full-time employee) may be associated with a mobile device because the user owns the mobile device (e.g., the mobile device is a smartphone). In other cases, a user may be associated with a mobile device because the user temporarily keeps the mobile device (e.g., the user checks out the mobile device at the beginning of the day, will use it during the day, and will return it at the end of the day).

[0059] In some embodiments, WMS 119 may maintain a work log for each user associated with system 100. For example, WMS 119 may store information associated with each employee, including any specified process (e.g., unloading a truck, picking items in a picking area, rebin wall work, packaging items), user identifier, location (e.g., floor or area in fulfillment center 200), number of units moved by the employee through the system (e.g., number of items picked, number of items packaged), or identifiers associated with equipment (e.g., equipment 119A-119C), etc. In some embodiments, WMS 119 may receive check-in and check-out information from a timekeeping system, such as a timekeeping system running on equipment 119A-119C.

[0060] In some embodiments, third-party fulfillment (3PL) systems 121A-121C represent computer systems associated with third-party suppliers of logistics and products. For example, while some products are stored in fulfillment center 200 (as described below with reference to Figure 2 ), but other products may be stored off-site, may be produced on demand, or may not be stored in fulfillment center 200. 3PL systems 121A-121C may be configured to receive orders from FO system 113 (e.g., via FMG 115) and may provide products and / or services directly to customers (e.g., delivery or installation). In some embodiments, one or more of 3PL systems 121A-121C may be part of system 100, while in other embodiments, one or more of 3PL systems 121A-121C may be external to system 100 (e.g., owned or operated by a third-party provider).

[0061] In some embodiments, the fulfillment center authorization system (FC authorization) 123 can be implemented as a computer system with various functions. For example, in some embodiments, the FC authorization 123 can act as a single sign-on (SSO) service for one or more other systems in the system 100. For example, the FC authorization 123 can enable a user to log in via the internal front-end system 105, determine that the user has similar privileges to access resources at the shipping and order tracking system 111, and enable the user to obtain these privileges without a second login process. In other embodiments, the FC authorization 123 can enable users (e.g., employees) to associate themselves with specific tasks. For example, some employees may not have electronic devices (e.g., devices 119A-119C), but may move from one task to another and from one zone to another in the fulfillment center 200 within a day. The FC authorization 123 can be configured to enable these employees to indicate what tasks they are performing and what zones they are in at different times of the day.

[0062] In some embodiments, a labor management system (LMS) 125 may be implemented as a computer system that stores attendance and overtime information for employees (including full-time and part-time employees). For example, the LMS 125 may receive information from FC authorization 123, WMA 119, devices 119A-119C, transportation system 107, and / or devices 107A-107C.

[0063] Figure 1A The specific configuration shown in is only an example. For example, although Figure 1A The FC authorization system 123 connected to the FO system 113 is shown, but not all embodiments require this specific configuration. In fact, in some embodiments, the systems in the system 100 can be connected to each other through one or more public or private networks, including the Internet, an intranet, a wide area network (WAN), a metropolitan area network (MAN), a wireless network that complies with the IEEE802.11a / b / g / n standard, or a leased line, etc. In some embodiments, one or more systems in the system 100 can be implemented as one or more virtual servers implemented in a data center, a server farm, etc.

[0064] Figure 2 A fulfillment center 200 is shown. A fulfillment center 200 is an example of a physical location where merchandise is stored for delivery to customers when ordered. A fulfillment center (FC) 200 may be divided into multiple zones or locations, each with a Figure 2In some embodiments, these "zones" can be thought of as virtual divisions between different stages of the process of receiving goods, storing goods, searching for goods, and delivering goods. Figure 2 , but in some embodiments, other divisions of the zone may be possible, and Figure 2 The fields in the may be omitted, duplicated, or modified.

[0065] Inbound zone 203 represents an area of ​​FC 200 where passengers wishing to use system 100 ( Figure 1A ) A seller selling a product may receive the product from a seller. For example, the seller may deliver products 202A and 202B using truck 201. Product 202A may represent a single product that is large enough to occupy its own shipping pallet, while product 202B may represent a group of products that are stacked together on the same pallet to save space.

[0066] Employees will receive the merchandise in the inbound area 203, and can use a computer system (not shown) to selectively check whether the merchandise is damaged and whether it is correct. For example, an employee can use a computer system to compare the quantity of merchandise 202A and 202B with the ordered quantity of the merchandise. If the quantity does not match, the employee can reject one or more of merchandise 202A or 202B. If the quantity matches, the employee can move the merchandise to a buffer 205 (using, for example, a trolley, a hand truck, a forklift, or manually). The buffer 205 can be a temporary storage area for merchandise that is not currently needed in the picking area, for example, because there is a sufficient amount of the merchandise in the picking area to meet the predicted demand. In some embodiments, a forklift 206 operates to move the merchandise around the buffer 205 and between the inbound area 203 and the unloading area 207. If merchandise 202A or 202B is needed in the picking area (for example, due to predicted demand), the forklift can move merchandise 202A or 202B to the unloading area 207.

[0067] Drop-off area 207 may be an area of ​​FC 200 where merchandise is stored before being moved to picking area 209. An employee assigned a picking task ("picker") may approach merchandise 202A and 202B in the picking area, scan a barcode of the picking area using a mobile device (e.g., device 119B), and scan barcodes associated with merchandise 202A and 202B. The picker may then bring the merchandise to picking area 209 (e.g., by placing the merchandise on a cart or carrying the merchandise).

[0068] The picking area 209 may be an area of ​​the FC 200 where the merchandise 208 is stored on a storage unit 210. In some embodiments, the storage unit 210 may include one or more of a physical shelf, a bookshelf, a box, a tote, a refrigerator, a freezer, or a cold storage. In some embodiments, the picking area 209 may be organized into multiple levels. In some embodiments, employees or machines may move merchandise into the picking area 209 in a variety of ways, including, for example, a forklift, an elevator, a conveyor belt, a cart, a hand truck, a trolley, an automatic robot or device, or manually. For example, a picker may place merchandise 202A and 202B on a hand truck or a cart in the unloading area 207 and carry the merchandise 202A and 202B to the picking area 209 on foot.

[0069] The picker may receive instructions to place (or "deposit") an item at a specific point in the picking area 209, such as a specific space on the storage unit 210. For example, the picker may scan the item 202A using a mobile device (e.g., device 119B). The device may instruct the picker where to deposit the item 202A (e.g., using a system indicating aisles, shelves, and locations). The device may then prompt the picker to scan a barcode at the location before depositing the item 202A at the location. The device may send the data (e.g., via a wireless network) to a network such as a storage device. Figure 1A The computer system of WMS 119 indicates that the user has deposited item 202A at the location using device 119B.

[0070] Once the user places an order, the picker can receive instructions on the device 119B to obtain one or more items 208 from the storage unit 210. The picker can obtain the item 208, scan the barcode on the item 208, and place it on the transport mechanism 214. Although the transport mechanism 214 is shown as a slide, in some embodiments, the transport mechanism can be implemented as one or more of a conveyor belt, an elevator, a cart, a forklift, a hand truck, a dolly, or a cart, etc. Then, the item 208 can arrive at the packaging area 211.

[0071] Packing area 211 can be an area of ​​FC 200 where merchandise is received from picking area 209 and packaged in boxes or bags for final delivery to customers. In packing area 211, employees assigned to receive merchandise ("pickup employees") will receive merchandise 208 from picking area 209 and determine the order to which it corresponds. For example, the pickup employee can use a device such as computer 119C to scan the barcode on the merchandise 208. Computer 119C can visually indicate which order is associated with merchandise 208. For example, this can include a space or "cell" on wall 216 corresponding to an order. Once the order is complete (e.g., because the cell contains all the merchandise for the order), the pickup employee can indicate to the packing employee (or "packer") that the order is complete. The packer can remove the merchandise from the cell and place it in a box or bag for delivery. The packer can then deliver the box or bag to hub area 213, for example, via a forklift, cart, trolley, hand truck, conveyor belt, manually or in other ways.

[0072] Hub area 213 may be an area of ​​FC 200 where all boxes or bags ("parcels") are received from packaging area 211. Employees and / or machines in hub area 213 may retrieve parcels 218 and determine which portion of the delivery area each parcel is going to, and send the parcel to the appropriate camp area 215. For example, if the delivery area has two smaller sub-areas, the parcel will go to one of the two camp areas 215. In some embodiments, an employee or machine may scan the parcel (e.g., using one of devices 119A-119C) to determine the final destination of the parcel. Sending the parcel to a camp area 215 may, for example, include determining (e.g., based on a zip code) a portion of a geographic area to which the parcel is shipped and determining a camp area 215 associated with that portion of the geographic area.

[0073] In some embodiments, camp area 215 may include one or more buildings, one or more physical spaces, or one or more areas where packages are received from hub area 213 for sorting packages into routes and / or sub-routes. In some embodiments, camp area 215 is physically separated from FC 200, while in other embodiments, camp area 215 may be part of FC 200.

[0074] Employees and / or machines in the operating area 215 can determine which route and / or sub-route a package 220 should be associated with, for example, based on a comparison of the destination with existing routes and / or sub-routes, a calculation of the workload of each route and / or sub-route, the time of day, the shipping method, the cost of shipping the package 220, the PDD associated with the merchandise in the package 220, etc. In some embodiments, an employee or machine can (e.g., using one of the devices 119A-119C) scan the package to determine the final destination of the package. Once a package 220 is assigned to a particular route and / or sub-route, the employee and / or machine can move the package 220 to be shipped. In an exemplary embodiment, the package 220 is assigned to a particular route and / or sub-route. Figure 2 In the embodiment of the present invention, the camp area 215 includes trucks 222, cars 226, and delivery employees 224A and 224B. In some embodiments, truck 222 can be driven by delivery employee 224A, where delivery employee 224A is a full-time employee who delivers packages for FC 200, and truck 222 is owned, leased, or operated by the same company that owns, leases, or operates FC 200. In some embodiments, car 226 can be driven by delivery employee 224B, where delivery employee 224B is a "flexible" or temporary employee who makes deliveries on an as-needed basis (e.g., seasonally). Car 226 can be owned, leased, or operated by delivery employee 224B.

[0075] Figure 3 3 is a block diagram of an exemplary system 300 consistent with the disclosed embodiments. In the system 300, the API manager 320 may include a server, a computer module, and / or a data processing center configured to process information requests from data streams of real-time client devices. For example, the API manager 320 may process requests from external communications (e.g., the API manager 320 may be part of the external front-end system 103), internal requests from other departments within the system (e.g., the API manager 320 may be part of the internal front-end system 105), and communications between different parts of the system 100 (e.g., the API manager 320 may interface with the WMS 119 and the FMG 115). In these various cases, the API manager 320 may process API calls and resolve client requests. The API manager 320 may also connect with clients and / or third parties (e.g., through the 3PL systems 121A-121C), and clients and / or third parties may request information or interact with the back-end system. In addition, the API manager 320 may provide information to resolve client requests for information or operations in the database.

[0076] In some embodiments, the API manager 320 may also perform operations to update or migrate APIs used to interface with different clients. For example, the API manager 320 may perform operations to separate client groups between different APIs and perform API allocation during migration or testing. Fig.12 As further described, the API manager 320 may perform operations to run comparison and compatibility tests between different APIs and implement API allocation based on the results. In some embodiments, the API manager 320 may include a network analyzer to evaluate the performance of the APIs and calculate API metrics.

[0077] Additionally or alternatively, in some embodiments, API manager 320 may be implemented with system 100 ( Figure 1A ) is implemented by one or more components of the SAT system 101, the external front-end system 103, the FO system 113, the SCM system 117 and / or the WMS 119 ( Figure 1A ). In other embodiments, the API manager 320 may be implemented with one or more independent servers configured to perform operations for providing content to client devices and / or generating web pages for client devices 350.

[0078] In addition to the API manager 320, the system 300 may also include online resources 340, client devices 350, third-party systems 360, and databases 380. Figure 3 As shown, the components of system 300 can be connected to network 370. However, in other embodiments, the components of system 300 can be directly connected to each other without network 370. For example, database 380 can be directly connected to API manager 320.

[0079] Online resource 340 can include one or more storage services or servers provided by entities such as web hosting, network, cloud or backup service providers. In certain embodiments, online resource 340 can be associated with a server or hosting service storing a web page, domain name system (Domain Name System, DNS) or login page for authentication services. In other embodiments, online resource 340 can be associated with cloud computing services. In other embodiments, online resource 340 can be associated with messaging services such as Apple Push Notification Service, Azure Mobile Services or Google Cloud Messaging. In such embodiments, online resource 340 can handle the message and notification transmission relevant to the function of disclosed embodiments, such as processing digital rights management.

[0080] Client device 350 may include one or more computing devices configured to perform one or more operations consistent with the disclosed embodiments. For example, client device 350 may include a desktop computer, a portable computer, a server, a mobile device (e.g., a tablet computer, a smart phone, etc.), a set-top box, a gaming device, a wearable computing device, or other types of computing devices. In some embodiments, client device 350 may include user device 102 ( Figure 1A ), and can operate as part of the system 100. However, in other embodiments, the client device 350 can be independent of the system 100. The client device 350 can include one or more processors configured to execute software instructions stored in a memory such as in the client device 350 to perform operations for implementing the functions described below. For example, the client device 350 can be configured to communicate with the API manager 320 to request information for displaying a web page or sending a client request. In addition, the client device 350 can be configured to perform operations, such as callback scripts or functions, according to instructions sent by the API manager 320. In addition, the client device 350 can be configured for wired and / or wireless communication, and can include software that, when executed by the processor, performs communications (e.g., TCP / IP) and content display processes related to the Internet. For example, the client device 350 can execute browser software that generates and displays an interface with product information. Therefore, the client device 350 can execute an application that allows the client device 350 to communicate with components through the network 370 and display content in the interface via a display device included in the client device 350.

[0081] In some embodiments, the following is combined Figure 4 As further described, client device 350 may run an application specifically configured to interact with API manager 320. In addition, client device 350 may store one or more accounts. For example, client device 350 may store information about a customer's delivery preferences, the customer's location, the customer's account, and a customer identifier to authenticate during API exchanges.

[0082] The disclosed embodiments are not limited to any particular configuration of the client device 350. For example, the client device 350 may be a mobile device that stores and executes a mobile application to perform operations that provide the functionality provided by the API manager 320 and / or the online resources 340. In some embodiments, the client device 350 may be configured to execute software instructions related to location services, such as GPS location. For example, the client device 350 may be configured to determine a geographic location and provide location data and timestamp data corresponding to the location data. In conjunction with Figure 4 Client device 350 will be described further.

[0083] Database 380 may include one or more computing devices configured with appropriate software to perform operations consistent with providing customer accounts, API configurations, metrics (e.g., API metrics), and reporting API manager 320 data. Database 380 may include, for example, Oracle TM Database, Sybase TM Database or other relational or non-relational databases such as Hadoop TM Sequence Files, HBase TM or Cassandra TM Database 380 may also include computing components (eg, database management systems, database servers, etc.) configured to receive and process requests for data stored in a storage device of the database and to provide data from the database.

[0084] Although database 380 is shown separately, in some embodiments, database 380 may be included in or associated with API manager 320 or online resource 340 .

[0085] Database 380 may be configured to collect and / or maintain data associated with user accounts and API assigned or recorded communications. For example, database 380 may store user profile information about system 300 users. In addition, database 380 may store information about addresses and client IDs, including delivery methods for specific addresses and / or client IDs. Database 380 may also store previously generated API mapping tables, and may store API plugins. Database 380 may collect data from various sources including, for example, online resources 340 or third-party systems 360. In addition, database 380 may include information about the operating system of client device 350. This will be discussed below in conjunction with Figure 5 Database 380 is further described.

[0086] In some embodiments, third-party system 360 may include one or more elements of system 100. For example, third-party system 360 may include 3PL system 121A-121C (Figure 1). Additionally or alternatively, third-party system 360 may include one or more storage services or servers provided by an entity related to API manager 320. Third-party system 360 may also be connected to system 300 via network 370, but in other embodiments, third-party system 360 may include direct connections to some units of system 300. For example, to minimize latency or network congestion, some third-party systems 360 may be connected to API manager 320 in a dedicated network. In addition, third-party system 360 may be configured to request information and / or provide information from API manager 320 to access information from other units of system 300. In some embodiments, although third-party systems 360 may also be connected to network 370, they may not be clients of API manager 320.

[0087] The network 370 can be any type of network configured to provide communication between components of the system 300. For example, the network 370 can be any type of network (including infrastructure) that provides communication, exchanges information, and / or facilitates information exchange, such as the Internet, a local area network, near field communication (NFC), or other suitable connections that enable sending and receiving information between components of the system 300. In other embodiments, one or more components of the system 300 can communicate directly via a dedicated communication link. In other embodiments, the network 370 can include multiple networks, such as organized as one network or multiple networks.

[0088] It should be understood that the configuration and boundaries of the functional building blocks of system 300 have been defined herein for ease of description. Alternative boundaries may be defined so long as the specified functions and their relationships are properly performed. Alternatives (including equivalents, extensions, variations, deviations, etc. of the solutions described herein) will be apparent. Such alternatives fall within the scope of the disclosed embodiments.

[0089] Now refer to Figure 4 , which illustrates an exemplary client device 350 ( Figure 3 In some embodiments, the client device 350 may implement the user device 102A-B ( Figure 1A ).

[0090] In one embodiment, the client device 350 may include one or more processors 402, one or more input / output (I / O) devices 404, and one or more memories 410. In some embodiments, the client device 350 may take the form of a mobile computing device, such as a smart phone or tablet computer, a general-purpose computer, or any combination of these devices. Alternatively, the client device 350 may be configured as a specific device, embedded system, dedicated circuit based on storing, executing and / or implementing software instructions. The instructions perform one or more operations consistent with the disclosed embodiments. According to some embodiments, the client device 350 may include a web browser or similar computing device that accesses a website consistent with the disclosed embodiments.

[0091] Processor 402 may include one or more known processing devices, such as those provided by Intel TM , NVIDIA TM The disclosed embodiments are not limited to any particular type of processor configured in the client device 350 .

[0092] Memory 410 may include one or more storage devices configured to store instructions used by processor 402 to perform functions related to the disclosed embodiments. For example, memory 410 may be configured with one or more software instructions, such as program 412, that may perform operations when executed by processor 402. The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example, memory 410 may include a single program 412 that performs the functions of client device 350, or program 412 may include multiple programs. Memory 410 may also include client application 414, which may configure client device 350 to communicate or perform operations that interact with other elements of system 300. For example, client application 414 may specify instructions for communicating with API manager 320 and / or generating a product information request, which will be combined with Figure 7 In addition, the client application 414 can interpret instructions for generating a graphical user interface (GUI) or modifying a displayed GUI in the client device 350. The memory 410 can also store data 416 that can be used by the API manager 320 to generate and maintain information clusters.

[0093] In some embodiments, the memory 410 may store instructions for accessing or sending requests to the API manager 320. For example, the memory 410 may include an application that communicates with the API manager 320 via TCP / IP. In addition, other software components may be configured to request information from the API manager 320 or determine the location of the client device 350. For example, these software instructions, when executed by the processor 402, may use the API to request information and / or request information updates from the database 380. The software instructions may also implement a script to modify a web page displayed in the client device 350.

[0094] I / O devices 404 may include one or more devices configured to allow client device 350 to receive and / or send data and to allow client device 350 to communicate with other machines and devices, such as other components of system 300. For example, I / O devices 404 may include a screen for confirming the delivery of a package or providing information to a user. I / O devices 404 may also include components for NFC communications. I / O devices 404 may also include one or more digital and / or analog devices that allow a user to interact with client device 350 such as touch-sensitive areas, buttons, or microphones. I / O devices 404 may also include one or more accelerometers to detect the orientation and inertia of client device 350. I / O devices 404 may also include other components known in the art for interacting with API manager 320.

[0095] In some embodiments, the client device 350 may also include a camera 420 that captures images and can be used to identify products that the user wants. Such identification can trigger a display request for content information. Additionally or alternatively, the client device 350 may include a fingerprint sensor 430 that allows the user to unlock the client device 350 to access their account, send information requests, and purchase items. Both the camera 420 and the fingerprint sensor 430 can be operated by the processor 402 and use cryptographic security to make it impossible for the user to access fingerprint or camera information from the outside.

[0096] It will be apparent to those skilled in the art that the components of the client device 350 may be implemented in hardware, software, or a combination of hardware and software.

[0097] Now refer to Figure 5 , showing a database 380 ( Figure 3 ) is a block diagram of an exemplary one of the examples. In some embodiments, database 380 may be included in a unit of system 100. For example, database 380 may be an external front-end system 103 or WMS 119 ( Figure 1A ) part.

[0098] The database 380 may include a communication device 502, one or more database processors 504, and a database memory 510 including one or more database programs 512 and data 514. The database 380 may include a NoSQL database, such as HBase, MongoDB TM or Cassandra TM Alternatively, database 380 may include a relational database, such as Oracle, MySQL, and Microsoft SQL Server.

[0099] In some embodiments, database 380 may be a server, a general purpose computer, a mainframe computer, or any combination of these components. In some embodiments, database 380 is included in other units of system 300, such as API manager 320. Other implementations consistent with the disclosed embodiments are possible.

[0100] In some embodiments, database 380 may include a non-relational database and an embedded database. For example, database 380 may include a non-relational database, such as Hbase, and an embedded database, such as RocksDB (eg, a key-value storage database).

[0101] The communication device 502 can be configured to communicate with one or more components of the system 300 or system 100, such as the online resource 340, the API manager 320, or the SCM system 117. In particular, the communication device 502 can be configured to communicate with the client device 350 or other units of the system 300 through the API manager 320.

[0102] The components of database 380 can be implemented in hardware, software or a combination of hardware and software. For example, although one or more components of database 380 can be implemented as computer processing instruction modules, all or part of the functions of database 380 can be implemented in dedicated electronic hardware instead.

[0103] Database storage 510 may include program 512, which may include instructions for generating record clusters and / or responding to information requests from client device 350. In addition, database storage 510 may include instructions for communication between elements of system 300. For example, database storage 510 may include instructions for communication between client device 350 and API manager 320. In addition, program 512 may include instructions for storing information in real time as it is processed by API manager 320.

[0104] Data 514 may also be data associated with a web page, such as information of online resources 340 or a user account from client device 350. For example, data 514 may include information related to API assignments or communication preferences.

[0105] Figure 6 6 is a block diagram of an exemplary API migration system 600 consistent with the disclosed embodiments. In the API migration system 600, the API manager 320 ( Figure 3 ) can connect to client accounts 610, servers and data centers 620, communication analyzers 640, and report generators 660.

[0106] Client account 610 may include system 300 ( Figure 3 ) can interact with other units of system 300 through API manager 320. For example, client accounts 610 may include accounts 360 associated with client devices 350, third-party systems, and / or online resources 340. In some embodiments, client accounts may include shopper accounts, internal service accounts, and customers of online retailers. Additionally or alternatively, client accounts 610 may include accounts associated with sellers (e.g., accounts connected through seller portal 109), employees (e.g., specified in labor management system 125), or fulfillment centers (e.g., FMG 115). Figure 6 As shown, client accounts can be divided into multiple groups. API manager 320 can classify client accounts 610 into different groups to implement and manage the API of each group with a specific configuration. For example, client accounts 610 can be classified into a first group 612, a second group 614, and a third group 616. In some embodiments, as Figure 6 As shown, each of these groups can be independent of each other (i.e., each group has unique accounts), and these groups sample a portion of the total number of client accounts 610. However, in other embodiments, the first group 612, the second group 614, and the third group 616 can share some accounts and / or can include the total number of accounts.

[0107] The client accounts 610 may be divided into a first group 612, a second group 614, and a third group 616 based on group division rules. In such an embodiment, the API manager 320 may implement group division rules to divide the client accounts 610 for API testing. The group division rules may include, for example, group size rules such that each group should have the same number of accounts. The division rules may also include account diversity rules, which may require each group to have at least one account associated with an internal API call, one account associated with an external API call, and / or an account that generates regular calls. For example, the division rules may specify that each group should include an account with at least one request per minute. Account categories may also include new accounts and return accounts, and the division rules may require that each group have both new accounts and old accounts. The group division rules may also include a specific number of accounts (e.g., each group should include at least 1,000 accounts) and include rules for geographical division. In addition, in some embodiments, the division rules may divide accounts based on the original type of device, requiring each group to include, for example, accounts related to mobile devices, accounts related to servers, and accounts related to desktop computers. Additionally, the group partitioning rules may specify a relationship between the sizes of the different groups, such as requiring that the first group 612 is larger than the second group 614, and the third group is larger than the first group 612. This type of partitioning may be important for ensuring statistical significance of API system evaluations.

[0108] In some embodiments, the group division rules can be configured to be dynamic and change based on the behavior of the account. For example, the API manager 320 can monitor the activity of the accounts in each of the groups. If the API manager 320 determines that the account is inactive, it can replace the account with an account different from the ungrouped account.

[0109] In some embodiments, Figure 6 As shown, the third group 616 is further divided into a first portion 616A and a second portion 616B. Fig.12 As further described, the subdivision into third groups 616 may allow compatibility testing to be run in separate groups that run multiple APIs simultaneously. The simultaneous running of different APIs in a group of users may reveal incompatibilities or redundancies in API performance.

[0110] The client account 610 can be connected to the API manager 320 through an API gateway. In some embodiments, the API manager 320 may include multiple API gateways, such as API gateway A 632 and API gateway B 634. API gateway A 632 and API gateway B 634 can be located between the client account 610 and the backend services interfaced by the API manager 320. In some embodiments, API gateway A 632 and API gateway B 634 can act as a reverse proxy to accept API calls, aggregate the various services required to implement them, and return appropriate results. In addition, API gateway A 632 and API gateway B 634 can handle tasks such as user authentication, rate limiting, and statistics.

[0111] In some embodiments, API Gateway A 632 and API Gateway B 634 can be configured to disconnect the client interface from the backend implementation. Thus, when one of the client accounts 610 makes a request, API Gateway A 632 and API Gateway B 634 can break the request into multiple requests, routing them to the correct module (e.g., in conjunction with Figure 7 further described), generates responses, and tracks additional calls.

[0112] In some embodiments, API Gateway A 632 and API Gateway B 634 can be dedicated to different API groups or systems, can be assigned to different accounts, and can be configured to work simultaneously. For example, while API Gateway A 632 processes calls from the first group 612, API Gateway B 634 can process calls from the second group 614. In addition, while API Gateway A 632 can perform processing calls using a legacy API (with previously deployed functions and operations), API Gateway B 634 can perform processing calls using an updated or modified API (with new functions and operations). Having this diversity of API gateways allows the API manager 320 to test and compare the performance of different APIs in automated measurements by assigning different APIs to different client account groups. Such a configuration can allow the API manager 320 to perform automated batch testing or bucket testing to compare the performance and compatibility of two or more APIs. As Figure 6 As shown, in some embodiments, the API manager 320 can configure API gateway A 632 to handle communications from the first group 612 and the first portion 616A, and configure API gateway B 634 to handle communications from the second group 614 and the second portion 616B. For example, the API manager 320 can assign API gateway A 632 and API gateway B 634 to a specific account using an API mapping table that specifies user groups and assigned gateways.

[0113] In addition to the gateways, the API manager 320 may also include a metadata store 636 that can record data from API Gateway A 632 and API Gateway B 634. For example, the metadata store 636 can record bucket access controls, channels, default object controls, notifications, objects, keys, and projects received from the client account 610 through the gateway. In some embodiments, the information stored in the metadata store can be used for the calculation of API metrics, such as in conjunction with Fig.14 as further described.

[0114] The API manager 320 can be connected to the server and data center 620 and request information after processing an API call. For example, the API manager 320 can process a request from a client device associated with a client account 610 and request information from the server and data center 620 to resolve the client request. In some embodiments, when a user requests product information through an API call, the API manager 320 can obtain the information from the server and data center 620 to forward it to the client. In some embodiments, the server and data center 620 may include a server of an online retailer. Alternatively, the API manager 320 can be connected to the server and data center 620 via a method converter 625, which can convert instructions between different syntaxes to interact with the server and data center 620. For example, when an API call is received in one format but the API manager determines that the format is no longer available or valid, the API manager 320 can instruct the method converter 625 to adjust the instruction to the selected format.

[0115] In addition to being connected to the servers and data center 620, the API manager 320 may also be connected to a communication analyzer 640, which may capture and classify communications passing through the API manager 320 to perform comparisons and compatibility assessments. The communication analyzer 640 may include a network analyzer 642, which may be configured to filter and capture communication packets from and to the client accounts 610. In some embodiments, the API manager 320 may mark communications processed by each concurrent API to facilitate filtering or classification by the network analyzer 642. In addition, the communication analyzer 640 may include dedicated memories 644A-644C, which may be configured to store packets or data from communications of each separate group. In order to facilitate later analysis of the performance of each API and each client account group, the dedicated memories 644A-644C may be configured to specifically store data associated with one of the separate groups. For example, dedicated memory 644A may store data related to first group 612, dedicated memory 644B may store data related to second group 614, and dedicated memory 644C may store data related to third group 616. This separation of data may facilitate later data processing. In some embodiments, network analyzer 642 may be configured to capture incoming packets from client devices associated with client accounts (in the first, second, and third groups) and store the captured packets from each group in separate memory spaces, such as dedicated memories 644A-644C.

[0116] like Figure 6 As shown, the communication analyzer 640 can be connected to the old version / update analyzer 650, which can estimate indicators and evaluate the performance of the API and its compatibility. For example, based on the information in the dedicated memory 644A-644C, the old version / update analyzer 650 can determine the infrastructure API indicators, application API indicators, and API product indicators to compare the performance of the APIs processed by API gateway A 632 and API gateway B 634. In addition, the old version / update analyzer 650 can determine API compatibility and analyze the behavior of, for example, HTTP response codes. The old version / update analyzer 650 is combined with Fig.10 For further description.

[0117] The old version / update analyzer 650 may provide information to the report generator 660, which may generate a compatibility and / or comparison report of the API performance. For example, the report generator 660 may generate an alert when the performance of one tested API is worse than that of others, or may provide suggestions about which functions or processes cause incompatibility. In some embodiments, the report generator 660 may send an email or message to the administrator network 670 to broadcast the alert or suggestion. The report generator 660 may also be configured to send instructions to the API manager 320. For example, in some embodiments, the old version / update analyzer 650 may conclude that the updated or current API performs better than the old version API. Further, the old version / update analyzer 650 may determine that there is no substantial comparability problem. In such a scenario, the report generator 660 may send instructions to the API manager 320 to switch the account assigned to the old version API to facilitate the updated API. In some embodiments, the API manager 320 may shut down the API gateway A 632 and reallocate the client account associated with the old version API to be processed by the updated API.

[0118] Figure 7 is a block diagram of an exemplary API routing system 700 consistent with the disclosed embodiments. The system 700 can be used to resolve API calls from client devices 350 by selecting different levels and types of APIs. In addition, in the system 700, each group of client devices 350 can be assigned to a different API group and / or path to enable automatic comparison of complete API operations.

[0119] In system 700, order gateway 704 can receive requests from client device 350. In some embodiments, order gateway 704 can be implemented with stream processing software to collect information streams and process them in real time, which is combined with Figure 8 704. The order gateway 704 can provide information to the router API 710, which can route client requests and API calls to different API services. For example, the router API 710 can route the API call to the legacy API system when it determines that the request comes from an account associated with the first group 612, and route the API call to the updated API system when it determines that the request comes from an account associated with the second group 614. In some embodiments, the router API 710 can select one of the API gateway A 632 or the API gateway B 634 to handle the request based on the API mapping table and the information extracted by the order entry 704.

[0120] The router API 710 can direct requests through different internal APIs, which can include multiple levels of APIs. The first level API may generate the content, features, and functions of several other APIs. The first level API can specify the project data format, interaction timing, or protocol to a specific channel and context. The first level API can include the functions of submitting an order 722, obtaining an order 724, and checking the order status 726.

[0121] The first level API can communicate with the second level API. The second level API can combine data and coordinate other APIs for specific tasks. For example, the second level API can support a combination of enterprise supplies (e.g., products and services). The second level API may include functions for order broadcasting 732, internal orders 734, and order tracking 736. These functions can enable logic and orchestration. Unlike other levels, the second level API does not communicate directly with the terminal system, but connects to the third level API to obtain data. In some embodiments, the second level API uses a representational state transfer (REST) ​​function to aggregate data from multiple systems.

[0122] The second level API can communicate with a third level API, which can be configured to return information to the client device 350 and / or enable direct interaction between the client device 350 and the backend system. The third level API may support multiple value streams and / or enterprise capabilities. The third level API can be configured to communicate with the system using, for example, direct Java calls or SAP calls. The third level API can handle system-specific connections and settings and expose resources and standard formats. The third level API can include functionality for service exchange 742, order queues 744, order database access 746, and order tracking.

[0123] The legacy API and updated API may include each of the first through third level APIs. Thus, the API routing system 700 illustrates an exemplary path configuration for parsing API calls from the client device 350, but similar processing may be performed to process calls from different sources. For example, a similar architecture may be employed to process internal requests for information and / or communicate with a fulfillment center.

[0124] Figure 8800 is a block diagram of an exemplary API call processing flow 800 consistent with the disclosed embodiments. The processing flow 800 describes how the API manager 320 processes a data stream (e.g., a stream of API calls from a client device 350). For example, the API manager 320 can use the process flow 800 to process and categorize the stream of API calls for comparison or batch running of API tests. In some embodiments, the API manager 320 can route the stream of API calls to multiple API gateways through the process flow 800.

[0125] In process flow 800, event log 802 can receive an incoming data stream. The incoming data stream can include a stream of API calls or requests from client devices and users of the system requesting information or operations. For example, the incoming data stream can include orders and / or tracking requests. In some embodiments, event log 802 can be implemented with stream processing software such as Apache Kafka, which provides high throughput processing of real-time feeds. For example, event log 802 can include a Java stream processing library and use a binary TCP-based protocol that relies on a "message set" abstraction that naturally groups messages together to reduce the overhead of network round trips.

[0126] The event log 802 can then pass the message set and / or processed data stream to the cluster event stream 804. The cluster event stream 804 can generate cluster groups of incoming data calls and provide an optimized engine based on the generated groups to support general operation execution. In some embodiments, the cluster event stream 804 can create a batch of data streams based on intervals, geography, and / or client account classifications. Such data clustering can optimize API calls by batching API calls based on similar requests and / or communication paths. In some embodiments, the cluster event stream 804 can be implemented with Apache Spark.

[0127] Cluster events can be sent to the event integration processor 806, which can include event-driven applications for use cases such as real-time analysis, data integration, notification management, and adaptive decision making. The event integration processor 806 can capture events from various data sources, process and analyze them, integrate with multiple services and data stores, and publish real-time output to various endpoints. The integrated events can then be stored in unstructured documents in the distributed document store 808. The distributed document store 808 can be implemented using a NoSQL database program that allows ad hoc queries, indexing, replication, and load balancing.

[0128] The microservice module 810 can use the data in the distributed document storage 808 to identify events and process the events in the virtual core. For example, the microservice module 810 can employ multiple event-driven application frameworks running in a dedicated virtual core. The microservice module 810 can process and filter API calls (even if they are using different versions of API functions or configurations) and standardize or transform them for later processing by, for example, the API manager 320.

[0129] At the microservice module 810, the processing flow 800 may have parsed and standardized the real-time data stream to facilitate its identification and routing. Performing this preparation phase, API calls under different API systems (e.g., old version vs. current) can be distinguished to perform bucket testing. By browsing the event log 802, cluster event stream 804, and even the integration processor 806, groups can be identified and correctly routed to one of the API systems, while collecting relevant information for later evaluation and / or comparison.

[0130] The microservice module 810 can communicate with the authentication provider 812 and the event bus 814, the authentication provider 812 can verify the validity of the processed API call, and the event bus 814 can organize the call to feed it to the API gateway. The authentication provider 812 can include a token-based authentication and / or implement a security component at each microservice in the microservice module 810. The event bus 814 can handle inter-service communication. In some embodiments, the event bus 814 can serve as an intermediary channel for asynchronous event-driven communication. In addition, the event bus 814 can support publish / subscribe, distributed, point-to-point, and request-response messaging. In some embodiments, the event bus 814 can allow the client to use the event bus 814 to communicate with the corresponding server node.

[0131] The authentication provider 812 and the event bus 814 can communicate with both the old version API gateway 818 and the updated API gateway 820. For example, the authentication provider 812 can provide verification of API calls in the incoming data stream, while the event bus 814 can provide information about a specific request and associated tagged metadata generated by the microservice module 810 and / or the event integration processor. In some embodiments, the old version API gateway 818 and the updated API gateway 820 can be used with API gateway A 632 and API gateway B 634 ( Figure 6 ) to achieve it.

[0132] Fig. 9is a block diagram of an exemplary system 900 for API call analysis and comparison consistent with the disclosed embodiments. In some embodiments, the system 900 can be a subsystem of the system 600. For example, when the API manager 320 is aimed at real-time evaluation of API performance, the system 900 can implement the legacy / update analyzer 650.

[0133] The system 900 may include a data flow module 902 that may receive information from a network analyzer and / or communications associated with a set of client accounts. For example, since the data flow module 902 captures packets or information of communications passing through the API manager 320, it may be possible to receive information from the network analyzer 642 ( Figure 6 ) receives information. The data flow module 902 can send the information to the ingestion engine 904, which can perform data filtering, recognition, or standardization. For example, the ingestion engine 904 can use data preparation features to perform automatic data ingestion to structure and organize API calls so that they can be analyzed in real time. The ingestion engine 904 can perform batch and streaming ingestion of API calls.

[0134] In some embodiments, the ingest engine 904 may store the processed data in dedicated memory 644A-C ( Figure 6 ). Additionally or alternatively, the ingestion engine 904 can provide information to a queue module 908 that sorts the data from two or more API systems. The organized data can then be sent to a real-time analytics module 914 via a log pipeline 912. Real-time analytics can estimate API metrics based on the records of API calls processed by each API system. Fig.14 As further described, the real-time analysis module 914 can quantify performance based on API interaction metrics. For example, the real-time analysis module 914 can determine metrics such as latency, compatibility, and error metrics based on information passed through the log pipeline 912. In addition, in some embodiments, the real-time analysis module 914 can perform additional tests on two or more APIs. For example, the real-time analysis module 914 can send the same GET, POST, and PUT requests to multiple APIs and compare the results.

[0135] The output from the real-time analysis module 914 can be transmitted to the compiler 916, which can aggregate the estimated indicators and determine statistics, which are forwarded to the compatibility and comparison reporter 918, which can generate compatibility and comparison reports between different API systems. The compatibility and comparison reporter 918 can use the indicators generated by the real-time analysis module 914 to determine, for example, whether the updated API is compatible with the old version API and / or whether they have improved indicators. In addition, the compatibility and comparison reporter 918 can generate a report that describes the functions or routines that cause incompatibility. In such an embodiment, the compatibility and comparison reporter 918 can include source compatibility issues (e.g., code written for the old version API cannot be compiled for the updated API) and binary compatibility issues (e.g., code compiled for the old version API cannot be linked / run against the updated API library). In addition, the compatibility report can also include wire compatibility, listing communication errors between the old and updated APIs and semantic compatibility indicating unexpected results.

[0136] In some embodiments, the compatibility and comparison reporter 918 can generate alerts or reports to compare the performance of the APIs. For example, the compatibility and comparison reporter 918 can generate results from an online JavaScript Object Notation (JSON) comparator that details the inputs and responses of the endpoints tested in the online comparator and repeats the operation for each endpoint.

[0137] Fig.10 1 is a block diagram of an exemplary batch run test system 1000 for API migration consistent with the disclosed embodiments. The batch run test system 1000 shows an old version / update analyzer 650 ( Figure 6 ) configuration.

[0138] like Fig.10As shown, the old version / update analyzer 650 may include multiple modules for comparing performance and determining the compatibility of two APIs. These modules may include a metadata comparator 1012, a proxy comparator 1014, a client comparator 1016, and an allocation record 1018. The metadata comparator 1012 can compare metadata in the communication for each API. For example, the metadata comparator 1012 can obtain and analyze metadata in the communication, such as address, location, and time, from each API call or communication processed by different API gateways. The proxy comparator 1014 can compare the runtime and computing resource usage of each API. For example, the proxy comparator 1014 can compare the API runtime, the number of interactions with the backend system, and the number of responses sent back to the API client. In addition, the proxy comparator 1014 can determine the differences between security measures. The proxy comparator 1014 can compare backend protection and authentication success rates.

[0139] The client comparator 1016 can compare API clients using each API system. For example, the client comparator 1016 can use each API to identify and evaluate API customers. For example, the client comparator 1016 can store the device or account that sends requests to each API. The client comparator 1016 can also evaluate the usage level of each API client and the use of software development kits (SDKs) during API client interaction. The allocation record 1018 can compare the acquisition request and allocation of each API requested to the backend server through the representational state transfer (REST) ​​API endpoint. In addition, the allocation record 1018 can implement allocation rules that compare the context passed from the old version of the API and the updated API. The allocation record 1018 can also store the allocation of computing resources, which are allocated to respond to requests associated with multiple APIs.

[0140] The modules in the legacy / update analyzer 650 allow for automatic evaluation of the performance of two APIs. For example, the legacy / update analyzer 650 can use the metadata comparator 1012, the proxy comparator 1014, the client comparator 1016, and the allocation record 1018 to generate comparison and / or compatibility indicators to allow automatic evaluation and temporary migration of different APIs. Therefore, in some embodiments, the legacy / update analyzer 650 can output a comparison indicator 1022, which can reflect the performance comparison between the legacy API and the updated API.

[0141] like Fig.10 As shown, the old version / update analyzer 650 can be connected to the test definition 1020 and the redundant filter 1006. The test definition 1020 can be provided by, for example, the administrator network 670 ( Figure 6) definition, and can specify the length of API call collection, the number of API systems to be tested, and / or specify client account division rules. Redundancy filter 1006 can be connected to the systems of old version API 1002 and updated API 1004. For example, old version API 1002 and updated API 1004 can be connected to API gateway A 632 and API gateway B 634 respectively. In order to facilitate comparative evaluation and minimize the resources used during comparative analysis, redundancy filter 1006 can remove calls with the same characteristics in old version API and updated API. Between old version API 1002 and updated API 1004, some functions may remain unchanged. For example, some basic operations may be retained from one version of API to another. For some cases (for example, when evaluating compatibility), tracking similar or redundant calls between two API systems may be unnecessary and / or lead to redundant monitoring. Therefore, redundancy filter 1006 can eliminate redundant calls to remove them from batch run analysis. However, other embodiments can be directed to more general methods and even collect redundant calls to evaluate the interaction between multiple components of each API system.

[0142] Fig.11 1 is an exemplary API mapping table 1100 for running tests in batches consistent with the disclosed embodiments. The API mapping table 1100 may include API clients 1102, listing user groups or classifications. For example, in the API mapping table 1100, a row may include client account groups, such as a legacy group 1110 (e.g., the first group 612), an update group 1112 (e.g., the second group 614), a compatibility group A (e.g., the first part 616A), and a compatibility group B (e.g., the second part 616B). For each API client 1102, the API mapping table 1100 may specify the assigned API. As Fig.11 As shown, the assigned API 1104 can be selected from one of two options "API1" and "API2". For example, the API mapping table 1100 can specify that the legacy group 1110 and the compatibility group A 1112 use the legacy API (e.g., by Figure 6 ), while update group 1112 and compatibility group B use the updated API (e.g., through API Gateway B 634).

[0143] The API mapping table 1100 may also specify methods associated with the API and / or allowed by each API client 1102. In some embodiments, different APIs may have the same methods and functions. Fig.11 As shown in , different APIs may have different methods and / or include additional methods and functionality.

[0144] In addition, the API mapping table 1100 can specify a test scenario 1108 for each group of API clients 1102. For example, the API mapping table 1100 can determine the type of analysis that the legacy / update analyzer 650 will perform and define the test scenario 1108 for the test definition 1020 ( Fig.10 ) provides parameters. In addition, the API mapping table 1100 can specify whether the old version / update analyzer 650 will compare the load time, response time and / or write time of each API client 1102 group.

[0145] Fig.12 1 is a flow chart of an exemplary API migration testing process 1200 consistent with the disclosed embodiments. In some embodiments, units of system 300 can perform process 1200. For example, as disclosed in the step description below, API manager 320 can perform process 1200. Alternatively, or in addition, third-party system 360 can perform process 1200 or a portion of process 1200. Moreover, in other embodiments, system 100 or a portion of system 100 can perform process 1200. For example, external front-end system 103, internal front-end system 105, and / or FMG 115 can perform process 1200.

[0146] In step 1202, the API manager 320 may group the client accounts according to the group division rule. For example, the API manager 320 may select a client account (e.g. Figure 6 The API manager 320 may be configured to generate a group of client accounts 610) and divide it into three or more group subgroups, such as a first group 612, a second group 614, and a third group 616 to start API testing / evaluation. For this division, the API manager 320 may adopt a group division rule that may include the same number of accounts in each subgroup, include the same number of mobile devices in each subgroup, and / or maximize the diversity of accounts in each subgroup. For example, the API manager 320 may generate a subgroup having at least one type of user account, wherein the user account may include an external retailer, a third-party supplier, a user account, and / or an internal department. Alternatively or additionally, the group division rule may specify the relative size of the client account group. For example, in some embodiments, the API manager 320 may generate groups such that the first group and the second group include a greater number of client accounts than the third group.

[0147] In some embodiments, Figure 6 As shown, in step 1202, the API manager 320 can divide the client accounts into a first group, a second group, and a third group, each group having different members. Figure 6 As described, the API manager 320 may divide the client base into three groups and generate subgroups that may be used to evaluate API compatibility.

[0148] In step 1204, the API manager 320 may allocate APIs for communicating with the groups generated in step 1202. The APIs selected for communication may include legacy APIs and updated APIs. For example, the API manager 320 may configure an API mapping table that specifies an API gateway that responds to API calls from different groups. Additionally or alternatively, the API manager 320 may configure an API router, such as the router API 710 ( Figure 7 ) to resolve API calls with different API systems based on addresses and / or client IDs. In some embodiments, in step 1204, the API manager can allocate a first API (e.g., a legacy API) for communicating with the first group and a second API (e.g., a new or modified API) for communicating with the second group. In step 1204, the first API is allocated for communicating with a first portion of the third group, and the second API is allocated for communicating with a second portion of the third group.

[0149] In step 1206, API manager 320 may use a network analyzer, such as network analyzer 642 ( Figure 6 ), collect communications from each group. For example, the API manager 320 can configure the network analyzer to capture communications related to API calls from each group formed in step 1202. In some embodiments, the API manager 320 can collect communications at router points to process two-way communications (e.g., API requests and responses), and configure it to collect data within a predetermined time interval that provides valid samples. In order to collect a sufficient number of samples that produce statistically significant data, collection can be defined for a specific time interval, or collection can be performed in real time as the data stream arrives. For example, the API manager 320 can configure the network analyzer to collect information within a few hours of expected high traffic to collect a sufficient and varying number of API calls. In such an embodiment, in step 1206, the API manager 320 can collect communications from the first group, the second group, and the third group within the time interval and generate API metrics associated with each group. Alternatively or additionally, the API manager 320 can use, for example, the processing flow 800 to perform communication collection in real time to process and evaluate the data stream. In addition, the API manager 320 can filter communications in step 1206 to facilitate processing and generating API metrics. For example, in step 1206 , the API manager 320 may implement a redundancy filter 1006 to filter duplicate API calls or identify behaviors that remain unchanged between the legacy API 1002 and the updated API 1004 .

[0150] In step 1208, the API manager 320 may calculate and / or generate API metrics for each group. Based on the results of the API calls associated with each group in step 1202, the API manager 320 may estimate API metrics such as infrastructure, application, and / or product metrics to evaluate the performance of the API. For example, in some embodiments, the API manager 320 may determine API metrics for legacy and updated APIs. Fig.14 As further described, the API manager 320 can determine API metrics based on specific API applications and / or calls captured in the sample. In embodiments where the API manager 320 includes the system 900, generating the metrics can include using the real-time analysis module 914 ( Fig. 9 ) to calculate the metric. Alternatively or additionally, the API manager 320 may communicate with the legacy / update analyzer 650 to estimate the performance of two or more APIs and generate a comparative metric 1022.

[0151] In step 1210, the API manager 320 may use the API metrics from step 1208 to generate a compatibility and comparison report. For example, the API manager 320 may generate a report of metric mismatches, inconsistent calls, or poor infrastructure performance. Fig.13 As further described, when generating a compatibility and comparison report, the API manager 320 may compare API metrics and / or scores to a threshold. In some embodiments, the comparison report may compare API metrics between legacy and updated API operations. For example, the comparison report may include metrics associated with calls in the legacy version as well as updated metrics. In addition, the compatibility report may specify API metrics in a group that runs legacy APIs and updated APIs at the same time. In such an embodiment, the compatibility report may identify mismatches between APIs to attempt to confirm whether operating the two APIs simultaneously will create compatibility issues that affect the entire system. In some embodiments, in step 1210, the API manager 320 may generate a report from the report generator 660 ( Figure 6 ) to request a compatibility and comparison report.

[0152] The compatibility report can allow the API manager 320 to evaluate the effect of a user operating two API systems simultaneously. In some cases, clients may not be able to update their systems in view of changes or updates to the API. Therefore, it is necessary to run two APIs (old and updated versions) simultaneously. The compatibility report can identify problems with the simultaneous operation of the APIs. The compatibility report can describe source compatibility, binary compatibility, line compatibility, and semantic compatibility. The compatibility report can indicate whether there are any removed or renamed services, changes in HTTP bindings, changes in field types, or changes in resource formats between the old API and the updated API. The compatibility report can also describe specific calls that change the URL format in the HTTP definition. Additionally or alternatively, the compatibility report can describe source, binary, and semantic compatibility errors between APIs.

[0153] In addition, in some embodiments, the API manager 320 can also generate a comparison report that compares the API metrics associated with the first group and the API metrics associated with the second group, while generating a compatibility report based on the API metrics associated with the third group (which uses both APIs). In such an embodiment, the API manager 320 can use a JSON or GSON comparator to evaluate how each API handles different requests or methods. In such an embodiment, the API manager 320 can use a JSON path extractor post-processor that compares metadata and keys for similar communications in each API system. In addition, the comparison report can list the mismatches between the API calls from the first group and the differences between the metrics associated with the first group and the second group.

[0154] In some embodiments, the comparison and compatibility reports may include scores. The API manager 320 may determine a comparison score based on the comparison report, and a compatibility score based on the compatibility report. The API manager 320 may determine a comparison score that provides a performance evaluation between two APIs in a single quantity. For example, when the API metrics associated with the legacy API are worse than the metrics associated with the updated API, the comparison score may be positive and high. Conversely, when the API metrics associated with the legacy API are better than the metrics associated with the updated API, the comparison score may be negative and / or low. The comparison report may also include a threshold comparison.

[0155] Similarly, the API manager 320 can calculate a compatibility score based on the compatibility report. If there are many functional incompatibilities, or errors in communication come from groups using both the old and updated APIs, the API manager 320 can assign a low and / or negative compatibility score. However, if there are no incompatibilities and the error rate of the group using both the old and updated APIs is low, the API manager 320 can assign a high and / or positive score.

[0156] In step 1212, the API manager 320 may generate and send alerts and / or suggestions based on the compatibility and comparison reports. For example, when the comparison report shows that the old version of the API has better performance than the newer API, the API manager 320 may generate a suggestion not to switch to the newer API and / or propose modifications to the API. In addition, in step 1212, when any API metric of step 1208 is below a threshold and / or when the API manager 320 finds that there is an incompatibility between different calls, such as syntactic incompatibility, the API manager 320 may generate an alert. Therefore, in step 1212, the API manager 320 may send at least one of an alert or a suggestion based on the comparison report and the compatibility report. As combined Fig.16 As further described, the alerts and / or suggestions may include instructions for displaying a graphical user interface with the suggestions. In some embodiments, alerts and messages regarding the compatibility and comparability of the APIs may be sent via the administrator network 670. In such embodiments, the alert or suggestion may include an unmatched API call, and the API manager 320 may generate the alert or suggestion by automatically broadcasting the message over the administrator network 670.

[0157] In some embodiments, the alert and suggestion in step 1212 may include specific information. For example, the alert may include an indicator associated with the third group below the compatibility threshold, and the suggestion may include at least one of an updated API mapping table and a migration API plug-in. The updated API mapping table may include a table with modification information based on the suggestion or alert, such as API mapping table 1100 ( Fig.11 ). The migration API plugin may include a step-by-step wizard that guides administrators through the API migration process. For example, the migration plugin can create a migration package for the API that can be downloaded along with an installer script. The migration plugin can also allow users to upload the installer script to the cloud environment and run a migration wizard that converts API calls and URLs to comply with the interface conditions of the server and data center. For example, the migration plugin can be installed in the method converter 625 and provide tools for renaming or modifying the syntax of API calls.

[0158] In step 1214, the API manager 320 may automatically migrate the selected group of APIs by updating the API mapping table and / or employing an API migration plug-in. In some embodiments, the migration may be based on the recommendations or alerts of step 1212. For example, when the API manager 320 generates an alert indicating that the performance of the legacy system exceeds the updated API, the API manager 320 may automatically migrate customer accounts assigned to the updated API to the legacy API. This migration may involve reconfiguring an API gateway or router to resolve API calls using the legacy API. Alternatively or additionally, based on the recommendations, when both the compatibility and comparison scores of step 1210 exceed a threshold, the API manager 320 may automatically migrate customer accounts in the group assigned to the legacy API to the updated API. For example, when the API manager 320 utilizes Figure 6 When the illustrated configuration performs bucket testing, in response to determining that the comparison score and the compatibility score are above the threshold, the API manager 320 may assign the second (updated) API to the first group 612 and the third group 616 .

[0159] The API manager 320 can reconfigure the API mapping table, such as the API mapping table 1100 ( Fig.11 ), or by executing an API migration plug-in to perform automatic migration. For example, based on the suggestion or alert in step 1212, the API manager 320 may perform automatic migration on the API gateway A 632 and the API gateway B 634 ( Figure 6 ) to route content to a specific API. Additionally, in some embodiments, in step 1214, the API manager 320 can automatically adjust the API mapping instructions by, for example, replacing the functionality of the legacy API with the functionality of the updated API. For example, the API manager 320 can establish equivalence between API functions and determine relationships with corresponding API functions in the updated system. In some embodiments, automatic migration can include applying conversion functions or compiling tables to convert client instructions or requests from the legacy API format to the current or updated API. These conversion functions can include using, for example, a method converter 625 to update the syntax of the call.

[0160] Fig.131 is a flow chart of an exemplary API difference assessment process 1300 consistent with the disclosed embodiments. In some embodiments, units of system 300 may perform process 1200. For example, as disclosed in the steps described below, API manager 320 may perform process 1300. Alternatively or in addition, third-party system 360 and / or database 380 may perform process 1300 or portions of process 1300. Furthermore, in other embodiments, system 100 or portions of system 100 may perform process 1300. For example, internal front-end system 105 and / or FMG 115 may perform process 1300. In some embodiments, process 1300 may be after process 1200. However, in other embodiments, process 1300 may be independent of process 1200.

[0161] In step 1302, the API manager 320 may calculate API metrics for each group of client accounts. For example, the API manager 320 may use a network analyzer 642 ( Figure 6 ) to collect communications associated with each group of customer accounts and determine API metrics based on the communication logs.

[0162] In step 1304, the API manager 320 may determine a comparison score and / or a compatibility score. For example, based on the API metrics, the API manager 320 may determine that the updated API has better performance than the old version of the API and generate a higher comparison score. In addition, based on the API metrics of the client group operating the two APIs simultaneously, the API manager may determine whether there are no compatibility issues when running the APIs simultaneously and generate a high compatibility score.

[0163] In step 1306, the API manager 320 may determine whether the comparison score is below a threshold. If the API manager 320 determines that the comparison score is below a threshold (step 1306: yes), the API manager 320 may proceed to step 1308 and identify mismatching indicators or calls that cause lower performance. However, if the API manager 320 determines that the comparison score is not below a threshold (step 1306: no), the compatibility score may proceed to step 1310.

[0164] In step 1310, the API manager 320 may determine whether the compatibility score is below a threshold. If the API manager 320 determines that the compatibility score is below a threshold (step 1310: yes), the API manager 320 may proceed to step 1312 and identify incompatibility types and behavior changes between the two APIs or between members of a group that use the two APIs simultaneously. After step 1312 and / or step 1308, the API manager 320 may generate an alert or suggestion in step 1314. However, if the API manager 320 determines in step 1310 that the compatibility score is not below a threshold (step 1310: no), the API manager 320 may proceed to step 1316.

[0165] In step 1316, API manager 320 can generate updated API mapping table and / or generate migration plug-in.For example, API manager 320 can update API mapping table 1100.The migration plug-in can include one or more of different plug-ins, which can be used to transfer client accounts between different APIs.In certain embodiments, in addition to the migration wizard, the migration plug-in can include deprecated functions to promote, identify or build conversion functions.The migration plug-in can also include download functions, determine whether functions exist, explode functions and normalization functions.

[0166] In step 1318, the API manager 320 may generate migration strategies and recommendations. For example, based on the compatibility and comparison scores, the API manager 320 may generate recommendations for initiating migration and when to initiate API migration. Fig.15 As further described, the recommendations may include a strategy for migrating to a newer API.

[0167] In step 1320, API manager 320 may transmit the suggestion. For example, API manager 320 may send the suggestion of step 1318 to a device associated with the network manager. In some embodiments, the suggestion may be sent in real time or when the compatibility and comparison scores are estimated.

[0168] Fig.141400 is a flow chart of an exemplary process 1400 for determining API metrics consistent with the disclosed embodiments. In some embodiments, elements of system 300 may perform process 1400. For example, as disclosed in the steps described below, API manager 320 may perform process 1400. Alternatively or additionally, legacy / update analyzer 650 may perform process 1400 or a portion of process 1400. Furthermore, in other embodiments, system 100 or a portion of system 100 may perform process 1400. For example, internal front-end system 105 and / or FMG 115 may perform process 1400. In some embodiments, process 1400 may be a portion of process 1300. For example, process 1400 may be performed as step 1208 ( Fig.12 However, in other embodiments, process 1400 may be independent of process 1300.

[0169] In step 1402, API manager 320 may receive instructions for calculating API metrics. For example, API manager 320 may receive instructions from a network administrator to perform a comparative analysis of the performance of two APIs and request that API metrics be calculated. However, in other embodiments, the request may be automatic and generated after a collection period and / or based on a network analyzer configuration.

[0170] In step 1404, the API manager 320 may identify a memory group with the collected API calls. For example, the API manager 320 may identify a memory space storing communications associated with the first, second, and third groups. In step 1406, the API manager 320 may determine whether it is necessary to estimate infrastructure API metrics. If the API manager 320 determines that it is necessary to estimate infrastructure API metrics (step 1406: yes), the API manager 320 may proceed to step 1408.

[0171] In step 1408, the API manager 320 may estimate infrastructure API metrics, which may include uptime metrics, CPU usage metrics, and memory usage metrics. The uptime metric may measure the availability of the API service. In some embodiments, the uptime metric may be based on a proportion of downtime. A lower uptime metric may indicate that the API is not responding as expected and some redundancy metrics may be required. In some embodiments, the API manager 320 may determine the uptime metric by evaluating a specific sequence of API calls. The CPU usage metric may measure the CPU usage of the API server. Such a metric may be associated with oversubscription and overloaded applications such as too many spinlocks. To measure CPU usage, the API manager may monitor activity in computer resources in the server and / or include an agent that captures metrics such as CPU and memory usage. The memory usage metric, similar to CPU usage, may also measure resource utilization as the capacity of CPU and memory. The API manager 320 may determine memory usage using an agent that monitors the availability of memory sources. In some embodiments, the memory usage metric may also measure the distribution of tasks between memories to assess whether the API overloads a particular memory unit.

[0172] If the API manager 320 determines that it is not necessary to estimate infrastructure API metrics (step 1406: No), the API manager 320 may skip step 1408 and proceed to step 1410. In step 1410, the API manager 320 determines whether it is necessary to estimate application metrics. If the API manager 320 determines that it is necessary to estimate application API metrics (step 1410: Yes), the API manager 320 may proceed to step 1412.

[0173] In step 1412, the API manager 320 may estimate application metrics, which may include the number of requests per minute (e.g., API calls per minute), the maximum latency of responses, and the number of errors per minute. To calculate the number of requests per minute, the API manager 320 may be used to evaluate the performance of the database and / or server. The API manager may confirm whether the number of requests per minute for the API is greater than the expected number, and find out whether there are related errors such as those that cause repeated calls. Alternatively or additionally, the number of requests per minute may show that certain functions should be merged to reduce API calls. In addition, the API manager 320 may estimate wait times to track delays in responses to client requests. In some embodiments, tracking changes in wait times may show that new endpoints have been added, patterns have changed, and more operations have been stopped. Therefore, the API manager 320 may track each communication between the server and the client through the API gateway to determine the average wait time for each communication. The API manager 320 may estimate other similar metrics, such as requests per second (RPS) and queries per second (QPS).

[0174] Step 1412 may also include estimating the number of errors per minute for each of the APIs and / or associated groups. For example, the API manager 320 may determine the number of errors for the number of API calls. Such an indicator may estimate the errors and error propensity of an API. In some embodiments, the API manager 320 may use HTTP status codes to determine the number of errors per minute.

[0175] If the API manager 320 determines that the application API metrics do not need to be estimated (step 1410: No), the API manager 320 may skip step 1412 and proceed to step 1414. In step 1414, the API manager 320 determines whether the product metrics need to be estimated. If the API manager 320 determines that the product API metrics need to be estimated (step 1414: Yes), the API manager 320 may proceed to step 1416.

[0176] In step 1416, the API manager 320 may determine metrics such as usage growth, unique and / or top consumers, API retention, time to first Hello World (TTFHW), calls per transaction, and SDK adoption rate. In addition, the API manager may determine product API metrics including the number of unique API consumers and calls per business transaction.

[0177] If API manager 320 determines that product API metrics do not need to be estimated (step 1414: No), API manager 320 may skip step 1416 and proceed to step 1420. In step 1420, API manager 320 may return API metrics for API operations associated with one or more evaluation groups.

[0178] Fig.15 1 is a flow chart of an exemplary process 1500 for performing API migration recommendations consistent with the disclosed embodiments. In some embodiments, a unit of system 300 may perform process 1500. For example, as disclosed in the steps described below, API manager 320 may perform process 1500. Alternatively or additionally, third-party system 360 may perform process 1500 or a portion of process 1500. Furthermore, in other embodiments, system 100 or a portion of system 100 may perform process 1500. For example, internal front-end system 105 and / or FMG 115 may perform process 1500. In some embodiments, process 1500 may be after process 1200. However, in other embodiments, process 1500 may be independent of process 1200.

[0179] In step 1502, the API manager 320 may receive an instruction to provide a suggestion for API migration. For example, when the comparison score is higher than a threshold, the API manager 320 may receive an instruction to generate a suggestion for API migration.

[0180] In step 1504, the API manager 320 may perform a wireframe check on the API network. For example, the API manager 320 may generate a visual guide that represents the skeleton of the API and its connections. In some embodiments, the wireframe may include a list of API functions, the priority of information and functions in the API interaction, rules for displaying certain types of information, and the effects of different scenarios on the display.

[0181] In step 1506, the API manager 320 may be configured to redirect testing and generate a risk assessment. For example, the API manager 320 may configure a redirection test engine that allows different APIs to be tested against each other. The redirection tests may include different API calls for each function. In addition, the API manager 320 may generate a risk assessment that includes the scope, nature, quantification, tolerance, and risk treatment of the risk. For example, in step 1506, the API manager 320 may determine whether the risk of an API failure is operational or financial, and may also estimate the likelihood of risk during migration and make recommendations to reduce risk during migration.

[0182] In step 1508, the API manager 320 may determine a benchmark for the evaluation. For example, the API manager 320 may determine threshold numbers for API metrics, compatibility scores, and comparison scores. In step 1510, the API manager 320 may migrate the group and perform real-time API testing on the migrated group. For example, the API manager 320 may update the API mapping table and execute the plug-in through a network analyzer and initiate performance monitoring for the group with the modified API.

[0183] In step 1512, the API manager 320 may perform error correction and performance correction based on the metrics and events recorded in step 1510. Based on the error and performance correction of step 1512, the API manager 320 may generate an API migration performance report in step 1514. In some embodiments, the API manager 320 may generate an automatic report with information about the collected metrics and / or performance results.

[0184] Fig.16 An exemplary graphical user interface (GUI) for alerts and / or notifications generated during API evaluation consistent with the disclosed embodiments is shown. Fig.16 Exemplary alerts for desktop GUI 1600 and mobile GUI 1650 are shown. Fig.12 As further described, the API manager 320 can generate the desktop GUI 1600 and / or the mobile GUI 1650 as part of the process 1200 and communicate via the administrator network 670 .

[0185] Desktop GUI 1600 may include a title 1602 specifying the notification type, a report section 1604, and an error details panel 1606, which may include more specific information about incompatible API calls and / or poor performance indicators. In addition, desktop GUI 1600 may include a results link 1608 to view additional results of the compatibility and comparison report.

[0186] The mobile GUI 1650 may include a message 1652 containing detailed information about the compatibility error or the comparison results of the bucketed or batched run tests between the legacy API and the updated API.

[0187] Another aspect of the present disclosure is directed to a non-transitory computer-readable medium storing instructions that, when executed, cause one or more processors to perform the method described above. The computer-readable medium may include a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of computer-readable medium or computer-readable storage device. For example, as disclosed, the computer-readable medium may be a storage unit or storage module having computer instructions stored thereon. In some embodiments, the computer-readable medium may be a disk or flash drive having computer instructions stored thereon.

[0188] It will be apparent to those skilled in the art that various modifications and variations may be made to the disclosed systems and related methods. Other embodiments will be apparent to those skilled in the art by consideration of the specification and practice of the disclosed systems and related methods. The specification and examples are intended to be considered exemplary only, with the true scope being indicated by the appended claims and their equivalents.

[0189] Although the present invention has been shown and described in conjunction with its specific embodiments, it should be understood that the present invention can be implemented without modification in other environments. The foregoing description is given for illustrative purposes only. It is not exhaustive and is not limited to the precise form or embodiment disclosed. By considering the specification and practice of the disclosed embodiments, modifications and adjustments will be apparent to those skilled in the art. In addition, although the aspects of the disclosed embodiments are described as being stored in a memory, it should be understood by those skilled in the art that these aspects can also be stored in other types of computer-readable media, such as auxiliary storage devices, such as hard disks or CD-ROMs (CDROMs), or other forms of random access memory (RAM) or read-only memory (ROM), universal serial bus (USB) media, digital video disks (DVDs), blue-rays or other optical drive media.

[0190] Computer programs based on written descriptions and disclosed methods are within the skill set of experienced developers. Various programs or program modules can be created using any technology known to those skilled in the art, or can be designed in conjunction with existing software. For example, program segments or program modules can be designed in or through: .NET Framework, .NET Compact Framework (and related languages, such as Visual Basic, C, etc.), Java, C++, Objective-C, HTML, HTML / AJAX combination, XML, or HTML containing Java applets.

[0191] In addition, although illustrative embodiments are described herein, those skilled in the art will understand in light of the present invention that the scope of any and all embodiments has equivalent elements, modifications, omissions, combinations (e.g., combinations across aspects of the various embodiments), modifications and / or changes. Limitations in the claims should be interpreted broadly based on the wording used in the claims and are not limited to the examples described in this specification or during the prosecution of the application. These examples are to be interpreted as non-exclusive. In addition, the steps of the disclosed method may be modified in any way, including by reordering steps and / or inserting or deleting steps. Therefore, this specification and examples are to be considered illustrative only, with the true scope and spirit being indicated by the following claims and the full scope of their equivalents.

[0192] Therefore, the foregoing description is given for illustrative purposes only. It is not exhaustive and is not limited to the precise forms or embodiments disclosed. Modifications and adaptations will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed embodiments.

[0193] The claims are to be interpreted broadly based on the language used in the claims and not limited to the examples described in the specification, which are to be interpreted as non-exclusive. Furthermore, the steps of the disclosed methods may be modified in any manner, including by reordering steps and / or inserting or deleting steps.

Claims

1. A computerized system for API migration, the system comprising: at least one memory for storing instructions; and At least one processor is configured to execute instructions to perform operations, the operations comprising: Divide the client accounts into first, second and third groups, each with different members; allocating a first API for communicating with the first group and a second API for communicating with the second group; allocating the first API for communicating with a first portion of the third group and allocating the second API for communicating with a second portion of the third group; collecting communications from the first group, the second group, and the third group over a time interval and generating metrics associated with each group; generating a comparison report comparing the indicator associated with the first group and the indicator associated with the second group; generating a compatibility report based on the indicators associated with the third group; and At least one of an alert or a recommendation is transmitted based on the comparison report and the compatibility report.

2. The system according to claim 1, wherein: The first API is an old version API, and the second API is an updated API; and The operations also include automatically migrating the client account to the updated API based on the recommendation.

3. The system according to claim 2, wherein: The operations also include: determining a comparison score according to the comparison report, determining a compatibility score based on the compatibility report; and In response to determining that the comparison score and the compatibility score are above a threshold, the second API is assigned to the first group and the third group.

4. The system according to claim 1, wherein: The first group and the second group include a greater number of client accounts than the third group.

5. The system according to claim 1, wherein: The comparison report lists mismatches between API calls from the first group and differences between metrics associated with the first group and the second group; The compatibility report lists source, binary, and semantic compatibility errors between the first API and the second API; The alert or advisory includes the mismatch; and Generating the alert or advisory includes automatically broadcasting a message across an administrator's network.

6. The system of claim 1 , wherein collecting the communications comprises configuring a network analyzer to: capturing packets incoming from client devices associated with client accounts in the first group, the second group, and the third group; and Store captured packets in each group in separate storage spaces.

7. The system according to claim 6, wherein: Generating the indicator includes: For each of the first group, the second group, and the third group, generate: Infrastructure API metrics, including uptime, CPU usage, and memory usage; Application API metrics, including requests per minute, average maximum latency, and errors per minute; and Product API metrics, including the number of unique API users and the number of calls per business transaction.

8. The system according to claim 7, wherein: The alert includes a metric associated with the third group being below a compatibility threshold; and The suggestion includes at least one of an updated API mapping table and a migration API plug-in.

9. The system according to claim 1, wherein: The first group, the second group, and the third group include an equal number of the client accounts.

10. The system according to claim 1, wherein: The first API and the second API include an integration extension that connects an online store with an e-commerce data center; and Collecting the communications includes recording properties of the communications obtained from the log pipeline while excluding client-side communications.

11. A computer-implemented method for API migration, the method comprising: Divide the client accounts into first, second and third groups, each with different members; allocating a first API for communicating with the first group and a second API for communicating with the second group; allocating the first API for communicating with a first portion of the third group and allocating the second API for communicating with a second portion of the third group; collecting communications from the first group, the second group, and the third group over a time interval and determining a metric associated with each group; generating a comparison report comparing the indicator associated with the first group and the indicator associated with the second group; generating a compatibility report based on the indicators associated with the third group; and At least one of an alert or a recommendation is transmitted based on the comparison report and the compatibility report.

12. The method according to claim 11, wherein: The first API is an old version API, and the second API is an updated API.

13. The method according to claim 12, further comprising: determining a comparison score according to the comparison report, and determining a compatibility score based on the compatibility report; as well as In response to determining that the comparison score and the compatibility score are above a threshold, the second API is assigned to the first group and the third group.

14. The method of claim 11, wherein the first group and the second group include a greater number of client accounts than the third group.

15. The method according to claim 11, wherein: the comparison report lists mismatches between API calls from the first group and the second group; The compatibility report lists source, binary, and semantic compatibility errors between the first API and the second API; The alert or advisory includes the mismatch; and Generating the alert or advisory includes automatically broadcasting a message across an administrator's network.

16. The method according to claim 11, wherein: Collecting the communications includes configuring a network analyzer to: capturing packets incoming from client devices associated with client accounts in the first group, the second group, and the third group; as well as Store captured packets in each group in separate storage spaces.

17. The method according to claim 16, wherein: Generating the indicator includes generating, for each of the first group, the second group, and the third group: Infrastructure API metrics, including uptime, CPU usage, and memory usage; Application API metrics, including requests per minute, average maximum latency, and errors per minute; as well as Product API metrics, including the number of unique API users and the number of calls per business transaction; The alert includes a metric associated with the third group being below a feasibility threshold; and The suggestion includes at least one of an updated API mapping table and a migration API plug-in.

18. The method according to claim 11, wherein: The first group, the second group, and the third group include an equal number of the client accounts.

19. The method of claim 11, wherein: The first API and the second API include an integration extension that connects an online store with an e-commerce data center; and Collecting the communications includes recording properties of the communications obtained from the log pipeline while excluding client-side communications.

20. A system for automatically evaluating and migrating an application programming interface, comprising: one or more processors; and one or more storage devices storing instructions that, when executed by the one or more processors, configure the one or more processors to: Divide the client accounts into first, second and third groups, each with different members; allocating a first API for communicating with the first group and a second API for communicating with the second group, the first API being a legacy API and the second API being a newer API, the first API and the second API comprising an integration extension connecting an online store with an e-commerce data center; allocating the first API for communicating with a first portion of the third group and allocating the second API for communicating with a second portion of the third group; collecting communications from the first group, the second group, and the third group over a time interval and generating metrics associated with each group; generating a comparison report comparing the metrics associated with the first group and the metrics associated with the second group, the comparison report including a difference between the API metrics associated with the first group and the API metrics associated with the second group; generating a compatibility report based on API metrics associated with the third group; determining whether the difference is below a feasibility threshold; determining whether an API indicator associated with the third group is below a compatibility threshold; as well as In response to determining that the difference is below the feasibility threshold and the API metric associated with the third group is above the compatibility threshold, a recommendation including an updated API mapping table and a migration API plug-in is transmitted.

Images