Method, device and equipment for realizing unified API (Application Program Interface) of call center and storage medium

Abstract

The invention relates to the technical field of calling in financial and medical scenes, and discloses a call center unified API implementation method, device and equipment and a storage medium, and the method comprises the steps: dividing the type of an API into a first type of interface developed based on the capability of a product and a second type of interface customized and developed by depending on a service system; the method comprises the following steps: receiving a calling request initiated by a heterogeneous service system through a protocol analysis engine, extracting a protocol feature identifier in the calling request to obtain a heterogeneous protocol, uniformly converting the heterogeneous protocol into a standard API protocol format according to a preset protocol conversion rule base, and analyzing the type of an API interface in the conversion process; and executing differentiated routing according to the type of the API interface. In the invention, aiming at the call center of financial and medical scenes, a core framework of a unified API (Application Program Interface) of the call center is constructed, and the interface standardization of a call center system is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of call in financial and medical scenarios, and particularly relates to a call center unified API implementation method, device, equipment and storage medium. BACKGROUND

[0002] In the call center system in the financial and medical fields, the lack of interface standardization becomes the core bottleneck restricting service efficiency and system expansion. The call center of the financial industry (such as banks, securities, insurance institutions) needs to process high-concurrency transaction consultation, risk control early warning and customer identity verification in real time, while the medical field (such as Internet hospitals, emergency dispatch platforms) relies on the call center to realize patient privacy communication, emergency coordination and remote diagnosis support.

[0003] However, the current industry generally has the following defects: the proportion of customization is too high, the interface reuse rate is low; the monitoring capability is missing, and the interface failure (such as financial transaction congestion and medical call disconnection) cannot be diagnosed in real time; there is a lack of product specification, and the same function interface needs to be developed repeatedly in the financial risk control and medical follow-up scenarios.

[0004] The above defects have caused systematic efficiency loss and safety risks in the financial and medical scenarios with strong supervision and high concurrency, and it is urgent to get rid of the integration dilemma through a unified API architecture. SUMMARY

[0005] The purpose of the present application is to provide a call center unified API implementation method, device, equipment and storage medium, which aims to solve the problem of the lack of interface standardization of the existing call center system.

[0006] In a first aspect, the present application provides a call center unified API implementation method, comprising:

[0007] The type of API interface is divided into a first type of interface developed based on the product's own capabilities and a second type of interface developed by relying on business system customization;

[0008] The protocol analysis engine receives a call request initiated by a heterogeneous business system, extracts the protocol feature identifier in the call request to obtain a heterogeneous protocol, uniformly converts the heterogeneous protocol into a standard API protocol format according to a preset protocol conversion rule library, and parses the type of API interface in the conversion process;

[0009] According to the type of the API interface, differential routing is performed; including: if the API interface is the first type of interface, the call request is routed to the product capability engine to perform basic communication or value-added service logic; if the API interface is the second type of interface, the parameters of the call request are adapted to the target business system through the configuration mapping module;

[0010] Real-time collection of all API interface call operation indexes, generation of health degree reports by a monitoring center, and return of processing results in a unified data format.

[0011] In a second aspect, an embodiment of the present application provides a call center unified API implementation device, comprising:

[0012] An interface division unit is configured to divide the types of API interfaces into a first type of interface developed based on product self-capabilities and a second type of interface developed by relying on business system customization;

[0013] A protocol conversion unit is configured to receive a call request initiated by a heterogeneous business system through a protocol analysis engine, extract protocol feature identifiers in the call request to obtain a heterogeneous protocol, uniformly convert the heterogeneous protocol into a standard API protocol format according to a preset protocol conversion rule library, and parse the type of the API interface in the conversion process;

[0014] A routing execution unit is configured to execute differentiated routing according to the type of the API interface, including: if the API interface is the first type of interface, routing the call request to a product capability engine to execute basic communication or value-added service logic; and if the API interface is the second type of interface, adapting parameters of the call request to a target business system through a configuration mapping module;

[0015] A monitoring unit is configured to collect operation indexes of all API interface calls in real time, generate health degree reports by a monitoring center, and return processing results in a unified data format.

[0016] In a third aspect, an embodiment of the present application provides a computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the call center unified API implementation method of the first aspect when executing the computer program.

[0017] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program causes a processor to execute the call center unified API implementation method of the first aspect when the processor executes the computer program.

