A multi-source adaptive enterprise-micro group robot message intelligent pushing method and device

Abstract

The application provides a multi-source adaptive enterprise micro group robot message intelligent pushing method and device, and relates to the technical field of computer application. The method realizes the format unification and effectiveness guarantee of different source business data through unified access and standardized preprocessing of multi-source business data, and realizes professional processing of massive real-time raw data through a distributed stream processing engine. Through the combination of multiple trigger modes and distributed lock control, reliable triggering of full-scene pushing tasks is realized, and the problem of repeated execution of tasks in a distributed cluster environment is completely solved. Through standardized content rendering and traffic control based on the token bucket algorithm, accurate adaptation of pushing content and enterprise micro robot API is realized, avoiding API ban problems in high-concurrency scenarios, and comprehensively improving the efficiency, success rate, stability and scene adaptation ability of enterprise micro group message pushing, which can meet the enterprise micro message pushing needs in multiple scenarios of the financial, Internet and other industries.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a method and apparatus for intelligent push of enterprise WeChat group robot messages with multi-source adaptation. Background Technology

[0002] With the deepening of enterprise digital transformation, WeChat Work (hereinafter referred to as WeChat Work) has become the core carrier for internal collaboration and business information flow. Especially in industries such as finance and the Internet, there is a need to push transaction data, operating reports, risk warnings, and massive amounts of real-time business data (such as real-time transaction streams, system log streams, and device data collection streams) to WeChat Work groups (hereinafter referred to as WeChat Work groups) in a timely and standardized manner to support efficient team collaboration and rapid decision-making.

[0003] Currently, existing WeChat Work push notification solutions suffer from several technical shortcomings. First, the triggering modes are relatively simple and isolated, often relying on scheduled or manual triggering, which cannot adapt to the collaborative needs of various scenarios such as high-concurrency real-time data changes (e.g., financial transaction changes), periodic reports, and temporary emergency notifications. Second, the push notification of image content does not fully consider WeChat Work's transmission limitations, and inconsistent screenshot styles and numerous compatibility issues lead to a high failure rate. Third, in a distributed environment deployed in a cluster, the lack of an effective concurrency control mechanism easily results in issues such as task duplication or execution anomalies. Fourth, the system's scalability and adaptability are weak; adding new push formats or data access sources often requires modifying the core code, and in high-concurrency scenarios, it is prone to triggering the frequency limits of the WeChat Work robot API (Application Programming Interface), leading to service blocking. Furthermore, the linkage between multi-source data (such as databases, message queues, third-party interfaces, etc.) and push content is poor, resulting in low dynamic rendering efficiency. For massive amounts of real-time data, existing solutions only perform simple direct access processing and lack professional stream processing links, resulting in data clutter, inaccurate filtering of effective data, low processing throughput, and high latency, which cannot meet the timeliness and accuracy requirements of industries such as finance for high-throughput real-time data push.

[0004] Therefore, the aforementioned technical problems urgently need to be solved. Summary of the Invention

[0005] In view of the above problems, this application is proposed to provide a multi-source adapted intelligent push method and apparatus for enterprise WeChat group robot messages that overcomes or at least partially solves the above problems. The technical solution is as follows: Firstly, a multi-source adapted intelligent push method for enterprise WeChat group robot messages is provided, the method comprising: Acquire multi-source business data, perform unified access and standardized preprocessing on the multi-source business data to obtain standardized business data; the multi-source business data includes standardized real-time data obtained by cleaning, transforming and filtering massive real-time raw data through a distributed stream processing engine. Based on standardized business data, the push task is triggered by multiple preset trigger modes, and the unique execution of the push task in the distributed cluster environment is controlled by a distributed lock component. Based on the business requirements corresponding to the push task, standardized business data is processed to render push content, resulting in push content that meets the requirements of the Enterprise Robot API format. The token bucket rate limiting algorithm is used to control the flow of calls to the Enterprise Robot API, pushing content to the target Enterprise Group through the Enterprise Robot API and providing synchronous feedback on the execution status of the push task.

[0006] In one possible implementation, multi-source business data is acquired, and the multi-source business data undergoes unified access and standardized preprocessing to obtain standardized business data, including: Access business data in a structured database via a database connection protocol, and perform format standardization processing on the business data in the structured database; Standardized real-time data is accessed through a distributed message queue consumption component, and validity filtering is performed on the standardized real-time data. The interface data of the third-party business system is accessed through the Hypertext Transfer Protocol, and the interface data of the third-party business system is processed for format standardization. All business data that has undergone format standardization and validity filtering are subjected to unified rule validation to obtain standardized business data.

[0007] In one possible implementation, the steps of cleaning, transforming, and filtering massive amounts of real-time raw data using a distributed stream processing engine to obtain standardized real-time data include: By connecting to massive real-time raw data sources through a distributed stream processing engine, massive amounts of real-time raw data can be obtained. Data cleaning is achieved by performing data filtering operations on massive amounts of real-time raw data through a distributed stream processing engine. The distributed stream processing engine performs unified conversion operations on the cleaned real-time data, including field naming, data type, and time format, to complete the format conversion. The distributed stream processing engine performs effective data extraction operations on real-time data that has undergone format conversion based on preset business rules, and completes conditional filtering. The cleaned, transformed, and filtered real-time data is standardized and pushed to the designated business topic in the distributed message queue.

[0008] In one possible implementation, the push task is triggered based on standardized business data through multiple preset trigger modes, including: The scheduled task trigger mode, based on preset period configuration rules, triggers the execution of push tasks at regular intervals; In manual trigger mode, push tasks are executed synchronously or asynchronously based on trigger commands received through a standardized interface; In real-time trigger mode, push tasks can be triggered in real time based on standardized real-time data obtained from the distributed message queue consumption component, or push tasks can be triggered at preset times after performing storage operations on the standardized real-time data.

