An efficient management method for official accounts and mini-programs on third-party platforms

Abstract

The present invention discloses an efficient management method for official accounts and mini-programs on a third-party platform, which belongs to the field of information technology. It includes authorization submission management and templates and batch operations, and solves the technical problems of efficiently realizing full-process automation, high-concurrency batch submission and real-time status feedback mechanism for official accounts and mini-programs. The present invention integrates operation processes such as authorization, code upload, submission and release, significantly reduces the frequency of manual intervention, and improves overall processing efficiency. Through parameter template mechanism and batch task scheduling capabilities, it is suitable for large customers and multi-project operation scenarios, introduces configuration templates and dynamic parameter mapping, avoids consistency risks and configuration errors in manual operations, supports active push and visual monitoring of audit results and abnormal errors, and greatly shortens problem response time.

Description

Technical Field

[0001] The present invention belongs to the field of information technology, and in particular relates to a method for efficiently managing public accounts and mini-programs on a third-party platform. Background Art

[0002] WeChat Official Accounts and Mini Programs, as key vehicles for digital enterprise services, are widely used in scenarios such as brand marketing, customer service, and business development. Currently, businesses typically rely on the native backend functionality provided by the WeChat Official Account platform or access third-party service platforms to complete the authorization, review, and release processes for Official Accounts and Mini Programs.

[0003] In the existing technology, there are mainly two management methods:

[0004] WeChat Official Accounts Platform's native management method: Users log in to the WeChat official management backend and complete authorization, code package upload, submission for review, domain name configuration, and publishing processes one by one. The operation process is highly dependent on manual execution.

[0005] Third-party platform tools assist in management: For example, some commercial management platforms provide a centralized interface that allows unified viewing and control of basic information of multiple accounts. However, the operational process and functional depth are still limited to the original calls of the WeChat interface and lack high-level automation capabilities.

[0006] However, the existing technology has the following deficiencies in practical applications:

[0007] The process is cumbersome and the degree of automation is low: users need to manually handle the authorization, upload and review processes. There is a lack of task scheduling and status linkage mechanisms, resulting in long operations and low efficiency.

[0008] Incomplete support for batch management: When faced with multiple mini-programs or official accounts, the existing system is unable to implement template reuse and parameter mapping, and repetitive operations lead to a waste of human resources.

[0009] Lack of real-time feedback and error warning mechanism: When the audit fails or the interface call is abnormal, the system cannot actively push reminders, and users need to poll manually, which seriously affects response time and business continuity.

[0010] Grayscale release and domain name configuration are complex operations: users need to adjust the release strategy and server domain name configuration one by one. The lack of a unified distribution and verification mechanism makes configuration errors prone to occur. Summary of the Invention

[0011] The purpose of this invention is to provide an efficient management method for official accounts and mini-programs on a third-party platform, which solves the technical problems of efficiently realizing full-process automation, high-concurrency batch submission and real-time status feedback mechanism for official accounts and mini-programs.

[0012] To achieve the above object, the present invention adopts the following technical solutions:

[0013] A method for efficiently managing official accounts and mini-programs on a third-party platform, comprising the following steps:

[0014] Step 1: Authorization submission management sub-process, the specific steps are as follows:

[0015] Step 1-1: The user logs in through the front-end interface and selects the target application in the front-end interface;

[0016] Step 1-2: After successfully authenticating the user, the authorization process begins, including generating a pre-authorization QR code, the user scanning the code and completing the WeChat callback to obtain an authorization token;

[0017] Steps 1-3: After successful authorization, the authorization data is obtained; the user uploads a file, which includes the mini program code package and related configuration information;

[0018] Steps 1-4: Encapsulate the file and authorization data, generate an audit task, and submit it to the WeChat audit client in parallel through the message queue. Adopt an adaptive concurrent scheduling strategy to complete the submission.

[0019] Steps 1-5: Monitor the audit status through polling, obtain the audit results, generate messages, send messages through multiple channels, and process all interface calls through the unified interface adaptation layer;

[0020] Steps 1-6: If the audit fails, classify the audit task as an error, record the entire process log, and notify the user to correct the error on the front end, regenerate the audit task, and submit it;

[0021] Step 2: Template and batch operation sub-process, including the following steps:

[0022] Step 2-1: After the user defines or selects a standardized mini-program template, the template parameters of the standardized mini-program template are verified and stored, and the user's operation log is recorded and stored;

[0023] Step 2-2: After the user selects the target application list and template, the variable data of each application is read and a personalized batch review task is generated through parameter mapping;

[0024] Step 2-3: After queueing the personalized batch review tasks, call the WeChat review interface in parallel to submit them;

[0025] Steps 2-4: After successful review, the new version will be released in stages according to the grayscale release strategy set by the user. During the grayscale release process, feedback will be collected in real time to automatically adjust the release ratio.

[0026] Step 2-5: Perform unified configuration and format verification on the domain name of the target application, distribute it uniformly through the interface adaptation layer, and record the change in the entire process log.

[0027] Preferably, when executing step 1-1, the following steps are specifically included:

[0028] Step 1-1-1: On the front end, the user fills in the account and password on the login page. The front end encrypts the credentials using HTTPS, generates a request, and submits it to the back end authentication interface;

[0029] Step 1-1-2: On the backend, after receiving the request, the authentication module verifies the user credentials. If the verification fails, a clear error code and prompt are returned. If the verification succeeds, a session token is generated and the user session data is written. The user session data includes the login time, IP address, and a list of bound applications.

