Method for monitoring whether cross-service system super-long asynchronous flow processing runs normally or not

Abstract

The invention belongs to the technical field of business process management and monitoring, and discloses a method for monitoring whether cross-business system super-long asynchronous process processing runs normally or not, and the method comprises the following specific steps: S1, business lock data is inserted; S2, a main business system assembles information and calls an outbound interface; s4, the operator system initiates a real call operation; S5, information is pushed back after the call is ended; S6, the robot call-out platform system arranges and pushes back the information; S7, a main service system performs subsequent processing; and no abnormal processing exists. According to the method, monitoring is carried out aiming at the function that the process is complex and long and has asynchronous processing, and accurate monitoring can be carried out when the process node abnormity exists in the whole process. The problem that other systems are abnormal and cannot be monitored is solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of business process management and monitoring, and specifically is a method for monitoring whether super-long asynchronous process processing across business systems runs normally. Background Art

[0002] The voice processing technology in the current AI industry is developing rapidly, especially in the field of robot phone calls, the technology is relatively mature. However, there are still some challenges and problems in the entire process of robot calls. The process nodes involve multiple links such as specifying clues, selecting speech techniques, determining the small number used for outbound calls, selecting the operator to call, and actually calling. During the actual dialing process, the business system often cannot synchronously obtain the details of the call, such as the call bill information, ASR (automatic speech recognition) information, and the robot's AI judgment information. This information usually needs to be received through the asynchronous callback interface after the actual call is completed.

[0003] After the business system initiates a robot call, if there is a problem with the subsequent processing system or operator's call, the business system often cannot proactively perceive it. The current common processing method is to rely on operators to log in to the system and regularly check the business data of the robot's outbound calls through the statistical management function to find out whether there are any abnormalities. However, this method has obvious limitations, such as over-reliance on regular checks by operators, which is easily affected by human factors, resulting in the inability to guarantee the timeliness and accuracy of abnormality discovery. At the same time, if you keep waiting for other system personnel to feedback problems instead of proactively discovering problems, you are likely to miss the best window for solving the problem, increasing the difficulty and complexity of problem solving.

[0004] More importantly, this passive way of dealing with problems can neither solve the problems in a timely manner nor prevent the problems from occurring fundamentally. The business data management of robot outbound calls should be an active, intelligent and comprehensive process. However, since different business processes require different statistical data, it is necessary to customize a special monitoring plan for each business process, which undoubtedly increases the workload and complexity. For some more complex business processes, the corresponding data dimensions are also particularly complex, and the amount of data that needs to be counted and analyzed is very large, which brings great challenges to data processing and analysis.

[0005] In addition, frequent and scheduled queries of business data, especially large amounts of data, will have a certain impact on the performance of the business database. Over time, this may cause the performance of the business database to degrade or even fail. Therefore, how to effectively manage the business data of robot outbound calls and achieve active, intelligent, and comprehensive monitoring is an important issue facing the current AI industry in the field of voice processing. Summary of the invention

[0006] The purpose of the present invention is to provide a monitoring method for whether super-long asynchronous process processing across business systems is running normally, so as to solve the problems raised in the above-mentioned background technology.

[0007] In order to achieve the above object, the present invention provides the following technical solution: a monitoring method for whether the cross-business system super-long asynchronous process processing is running normally, and the specific steps of the monitoring method include:

[0008] S1, inserting business lock data: before executing the robot outbound call operation, insert a piece of business lock data and record the current time as the start lock time;

[0009] S2, the main business system assembles information and calls the outbound call interface: the main business system assembles the basic information required for the outbound call according to business needs, and calls the outbound call interface of the robot outbound call platform system; then, the main system waits for the callback information after the outbound call ends;

[0010] S3, the robot outbound call platform system obtains the script and calls the operator interface: The robot outbound call platform system obtains the clear script based on the information provided by the upstream, and integrates it into the information required by the operator system; then, it calls the outbound call interface provided by the operator system;

[0011] S4, the operator system initiates a real phone call: The operator system initiates a real phone call based on the information transmitted by the upstream. During the process, the system continuously obtains detailed recording information and communicates with the user through the robot AI until the call ends.