[0009] In one possible implementation, a distributed lock component controls the unique execution of the push task in a distributed cluster environment, including: Generate a unique task identifier for each push task; Based on the unique task identifier of the push task, a corresponding distributed lock is created through the distributed lock component, and the waiting time and expiration time of the distributed lock are set. The push logic corresponding to the push task will be executed only if the push task successfully acquires the corresponding distributed lock. If the push task fails to acquire the corresponding distributed lock, the execution process of the push task will be terminated.

[0010] In one possible implementation, based on the business requirements corresponding to the push task, standardized business data is processed for push content rendering to obtain push content that conforms to the Enterprise Robot API format requirements, including: Determine the target format type of the push content based on the business requirements corresponding to the push task; When the target format type is text, standardized business data is filled into the parameter placeholders of the preset standardized text template to generate text-based push content that meets the requirements of the Enterprise Robot API format. When the target format is an image, perform full-link image adaptation processing on standardized business data to generate image-based push content that meets the API format requirements and transmission limitations of Enterprise Robot. When the target format is a mixed text and image format, the generated text-based push content and image-based push content are combined and packaged into a mixed text and image push content that meets the requirements of the Enterprise Robot API.

[0011] In one possible implementation, standardized business data undergoes end-to-end image adaptation processing to generate image-based push content that conforms to the API format requirements and transmission limitations of the Enterprise Robot, including: Standardized business data is populated into the parameter placeholders of the preset customized page template to generate the page to be rendered; Load the page to be rendered using a headless browser, perform a screenshot operation on a specified area of ​​the page to be rendered, and obtain the initial image file; According to the preset quality gradient reduction rule, the initial image file is subjected to adaptive compression until the size of the compressed image file meets the transmission limit requirements of the Enterprise Robot, thus obtaining image-based push content.

[0012] In one possible implementation, flow control is performed on the Enterprise Robot API call process based on a token bucket rate limiting algorithm, including: Based on the call frequency limit rules of the Enterprise Robot API, set the token generation rate and token cache limit of the token bucket; Before initiating an API call request to the Enterprise Robot, verify whether there are available tokens in the token bucket; The Enterprise Robot API call request will be sent only if there are available tokens in the token bucket. If no available token is found in the token bucket, terminate the sending operation of the current Enterprise Robot API call request, and wait for the token bucket to generate a new available token before re-executing the verification operation.

[0013] In one possible implementation, the execution status of the push task is synchronously fed back, including: When the push task is in synchronous trigger mode, the execution result, execution status and error information of the push task will be returned immediately after the push task is completed. When the push task is triggered asynchronously, after the push task is completed, the execution result, execution status and error information of the push task are stored in the structured database. At the same time, a unique serial number corresponding to the push task is generated, and an execution status query interface based on the unique serial number is provided.

[0014] Secondly, a multi-source adapted intelligent push device for enterprise WeChat group robot messages is provided, the device comprising: The data access and processing unit is used to acquire multi-source business data, perform unified access and standardized preprocessing on the multi-source business data, and obtain standardized business data; the multi-source business data includes standardized real-time data obtained by cleaning, transforming and filtering massive real-time raw data through a distributed stream processing engine. The task scheduling and control unit is used to trigger the execution of push tasks based on standardized business data and through multiple preset trigger modes, while controlling the unique execution of push tasks in a distributed cluster environment through a distributed lock component; The content rendering processing unit is used to render push content on standardized business data according to the business requirements corresponding to the push task, so as to obtain push content that meets the requirements of the Enterprise Robot API format. The push execution control unit is used to control the flow of calls to the Enterprise Robot API based on the token bucket rate limiting algorithm, pushes the content to the target Enterprise Group through the Enterprise Robot API, and synchronously provides feedback on the execution status of the push task.

[0015] By employing the above technical solutions, the multi-source adapted intelligent push method and apparatus for enterprise WeChat group robot messages provided in this application embodiment achieves unified format and validity assurance of business data from different sources through unified access and standardized preprocessing of multi-source business data. Simultaneously, it achieves professional processing of massive real-time raw data through a distributed stream processing engine, solving the problems of messy real-time data and low precision in effective data filtering in existing technologies. Through the combination of multiple triggering modes and distributed locking, reliable triggering of push tasks across all scenarios is achieved, completely solving the problem of repeated task execution in a distributed cluster environment. Through standardized content rendering and flow control based on the token bucket algorithm, precise adaptation between push content and enterprise WeChat robot API is achieved, avoiding API blocking issues in high-concurrency scenarios. This comprehensively improves the efficiency, success rate, stability, and scenario adaptability of enterprise WeChat group message push, meeting the enterprise WeChat message push needs of multiple scenarios in industries such as finance and the internet. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0017] Figure 1 The flowchart illustrates a multi-source adapted intelligent push method for enterprise WeChat group robot messages provided in an embodiment of this application. Figure 2 The diagram shows the structure of the multi-source adapted enterprise WeChat group robot message intelligent push device provided in the embodiment of this application. Detailed Implementation

[0018] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0019] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the term "comprising" and its variations should be interpreted as open-ended terms meaning "including but not limited to."

[0020] To address the aforementioned technical problems, this application provides a multi-source adapted intelligent message push method for WeChat group robots, such as... Figure 1 As shown, the multi-source adapted WeChat group robot message intelligent push method may include the following steps S101 to S104: Step S101: Obtain multi-source business data, perform unified access and standardized preprocessing on the multi-source business data to obtain standardized business data; wherein the multi-source business data includes standardized real-time data obtained by cleaning, transforming and filtering massive real-time raw data through a distributed stream processing engine.