[0018] In the scheme realized by the call center unified API implementation method, device, equipment and storage medium, the types of API interfaces can be divided into a first type of interface developed based on product self-capabilities and a second type of interface developed by relying on business system customization; a protocol analysis engine receives a calling request initiated by a heterogeneous business system, extracts a protocol feature identifier in the calling request to obtain a heterogeneous protocol, uniformly converts the heterogeneous protocol into a standard API protocol format according to a preset protocol conversion rule library, and parses the type of the API interface in the conversion process; differential routing is performed according to the type of the API interface; if the API interface is the first type of interface, the calling request is routed to a product capability engine to perform basic communication or value-added service logic; if the API interface is the second type of interface, parameters of the calling request are adapted to a target business system through a configuration mapping module; running indexes of all API interface calls are collected in real time, a health degree report is generated through a monitoring center, and a processing result is returned in a unified data format. In the application, a core framework of the call center unified API is constructed for the call center unified API implementation application in the financial and medical scenarios, the core lies in that the API interface is divided into the first type of interface developed by the product self-capabilities and the second type of interface customized by the business system, and intelligent conversion of the heterogeneous protocol is realized through the protocol analysis engine, so that the interface standardization of the call center system is realized, and the following three aspects of optimization are realized through the improvement of the interface standardization: 1. the integration development amount is reduced through protocol unification; 2. the request processing efficiency is improved based on the dynamic routing mechanism of the interface type; and 3. unified monitoring indexes (such as time delay and abnormal stack) provide quantitative basis for the system health degree. In the financial scenario, for example, the bank needs to connect the traditional telephone system, the mobile terminal application and the third-party risk control platform, these systems often use different interface protocols such as SIP, HTTP / JSON-RPC, the protocol analysis engine realizes standardized conversion by extracting protocol feature identifiers (such as HTTP header Content-Type or SIP message Via field) and combining a preset rule library (such as converting XML load into JSON), and the system connection cost is greatly reduced. In the medical scenario, for example, the application can uniformly process HIS system HL7 protocol, Internet of Things device MQTT protocol and WebService call of the medical insurance platform, and ensure seamless transmission of emergency call requests across systems. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0020] Figure 1An application environment schematic diagram of the call center unified API implementation method provided by the embodiment of the present application is provided;

[0021] Figure 2 A flow schematic diagram of the call center unified API implementation method provided by the embodiment of the present application is provided;

[0022] Figure 3 A sub-flow schematic diagram of the construction process of the protocol conversion rule library provided by the embodiment of the present application is provided;

[0023] Figure 4 A sub-flow schematic diagram of the step S202 provided by the embodiment of the present application is provided;

[0024] Figure 5 A sub-flow schematic diagram of the step S203 provided by the embodiment of the present application is provided;

[0025] Figure 6 Another sub-flow schematic diagram of the step S203 provided by the embodiment of the present application is provided;

[0026] Figure 7 A sub-flow schematic diagram of the step S204 provided by the embodiment of the present application is provided;

[0027] Figure 8 A schematic block diagram of the call center unified API implementation device provided by the embodiment of the present application is provided;

[0028] Figure 9 A structure schematic diagram of the computer device provided by the embodiment of the present application is provided;

[0029] Figure 10 Another structure schematic diagram of the computer device provided by the embodiment of the present application is provided. DETAILED DESCRIPTION

[0030] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0031] The call center unified API implementation method provided by the embodiment of the present application can be applied in, for example Figure 1In an application environment of the application, a business system communicates with a call center through a network. The business system can initiate a calling request. The call center can divide types of API interfaces into a first type of interface developed based on product self-capabilities and a second type of interface developed by relying on business system customization. The call center receives a calling request initiated by a heterogeneous business system through a protocol analysis engine, extracts a protocol feature identifier in the calling request to obtain a heterogeneous protocol, uniformly converts the heterogeneous protocol into a standard API protocol format according to a preset protocol conversion rule library, and parses the type of the API interface in the conversion process. According to the type of the API interface, differential routing is performed. If the API interface is the first type of interface, the calling request is routed to a product capability engine to perform basic communication or value-added service logic. If the API interface is the second type of interface, the parameters of the calling request are adapted to a target business system through a configuration mapping module. Real-time collection of running indexes of all API interfaces is performed, a health degree report is generated through a monitoring center, and a processing result is returned in a unified data format. In the application, a call center unified API implementation application for financial and medical scenarios is constructed, and a core framework of the call center unified API is constructed. The core lies in that the API interface is divided into the first type of interface developed based on product self-capabilities and the second type of interface developed by relying on business system customization, and the intelligent conversion of the heterogeneous protocol is implemented through the protocol analysis engine, so that the interface standardization of the call center system is implemented. Through the improvement of the interface standardization, the following three aspects of optimization are implemented: 1. The integration development amount is reduced through protocol unification; 2. The request processing efficiency is improved based on the dynamic routing mechanism of the interface type; and 3. Unified monitoring indexes (such as time delay and abnormal stack) provide quantitative basis for system health degree. The business system can be but is not limited to a bank, an insurance company, a securities company, a medical institution, etc. The call center can be but is not limited to a telephone customer service center, an online customer service center or a multimedia customer service center, etc. The application will be described in detail through specific embodiments.

[0032] Referring to Figure 2 , a call center unified API implementation method provided by an embodiment of the application is shown. Figure 2 A flowchart of the call center unified API implementation method provided by an embodiment of the application is shown.