[0030] Step 1-1-3: Call multi-factor authentication, including sending a text message verification code or TOTP dynamic code to the front-end. After the user enters the code correctly, execute step 1-2;

[0031] When executing steps 1-2, the specific steps are as follows:

[0032] Step 1-2-1: The authorization processing module calls the interface adaptation layer to send a request to obtain the component token and pre-authorization code to the WeChat API interface, that is, / cgi-bin / component / api_component_token, and passes the component AppID and Secret parameters to the WeChat API interface;

[0033] The interface adaptation layer performs unified encapsulation and error handling on the JSON data returned by the WeChat client. The JSON data contains component_access_token.

[0034] After successfully obtaining the component_access_token, i.e. the component token, call the WeChat API interface and pass in the component token to obtain the pre-authorization code pre_auth_code;

[0035] Step 1-2-2: During step 1-2-1, detailed logs are recorded for each call throughout the entire process, including request time, parameters, return data, and response latency. The detailed logs are saved in the full-link log library.

[0036] Step 1-2-3: The authorization processing module uses the pre-authorization code pre_auth_code to construct the authorization QR code URL;

[0037] The interface adaptation layer uses the HMAC-SHA256 algorithm to uniformly sign the parameters of the authorization QR code URL and send it to the front end;

[0038] After the front-end receives the authorization QR code URL, it uses the JS QR code generation tool to convert it into a QR code image and display it to the user;

[0039] Step 1-2-4: The user scans the QR code with WeChat. After WeChat completes the scan, it sends an HTTP callback request to the backend through the pre-configured redirect_uri. The HTTP callback request contains the auth_code information;

[0040] The callback processing module receives the HTTP callback request, extracts the auth_code, and calls the WeChat API interface / cgi-bin / component / api_query_auth through the interface adaptation layer, passing the auth_code and component_access_token to the WeChat side. The WeChat side returns the return data, which includes the authorizer_access_token, authorizer_refresh_token, and the bound authorizer_appid.

[0041] The callback processing module verifies the format of the returned data, including validity period verification and signature verification, and encrypts sensitive data using the AES-256 algorithm before storing it in the database;

[0042] Step 1-2-5: When executing step 1-2-4, the entire process generates a full-link logging session, namely TraceID, and stores it in the database;

[0043] When executing steps 1-3, specifically: the user uploads the code package and fills in the audit parameters on the front end using HTTPS, and the interface adaptation layer performs HMAC signature verification on the file uploaded by the user;

[0044] The upload module obtains the file uploaded by the user and verifies the file format. After passing the verification, the file is stored in the object storage and the storage path and metadata are entered into the database.

[0045] When executing steps 1-4, the specific steps include:

[0046] Step 1-4-1: The review task management module obtains the filled-in review parameters in the file, including configuration information, code package storage information, and stored authorization data, encapsulates the filled-in review parameters into a review task in JSON format, writes the review task to the task log, and stores it in the database;

[0047] Step 1-4-2: The task scheduling module pushes the audit task into the message queue and calculates the current allowed number of concurrent tasks based on real-time monitoring indicators. , according to the number of hair Start or adjust thread / coroutine pool;

[0048] Step 1-4-3: If the task call fails, the task scheduling module retries according to the exponential backoff retry strategy;

[0049] In this embodiment, the maximum number of retries of the exponential backoff retry strategy is 3. After the final failure, the task is marked as "failed" and an alarm notification is triggered.

[0050] Specifically, for each task, a retry_count field is set to record the number of retries. If the number exceeds the upper limit, the task will be put into the failure queue, logged, and a message will be sent.

[0051] When executing steps 1-5, the specific steps are as follows:

[0052] Step 1-5-1: The audit status monitoring module periodically calls the WeChat audit status interface / wxa / get_auditstatus, sends a status request, and obtains the status of the audit task; when sending the status request, it uses a dynamic retry mechanism and uniformly processes the status request through the interface adaptation layer;

[0053] Step 1-5-2: The audit status monitoring module parses the returned data and enters the audit status into the database. The audit status includes "pending audit", "audit passed" or "audit failed";

[0054] Step 1-5-3: When the audit status monitoring module parses the errors in the returned data, the audit status monitoring module calls the error code mapping table to classify common errors;

[0055] Step 1-5-4: Assign a TraceID to each audit task, record the entire audit status from submission to return, and enter it into the database;

[0056] Step 1-5-5: When a change in the review status is detected, the review status monitoring module generates a message and sends a notification to the front-end through the DingTalk robot interface, SMS or email; the message contains the task ID, status, error details, TraceID and a resubmit link;

[0057] When executing steps 1-6, the specific steps include:

[0058] Step 1-6-1: After receiving the audit failure status, the exception handling module parses the error details and classifies the errors according to the preset rules, specifically into parameter configuration errors and system interface call exceptions;

[0059] Generate security logs based on error details, retry counts, timestamps, and TraceIDs, and enter them into the database;

[0060] Step 1-6-2: The front-end sends a reminder through a notification, and at the same time displays a detailed error information page in the user management backend, lists the error categories, and marks the recommended modification items. After the user modifies the parameters on the front-end or re-uploads the necessary files, the user submits a modification request to the back-end, which regenerates the review task and submits it.

[0061] Preferably, when executing step 1-1, the backend reads the public account or mini program information bound to the user from the database based on the user ID, and returns the authentication result and application list to the front end in the form of JSON data. The front end displays the operation options for the user to check in the list.

[0062] Preferably, when executing step 1-4-2, calculate the current allowed number of concurrent The specific formula is as follows:

[0063] ;