[0021] In this step, the distributed stream processing engine can be the open-source Flink stream processing engine, which is an open-source framework for distributed processing of massive real-time data streams.

[0022] Massive amounts of real-time raw data can include real-time financial transaction streams, system operation log streams, and device-collected data streams, etc., and this embodiment does not impose any limitations on this.

[0023] Step S102: Based on standardized business data, the push task is triggered to execute through multiple preset trigger modes, and the unique execution of the push task in the distributed cluster environment is controlled by a distributed lock component.

[0024] Step S103: Based on the business requirements corresponding to the push task, perform push content rendering processing on the standardized business data to obtain push content that meets the requirements of the Enterprise Robot API format.

[0025] Step S104: Based on the token bucket rate limiting algorithm, the call process of the Enterprise Robot API is controlled to push the content to the target Enterprise Group through the Enterprise Robot API, and the execution status of the push task is fed back synchronously.

[0026] This embodiment achieves unified formatting and validity assurance of business data from different sources through unified access and standardized preprocessing of multi-source business data. Simultaneously, it utilizes a distributed stream processing engine to professionally process massive amounts of real-time raw data, resolving the issues of messy real-time data and low precision in filtering effective data in existing technologies. By combining multiple triggering modes with distributed locking, it achieves reliable triggering of push tasks across all scenarios, completely solving the problem of repetitive task execution in distributed cluster environments. Through standardized content rendering and token bucket algorithm-based traffic control, it achieves precise adaptation between push content and the Enterprise WeChat robot API, avoiding API blocking issues in high-concurrency scenarios. This comprehensively improves the efficiency, success rate, stability, and scenario adaptability of Enterprise WeChat group message pushes, meeting the needs of Enterprise WeChat message pushes in multiple scenarios across industries such as finance and the internet.

[0027] This application embodiment provides a possible implementation method. Step S101 above obtains multi-source service data, performs unified access and standardized preprocessing on the multi-source service data to obtain standardized service data, which may specifically include the following steps A1 to A4: Step A1: Access the business data in the structured database through the database connection protocol and perform format standardization processing on the business data in the structured database.

[0028] Specifically, you can connect to a specified database via JDBC (Java Database Connectivity), extract business data (such as transaction reports, contract data, etc.) using a preset SQL (Structured Query Language) script, and then standardize the data format, for example, unify the date to yyyy-mm-dd format.

[0029] Step A2 involves accessing standardized real-time data through the consumer component of a distributed message queue and performing validity filtering on the standardized real-time data.

[0030] Specifically, Kafka consumers can be deployed to listen to specified business topics (such as database change log topics, lightweight business operation log topics, etc.), and after receiving real-time data, filter valid data according to preset filtering rules. Kafka is a distributed message queue system.

[0031] Step A3: Access the interface data of the third-party business system via the Hypertext Transfer Protocol and perform format standardization processing on the interface data of the third-party business system.

[0032] Specifically, a standardized interface adaptation layer can be provided to obtain data from third-party business systems via HTTP / HTTPS (Hypertext Transfer Protocol / Secure) requests and complete the format conversion.

[0033] Step A4: Perform unified rule validation on all business data that has completed format standardization and validity filtering to obtain standardized business data.

[0034] This embodiment achieves full coverage access to multi-source heterogeneous business data by classifying and adapting to three core data source access methods: databases, distributed message queues, and third-party interfaces. At the same time, through classification processing and unified rule verification, it ensures the consistency and validity of the format of all accessed data. New data sources can be added without modifying the core code, which greatly improves the scalability and adaptability of the system.

[0035] This application embodiment provides a possible implementation method. The step S101 above, which cleans, transforms, and filters massive real-time raw data using a distributed stream processing engine to obtain standardized real-time data, may specifically include the following steps B1 to B5: Step B1 involves connecting to massive real-time raw data sources via a distributed stream processing engine to obtain massive amounts of real-time raw data.

[0036] Step B2 involves using a distributed stream processing engine to perform data filtering operations on massive amounts of real-time raw data, thus completing the data cleaning process. For example, filtering out dirty or empty data.

[0037] Step B3 involves using a distributed stream processing engine to perform a unified conversion operation on the cleaned real-time data, including field naming, data type, and time format, to complete the format conversion.

[0038] Step B4 involves using a distributed stream processing engine to perform effective data extraction operations on the real-time data that has undergone format conversion, based on preset business rules, to complete conditional filtering. Here, preset business rules include things like transaction amount ≥ a threshold, and data change type being "new," etc., but this embodiment does not impose restrictions on these.

[0039] Step B5 involves pushing the cleaned, transformed, and filtered real-time data as standardized real-time data to the designated business topic in the distributed message queue.

[0040] This embodiment introduces a professional distributed stream processing engine (such as Flink) to clean, transform, and filter massive amounts of real-time raw data, achieving high throughput and low latency real-time data processing. The data processing throughput is more than 10 times higher than that of the direct access method, and the effective data filtering accuracy reaches more than 99.5%, solving the problems of messy real-time data and high latency in the original solution.

[0041] This application embodiment provides a possible implementation method. In step S102 above, the execution of the push task is triggered based on standardized business data through multiple preset trigger modes, which may specifically include the following steps C1 to C3: Step C1 involves triggering the push task execution periodically based on preset period configuration rules using a scheduled task trigger mode. Specifically, scheduled tasks can be implemented using Spring Task, supporting four period configurations (such as fixed time per day, fixed date and time per month, every trading day, and one-time scheduled task). Here, Spring Task is a native scheduled task scheduling tool provided by the Spring Framework open-source framework.