[0033] As Figure 2 shown, the method includes steps S201-S204.

[0034] S201, divide the type of the API interface into the first type of interface developed based on product self-capabilities and the second type of interface developed by relying on business system customization.

[0035] For step S201, the first type of interface includes a telephone platform basic capability interface and a telephone platform value-added service capability interface; the telephone platform basic capability interface includes: a call control interface, a media stream transmission and session state management interface; and the telephone platform value-added service capability interface includes: a number shield risk control interface, a privacy number dynamic binding interface and a voice synthesis engine interface.

[0036] For example, in a financial debt collection business, the call control interface can realize intelligent outbound call frequency adjustment to avoid triggering operator risk control; the privacy number dynamic binding interface enables a collector and a customer to contact through a virtual number, protecting the real information of both parties. In a medical scenario, the voice synthesis engine interface can convert electronic medical record text into multilingual voice notification to assist cross-country patient follow-up. Based on this, the standardization of the basic capability interface shortens the communication link establishment time of the financial / medical business; the value-added service interface (such as the number shield) can intercept most of the financial fraud calls, and the privacy number function meets the HIPAA medical privacy compliance requirements.

[0037] S202, receiving a calling request initiated by a heterogeneous business system through a protocol analysis engine, extracting a protocol feature identifier in the calling request to obtain a heterogeneous protocol, uniformly converting the heterogeneous protocol into a standard API protocol format according to a preset protocol conversion rule library, and parsing the type of the API interface in the conversion process.

[0038] For step S202, as shown in Figure 3 the construction process of the protocol conversion rule library includes:

[0039] S301, collecting historical heterogeneous protocol samples, extracting protocol header field, payload structure and encryption mode features;

[0040] S302, establishing a field mapping relationship of protocol features and a standard API protocol and a data type conversion rule;

[0041] S303, realizing the structured extraction of unstructured request data through a regular expression engine.

[0042] The core of steps S301-S303 is the double-layer design of the feature extraction system and the structured mapping engine based on historical heterogeneous protocol samples. In the rule library construction phase, the system collects historical heterogeneous protocol samples (such as the FIX transaction protocol in the financial field and the HL7 clinical message in the medical industry), and performs three feature deconstruction: protocol header field feature extraction, payload structure feature modeling and payload structure feature modeling.

[0043] Among them, the protocol header field feature extraction: for example, extracting the 8=FIX.4.2 identifier protocol version from the FIX protocol header, or determining the message type from the MSH-9=ADT^A01 of the MSH segment of the HL7 message.

[0044] Among them, the load structure feature modeling: for the nested structure of financial SWIFT message {1:{field:value},2:{...}} Establish a tree parsing model, or divide the metadata area and pixel area in the binary data stream of medical DICOM image transmission protocol.

[0045] Among them, the encryption method feature identification: automatically detect the AES-256-CBC encryption header used by the financial system or the SSL / TLS handshake feature required by the medical HIPAA compliance.

[0046] In the financial scenario, the mechanism can standardize the diversified order interface of securities companies: the binary structure of CTP protocol of China Financial Futures Exchange and the Tag=Value text of STEP protocol of Shanghai Stock Exchange are uniformly mapped to the standard API structure {"order_type":"limit","price":9.8}.

[0047] For step S202, as shown in the figure, according to the preset protocol conversion rule library, the heterogeneous protocol is uniformly converted into the standard API protocol format, which includes: Figure 4

[0048] S401, convert the unstructured data of the heterogeneous protocol into a key-value pair structure through a regular expression engine;

[0049] S402, according to the field mapping relationship table, the heterogeneous parameter name of the heterogeneous protocol is standardized and renamed;

[0050] S403, according to the data type conversion rule, the key-value pair structure and the heterogeneous parameter name are uniformly formatted, and the standard protocol conforming to the standard API protocol format is generated.

[0051] In this embodiment, steps S401-S403 focus on the runtime processing logic of protocol conversion, mainly embodied as regular expression guided pipeline technology and strong consistency guarantee of data type. The conversion process is divided into three stages of fine operation: unstructured data splitting, heterogeneous parameter name standardization and data type forced uniformity.

[0052] Among them, the unstructured data splitting refers to the decomposition of the original protocol into key-value pairs through the regular expression engine (such as PCRE library).

[0053] Among them, the heterogeneous parameter name standardization refers to the semantic renaming based on the field mapping relationship table; for example: in the financial field, transfer_amount of Alipay interface and txnAmt of UnionPay are unified as amount; in the medical field, pat_name of HIS system and patient_fullname of EMR system are mapped to patient_name. ​

[0054] Among them, the data type forced uniformity refers to performing type conversion according to preset rules: such as financial currency field processing: converting the string "USD 1,000.50" to the numerical value 1000.50, and appending the currency code currency="USD"; such as medical laboratory data conversion: splitting the text "white blood cell count: 12.3 x 10 9 / L" into the scientific notation structure of {"wbc_count": 12.3, "unit": "10^9 / L"}.