[0064] in, Indicates the baseline concurrency number, which is the number of backend transactions under no-load conditions; indicates server load; Indicates the maximum load allowed; Indicates the response time of the target interface, which is fixed at 300ms; Indicates the response time of the WeChat interface; Indicates the maximum number of tasks queued that can be backlogged, fixed at 50. Indicates the number of unprocessed tasks in the message queue.

[0065] Preferably, when executing step 2-1, specifically: the user chooses to upload a template file in JSON format on the front end, and the template management module on the back end obtains the template file, verifies the format of each field, and ensures that the placeholder format conforms to the preset regular expression;

[0066] After verification, the template management module stores the template file and its metadata into the template library database. The metadata includes the template name, version, creation time and field description.

[0067] Record the entire link log, generate a TraceID and enter it into the database;

[0068] When executing step 2-2, the specific steps include:

[0069] Step 2-2-1: The user selects multiple target applications on the front-end interface, selects a template, and uploads the variable mapping data corresponding to the selected target application. The variable mapping data includes the application's AppID and API address;

[0070] Step 2-2-2: The parameter variable mapping module obtains the variable mapping data. For each target application, it reads the uploaded data of the application, replaces the placeholders one by one according to the selected template to generate a complete configuration string, and generates a review task.

[0071] The review task includes the application ID, code package path, personalized configuration, template ID, and review status. The review status is "pending review" at this time.

[0072] Step 2-2-3: Based on the method in step 2-2-2, batch generate review tasks for each target application; record the replacement operation log for each step, generate the corresponding TraceID, and enter it into the database;

[0073] When executing steps 2-3, the task scheduling module processes batches of review tasks according to the method of steps 1-4-2. The submission result, response time and error code of each review task are recorded in the log and stored in the database;

[0074] When executing steps 2-4, the specific steps are as follows:

[0075] Step 2-4-1: The user sets the grayscale release policy parameters on the front-end, including the new version number, target grayscale ratio, and target user attributes;

[0076] Step 2-4-2: The back-end grayscale release control module obtains the grayscale release policy parameters, binds the grayscale release policy parameters with the submission results of the review task, generates a grayscale release plan, and records the operation log and TraceID and enters them into the database;

[0077] Step 2-4-3: The grayscale release control module calls the WeChat interface / wxa / changestatus and releases the content through the interface adaptation layer;

[0078] Record the release time, release ratio, WeChat interface response and return error code of each stage, generate a release log, and store it in the database;

[0079] Step 2-4-4: The grayscale release control module collects real-time feedback including error rates;

[0080] Build an indicator mathematical model, generate control information, and perform the second-stage release or rollback operation after unified processing through the interface adaptation layer;

[0081] The specific formula of the indicator mathematical model is as follows:

[0082] ;

[0083] in, is the error rate, error rate Used to control expansion decisions, when When the second phase is released, ,when When the rollback operation is performed, ; Indicates an operation; Indicates the preset threshold;

[0084] In this embodiment, the error rate Specifically, it refers to the failure rate of request processing within a certain time period, which can include interface-level error rate and business-level error rate.

[0085] The interface-level error rate is the proportion of HTTP responses other than 200 that a grayscale version returns within a unit of time. For example, if a grayscale version has 1,000 total requests within 10 minutes, and 87 of them return errors such as 500, 502, or 504, the error rate is 8.7%.

[0086] The business-level error rate is that although the interface returns 200, the returned data contains a business failure status (such as code ≠ 0). For example, the agreed response structure format is unified, such as { code: 0, message: "ok", data: {}}. Based on the agreed format, the business anomaly is identified. When executing steps 2-5, the specific steps include the following:

[0087] Step 2-5-1: The user uploads the domain name configuration file on the front end in Excel or CSV format. The domain name configuration file includes the domain name and type.

[0088] The domain name management module obtains and parses the domain name configuration file, converts it into a standard format, and verifies whether the format of each domain name conforms to the preset regular rules;

[0089] Step 2-5-2: For domain names that fail format verification, an error report will be generated and fed back to the user, requiring them to modify and re-upload;

[0090] Step 2-5-3: The allocation engine automatically allocates domain names to each target application based on the target application's identification and preset priority sorting rules;

[0091] Step 2-5-4: Call the WeChat interface / wxa / modify_domain to uniformly distribute domain name configurations through the interface adaptation layer, record the distribution results and return status, generate domain name logs, and enter them into the database.

[0092] The efficient management method for public accounts and mini-programs on a third-party platform described in the present invention solves the technical problems of efficiently realizing full-process automation, high-concurrency batch submission for review, and real-time status feedback mechanism for public accounts and mini-programs. The present invention integrates operational processes such as authorization, code upload, submission for review, and publication, significantly reducing the frequency of manual intervention and improving overall processing efficiency. Through the parameter template mechanism and batch task scheduling capabilities, unified configuration and centralized management of multiple public accounts or mini-programs are achieved, and large-scale submission for review and publication are supported at one time. It is suitable for large customers and multi-project operation scenarios. The introduction of configuration templates and dynamic parameter mapping solves the problems of repeated setting of server domain names and business domain names for each account, avoiding consistency risks and configuration errors in manual operations, supporting active push and visual monitoring of audit results and abnormal errors, greatly shortening problem response time, and improving business continuity assurance capabilities. It has grayscale policy management capabilities and supports batch release by account, region, user group and other dimensions, facilitating testing and risk control. BRIEF DESCRIPTION OF THE DRAWINGS

[0093] Figure 1 It is the main flow chart of the present invention;