[0042] Step C2 involves manually triggering the push task execution synchronously or asynchronously based on the trigger command received through the standardized interface. Specifically, a standardized RESTful (Representational State Transfer) interface can be exposed to achieve full lifecycle management of the task.

[0043] Step C3: In real-time trigger mode, based on the standardized real-time data obtained by the distributed message queue consumption component, the push task is triggered to execute in real time, or the standardized real-time data is stored and then the push task is triggered at a preset time.

[0044] This embodiment achieves full coverage of all business scenarios, such as periodic report push, temporary emergency notification push, and real-time data change notification push, through the coordinated operation of three trigger modes: timed, manual, and real-time. The push response latency can be controlled within 2 seconds. At the same time, the standardized interface enables full lifecycle management of push tasks, which greatly improves the flexibility and scenario adaptability of push tasks.

[0045] This application embodiment provides a possible implementation method in which the distributed lock component controls the unique execution of the push task in the distributed cluster environment in step S102 above, which may specifically include the following steps D1 to D4: Step D1: Generate a unique task identifier for each push task.

[0046] Step D2 involves creating a corresponding distributed lock based on the unique task identifier of the push task using a distributed lock component, and setting the waiting time and expiration time of the distributed lock. Specifically, a Redisson client can be used to generate a unique taskId for each task and create a distributed lock, setting a 5-second lock waiting time and a 30-second lock expiration time; here, Redisson is a Java-based in-memory data grid client based on the Redis open-source in-memory database.

[0047] Step D3: Only if the push task successfully acquires the corresponding distributed lock will the push logic corresponding to the push task be executed.

[0048] Step D4: If the push task fails to acquire the corresponding distributed lock, terminate the execution process of the push task.

[0049] This embodiment completely solves the problems of repeated execution and execution anomalies of push tasks in a distributed cluster deployment environment by using a distributed lock mechanism based on a unique task identifier. By adapting the lock wait time and expiration time configuration of the push task, more than 1,000 push tasks can be executed without anomalies, which greatly improves the reliability and stability of push task execution.

[0050] This application embodiment provides a possible implementation method. Step S103 above performs push content rendering processing on standardized business data according to the business requirements corresponding to the push task to obtain push content that meets the requirements of the Enterprise Robot API format. Specifically, it may include the following steps E1 to E4: Step E1: Determine the target format type of the push content based on the business requirements corresponding to the push task. The target format type can include five types: text, rich text, image, image and text combination, and template card.

[0051] Step E2: If the target format type is text, fill the standardized business data into the parameter placeholders of the preset standardized text template to generate text-based push content that meets the requirements of the Enterprise Robot API format.

[0052] Step E3: If the target format is an image, perform full-link image adaptation processing on the standardized business data to generate image-based push content that meets the API format requirements and transmission limitations of Enterprise Robot.

[0053] Step E4: If the target format type is a mixed text and image format, combine the generated text-based push content and image-based push content, and encapsulate them into a mixed text and image push content that meets the requirements of the Enterprise Robot API.

[0054] This embodiment achieves full coverage of various push formats, including text, images, and mixed text and images, through multi-format adaptation rendering. It enables rapid matching of business data and push content through template-based filling, improving content generation efficiency by more than 60%. At the same time, it performs targeted adaptation processing for different format types, ensuring that all push content conforms to the format requirements of the Enterprise Robot API, avoiding push failures caused by format incompatibility.

[0055] This application embodiment provides a possible implementation method. Step E3 above performs full-link image adaptation processing on standardized business data to generate image-based push content that conforms to the API format requirements and transmission limitations of Enterprise Robot. Specifically, it may include the following steps E3-1 to E3-3: Step E3-1: Fill the parameter placeholders of the preset customized page template with standardized business data to generate the page to be rendered.

[0056] Step E3-2: Load the page to be rendered using a headless browser, and perform a screenshot operation on a specified area of ​​the page to be rendered to obtain the initial image file. Here, a headless browser is a browser without a graphical user interface. It can be controlled and operated programmatically to automate tasks such as webpage loading, rendering, interaction, and data acquisition.

[0057] Step E3-3 involves performing adaptive compression on the initial image file according to a preset quality gradient reduction rule until the compressed image file size meets the transmission limitations of the Enterprise Robot, thus obtaining image-based push content. Specifically, the Thumbnails tool can be used to decrease the compression quality in 0.1 increments until the image size is less than or equal to 1MB. Here, Thumbnails is an image thumbnail generation and compression tool library developed based on the Java language.

[0058] Specifically, the entire process of image format rendering and adaptation: Front-end custom rendering page development: Develop fixed-style HTML (HyperText Markup Language) pages, define a unified layout using CSS (Cascading Style Sheets), and reserve parameter placeholders; support two data rendering methods: URL (Uniform Resource Locator) parameter filling and backend API call filling; Headless screenshot on the backend: Configure ChromeOptions to headless mode (headless=new), set the window size; concatenate the page URL containing business data parameters, load the page through ChromeDriver and wait for it to fully render; capture an image of a specified area (full screen by default, the target area can be located by element ID); Adaptive compression adaptation: The screenshot is compressed using the Thumbnails tool. The initial compression quality is 0.9. If the compressed image still exceeds 1MB (limited by Enterprise Microelectronics), the compression quality is decreased by 0.1 increments until the image size is ≤1MB. Image and text format rendering: Combine text content with compressed images and encapsulate them into an image and text message structure according to the Enterprise WeChat API requirements.

[0059] This embodiment adopts a full-link image processing solution of "customized rendering - headless screenshot - adaptive compression", which unifies the image style and dynamically adapts to the transmission limit of Enterprise WeChat (such as 1MB), increasing the image push success rate from 60%-70% to over 99%, and solving the compatibility problem between screenshot tools and browser versions.