[0055] Based on this, steps S401-S403 realize efficient and accurate protocol conversion, can process data format differences in various complex scenarios, making data intercommunication between different protocols simple and easy. Through this embodiment, the call center can uniformly manage and call various heterogeneous protocols, realizing the standardization and unification of API interfaces, and providing strong support for the integration of business systems and the interaction of data.

[0056] S203, performing differentiated routing according to the type of the API interface; including: if the API interface is a first type of interface, routing the calling request to a product capability engine to perform basic communication or value-added service logic; if the API interface is a second type of interface, adapting parameters of the calling request to a target business system through a configuration mapping module.

[0057] For step S203, when the API interface is a first type of interface, it mainly involves basic communication or value-added service logic, which is usually executed by the product capability engine. The product capability engine is a highly integrated module that encapsulates various communication protocols and value-added service functions, can quickly respond to and process calling requests, and ensures the stability of basic communication and the diversity of value-added services. When the API interface is a second type of interface, the second type of interface is usually closely related to the target business system, and its parameter format and logic processing flow are different. In order to realize accurate calling of the second type of interface, the embodiment introduces a configuration mapping module. The module can adapt the parameters of the calling request to the target business system according to the pre-set mapping rules. This configuration greatly improves the flexibility and scalability of the system, so that the system can easily cope with the access of various new business systems and the upgrade of old business systems.

[0058] In the financial scenario, for example, on the one hand, if a customer wants to query the account balance through the API interface and the request is identified as the first type of interface, it will be routed to the product capability engine. The product capability engine will call the corresponding communication protocol, interact with the background database, obtain the account balance information, and return it to the customer. The whole process is efficient and stable, ensuring that the customer can obtain the account information in real time. On the other hand, if the customer wants to transfer money through the API interface and the request is identified as the second type of interface, since the transfer operation involves sensitive information such as specific bank accounts and transfer amounts, and the transfer process of different banks may differ, the request needs to be processed through the configuration mapping module. The module will convert the parameters in the request into the format required by the target business system according to the preset mapping rules, and route it to the corresponding bank system for transfer operation. This flexible configuration method enables the system to easily handle the transfer process of different banks and provide convenient transfer services for customers. In the financial scenario, this differentiated routing processing method greatly improves the processing efficiency of the system and customer satisfaction.

[0059] For step S203, as shown in the following table, if the API interface is the first type of interface, the request is routed to the product capability engine to execute the basic communication or value-added service logic steps, including: Figure 5

[0060] S501, when the call request is identified as the first type of interface, it is distributed to the target node in the cluster of the product capability engine through the dynamic load balancer;

[0061] S502, the product capability engine calls the pre-packaged atomic capability component according to the interface type; specifically, when executing the logic of basic communication, it controls real-time signaling interaction and routes media streams; when executing the logic of value-added services, it triggers a multi-level risk control verification engine or a voice synthesis engine through an asynchronous message queue;

[0062] S503, during execution, real-time session state data is collected and written into a distributed transaction log, and asynchronous execution results are pushed to the business system through a callback gateway.

[0063] In this embodiment, steps S501-S503 provide a high-performance routing and atomic processing framework for the first type of interface. The technical breakthrough lies in the following three synergistic mechanisms.

[0064] ​Firstly, the first re-coordination mechanism of intelligent scheduling of dynamic load balancing is implemented. Specifically, when the protocol analysis engine identifies the first type of interface, the dynamic load balancer distributes the request to the optimal node of the product capability engine cluster based on the real-time collected cluster node indicators (CPU utilization, memory pressure, queue depth) through the weighted round-robin algorithm. For example, when the delay of a node in processing an outbound call request exceeds a threshold (such as 200 ms), the scheduler automatically shunts new requests to a low-load node, ensuring linear expansion capability in high-concurrency scenarios.

[0065] Secondly, the second re-coordination mechanism of modular execution of atomic capability components is implemented. Specifically, the product capability engine calls pre-packaged atomic capability components to execute core logic:

[0066] Basic communication components: establish real-time media channels through signaling control layers (such as SIP session controllers) and synchronously manage session state machines (such as state transitions from ringing to connected to hung up);

[0067] Value-added service components: decouple time-consuming operations using asynchronous message queues (such as Kafka), such as pushing speech synthesis tasks to a dedicated thread pool to avoid blocking the main call link.

[0068] Finally, the third re-coordination mechanism of a distributed transaction guarantee system is provided. Specifically, during execution, real-time structured logs (such as operation type, timestamp, session ID) are written to a distributed transaction storage (such as Apache BookKeeper), and asynchronous results are pushed through a callback gateway. The log adopts the WAL (Write-Ahead Logging) mechanism to ensure that even if the system crashes, the final state can be recovered through log replay.