[0094] Figure 2 is a flow chart of step 1 of the present invention;

[0095] Figure 3 It is a flow chart of step 2 of the present invention. DETAILED DESCRIPTION

[0096] Depend on Figure 1-Figure 3 The method for efficiently managing official accounts and mini-programs on a third-party platform includes the following steps:

[0097] Step 1: Authorization submission management sub-process, the specific steps are as follows:

[0098] Step 1-1: The user logs in through the front-end interface and selects the target application in the front-end interface;

[0099] When executing step 1-1, the backend reads the official account or mini program information bound to the user from the database based on the user ID, and returns the authentication result and application list to the frontend in the form of JSON data. The frontend displays the operation options in the list for the user to check.

[0100] When executing step 1-1, the specific steps include:

[0101] Step 1-1-1: On the front end, the user fills in the account and password on the login page. The front end encrypts the credentials using HTTPS, generates a request, and submits it to the back end authentication interface;

[0102] In this embodiment, the user can enter the account (mobile phone number or email address) and password on the Web management platform login interface and click to log in; the front end sends the user input information to the login authentication API interface via a POST request, and the entire communication process uses the HTTPS protocol to ensure transmission security.

[0103] After the backend receives the login request, it first performs SHA-256 hashing on the password and matches it with the salted password digest stored in the database. If secondary authentication (such as SMS verification code) is enabled, the system verifies the legitimacy of the OTP dynamic code. If the verification passes, a user session token (JWT format) is generated. The token contains information such as user ID, role permissions, expiration time, etc., and is signed with the server private key.

[0104] In practical applications, each user can use a unique randomly generated salt value. This salt value is generated during registration and stored in the database, tied to the user record. A salt field is added to the user table. During password verification, the user's input password is combined with the salt for the user and then a SHA-256 hash is performed.

[0105] If the number of consecutive login failures exceeds the set number (such as 5 times), the account may be temporarily locked or a graphic verification code verification may be triggered.

[0106] All login behaviors are written into the log, including fields such as time, IP, user ID, and failure reason.

[0107] Step 1-1-2: On the backend, after receiving the request, the authentication module verifies the user credentials. If the verification fails, a clear error code and prompt are returned. If the verification succeeds, a session token is generated and the user session data is written. The user session data includes the login time, IP address, and a list of bound applications.

[0108] In this embodiment, account security is ensured through a user credential verification mechanism (such as database comparison or OAuth verification).

[0109] The generated token is used to maintain subsequent sessions to avoid repeated logins. It also caches the user's basic information and bound applications for quick access to subsequent operations.

[0110] Step 1-1-3: Call multi-factor authentication, including sending a text message verification code or TOTP dynamic code to the front-end. After the user enters the code correctly, execute step 1-2.

[0111] In this embodiment, the use of multi-factor authentication can improve system security. By integrating with the SMS platform or TOTP algorithm library, it can ensure that even if the password is leaked, the account will not be illegally accessed.

[0112] Step 1-2: After successfully authenticating the user, the authorization process begins, including generating a pre-authorization QR code, the user scanning the code and completing the WeChat callback to obtain an authorization token;

[0113] When executing steps 1-2, the specific steps are as follows:

[0114] Step 1-2-1: The authorization processing module calls the interface adaptation layer to send a request to obtain the component token and pre-authorization code to the WeChat API interface, that is, / cgi-bin / component / api_component_token, and passes the component AppID and Secret parameters to the WeChat API interface;

[0115] The interface adaptation layer performs unified encapsulation and error handling on the JSON data returned by the WeChat client. The JSON data contains component_access_token.

[0116] After successfully obtaining the component_access_token, i.e. the component token, call the WeChat API interface and pass in the component token to obtain the pre-authorization code pre_auth_code;

[0117] Step 1-2-2: During step 1-2-1, detailed logs are recorded for each call throughout the entire process, including request time, parameters, return data, and response latency. The detailed logs are saved in the full-link log library.

[0118] Step 1-2-3: The authorization processing module uses the pre-authorization code pre_auth_code to construct the authorization QR code URL;

[0119] In this embodiment, a one-time token or a timestamp + signature can be added to the QR code to limit the validity period.

[0120] For example, add ts and nonce to the URL and record whether they are used.

[0121] After each successful scan, the token status is set to "used" to prevent reuse.

[0122] The interface adaptation layer uses the HMAC-SHA256 algorithm to uniformly sign the parameters of the authorization QR code URL and send it to the front end;

[0123] After the front-end receives the authorization QR code URL, it uses the JS QR code generation tool to convert it into a QR code image and display it to the user;

[0124] The pre-authorization code pre_auth_code is a temporary authorization credential that needs to be encapsulated as a URL and signed before the user operates to ensure that the parameters have not been tampered with.

[0125] The QR code is the core medium for authorized interaction between users and WeChat, and the front end displays it visually.

[0126] Step 1-2-4: The user scans the QR code with WeChat. After WeChat completes the scan, it sends an HTTP callback request to the backend through the pre-configured redirect_uri. The HTTP callback request contains the auth_code information;

[0127] The callback processing module receives the HTTP callback request, extracts the auth_code, and calls the WeChat API interface / cgi-bin / component / api_query_auth through the interface adaptation layer, passing the auth_code and component_access_token to the WeChat side. The WeChat side returns the return data, which includes the authorizer_access_token, authorizer_refresh_token, and the bound authorizer_appid.

[0128] The callback processing module verifies the format of the returned data, including validity period verification and signature verification, and encrypts sensitive data using the AES-256 algorithm before storing it in the database;