[0060] This application embodiment provides a possible implementation method. Step S104 above performs flow control on the calling process of the Enterprise Robot API based on the token bucket rate limiting algorithm, which may specifically include the following steps F1 to SF4: Step F1: Based on the API call frequency limit rules of the Enterprise Robot, set the token generation rate and token cache limit for the token bucket. Specifically, the token generation rate can be set to 20 tokens / minute, and the token cache limit can be set to 10 tokens.

[0061] Step F2: Before initiating the Enterprise Robot API call request, verify whether there are available tokens in the token bucket.

[0062] Step F3: Only if there are available tokens in the token bucket will the Enterprise Robot API call request be sent.

[0063] Step F4: If there are no available tokens in the token bucket, terminate the sending operation of the current Enterprise Robot API call request, and wait for the token bucket to generate new available tokens before re-executing the verification operation.

[0064] This embodiment achieves precise traffic control for Enterprise Robot API calls through the token bucket rate limiting algorithm. By adapting to Enterprise's official call frequency limit rules to set the token generation rate and cache limit, the API blocking problem caused by exceeding the call frequency limit can be completely avoided. In high-concurrency scenarios, the stability of push is improved by more than 80%, ensuring the smooth execution of massive push tasks.

[0065] This application embodiment provides a possible implementation method, in which step S104 above synchronously feeds back the execution status of the push task, which may specifically include the following steps G1 and G2: Step G1: When the push task is in synchronous trigger mode, after the push task is completed, the execution result, execution status, and error information of the push task are returned immediately. The execution status here includes statuses such as pending, executing, successful, and failed.

[0066] Step G2: When the push task is in asynchronous trigger mode, after the push task is completed, the execution result, execution status and error information of the push task are stored in the structured database. At the same time, a unique serial number corresponding to the push task is generated, and an execution status query interface based on the unique serial number is provided.

[0067] This embodiment distinguishes between synchronous and asynchronous feedback mechanisms, enabling full-process traceability of the push status, meeting the status feedback requirements under different triggering scenarios, and facilitating subsequent acquisition of execution results and troubleshooting.

[0068] The above introduces Figure 1 The embodiments shown have various implementation methods for each stage. The following will further explain the multi-source adapted enterprise WeChat group robot message intelligent push method of this application through specific embodiments.

[0069] The overall implementation approach of this application embodiment is as follows: A multi-source adaptive intelligent push system for enterprise WeChat group robots is built based on the Java technology stack. First, the massive real-time raw data is professionally cleaned, transformed, and filtered using the Flink stream processing engine, and the standardized real-time data is pushed to a designated Kafka business topic. Then, unified access and standardized preprocessing of multi-source business data (including Kafka real-time data processed by Flink, database table data, and custom interface data) are completed. Next, a unified scheduling hub enables coordinated triggering of three modes: scheduled, manual, and Kafka real-time, and the Redisson distributed lock mechanism ensures task uniqueness in a distributed environment. Then, intelligent rendering of multiple content formats such as text and images is completed according to business requirements, with a "custom rendering - headless screenshot - adaptive compression" end-to-end processing solution designed for image formats. Finally, the enterprise WeChat robot API is called through OkHttp (an HTTP client), and API rate limiting control is implemented using the token bucket algorithm to complete message push and synchronously feedback the push status, achieving accurate, efficient, and reliable integration between business data and enterprise WeChat push throughout the entire process.

[0070] Step S1: Unified Access and Preprocessing of Multi-Source Data. A multi-source data access hub is constructed, supporting four access methods: database table data access (via JDBC connection and extraction according to preset SQL), Flink stream processing + Kafka real-time data access (Flink connects to massive real-time raw data sources, performs cleaning, transformation, and filtering before pushing to Kafka business topics, which are then listened to and received by Kafka consumers), native Kafka real-time data access (Kafka consumers listen to specified topics and filter according to rules), and custom interface data access (obtaining and converting formats via HTTP / HTTPS requests). All accessed data undergoes standardized format preprocessing to unify data formats and filtering rules.

[0071] Step S2: Multi-mode Collaborative Triggering and Task Locking. A unified task scheduling hub is built, supporting three triggering modes: scheduled task triggering based on Spring Task (including four periodic configurations), manual synchronous / asynchronous triggering via a standardized interface, and real-time triggering or scheduled triggering after storing valid data via Kafka consumer filtering. A Redisson client is used to generate a unique taskId for each task and create a distributed lock, setting a 5-second lock wait time and a 30-second lock expiration time. The task executes the push logic after acquiring the lock; otherwise, it abandons execution.

[0072] Step S3: Intelligent Rendering of Multi-Format Content. Based on business needs, select five push formats: text, rich text, image, image-text, and template cards, and execute the corresponding rendering logic. Text formats generate content by filling data into preset standardized templates; image formats achieve adaptation through end-to-end processing: first, develop a customized HTML page and reserve placeholders; then, load the page using a headless Chrome browser and take a screenshot of the specified area (window size 1200×800); finally, use the Thumbnails tool to compress the quality in 0.1 increments until the image size is ≤1MB; image-text formats combine text content and compressed images into a standard Enterprise WeChat structure.

[0073] Step S4: Enterprise WeChat Push Execution and Status Feedback. The rendered content is encapsulated into a request body required by the Enterprise WeChat robot API and sent via OkHttp as a POST (a request method defined by the HTTP protocol) request to the robot's Webhook address. Rate limiting is implemented based on the token bucket algorithm, setting the token generation rate to 20 tokens / minute and the cache limit to 10 tokens to ensure the API call frequency does not exceed Enterprise WeChat's limits. After the push is completed, the status is fed back according to the trigger method: synchronous calls immediately return success / failure status and error information; asynchronous calls store the push status in the database and provide a serial number query interface.