[0069] In the example, in the high-frequency trading scenario of the financial scenario, the load balancer distributes batch outbound call requests to idle nodes based on the CPU load of the product capability engine cluster, while real-time screening of blacklisted numbers is performed through atomic components (such as risk verification engines). In the medical emergency scenario, an asynchronous message queue ensures that speech synthesis tasks (such as generating emergency navigation speech) do not block the core call link. Distributed transaction logs record the IVR operation trajectory of each call, meeting the requirements of financial regulatory audits. Thus, load balancing improves cluster resource utilization; atomic components reduce code redundancy; and transaction logs enable full-link tracking, allowing financial complaint scenarios to locate problem areas within seconds.

[0070] For step S203, as shown in Figure 6 the parameter adaptation of the call request to the target business system through the configuration mapping module, including:

[0071] S601, extract the field mapping template matched with the target business system from the protocol conversion rule library based on the standard API protocol format generated after protocol conversion;

[0072] S602, perform structured conversion according to the parameter adaptation rules in the field mapping template, specifically including: for nested parameters containing tree structure, use JSONPath expression for recursive parsing and reconstruction; for numerical parameters that need unit conversion, call the preset measurement converter for real-time conversion;

[0073] S603, perform concurrent queue scheduling and fuse detection on the converted call request through the traffic control module, and select the optimal business system instance through the adaptive routing algorithm;

[0074] S604, when detecting that the call is timed out or failed, automatically trigger the retry mechanism based on the exponential backoff strategy to distribute the request to the standby instance.

[0075] In this embodiment, steps S601-S603 construct the parameter intelligent mapping and self-healing system of the second type of interface, and the core technology contributions include four layers of design.

[0076] Firstly, the first layer design of the configuration conversion of the field mapping template is realized. Specifically, the field mapping template (YAML / JSON format) of the target business system is loaded from the protocol conversion rule library, and structured conversion is performed: nested parameter processing: recursively extract data using JSONPath expression ($.items[*].productId) for tree structure (such as order detail list), and reconstruct it into the required XML level of the target system; real-time conversion of measurement unit: call the preset converter to process numerical parameters (such as converting "kilometers" to "miles"), and support custom conversion formula (target value = source value × coefficient + offset).

[0077] Secondly, the second layer design of traffic shaping and fuse protection is realized. Specifically, the converted request can enter the traffic control module for concurrent queue scheduling and fuse detection; concurrent queue scheduling: based on the token bucket algorithm to limit the request quantity per second (such as 1000 QPS), and the over-limit request enters the priority queue to wait; fuse detection mechanism: when the error rate of the target system exceeds the threshold (such as 10%) or the average delay exceeds the upper limit (such as 1 second), the fuse is automatically triggered to interrupt the request, avoiding cascading failures.

[0078] Secondly, the third layer design of dynamic optimization of adaptive routing is realized. Specifically, the routing engine can calculate the optimal path according to real-time topology data (network delay, instance load, error rate); specifically, it can predict the instance health degree based on the improved EWMA (exponential weighted moving average) algorithm; it can also select the instance in the same availability zone, and enable cross-region request only when the network quality meets the standard.

[0079] Finally, the fourth layer design of the exponential backoff retry fault self-healing is implemented. Specifically, when the call fails, the system will start a retry sequence: the delay of the first retry is set to a base value (for example, 2 seconds), and the delay time of subsequent retries increases exponentially (such as 4 seconds, 8 seconds, etc.). At the same time, the retry request will be automatically distributed to the standby instance, and the maximum number of retries is limited to prevent the occurrence of an infinite loop.

[0080] S204, real-time collection of running indicators of all API interface calls, generation of health degree report by monitoring center, and return of processing results in a unified data format.

[0081] For step S204, as shown in Figure 7 , the specific steps include:

[0082] S701, real-time collection of running indicators of API interface calls through probes implanted in protocol parsing engines, product capability engines, and configuration mapping modules; the running indicators include time delay, success rate, abnormal stack, and resource consumption indicators;

[0083] S702, construction of a dynamic baseline model in a time series database based on the collected indicator data by a monitoring center, generation of a health degree alarm containing service topology links and abnormal root causes when the indicator data deviates from a preset baseline threshold;

[0084] S703, encapsulation of the final processing results into a three-layer JSON structure, wherein the three-layer JSON structure includes an outer layer containing a status code and a protocol version identifier, a middle layer containing encrypted business response data, and an inner layer embedding a tracking ID associated with a distributed transaction log.