[0012] S5, information push back after the call ends: After the call ends, the operator system integrates the information during the call and calls the interface provided by the robot outbound call platform system to push the relevant information back to the robot outbound call platform system;

[0013] S6, the robot outbound call platform system organizes and pushes back information: The robot outbound call platform system organizes and splits the call information, including call list information, intention information, and ASR information, and pushes this information back to the main business system through the callback interface provided by the main business system;

[0014] S7, subsequent processing of the main business system: The main business system receives relevant information through the interface and completes subsequent processing related to its own business;

[0015] S8, delete the business lock data: delete the business lock data inserted in S1, indicating that the outbound call operation has been completed;

[0016] S9, start a scheduled scheduling task: start a scheduled scheduling task, which is triggered every 1 minute to monitor the execution status of the outbound call operation;

[0017] S10, check the business lock data: query the business lock data through the scheduling task to see whether there is a situation of "data start lock time < current time - 5 minutes"; this means checking whether there is an outbound call operation that has been executed for 5 minutes but has not been completed;

[0018] S11, exception notification: If the corresponding data exists, the relevant data information will be proactively notified to the mobile phone or DingTalk of the relevant technical person in charge through the notification system, so that the technical staff can intervene to handle the exception as soon as possible and wait for the next scheduling execution;

[0019] S12, no exception processing: If there is no corresponding data, skip it directly and wait for the next scheduling execution.

[0020] Preferably, in step S1, the service lock data also includes a service type identifier, a user ID and an outbound call task ID, so as to more accurately identify and process different outbound call tasks in subsequent steps.

[0021] Preferably, in step S2, the information assembled by the main business system also includes user preference settings, and the robot outbound call platform system adjusts the outbound call strategy according to the user preference settings, including adjusting the voice speed and selecting specific speech techniques.

[0022] Preferably, in step S4, the actual calling operation initiated by the operator system also includes real-time monitoring of call quality. When it is detected that the call quality is lower than a preset threshold, the call is automatically redialed or transferred to manual service.

[0023] Preferably, in step S5, the call information integrated by the operator system also includes metadata of the call recording to facilitate subsequent analysis and quality monitoring.

[0024] Preferably, in step S6, the information collated and pushed back by the robot outbound call platform system also includes keyword analysis of user feedback, so that the main business system can adjust the business strategy according to user feedback.

[0025] Preferably, in step S9, the timed scheduling task is also configured with a dynamic adjustment function to automatically adjust the trigger interval according to the average completion time of historical outbound call operations and the current system load.

[0026] Preferably, in step S10, in addition to checking whether there is an outbound call operation timeout, it is also checked whether there is an abnormal state caused by other reasons in the service lock data, including outbound call failure and unresponsive callback interface, and corresponding exception handling measures are taken.

[0027] Preferably, in step S11, the notification system also has an automatic upgrade notification mechanism, and when the same outbound call task triggers abnormal notifications multiple times and is not processed, the notification level is automatically upgraded.

[0028] Preferably, the method also includes a feedback optimization link, which collects and analyzes the cause of the exception, the processing process and the result after each exception processing is completed, so as to optimize the subsequent outbound call operation process and monitoring mechanism.

[0029] The beneficial effects of the present invention are as follows:

[0030] The present invention is suitable for scenarios with asynchronous callback processing, complex business processes, and multiple business systems that require a certain processing cycle. It realizes monitoring operations that are highly proactive, time-effective, non-intrusive, and do not affect business performance. The operations of inserting and deleting business lock data are independent of business operations, ensuring that normal business will not be interfered with and facilitating the access of similar functions. In the S8 operation, the amount of data in the business lock table is kept moderate by continuously deleting data, thereby ensuring subsequent query performance. The solution uses a scheduled scheduling task to check the business lock table data instead of the business data table, which enhances versatility, avoids repeated development of the check data logic, and does not affect the business data query performance. The core point is to monitor complex and long processes and asynchronous processing functions to ensure that the process nodes can be accurately monitored when they are abnormal, solving the problem that other system abnormalities cannot be monitored. In addition, the solution also provides a communication group for feedback on multiple business systems and merchants. When the business system monitors a problem, it will actively synchronize the problem to the communication group, and encourage merchants to feedback the problem. After receiving the feedback, the technicians will investigate the cause of the abnormal data. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is a schematic diagram of the business lock table structure of the present invention;