[0074] This embodiment achieves intelligent, efficient, and stable enterprise WeChat group message push through technologies such as unified access of multi-source data, multi-mode collaborative triggering, distributed locking, multi-format intelligent rendering, and token bucket rate limiting, adapting to the push needs of multiple scenarios in industries such as finance and the Internet.

[0075] In another specific embodiment, taking the scenario of "investment advisor signing data push to enterprise WeChat" in the financial industry as an example: I. Implementation Environment The device is deployed on a distributed server cluster. A single node has the following configuration: 32 CPU cores, 64GB of memory, and 1TB of hard drive. The server runs Chrome 120.0 browser and the corresponding version of ChromeDriver. Dependencies include: Spring Boot 2.7.10, Redisson 3.20.0, Kafka Client 2.8.2, Selenium 4.8.3, Thumbnails 0.4.18, and OkHttp 4.9.3. A WeChat Work robot has been created, and the Webhook address and key are configured in the Nacos distributed configuration center.

[0076] II. Implementation Steps Step 1: Configure multi-source data access.

[0077] Database access: Configure a MySQL database connection, execute an SQL script, and extract the investment advisor signing data for the day; Kafka integration: Create a topic "advisor_sign_change" and configure the consumer with the filtering rule "trigger real-time push when signCount ≥ 5"; Data preprocessing: Standardize the contract signing date format to "yyyy-mm-dd" and format the number of contracts as an integer.

[0078] Step 2: Task trigger configuration and lock control.

[0079] Scheduled task creation: A daily contract data report push task is added at 09:30 via a RESTful interface, with taskId "TASK_SIGN_DAILY_2025" and push target "Investment Advisor Operations Group" robot key; distributed lock implementation.

[0080] Step 3: Content rendering (taking daily picture reports and template card notifications as examples).

[0081] 1) Daily photo rendering: 1.1) When rendering the front-end page "https: / / xxx.com / advisor-sign-page", reserve placeholders such as {{signDate}} and {{totalSignCount}}; 1.2) Back-end URL splicing: "https: / / xxx.com / advisor-sign-page?signDate=2025-01-13&totalSignCount=128&topAdvisor=Zhang San"; 1.3) Headless screenshot; 1.4) Image compression; 2) Template card rendering: Fill in the preset template to generate an advisor signing congratulatory message template card.

[0082] Step 4: Enterprise WeChat push and flow limiting execution.

[0083] Flow limiting configuration: The token generation rate of the token bucket flow limiting unit is set to 20 tokens per minute, and the cached token count is 10, ensuring that the API call frequency does not exceed the limit; API call: Send a POST request to the Enterprise WeChat robot Webhook address through OkHttp to push the picture daily report and template card; Status feedback: In this embodiment, synchronous calls are used, and the "push successful" status is directly returned; if it is an asynchronous call, the serial number "FLOW_20250113_10086" is returned, and the status can be obtained through the query interface.

[0084] Through the technical solution of this embodiment, the following technical effects are achieved: 1. Multi-scenario adaptation: Successfully support three scenarios: daily signing daily report (triggered regularly), large-amount signing emergency notice (triggered manually), and real-time signing data change (triggered by Kafka), and the push response delay ≤ 2 seconds; 2. 100% success rate of picture push: All generated pictures are adaptively compressed to fit the Enterprise WeChat restrictions, and there is no push failure due to size exceeding the limit; 3. Distributed reliability: Under cluster deployment, there is no repeated execution of 1000 push tasks, and the distributed lock control is effective; 4. High concurrency adaptation: Simulate 30 push requests per minute, the flow limiting mechanism is effectively triggered, the Enterprise WeChat API frequency limit is not triggered, and the push stability is 100%.

[0085] It should be noted that the size of the serial numbers of each step in the above embodiments does not mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of this application. In practical applications, all the above possible implementation manners can be combined in any combination to form the possible embodiments of this application, which will not be elaborated here one by one.

[0086] Based on the multi-source adapted intelligent push method for enterprise WeChat group robot messages provided in the above embodiments, and based on the same inventive concept, this application also provides a multi-source adapted intelligent push device for enterprise WeChat group robot messages.

[0087] Figure 2 This is a structural diagram of the multi-source adapted WeChat group robot message intelligent push device provided in the embodiments of this application. Figure 2 As shown, the multi-source adapted enterprise WeChat group robot message intelligent push device may specifically include a data access processing unit 210, a task scheduling control unit 220, a content rendering processing unit 230, and a push execution control unit 240.

[0088] The data access and processing unit 210 is used to acquire multi-source business data, perform unified access and standardized preprocessing on the multi-source business data, and obtain standardized business data; wherein the multi-source business data includes standardized real-time data obtained by cleaning, transforming and filtering massive real-time raw data through a distributed stream processing engine. The task scheduling and control unit 220 is used to trigger the execution of push tasks based on standardized business data through multiple preset trigger modes, and at the same time, it controls the unique execution of push tasks in a distributed cluster environment through a distributed lock component. The content rendering processing unit 230 is used to perform push content rendering processing on standardized business data according to the business requirements corresponding to the push task, so as to obtain push content that meets the requirements of the Enterprise Robot API format. The push execution control unit 240 is used to perform flow control on the calling process of the Enterprise Robot API based on the token bucket rate limiting algorithm, push the push content to the target Enterprise Group through the Enterprise Robot API, and synchronously provide feedback on the execution status of the push task.

[0089] This application embodiment provides a possible implementation, wherein the data access processing unit 210 is further configured to: Access business data in a structured database via a database connection protocol, and perform format standardization processing on the business data in the structured database; Standardized real-time data is accessed through a distributed message queue consumption component, and validity filtering is performed on the standardized real-time data. The interface data of the third-party business system is accessed through the Hypertext Transfer Protocol, and the interface data of the third-party business system is processed for format standardization. All business data that has undergone format standardization and validity filtering are subjected to unified rule validation to obtain standardized business data.