[0129] In this embodiment, auth_code is used to perform a second authorization code exchange to obtain authorizer_access_token (such as a public account or mini program exclusive token), which is used for all subsequent operation calls.

[0130] Step 1-2-5: When executing step 1-2-4, the entire process generates a full-link logging session, namely TraceID, and stores it in the database.

[0131] Steps 1-3: After successful authorization, the authorization data is obtained; the user uploads a file, which includes the mini program code package and related configuration information;

[0132] In this embodiment, the file is uploaded in zip format, and the Zip / file processing library of the backend framework can be used for decompression preview and directory scanning.

[0133] When executing steps 1-3, specifically: the user uploads the code package and fills in the audit parameters on the front end using HTTPS, and the interface adaptation layer performs HMAC signature verification on the file uploaded by the user;

[0134] The upload module obtains the files uploaded by the user and performs format verification on the files. After passing the verification, the files are stored in the object storage and the storage path and metadata are entered into the database.

[0135] This embodiment adopts the dual protection of HTTPS and HMAC to ensure the security of file transmission and the legitimacy of the source.

[0136] Object storage has high availability and high concurrent processing capabilities, and is suitable for storing static resources such as mini-program codes.

[0137] Metadata records are mainly used for later review and rollback tracking operations.

[0138] Steps 1-4: Encapsulate the file and authorization data, generate an audit task, and submit it to the WeChat audit client in parallel through the message queue. Adopt an adaptive concurrent scheduling strategy to complete the submission.

[0139] When executing steps 1-4, the specific steps include:

[0140] Step 1-4-1: The review task management module obtains the filled-in review parameters in the file, including configuration information, code package storage information, and stored authorization data, encapsulates the filled-in review parameters into a review task in JSON format, writes the review task to the task log, and stores it in the database;

[0141] Step 1-4-2: The task scheduling module pushes the audit task into the message queue and calculates the current allowed number of concurrent tasks based on real-time monitoring indicators. , according to the number of hair Start or adjust thread / coroutine pool;

[0142] In this embodiment, the task scheduling module periodically samples and caches indicator data.

[0143] When executing steps 1-4-2, calculate the current allowed number of concurrent The specific formula is as follows:

[0144] ;

[0145] in, Indicates the baseline concurrency number, which is the number of backend transactions under no-load conditions. Indicates server load; Indicates the maximum load allowed; Indicates the response time of the target interface, which is fixed at 300ms; Indicates the response time of the WeChat interface; Indicates the maximum number of tasks queued that can be backlogged, fixed at 50. Indicates the number of unprocessed tasks in the message queue.

[0146] Server Load The method to obtain the load is to read / proc / loadavg (Linux) or call the system API to obtain the load.

[0147] WeChat interface response time The method for obtaining is to use the interface adaptation layer to measure and calculate the average response time.

[0148] In this embodiment, asynchronous task decoupling is achieved through message queues (such as RabbitMQ and Kafka); adaptive concurrency dynamically adjusts resource allocation by monitoring system load to ensure a balance between system stability and throughput.

[0149] By encapsulating tasks in structured JSON, it is easy to decouple processing in a multi-threaded or distributed environment.

[0150] Step 1-4-3: If the task call fails, the task scheduling module retries according to the exponential backoff retry strategy.

[0151] In this embodiment, exponential backoff is used to avoid repeating high-frequency requests in a short period of time, which can alleviate errors caused by network jitter or API throttling. The exponential backoff retry strategy is an existing technology and will not be described in detail.

[0152] Steps 1-5: Monitor the audit status through polling, obtain the audit results, generate messages, send messages through multiple channels, and process all interface calls through the unified interface adaptation layer;

[0153] When executing steps 1-5, the specific steps are as follows:

[0154] Step 1-5-1: The audit status monitoring module periodically calls the WeChat audit status interface / wxa / get_auditstatus, sends a status request, and obtains the status of the audit task; when sending the status request, it uses a dynamic retry mechanism and uniformly processes the status request through the interface adaptation layer;

[0155] Step 1-5-2: The audit status monitoring module parses the returned data and enters the audit status into the database. The audit status includes "pending audit", "audit passed" or "audit failed";

[0156] In this embodiment, the state is structured and stored in the database, mainly for real-time display on the front end or for subsequent business logic (such as phased release and retry).

[0157] Step 1-5-3: When the audit status monitoring module parses the errors in the returned data, the audit status monitoring module calls the error code mapping table to classify common errors;

[0158] The error code mapping table can improve the readability and traceability of error responses, making it easier for users to understand the cause of the problem and quickly fix it. The error code mapping table is a preset data comparison table.

[0159] Step 1-5-4: Assign a TraceID to each audit task, record the entire audit status from submission to return, and enter it into the database;

[0160] Step 1-5-5: When a change in the review status is detected, the review status monitoring module generates a message and sends a notification to the front-end through the DingTalk robot interface, SMS or email; the message contains the task ID, status, error details, TraceID and resubmission link.

[0161] Steps 1-6: If the audit fails, classify the audit task as an error, record the entire process log, and notify the user to correct the error on the front end, regenerate the audit task, and submit it;

[0162] When executing steps 1-6, the specific steps include:

[0163] Step 1-6-1: After receiving the audit failure status, the exception handling module parses the error details and classifies the errors according to the preset rules, specifically into parameter configuration errors and system interface call exceptions;

[0164] Generate security logs based on error details, retry counts, timestamps, and TraceIDs, and enter them into the database;