[0032] Figure 2 This is a schematic diagram of the outbound call process of the robot of the present invention;

[0033] Figure 3 This is a schematic diagram of the service lock data monitoring notification process of the present invention. DETAILED DESCRIPTION

[0034] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0035] like Figures 1 to 3 As shown in the figure, a monitoring method for whether the cross-business system super-long asynchronous process processing is running normally is provided. The specific steps of the monitoring method include:

[0036] S1, business lock data insertion: Before executing the robot outbound call operation, insert a business lock data and record the current time as the start lock time; this helps monitor the duration of the outbound call operation and prevent repeated execution.

[0037] S2, the main business system assembles information and calls the outbound call interface: the main business system assembles the basic information required for the outbound call according to business needs, and calls the outbound call interface of the robot outbound call platform system; then, the main system waits for the callback information after the outbound call ends;

[0038] S3, the robot outbound call platform system obtains the script and calls the operator interface: The robot outbound call platform system obtains the clear script based on the information provided by the upstream, and integrates it into the information required by the operator system; then, it calls the outbound call interface provided by the operator system;

[0039] S4, the operator system initiates a real phone call: The operator system initiates a real phone call based on the information transmitted by the upstream. During the process, the system continuously obtains detailed recording information and communicates with the user through the robot AI until the call ends.

[0040] S5, information push back after the call ends: After the call ends, the operator system integrates the information during the call and calls the interface provided by the robot outbound call platform system to push the relevant information back to the robot outbound call platform system;

[0041] S6, the robot outbound call platform system organizes and pushes back information: The robot outbound call platform system organizes and splits the call information, including call list information, intention information, and ASR information, and pushes this information back to the main business system through the callback interface provided by the main business system;

[0042] S7, subsequent processing of the main business system: The main business system receives relevant information through the interface and completes subsequent processing related to its own business;

[0043] S8, delete the business lock data: delete the business lock data inserted in S1, indicating that the outbound call operation has been completed;

[0044] S9, start a scheduled scheduling task: start a scheduled scheduling task, which is triggered every 1 minute to monitor the execution status of the outbound call operation;

[0045] S10, check the business lock data: query the business lock data through the scheduling task to see whether there is a situation of "data start lock time < current time - 5 minutes"; this means checking whether there is an outbound call operation that has been executed for 5 minutes but has not been completed;

[0046] S11, exception notification: If the corresponding data exists, the relevant data information will be proactively notified to the mobile phone or DingTalk of the relevant technical person in charge through the notification system, so that the technical staff can intervene to handle the exception as soon as possible and wait for the next scheduling execution;

[0047] S12, no exception processing: If there is no corresponding data, skip it directly and wait for the next scheduling execution.

[0048] Wherein, in step S1, the service lock data also includes a service type identifier, a user ID and an outbound call task ID, so as to more accurately identify and process different outbound call tasks in subsequent steps.

[0049] The business lock data not only includes the current time as the start lock time, but also includes the business type identifier (such as marketing, customer service, survey, etc.), user ID (used to uniquely identify the user being called), and outbound task ID (used to identify a specific outbound task or batch). This information plays a key role in the subsequent steps, helping the system to more accurately identify and process different outbound tasks and avoid task confusion or duplication.

[0050] Among them, in step S2, the information assembled by the main business system also includes user preference settings, and the robot outbound call platform system adjusts the outbound call strategy according to the user preference settings, including adjusting the voice speed and selecting specific words.

[0051] The main business system not only assembles the basic information required for outbound calls (such as user name, phone number, etc.), but also adjusts the outbound call strategy based on user preferences (such as language preference, call time preference, whether to accept marketing calls, etc.). After receiving this information, the robot outbound call platform system can more intelligently choose the outbound call timing, words and voice speed, thereby improving outbound call efficiency and user satisfaction.

[0052] Among them, in step S4, the actual calling operation initiated by the operator system also includes real-time monitoring of the call quality. When it is detected that the call quality is lower than a preset threshold, it automatically redials or transfers to manual service.