[0090] This application embodiment provides a possible implementation, wherein the data access processing unit 210 is further configured to: By connecting to massive real-time raw data sources through a distributed stream processing engine, massive amounts of real-time raw data can be obtained. Data cleaning is achieved by performing data filtering operations on massive amounts of real-time raw data through a distributed stream processing engine. The distributed stream processing engine performs unified conversion operations on the cleaned real-time data, including field naming, data type, and time format, to complete the format conversion. The distributed stream processing engine performs effective data extraction operations on real-time data that has undergone format conversion based on preset business rules, and completes conditional filtering. The cleaned, transformed, and filtered real-time data is standardized and pushed to the designated business topic in the distributed message queue.

[0091] This application embodiment provides a possible implementation, wherein the task scheduling control unit 220 is further configured to: The scheduled task trigger mode, based on preset period configuration rules, triggers the execution of push tasks at regular intervals; In manual trigger mode, push tasks are executed synchronously or asynchronously based on trigger commands received through a standardized interface; In real-time trigger mode, push tasks can be triggered in real time based on standardized real-time data obtained from the distributed message queue consumption component, or push tasks can be triggered at preset times after performing storage operations on the standardized real-time data.

[0092] This application embodiment provides a possible implementation, wherein the task scheduling control unit 220 is further configured to: Generate a unique task identifier for each push task; Based on the unique task identifier of the push task, a corresponding distributed lock is created through the distributed lock component, and the waiting time and expiration time of the distributed lock are set. The push logic corresponding to the push task will be executed only if the push task successfully acquires the corresponding distributed lock. If the push task fails to acquire the corresponding distributed lock, the execution process of the push task will be terminated.

[0093] This application embodiment provides a possible implementation, wherein the content rendering processing unit 230 is further configured to: Determine the target format type of the push content based on the business requirements corresponding to the push task; When the target format type is text, standardized business data is filled into the parameter placeholders of the preset standardized text template to generate text-based push content that meets the requirements of the Enterprise Robot API format. When the target format is an image, perform full-link image adaptation processing on standardized business data to generate image-based push content that meets the API format requirements and transmission limitations of Enterprise Robot. When the target format is a mixed text and image format, the generated text-based push content and image-based push content are combined and packaged into a mixed text and image push content that meets the requirements of the Enterprise Robot API.

[0094] This application embodiment provides a possible implementation, wherein the content rendering processing unit 230 is further configured to: Standardized business data is populated into the parameter placeholders of the preset customized page template to generate the page to be rendered; Load the page to be rendered using a headless browser, perform a screenshot operation on a specified area of ​​the page to be rendered, and obtain the initial image file; According to the preset quality gradient reduction rule, the initial image file is subjected to adaptive compression until the size of the compressed image file meets the transmission limit requirements of the Enterprise Robot, thus obtaining image-based push content.

[0095] This application embodiment provides a possible implementation, wherein the push execution control unit 240 is further configured to: Based on the call frequency limit rules of the Enterprise Robot API, set the token generation rate and token cache limit of the token bucket; Before initiating an API call request to the Enterprise Robot, verify whether there are available tokens in the token bucket; The Enterprise Robot API call request will be sent only if there are available tokens in the token bucket. If no available token is found in the token bucket, terminate the sending operation of the current Enterprise Robot API call request, and wait for the token bucket to generate a new available token before re-executing the verification operation.

[0096] This application embodiment provides a possible implementation, wherein the push execution control unit 240 is further configured to: When the push task is in synchronous trigger mode, the execution result, execution status and error information of the push task will be returned immediately after the push task is completed. When the push task is triggered asynchronously, after the push task is completed, the execution result, execution status and error information of the push task are stored in the structured database. At the same time, a unique serial number corresponding to the push task is generated, and an execution status query interface based on the unique serial number is provided.

[0097] Those skilled in the art will clearly understand that the specific working process of the systems, devices, and modules described above can be referred to the corresponding process in the foregoing method embodiments. For the sake of brevity, it will not be repeated here.

[0098] Those skilled in the art will understand that the technical solution of this application, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several program instructions to cause an electronic device (e.g., a personal computer, server, or network device) to execute all or part of the steps of the methods described in the embodiments of this application when running the program instructions. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0099] Alternatively, all or part of the steps of the foregoing method embodiments can be implemented by hardware (such as electronic devices like personal computers, servers, or network devices) associated with program instructions. The program instructions can be stored in a computer-readable storage medium. When the program instructions are executed by the processor of the electronic device, the electronic device executes all or part of the steps of the methods described in the embodiments of this application.

[0100] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that within the spirit and principles of this application, modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the corresponding technical solutions to leave the protection scope of this application.

Claims

1. A multi-source adapted intelligent message push method for WeChat group robots, characterized in that, The method includes: Acquire multi-source business data, perform unified access and standardized preprocessing on the multi-source business data to obtain standardized business data; the multi-source business data includes standardized real-time data obtained by cleaning, transforming and filtering massive real-time raw data through a distributed stream processing engine. Based on standardized business data, the push task is triggered by multiple preset trigger modes, and the unique execution of the push task in the distributed cluster environment is controlled by a distributed lock component. Based on the business requirements corresponding to the push task, standardized business data is processed to render push content, resulting in push content that meets the requirements of the Enterprise Robot API format. The token bucket rate limiting algorithm is used to control the flow of calls to the Enterprise Robot API, pushing content to the target Enterprise Group through the Enterprise Robot API and providing synchronous feedback on the execution status of the push task.