[0165] Step 1-6-2: The front-end sends a reminder through a notification, and at the same time displays a detailed error information page in the user management backend, lists the error categories, and marks the recommended modification items. After the user modifies the parameters on the front-end or re-uploads the necessary files, the user submits a modification request to the back-end, which regenerates the review task and submits it.

[0166] In this embodiment, during use, error classification can also add WeChat side error classification, such as content violation, category error, insufficient qualifications, etc. These error classifications are all refined and classified through the error code mapping table.

[0167] Step 2: Template and batch operation sub-process, including the following steps:

[0168] Step 2-1: After the user defines or selects a standardized mini-program template, the template parameters of the standardized mini-program template are verified and stored, and the user's operation log is recorded and stored;

[0169] When executing step 2-1, specifically: the user chooses to upload a template file in JSON format on the front end, and the template management module on the back end obtains the template file, verifies the format of each field, and ensures that the placeholder format conforms to the preset regular expression;

[0170] After verification, the template management module stores the template file and its metadata into the template library database. The metadata includes the template name, version, creation time and field description.

[0171] Record the entire link log, generate a TraceID and enter it into the database.

[0172] Step 2-2: After the user selects the target application list and template, the variable data of each application is read and a personalized batch review task is generated through parameter mapping;

[0173] The specific steps include:

[0174] Step 2-2-1: The user selects multiple target applications on the front-end interface, selects a template, and uploads the variable mapping data corresponding to the selected target application. The variable mapping data includes the application's AppID and API address;

[0175] Step 2-2-2: The parameter variable mapping module obtains the variable mapping data. For each target application, it reads the uploaded data of the application, replaces the placeholders one by one according to the selected template to generate a complete configuration string, and generates a review task.

[0176] The review task includes the application ID, code package path, personalized configuration, template ID, and review status. The review status is "pending review" at this time.

[0177] Step 2-2-3: Based on the method in step 2-2-2, batch generate review tasks for each target application; record the replacement operation log for each step, generate the corresponding TraceID, and enter it into the database.

[0178] Step 2-3: After queueing the personalized batch review tasks, call the WeChat review interface in parallel to submit them;

[0179] When executing steps 2-3, the task scheduling module processes batches of review tasks according to the method of steps 1-4-2. The submission result, response time and error code of each review task are recorded in the log and stored in the database.

[0180] Steps 2-4: After successful review, the new version will be released in stages according to the grayscale release strategy set by the user. During the grayscale release process, feedback will be collected in real time to automatically adjust the release ratio.

[0181] When executing steps 2-4, the specific steps are as follows:

[0182] Step 2-4-1: The user sets the grayscale release policy parameters on the front-end, including the new version number, target grayscale ratio, and target user attributes;

[0183] Step 2-4-2: The back-end grayscale release control module obtains the grayscale release policy parameters, binds the grayscale release policy parameters with the submission results of the review task, generates a grayscale release plan, and records the operation log and TraceID and enters them into the database;

[0184] Step 2-4-3: The grayscale release control module calls the WeChat interface / wxa / changestatus and releases the content through the interface adaptation layer;

[0185] Record the release time, release ratio, WeChat interface response and return error code of each stage, generate a release log, and store it in the database;

[0186] Step 2-4-4: The grayscale release control module collects real-time feedback including error rates;

[0187] Build an indicator mathematical model, generate control information, and perform the second-stage release or rollback operation after unified processing through the interface adaptation layer;

[0188] The specific formula of the indicator mathematical model is as follows:

[0189] ;

[0190] in, is the error rate, error rate Used to control expansion decisions, when When the second phase is released, ,when When the rollback operation is performed, ; Indicates an operation; Indicates the preset threshold.

[0191] Step 2-5: Perform unified configuration and format verification on the domain name of the target application, distribute it uniformly through the interface adaptation layer, and record the change in the entire process log.

[0192] When executing steps 2-5, the specific steps include:

[0193] Step 2-5-1: The user uploads the domain name configuration file on the front end in Excel or CSV format. The domain name configuration file includes the domain name and type.

[0194] The domain name management module obtains and parses the domain name configuration file, converts it into a standard format, and verifies whether the format of each domain name conforms to the preset regular rules;

[0195] Step 2-5-2: For domain names that fail format verification, an error report will be generated and fed back to the user, requiring them to modify and re-upload;

[0196] Step 2-5-3: The allocation engine automatically allocates domain names to each target application based on the target application's identification and preset priority sorting rules;

[0197] Step 2-5-4: Call the WeChat interface / wxa / modify_domain to uniformly distribute domain name configurations through the interface adaptation layer, record the distribution results and return status, generate domain name logs, and enter them into the database.

[0198] In this embodiment, the front-end is responsible for prompting users to set up DNS TXT records such as verify.domain.com ->token, and the back-end initiates DNS queries or HTTP verification. Users need to configure TXT type DNS records or upload verification files.

[0199] The efficient management method for public accounts and mini-programs on a third-party platform described in the present invention solves the technical problems of efficiently realizing full-process automation, high-concurrency batch submission for review, and real-time status feedback mechanism for public accounts and mini-programs. The present invention integrates operational processes such as authorization, code upload, submission for review, and publication, significantly reducing the frequency of manual intervention and improving overall processing efficiency. Through the parameter template mechanism and batch task scheduling capabilities, unified configuration and centralized management of multiple public accounts or mini-programs are achieved, and large-scale submission for review and publication are supported at one time. It is suitable for large customers and multi-project operation scenarios. The introduction of configuration templates and dynamic parameter mapping solves the problems of repeated setting of server domain names and business domain names for each account, avoiding consistency risks and configuration errors in manual operations, supporting active push and visual monitoring of audit results and abnormal errors, greatly shortening problem response time, and improving business continuity assurance capabilities. It has grayscale policy management capabilities and supports batch release by account, region, user group and other dimensions, facilitating testing and risk control.