[0053] The operator system not only initiates the actual call operation, but also monitors the call quality in real time. This includes detecting parameters such as noise level, signal strength, and voice clarity during the call, and judging whether the call quality meets the standard based on the preset threshold. When the call quality is detected to be below the threshold, the system can automatically take remedial measures, such as redialing the call, transferring to manual service, or recording abnormal information for subsequent analysis.

[0054] Among them, in step S5, the call information integrated by the operator system also includes metadata of the call recording, such as recording duration, recording quality score, etc., to facilitate subsequent analysis and quality monitoring.

[0055] The call information integrated by the operator system includes not only the call recording itself, but also the metadata of the call recording. These metadata include the recording duration, the start and end time of the recording, the recording quality score (such as clarity, noise level, etc.), and possible speech recognition results (such as ASR text). This information is crucial for subsequent analysis and quality monitoring, helping to identify potential problems in calls and optimize outbound call strategies.

[0056] Among them, in step S6, the information sorted and pushed back by the robot outbound call platform system also includes keyword analysis of user feedback, so that the main business system can adjust the business strategy according to user feedback.

[0057] The robot outbound call platform system not only organizes and pushes back call information, intent information and ASR information, but also uses natural language processing technology to perform keyword analysis on user feedback. This helps the main business system to have a deeper understanding of user needs and market feedback, thereby adjusting business strategies and optimizing products or services.

[0058] Among them, in step S9, the timed scheduling task is also configured with a dynamic adjustment function, which automatically adjusts the trigger interval according to the average completion time of historical outbound call operations and the current system load.

[0059] Scheduled tasks are not only triggered at fixed time intervals (such as every 1 minute), but also have dynamic adjustment functions. The system automatically adjusts the trigger interval based on the average completion time of historical outbound call operations and the current system load. For example, during peak hours or when the system load is heavy, the trigger interval can be appropriately increased to reduce the occupation of system resources; during low hours or when the system load is light, the trigger interval can be shortened to improve the real-time monitoring.

[0060] Among them, in step S10, in addition to checking whether there is an outbound call operation timeout, it is also checked whether there is an abnormal state caused by other reasons in the service lock data, including outbound call failure and unresponsive callback interface, and corresponding exception handling measures are taken.

[0061] In addition to checking whether there is an outbound call timeout, the system also checks whether there are abnormal conditions caused by other reasons in the business lock data. These abnormal conditions include but are not limited to outbound call failures (such as invalid phone numbers, operator restrictions, etc.), no response or response timeout from the callback interface, missing or damaged call recordings, etc. When these abnormal conditions are detected, the system can take corresponding abnormal handling measures, such as recording abnormal information, retrying the outbound call operation, or notifying relevant personnel to handle it.

[0062] Among them, in step S11, the notification system also has an automatic upgrade notification mechanism. When the same outbound call task triggers abnormal notifications multiple times and is not processed, the notification level is automatically upgraded, such as from SMS notification to phone notification or video conference notification.

[0063] The notification system not only has basic notification functions (such as SMS, email notification, etc.), but also has an automatic upgrade notification mechanism. When the same outbound call task triggers abnormal notifications multiple times and is not handled in a timely manner, the system will automatically upgrade the notification level. For example, upgrade from SMS notification to phone notification or video conference notification to ensure that relevant personnel can receive and handle abnormal information as soon as possible. In addition, the system can also record the sending time and receipt of each notification for subsequent analysis and improvement of notification strategies.

[0064] Among them, the method also includes a feedback optimization link. After each exception handling is completed, the exception cause, handling process and results are collected and analyzed to optimize the subsequent outbound call operation process and monitoring mechanism.