2. The method according to claim 1, characterized in that, Acquire multi-source business data, perform unified access and standardized preprocessing on the multi-source business data to obtain standardized business data, including: Access business data in a structured database via a database connection protocol, and perform format standardization processing on the business data in the structured database; Standardized real-time data is accessed through a distributed message queue consumption component, and validity filtering is performed on the standardized real-time data. The interface data of the third-party business system is accessed through the Hypertext Transfer Protocol, and the interface data of the third-party business system is processed for format standardization. All business data that has undergone format standardization and validity filtering are subjected to unified rule validation to obtain standardized business data.

3. The method according to claim 1, characterized in that, The steps involved in using a distributed stream processing engine to clean, transform, and filter massive amounts of real-time raw data to obtain standardized real-time data include: By connecting to massive real-time raw data sources through a distributed stream processing engine, massive amounts of real-time raw data can be obtained. Data cleaning is achieved by performing data filtering operations on massive amounts of real-time raw data through a distributed stream processing engine. The distributed stream processing engine performs unified conversion operations on the cleaned real-time data, including field naming, data type, and time format, to complete the format conversion. The distributed stream processing engine performs effective data extraction operations on real-time data that has undergone format conversion based on preset business rules, and completes conditional filtering. The cleaned, transformed, and filtered real-time data is standardized and pushed to the designated business topic in the distributed message queue.

4. The method according to claim 1, characterized in that, Based on standardized business data, push tasks are triggered through multiple preset trigger modes, including: The scheduled task trigger mode, based on preset period configuration rules, triggers the execution of push tasks at regular intervals; In manual trigger mode, push tasks are executed synchronously or asynchronously based on trigger commands received through a standardized interface; In real-time trigger mode, push tasks can be triggered in real time based on standardized real-time data obtained from the distributed message queue consumption component, or push tasks can be triggered at preset times after performing storage operations on the standardized real-time data.

5. The method according to claim 1, characterized in that, Controlling the unique execution of push tasks in a distributed cluster environment through a distributed lock component includes: Generate a unique task identifier for each push task; Based on the unique task identifier of the push task, a corresponding distributed lock is created through the distributed lock component, and the waiting time and expiration time of the distributed lock are set. The push logic corresponding to the push task will be executed only if the push task successfully acquires the corresponding distributed lock. If the push task fails to acquire the corresponding distributed lock, the execution process of the push task will be terminated.

6. The method according to claim 1, characterized in that, Based on the business requirements corresponding to the push task, standardized business data is processed for push content rendering to obtain push content that conforms to the Enterprise Robot API format requirements, including: Determine the target format type of the push content based on the business requirements corresponding to the push task; When the target format type is text, standardized business data is filled into the parameter placeholders of the preset standardized text template to generate text-based push content that meets the requirements of the Enterprise Robot API format. When the target format is an image, perform full-link image adaptation processing on standardized business data to generate image-based push content that meets the API format requirements and transmission limitations of Enterprise Robot. When the target format is a mixed text and image format, the generated text-based push content and image-based push content are combined and packaged into a mixed text and image push content that meets the requirements of the Enterprise Robot API.

7. The method according to claim 6, characterized in that, Perform end-to-end image adaptation processing on standardized business data to generate image-based push content that conforms to the Enterprise Robot API format requirements and transmission limitations, including: Standardized business data is populated into the parameter placeholders of the preset customized page template to generate the page to be rendered; Load the page to be rendered using a headless browser, perform a screenshot operation on a specified area of ​​the page to be rendered, and obtain the initial image file; According to the preset quality gradient reduction rule, the initial image file is subjected to adaptive compression until the size of the compressed image file meets the transmission limit requirements of the Enterprise Robot, thus obtaining image-based push content.

8. The method according to claim 1, characterized in that, Traffic control is implemented for the Enterprise Robot API call process based on the token bucket rate limiting algorithm, including: Based on the call frequency limit rules of the Enterprise Robot API, set the token generation rate and token cache limit of the token bucket; Before initiating an API call request to the Enterprise Robot, verify whether there are available tokens in the token bucket; Only send the Enterprise Robot API call request if there are available tokens in the token bucket; If no available token is found in the token bucket, terminate the sending operation of the current Enterprise Robot API call request, and wait for the token bucket to generate a new available token before re-executing the verification operation.

9. The method according to claim 1, characterized in that, Synchronously report the execution status of the push task, including: When the push task is in synchronous trigger mode, the execution result, execution status and error information of the push task will be returned immediately after the push task is completed. When the push task is triggered asynchronously, after the push task is completed, the execution result, execution status and error information of the push task are stored in the structured database. At the same time, a unique serial number corresponding to the push task is generated, and an execution status query interface based on the unique serial number is provided.

10. A multi-source adapted enterprise WeChat group robot message intelligent push device, characterized in that, The device includes: The data access and processing unit is used to acquire multi-source business data, perform unified access and standardized preprocessing on the multi-source business data, and obtain standardized business data; the multi-source business data includes standardized real-time data obtained by cleaning, transforming and filtering massive real-time raw data through a distributed stream processing engine. The task scheduling and control unit is used to trigger the execution of push tasks based on standardized business data and through multiple preset trigger modes, while controlling the unique execution of push tasks in a distributed cluster environment through a distributed lock component; The content rendering processing unit is used to render push content on standardized business data according to the business requirements corresponding to the push task, so as to obtain push content that meets the requirements of the Enterprise Robot API format. The push execution control unit is used to control the flow of calls to the Enterprise Robot API based on the token bucket rate limiting algorithm, pushes the content to the target Enterprise Group through the Enterprise Robot API, and synchronously provides feedback on the execution status of the push task.

Images