Claims

1. A method for efficiently managing official accounts and mini-programs on a third-party platform, characterized by: The steps include: Step 1: Authorization submission management sub-process, the specific steps are as follows: Step 1-1: The user logs in through the front-end interface and selects the target application in the front-end interface; Step 1-2: After successfully authenticating the user, the authorization process begins, including generating a pre-authorization QR code, the user scanning the code and completing the WeChat callback to obtain an authorization token; Step 1-3: After successful authorization, obtain authorization data; The user uploads a file, which includes the Mini Program code package and related configuration information; Steps 1-4: Encapsulate the file and authorization data, generate an audit task, and submit it to the WeChat audit client in parallel through the message queue. Adopt an adaptive concurrent scheduling strategy to complete the submission. Steps 1-5: Monitor the audit status through polling, obtain the audit results, generate messages, send messages through multiple channels, and process all interface calls through the unified interface adaptation layer; Steps 1-6: If the audit fails, classify the audit task as an error, record the entire process log, and notify the user to correct the error on the front end, regenerate the audit task, and submit it; Step 2: Template and batch operation sub-process, including the following steps: Step 2-1: After the user defines or selects a standardized mini-program template, the template parameters of the standardized mini-program template are verified and stored, and the user's operation log is recorded and stored; Step 2-2: After the user selects the target application list and template, the variable data of each application is read and a personalized batch review task is generated through parameter mapping; Step 2-3: After queueing the personalized batch review tasks, call the WeChat review interface in parallel to submit them; Steps 2-4: After successful review, the new version will be released in stages according to the grayscale release strategy set by the user. During the grayscale release process, feedback will be collected in real time to automatically adjust the release ratio. When performing steps 2-4: The user sets the grayscale release policy parameters on the front end, including the new version number, target grayscale ratio, and target user attributes; The back-end grayscale release control module obtains grayscale release policy parameters, binds them to the submission results of the review task, generates a grayscale release plan, and records the operation log and TraceID, entering them into the database. The grayscale release control module calls the WeChat interface / wxa / changestatus and releases the content through the interface adaptation layer. Record the release time, release ratio, WeChat interface response and return error code of each stage, generate a release log, and store it in the database; The grayscale release control module collects real-time feedback including error rates. Build an indicator mathematical model, generate control information, and perform the second-stage release or rollback operation after unified processing through the interface adaptation layer; The specific formula of the indicator mathematical model is as follows: ； in, is the error rate, error rate Used to control expansion decisions, when When the second phase is released, ,when When the rollback operation is performed, ; Indicates an operation; Indicates the preset threshold; Step 2-5: Perform unified configuration and format verification on the domain name of the target application, distribute it uniformly through the interface adaptation layer, and record the change in the entire process log.