[0085] In this embodiment, steps S701-703 provide a monitoring system; the monitoring system design is the closed-loop guarantee of the present application. The running indicators collected by the probes focus on the transaction per second (TPS) and fraud interception rate in the financial scenario, and the emergency call connection rate in the medical scenario. The dynamic baseline model establishes the normal fluctuation range of the indicators through machine learning: for example, the time delay baseline of the bank during the lunch peak period is 300 ms, and an alarm is triggered when it exceeds 500 ms. The three-layer JSON response structure takes into account the security and traceability requirements: the outer layer status code identifies the financial transaction result (such as "code:2001" indicating fraud interception); the middle layer encrypts the patient diagnosis data; and the inner layer tracking ID is associated with the distributed log, which can trace the complete session flow in medical disputes. The technical effect is that the dynamic baseline improves the system anomaly detection speed by 90%; the three-layer response structure meets the GDPR / CCPA data compliance requirements; and the health degree report reduces the financial system operation and maintenance manpower by 35%.

[0086] It can be seen that in the above scheme, the call center unified API implementation application for financial and medical scenarios builds the core framework of the call center unified API. The core is to divide the API interface into a "first type of interface" developed by the product itself and a "second type of interface" customized by the business system, and to realize intelligent conversion of heterogeneous protocols through a protocol analysis engine, thereby realizing interface standardization of the call center system. Through the improvement of interface standardization, the following three aspects are optimized: first, reducing the integration development amount through protocol unification; second, improving request processing efficiency based on a dynamic routing mechanism of the interface type; and third, providing quantitative basis for system health through unified monitoring indicators such as latency and abnormal stack.

[0087] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution. The execution order of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0088] In an embodiment, a call center unified API implementation device is provided, which corresponds to the call center unified API implementation method in the above embodiment. As shown in the figure, the call center unified API implementation device includes an interface division unit 801, a protocol conversion unit 802, a routing execution unit 803, and a monitoring unit 804. The detailed description of each functional module is as follows: Figure 8

[0089] The interface division unit 801 is configured to divide the type of the API interface into a first type of interface based on the product's own capability development and a second type of interface dependent on the business system customization development.

[0090] The protocol conversion unit 802 is configured to receive a call request initiated by a heterogeneous business system through a protocol analysis engine, extract the protocol feature identifier in the call request to obtain a heterogeneous protocol, uniformly convert the heterogeneous protocol into a standard API protocol format according to a preset protocol conversion rule library, and parse the type of the API interface in the conversion process.

[0091] The routing execution unit 803 is configured to perform differentiated routing according to the type of the API interface, including: if the API interface is the first type of interface, routing the call request to the product capability engine to perform basic communication or value-added service logic; and if the API interface is the second type of interface, adapting the parameters of the call request to the target business system through a configuration mapping module.

[0092] The monitoring unit 804 is configured to collect running indicators of all API interface calls in real time, generate a health report through a monitoring center, and return the processing result in a unified data format.

[0093] In an embodiment, the first type of interface in the interface division unit 801 specifically includes:​

[0094] a telephone platform basic capability interface, the telephone platform basic capability interface comprising: a call control interface, a media stream transmission and session state management interface;

[0095] a telephone platform value-added service capability interface, the telephone platform value-added service capability interface comprising: a number shield risk control interface, a privacy number dynamic binding interface and a voice synthesis engine interface.

[0096] In an embodiment, the construction process of the preset protocol conversion rule library in the protocol conversion unit 802 comprises:

[0097] collecting historical heterogeneous protocol samples, extracting protocol header fields, payload structures and encryption method features;

[0098] establishing a field mapping relationship and a data type conversion rule of the protocol features and the standard API protocol;

[0099] structured extraction of unstructured request data is realized through a regular expression engine.

[0100] In an embodiment, the protocol conversion unit 802 is specifically configured to:

[0101] unstructured data of the heterogeneous protocol is converted into a key-value pair structure through a regular expression engine;

[0102] the heterogeneous parameter names of the heterogeneous protocol are standardized and renamed according to the field mapping relationship table;

[0103] the key-value pair structure and the heterogeneous parameter names are uniformly formatted according to the data type conversion rule, and a standard protocol conforming to the standard API protocol format is generated.

[0104] In an embodiment, the routing execution unit 803 is specifically configured to:

[0105] when the call request is identified as the first type of interface, the target node in the cluster of the product capability engine is distributed through a dynamic load balancer;

[0106] a pre-packaged atomic capability component is called by the product capability engine according to the interface type; specifically, when the logic of basic communication is executed, real-time signaling interaction is controlled and media stream is routed; when the logic of value-added service is executed, a multi-level risk control verification engine or a voice synthesis engine is triggered through an asynchronous message queue;

[0107] During the execution process, real-time session state data is collected and written into a distributed transaction log, and an asynchronous execution result is pushed to a business system through a callback gateway.

[0108] In an embodiment, the routing execution unit 803 is specifically further configured to:

[0109] Based on the standard API protocol format generated after protocol conversion, the field mapping template matched with the target business system is extracted from the protocol conversion rule library;

[0110] According to the parameter adaptation rule in the field mapping template, the structured conversion is performed, specifically including: for the nested parameters containing tree structure, the JSONPath expression is used for recursive parsing and reconstruction; for the numerical parameters needing unit conversion, the preset measurement converter is called for real-time conversion;