[0065] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0066] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A monitoring method for whether the super-long asynchronous process processing across business systems is running normally, characterized by: The specific steps of the monitoring method include: S1, inserting business lock data: before executing the robot outbound call operation, insert a piece of business lock data and record the current time as the start lock time; S2, the main business system assembles information and calls the outbound call interface: the main business system assembles the basic information required for the outbound call according to business needs, and calls the outbound call interface of the robot outbound call platform system; then, the main system waits for the callback information after the outbound call ends; S3, the robot outbound call platform system obtains the script and calls the operator interface: The robot outbound call platform system obtains the clear script based on the information provided by the upstream, and integrates it into the information required by the operator system; then, it calls the outbound call interface provided by the operator system; S4, the operator system initiates a real phone call: The operator system initiates a real phone call based on the information transmitted by the upstream. During the process, the system continuously obtains detailed recording information and communicates with the user through the robot AI until the call ends. S5, information push back after the call ends: After the call ends, the operator system integrates the information during the call and calls the interface provided by the robot outbound call platform system to push the relevant information back to the robot outbound call platform system; S6, the robot outbound call platform system organizes and pushes back information: The robot outbound call platform system organizes and splits the call information, including call list information, intention information, and ASR information, and pushes this information back to the main business system through the callback interface provided by the main business system; S7, subsequent processing of the main business system: The main business system receives relevant information through the interface and completes subsequent processing related to its own business; S8, delete the business lock data: delete the business lock data inserted in S1, indicating that the outbound call operation has been completed; S9, start a scheduled scheduling task: start a scheduled scheduling task, which is triggered every 1 minute to monitor the execution status of the outbound call operation; S10, check the business lock data: query the business lock data through the scheduling task to see whether there is a situation of "data start lock time < current time - 5 minutes"; this means checking whether there is an outbound call operation that has been executed for 5 minutes but has not been completed; S11, exception notification: If the corresponding data exists, the relevant data information will be proactively notified to the mobile phone or DingTalk of the relevant technical person in charge through the notification system, so that the technical staff can intervene to handle the exception as soon as possible and wait for the next scheduling execution; S12, no exception processing: If there is no corresponding data, skip it directly and wait for the next scheduling execution.

2. The method for monitoring whether the cross-business system super-long asynchronous process processing is running normally according to claim 1 is characterized in that: In step S1, the service lock data also includes a service type identifier, a user ID, and an outbound call task ID, so as to more accurately identify and process different outbound call tasks in subsequent steps.

3. The monitoring method for whether the cross-business system super-long asynchronous process processing is running normally according to claim 1 is characterized in that: In step S2, the information assembled by the main business system also includes user preference settings. The robot outbound call platform system adjusts the outbound call strategy according to the user preference settings, including adjusting the voice speed and selecting specific speech techniques.

4. The method for monitoring whether the cross-business system super-long asynchronous process processing is running normally according to claim 1 is characterized in that: In step S4, the actual calling operation initiated by the operator system also includes real-time monitoring of the call quality. When it is detected that the call quality is lower than a preset threshold, the call is automatically redialed or transferred to manual service.

5. The method for monitoring whether the cross-business system super-long asynchronous process processing is running normally according to claim 1 is characterized in that: In step S5, the call information integrated by the operator system also includes metadata of the call recording to facilitate subsequent analysis and quality monitoring.

6. The method for monitoring whether the cross-business system super-long asynchronous process processing is running normally according to claim 1 is characterized in that: In step S6, the information collated and pushed back by the robot outbound call platform system also includes keyword analysis of user feedback, so that the main business system can adjust the business strategy according to user feedback.

7. The method for monitoring whether the cross-business system super-long asynchronous process processing is running normally according to claim 1 is characterized in that: In step S9, the timed scheduling task is also configured with a dynamic adjustment function to automatically adjust the trigger interval according to the average completion time of historical outbound call operations and the current system load.

8. The method for monitoring whether the cross-business system super-long asynchronous process processing is running normally according to claim 1 is characterized in that: In step S10, in addition to checking whether there is an outbound call timeout, it is also checked whether there is an abnormal state caused by other reasons in the service lock data, including outbound call failure and unresponsive callback interface, and corresponding exception handling measures are taken.

9. The method for monitoring whether the cross-business system super-long asynchronous process processing is running normally according to claim 1, characterized in that: In step S11, the notification system also has an automatic upgrade notification mechanism. When the same outbound call task triggers abnormal notifications multiple times and is not processed, the notification level is automatically upgraded.

10. The method for monitoring whether the cross-business system super-long asynchronous process processing is running normally according to claim 1, characterized in that: The method also includes a feedback optimization link. After each exception handling is completed, the exception cause, handling process and results are collected and analyzed to optimize the subsequent outbound call operation process and monitoring mechanism.

Images