2. The method for efficiently managing official accounts and mini-programs on a third-party platform according to claim 1, characterized in that: When executing step 1-1, the specific steps include: Step 1-1-1: On the front end, the user fills in the account and password on the login page. The front end encrypts the credentials using HTTPS, generates a request, and submits it to the back end authentication interface; Step 1-1-2: On the backend, after receiving the request, the authentication module verifies the user credentials. If the verification fails, a clear error code and prompt are returned. If the verification succeeds, a session token is generated and the user session data is written. The user session data includes the login time, IP address, and a list of bound applications. Step 1-1-3: Call multi-factor authentication, including sending a text message verification code or TOTP dynamic code to the front-end. After the user enters the code correctly, execute step 1-2; When executing steps 1-2, the specific steps are as follows: Step 1-2-1: The authorization processing module calls the interface adaptation layer to send a request to obtain the component token and pre-authorization code to the WeChat API interface, that is, / cgi-bin / component / api_component_token, and passes the component AppID and Secret parameters to the WeChat API interface; The interface adaptation layer performs unified encapsulation and error handling on the JSON data returned by the WeChat client. The JSON data contains component_access_token. After successfully obtaining the component_access_token, i.e. the component token, call the WeChat API interface and pass in the component token to obtain the pre-authorization code pre_auth_code; Step 1-2-2: During step 1-2-1, detailed logs are recorded for each call throughout the entire process, including request time, parameters, return data, and response latency. The detailed logs are saved in the full-link log library. Step 1-2-3: The authorization processing module uses the pre-authorization code pre_auth_code to construct the authorization QR code URL; The interface adaptation layer uses the HMAC-SHA256 algorithm to uniformly sign the parameters of the authorization QR code URL and send it to the front end; After the front-end receives the authorization QR code URL, it uses the JS QR code generation tool to convert it into a QR code image and display it to the user; Step 1-2-4: The user scans the QR code with WeChat. After WeChat completes the scan, it sends an HTTP callback request to the backend through the pre-configured redirect_uri. The HTTP callback request contains the auth_code information; The callback processing module receives the HTTP callback request, extracts the auth_code, and calls the WeChat API interface / cgi-bin / component / api_query_auth through the interface adaptation layer, passing the auth_code and component_access_token to the WeChat side. The WeChat side returns the return data, which includes the authorizer_access_token, authorizer_refresh_token, and the bound authorizer_appid. The callback processing module verifies the format of the returned data, including validity period verification and signature verification, and encrypts sensitive data using the AES-256 algorithm before storing it in the database; Step 1-2-5: When executing step 1-2-4, the entire process generates a full-link logging session, namely TraceID, and stores it in the database; When executing steps 1-3, specifically: the user uploads the code package and fills in the audit parameters on the front end using HTTPS, and the interface adaptation layer performs HMAC signature verification on the file uploaded by the user; The upload module obtains the file uploaded by the user and verifies the file format. After passing the verification, the file is stored in the object storage and the storage path and metadata are entered into the database. When executing steps 1-4, the specific steps include: Step 1-4-1: The review task management module obtains the filled-in review parameters in the file, including configuration information, code package storage information, and stored authorization data, encapsulates the filled-in review parameters into a review task in JSON format, writes the review task to the task log, and stores it in the database; Step 1-4-2: The task scheduling module pushes the audit task into the message queue and calculates the current allowed number of concurrent tasks based on real-time monitoring indicators. , according to the number of hair Start or adjust thread / coroutine pool; Step 1-4-3: If the task call fails, the task scheduling module retries according to the exponential backoff retry strategy; When executing steps 1-5, the specific steps are as follows: Step 1-5-1: The audit status monitoring module periodically calls the WeChat audit status interface / wxa / get_auditstatus, sends a status request, and obtains the status of the audit task; when sending the status request, it uses a dynamic retry mechanism and uniformly processes the status request through the interface adaptation layer; Step 1-5-2: The audit status monitoring module parses the returned data and enters the audit status into the database. The audit status includes "pending review", "audit passed" or "audit failed"; Step 1-5-3: When the audit status monitoring module parses the errors in the returned data, the audit status monitoring module calls the error code mapping table to classify common errors; Step 1-5-4: Assign a TraceID to each audit task, record the entire audit status from submission to return, and enter it into the database; Step 1-5-5: When a change in the review status is detected, the review status monitoring module generates a message and sends a notification to the front-end through the DingTalk robot interface, SMS or email; the message contains the task ID, status, error details, TraceID and a resubmit link; When executing steps 1-6, the specific steps include: Step 1-6-1: After receiving the audit failure status, the exception handling module parses the error details and classifies the errors according to the preset rules, specifically into parameter configuration errors and system interface call exceptions; Generate security logs based on error details, retry counts, timestamps, and TraceIDs, and enter them into the database; Step 1-6-2: The front-end sends a reminder through a notification, and at the same time displays a detailed error information page in the user management backend, lists the error categories, and marks the recommended modification items. After the user modifies the parameters or re-uploads the file on the front-end, the modification request is submitted to the back-end, and the back-end regenerates the review task and submits it.

3. The method for efficiently managing official accounts and mini-programs on a third-party platform as claimed in claim 2, characterized in that: When executing step 1-1, the backend reads the official account or mini program information bound to the user from the database based on the user ID, and returns the authentication result and application list to the frontend in the form of JSON data. The frontend displays the operation options in the list for the user to check.

4. The method for efficiently managing official accounts and mini-programs on a third-party platform according to claim 2, wherein: When executing steps 1-4-2, calculate the current allowed number of concurrent The specific formula is as follows: ； in, Indicates the baseline concurrency number, which is the number of backend transactions under no-load conditions. Indicates server load; Indicates the maximum load allowed; Indicates the response time of the target interface, which is fixed at 300ms; Indicates the response time of the WeChat interface; Indicates the maximum number of tasks queued that can be backlogged, fixed at 50. Indicates the number of unprocessed tasks in the message queue.

5. The method for efficiently managing public accounts and mini-programs on a third-party platform according to claim 2, wherein: When executing step 2-1, specifically: the user chooses to upload a template file in JSON format on the front end, and the template management module on the back end obtains the template file, verifies the format of each field, and ensures that the placeholder format conforms to the preset regular expression; After verification, the template management module stores the template file and its metadata into the template library database. The metadata includes the template name, version, creation time and field description. Record the entire link log, generate a TraceID and enter it into the database; When executing step 2-2, the specific steps include: Step 2-2-1: The user selects multiple target applications on the front-end interface, selects a template, and uploads the variable mapping data corresponding to the selected target application. The variable mapping data includes the application's AppID and API address; Step 2-2-2: The parameter variable mapping module obtains the variable mapping data. For each target application, it reads the uploaded data of the application, replaces the placeholders one by one according to the selected template to generate a complete configuration string, and generates a review task. The review task includes the application ID, code package path, personalized configuration, template ID, and review status. The review status is "Awaiting Review" at this time. Step 2-2-3: Based on the method in step 2-2-2, batch generate review tasks for each target application; record the replacement operation log for each step, generate the corresponding TraceID, and enter it into the database; When executing steps 2-3, the task scheduling module processes batches of review tasks according to the method of steps 1-4-2. The submission result, response time and error code of each review task are recorded in the log and stored in the database; When executing steps 2-5, the specific steps include: Step 2-5-1: The user uploads the domain name configuration file on the front end in Excel or CSV format. The domain name configuration file includes the domain name and type. The domain name management module obtains and parses the domain name configuration file, converts it into a standard format, and verifies whether the format of each domain name conforms to the preset regular rules; Step 2-5-2: For domain names that fail format verification, an error report will be generated and fed back to the user, requiring them to modify and re-upload; Step 2-5-3: The allocation engine automatically allocates domain names to each target application based on the target application's identification and preset priority sorting rules; Step 2-5-4: Call the WeChat interface / wxa / modify_domain to uniformly distribute domain name configurations through the interface adaptation layer, record the distribution results and return status, generate domain name logs, and enter them into the database.

Images