[0111] The converted calling request is subjected to concurrent queue scheduling and fuse detection through the traffic control module, and the optimal business system instance is selected through the adaptive routing algorithm;

[0112] When the calling timeout or failure is detected, the retry mechanism based on the exponential backoff strategy is triggered to distribute the request to the standby instance.

[0113] In an embodiment, the monitoring unit 804 is specifically configured to:

[0114] Through the probes implanted in the protocol analysis engine, the product capability engine and the configuration mapping module, the running indicators of the API interface calling are collected in real time, and the running indicators include the time delay, the success rate, the abnormal stack and the resource consumption indicators;

[0115] Through the monitoring center, a dynamic baseline model is constructed in the time series database based on the collected indicator data, and when the indicator data deviates from the preset baseline threshold, a health degree alarm including the service topology link and the abnormal root cause is generated;

[0116] The final processing result is packaged into a three-layer JSON structure, wherein the three-layer JSON structure includes an outer layer including a status code and a protocol version identifier, a middle layer including encrypted business response data, and an inner layer embedding a tracking ID of an associated distributed transaction log.

[0117] The specific limitations of the call center unified API implementation device can be referred to the limitations of the call center unified API implementation method in the above, which will not be repeated here. Each module in the call center unified API implementation device can be realized by software, hardware and their combinations. The above modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to call and execute the operations corresponding to each module by the processor.

[0118] In one embodiment, a computer device is provided, which can be a server, and its internal structure diagram can be as shown in Figure 9As shown in the figure. The computer device includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media, internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external client through the network connection. The computer program is executed by the processor to implement the functions or steps of the server side of the call center unified API implementation method.

[0119] In one embodiment, a computer device is provided, which can be a client, and its internal structure diagram can be as shown in the figure. Figure 10 As shown in the figure. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile storage media, internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external server through the network connection. The computer program is executed by the processor to implement the functions or steps of the client side of the call center unified API implementation method.

[0120] In one embodiment, a computer device is provided, including a memory, a processor and a computer program stored on the memory and executable on the processor, and the processor executes the computer program to implement the following steps:

[0121] The type of API interface is divided into a first type of interface developed based on the product's own capabilities and a second type of interface developed by relying on business system customization;

[0122] The protocol analysis engine receives the call request initiated by the heterogeneous business system, extracts the protocol feature identifier in the call request to obtain the heterogeneous protocol, uniformly converts the heterogeneous protocol into a standard API protocol format according to the preset protocol conversion rule library, and parses the type of API interface in the conversion process;

[0123] According to the type of API interface, differential routing is performed; including: if the API interface is the first type of interface, routing the call request to the product capability engine to execute basic communication or value-added service logic; if the API interface is the second type of interface, the parameter of the call request is adapted to the target business system through the configuration mapping module;

[0124] Real-time collection of all API interface call operation indexes, generation of health degree reports by the monitoring center, and return of processing results in a unified data format.

[0125] In one embodiment, a computer-readable storage medium is provided, and the computer program is stored on the computer-readable storage medium. The computer program is executed by a processor to implement the following steps:

[0126] The types of API interfaces are divided into a first type of interface developed based on product capabilities and a second type of interface developed based on business systems;

[0127] The protocol analysis engine receives a call request initiated by a heterogeneous business system, extracts protocol feature identifiers in the call request to obtain a heterogeneous protocol, uniformly converts the heterogeneous protocol into a standard API protocol format according to a preset protocol conversion rule library, and parses the type of the API interface in the conversion process;

[0128] Differential routing is performed according to the type of the API interface, including: if the API interface is the first type of interface, routing the call request to the product capability engine to perform basic communication or value-added service logic; and if the API interface is the second type of interface, adapting parameters of the call request to a target business system through a configuration mapping module;

[0129] Real-time collection of all API interface call operation indexes, generation of health degree reports by the monitoring center, and return of processing results in a unified data format.

[0130] It should be noted that the functions or steps that the computer-readable storage medium or the computer device can implement correspond to the related descriptions of the server side and the client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0131] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to memory, storage, database or other medium used in the embodiments provided by the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0132] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of functional units and modules is exemplified. In actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the above-described functions.

[0133] The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, but not to limit it. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features. Such modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for implementing a unified API for call centers, characterized in that, include: API interfaces are categorized into two types: the first type, which is developed based on the product's own capabilities, and the second type, which is developed based on custom business systems. The protocol parsing engine receives call requests initiated by heterogeneous business systems, extracts protocol feature identifiers from the call requests to obtain heterogeneous protocols, and converts the heterogeneous protocols into standard API protocol formats according to a preset protocol conversion rule base, and parses out the type of API interface during the conversion process. Differentiated routing is performed based on the type of the API interface; including: if the API interface is a first type interface, the call request is routed to the product capability engine to execute basic communication or value-added service logic; if the API interface is a second type interface, the parameters of the call request are adapted to the target business system through the configuration mapping module; The system collects operational metrics from all API calls in real time, generates health reports through the monitoring center, and returns the processing results in a unified data format.

2. The call center unified API implementation method according to claim 1, characterized in that: The first type of interface includes basic capabilities interfaces for the telephone platform and value-added service capabilities interfaces for the telephone platform; The basic capability interfaces of the telephone platform include: call control interface, media stream transmission and session state management interface; The value-added service capabilities interfaces of the telephone platform include: number shield risk control interface, privacy number dynamic binding interface, and voice synthesis engine interface.

3. The call center unified API implementation method according to claim 1, characterized in that, The construction process of the preset protocol conversion rule base includes: Collect historical heterogeneous protocol samples and extract features of protocol header fields, payload structure, and encryption methods; Establish the mapping relationship between protocol features and field rules of standard API protocols, as well as data type conversion rules; Structured extraction of unstructured request data is achieved through a regular expression engine.

4. The call center unified API implementation method according to claim 3, characterized in that, The step of uniformly converting the heterogeneous protocols into a standard API protocol format according to a preset protocol conversion rule base includes: The unstructured data of the heterogeneous protocol is converted into a key-value pair structure using a regular expression engine; The heterogeneous parameter names of the heterogeneous protocol are standardized and renamed according to the field mapping relationship table; The key-value pair structure and heterogeneous parameter names are standardized according to data type conversion rules to generate a standard protocol that conforms to the standard API protocol format.

5. The call center unified API implementation method according to claim 1, characterized in that, If the API interface is a first-type interface, the step of routing the call request to the product capability engine to execute basic communication or value-added service logic includes: When the call request is identified as a first-type interface, it is distributed to the target node in the cluster of the product capability engine through a dynamic load balancer; The product capability engine invokes pre-packaged atomic capability components based on the interface type; specifically, when executing the basic communication logic, it controls real-time signaling interaction and routes media streams; when executing the value-added service logic, it triggers a multi-level risk control verification engine or a speech synthesis engine through an asynchronous message queue. During execution, session state data is collected in real time and written to the distributed transaction log, and the asynchronous execution results are pushed to the business system through the callback gateway.

6. The call center unified API implementation method according to claim 1, characterized in that, If the API interface is a second type of interface, the step of adapting the parameters of the call request to the target business system through the configuration mapping module includes: Based on the standard API protocol format generated after protocol conversion, field mapping templates that match the target business system are extracted from the protocol conversion rule base; The structured transformation is performed according to the parameter adaptation rules in the field mapping template, specifically including: recursively parsing and reconstructing nested parameters containing tree structures using JSONPath expressions; and calling a preset metering converter for real-time conversion of numerical parameters that require unit conversion. The transformed call request is processed by the flow control module for concurrent queue scheduling and circuit breaker detection, and the optimal business system instance is selected through an adaptive routing algorithm. When a call times out or fails, a retry mechanism based on an exponential backoff strategy is automatically triggered to distribute the request to a standby instance.

7. The call center unified API implementation method according to claim 1, characterized in that, The steps of collecting operational metrics from all API interface calls in real time, generating health reports through the monitoring center, and returning the processing results in a unified data format include: By embedding probes in the protocol parsing engine, product capability engine, and configuration mapping module, the operation metrics of API interface calls are collected in real time. These operation metrics include latency, success rate, exception stack, and resource consumption metrics. The monitoring center constructs a dynamic baseline model in the time series database based on the collected indicator data. When the indicator data deviates from the preset baseline threshold, a health alarm containing service topology links and abnormal root causes is generated. The final processing result is encapsulated into a three-layer JSON structure, which includes an outer layer containing status codes and protocol version identifiers, a middle layer containing encrypted business response data, and an inner layer embedding a tracking ID of the associated distributed transaction log.

8. A unified API implementation device for call centers, characterized in that, include: The interface partitioning unit is used to classify API interfaces into two types: the first type of interfaces developed based on the product's own capabilities and the second type of interfaces developed based on custom business systems. The protocol conversion unit is used to receive call requests initiated by heterogeneous business systems through the protocol parsing engine, extract the protocol feature identifiers in the call requests to obtain heterogeneous protocols, convert the heterogeneous protocols into standard API protocol formats according to the preset protocol conversion rule base, and parse out the type of API interface during the conversion process. The routing execution unit is used to perform differentiated routing based on the type of the API interface; including: if the API interface is a first type interface, routing the call request to the product capability engine to execute basic communication or value-added service logic; if the API interface is a second type interface, adapting the parameters of the call request to the target business system through the configuration mapping module; The monitoring unit is used to collect operational metrics of all API interface calls in real time, generate health reports through the monitoring center, and return the processing results in a unified data format.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the call center unified API implementation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the call center unified API implementation method as described in any one of claims 1 to 7.

Images