A service configuration processing method, device and equipment

Abstract

The embodiment of the specification discloses a service configuration processing method, device and equipment, the method comprises the following steps: receiving service demand information of a target service; based on the service demand information, performing intent analysis through a first large model to generate service configuration information of the target service; based on the service configuration information of the target service, acquiring a scene rule matched with the service configuration information of the target service from a preset scene rule library, and performing risk checking processing on the service configuration information of the target service through the acquired scene rule to obtain a corresponding risk checking result; based on the obtained risk checking result and the service configuration information of the target service, performing service configuration processing of the target service.

Description

Technical Field

[0001] This document relates to the field of computer technology, and in particular to a method, apparatus and device for processing business configuration. Background Technology

[0002] With the rapid development of various businesses, large-scale business expansion has become a core strategic approach for seizing market share and building long-term competitive barriers. The rapid integration of one organization (1-N) or business into another has become a crucial link supporting large-scale business expansion. However, in the actual integration process, it is necessary to simultaneously complete the configuration adjustments of multiple core systems, including heterogeneous systems such as DRM systems, databases, parameter centers, and permission management platforms, involving numerous changes and verifications of configuration items. The current integration process is highly complex, carries significant risks from manual operation, lacks unified control methods, and incurs high labor costs, resulting in low business configuration efficiency. Therefore, it is necessary to build a better business configuration mechanism to ensure high-quality integration for organizations while reducing manual intervention costs and improving overall integration and business configuration efficiency. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to build a better business configuration mechanism, thereby ensuring high-quality access for institutions while reducing the cost of manual intervention and improving the overall access efficiency and business configuration efficiency.

[0004] To achieve the above technical solution, the embodiments in this specification are implemented as follows: This specification provides an embodiment of a service configuration processing method, the method comprising: receiving service requirement information for a target service; performing intent analysis based on the service requirement information using a first major model to generate service configuration information for the target service; obtaining scenario rules matching the service configuration information from a preset scenario rule base based on the service configuration information of the target service, and performing risk verification processing on the service configuration information of the target service using the obtained scenario rules to obtain corresponding risk verification results; and performing service configuration processing for the target service based on the obtained risk verification results and the service configuration information of the target service.

[0005] This specification provides an embodiment of a service configuration processing apparatus, comprising: a service requirement module for receiving service requirement information for a target service; a configuration generation module for generating service configuration information for the target service based on the service requirement information and through intent analysis using a first model; a first verification module for obtaining scene rules matching the service configuration information of the target service from a preset scene rule base based on the service configuration information of the target service, and performing risk verification processing on the service configuration information of the target service using the obtained scene rules to obtain a corresponding risk verification result; and a configuration module for executing the service configuration processing of the target service based on the obtained risk verification result and the service configuration information of the target service.

[0006] This specification provides an embodiment of a service configuration processing device, comprising: a processor; and a memory configured to store computer-executable instructions, wherein the executable instructions, when executed, cause the processor to: receive service requirement information for a target service; perform intent analysis based on the service requirement information using a first model to generate service configuration information for the target service; based on the service configuration information for the target service, obtain scene rules matching the service configuration information for the target service from a preset scene rule base, and perform risk verification processing on the service configuration information for the target service using the obtained scene rules to obtain a corresponding risk verification result; and execute the service configuration processing for the target service based on the obtained risk verification result and the service configuration information for the target service.

[0007] This specification also provides a storage medium for storing computer-executable instructions. When executed by a processor, the executable instructions implement the following process: receiving business requirement information for a target service; performing intent analysis based on the business requirement information using a first major model to generate business configuration information for the target service; obtaining scene rules matching the business configuration information from a preset scene rule base based on the business configuration information of the target service, and performing risk verification processing on the business configuration information of the target service using the obtained scene rules to obtain corresponding risk verification results; and executing the business configuration processing of the target service based on the obtained risk verification results and the business configuration information of the target service.

[0008] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the following process: receiving business requirement information for a target business; performing intent analysis based on the business requirement information using a first major model to generate business configuration information for the target business; obtaining scenario rules matching the business configuration information from a preset scenario rule base based on the business configuration information of the target business, and performing risk verification processing on the business configuration information of the target business using the obtained scenario rules to obtain corresponding risk verification results; and executing the business configuration processing of the target business based on the obtained risk verification results and the business configuration information of the target business. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 This is a schematic diagram of the structure of a processing system for one service configuration described in this specification; Figure 2 This is a schematic diagram illustrating the processing procedure for one type of service configuration described in this manual. Figure 3 This is a schematic diagram illustrating the processing procedure for another business configuration described in this manual. Figure 4 This is a schematic diagram illustrating the processing procedure for yet another business configuration described in this manual. Figure 5 This is a schematic diagram illustrating the risk verification process for one type of business configuration information in this specification. Figure 6 This is a schematic diagram illustrating the processing procedure for yet another business configuration described in this manual. Figure 7 This is a schematic diagram illustrating the construction process of a data table as described in this specification; Figure 8 A schematic diagram of the processing system for another business configuration specified in this manual; Figure 9 This is a schematic diagram of the processing system for another business configuration described in this specification; Figure 10 This is a schematic diagram of a processing device for one service configuration described in this specification; Figure 11 This is a schematic diagram of a processing device for one service configuration described in this specification. Detailed Implementation

[0010] This specification provides a method, apparatus, and device for processing service configuration through its embodiments.

[0011] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0012] This specification provides a risk detection mechanism for business configuration of a target business. With the rapid development of various businesses, large-scale business expansion has become a core strategic tool for seizing market share and building long-term competitive barriers. The rapid integration of an organization (1-N) or business into another business has become a crucial link supporting large-scale business expansion. However, in the actual integration process, it is necessary to simultaneously complete the configuration adjustments of multiple core systems, including DRM systems, databases, parameter centers, permission management platforms, and other heterogeneous systems. This involves numerous changes and verifications of configuration items, resulting in high labor costs and the risk of overlooking anomalies. Current integration processes are highly complex, involving multiple systems and intricate dependencies. Furthermore, manual operation carries significant risks, easily leading to configuration omissions, accidental deletion of historical configurations, and field errors. Moreover, there is a lack of unified control measures, with each system maintained independently, making global consistency verification difficult. Labor costs are high, relying on experienced maintenance personnel to verify each item, resulting in low efficiency and difficulty in replication. Therefore, the current access methods severely impact the quality of institutional access. To address this, a systematic, automated, and intelligent configuration risk monitoring mechanism is needed to identify potential risks in advance, provide timely feedback to management, and achieve pre-emptive prevention, in-process alerts, and post-event verification of configuration errors. This will comprehensively improve configuration accuracy, ensure high-quality institutional access while reducing manual intervention costs, improving overall access efficiency, and ensuring the security, stability, and sustainable development of institutional access. With the rapid development of various businesses, the rapid integration of an institution (1-N) or business into another business faces significant challenges. During business configuration, the involved configuration platforms are dispersed, and the configuration process is complex and prone to errors. To improve access efficiency and security, a "system configuration risk detection mechanism" is proposed to achieve real-time monitoring and intelligent verification of configurations across multiple systems, including DRM, databases, and parameter centers, covering the entire chain from pre-emptive prevention to in-process alerts and post-event verification. Through automated configuration experience empowerment, problem feedback, and process standardization, manual input costs will be reduced, configuration errors will be minimized, and stable business operation will be ensured, while maintaining high efficiency, replicability, and scalability. Specific details can be found in the following embodiments.

[0013] The service configuration processing method provided in one or more embodiments of this specification is applicable to the implementation environment of service configuration processing. (Refer to...) Figure 1 The implementation environment includes at least: Client 100 and server 200. Furthermore, server 200 may include the primary model, various other models, and various algorithms, among others. Client 100 can run on terminal devices, which can be mobile phones, personal computers, tablets, e-book readers, wearable devices, devices that interact with information based on AR (Augmented Reality) and VR (Virtual Reality), and laptop computers, etc. Client 100 can be installed on terminal devices. Client 100 can be an application, a browser, or a subroutine embedded in an application, etc.

[0014] Server 200 can run on a server, which can be one or more servers, a server cluster consisting of several servers, or a cloud server on a cloud computing platform. Server 200 can be installed on the server. Server 200 can be an application or a subroutine embedded in an application. The main model, various different models, and various different algorithms can be integrated into server 200. Alternatively, server 200 can call any one or more of the main model, various different models, and various different algorithms to perform corresponding operations.

[0015] In addition, it may include a database 300, which may be set in the server on which the server 200 runs, or outside the server on which the server 200 runs. The database 300 may store relevant information such as business requirement information, business configuration information, scenario rule base, and risk verification results.

[0016] In this implementation environment, server 200 can receive business requirement information for the target service sent by client 100. Based on this business requirement information, server 200 can perform intent analysis through the first major model to generate business configuration information for the target service. Then, based on the business configuration information of the target service, server 200 can obtain scenario rules that match the business configuration information of the target service from a preset scenario rule base. Server 200 can then perform risk verification processing on the business configuration information of the target service using the obtained scenario rules to obtain the corresponding risk verification results. Finally, based on the obtained risk verification results and the business configuration information of the target service, server 200 can execute the business configuration processing of the target service.

[0017] like Figure 2As shown in the embodiments of this specification, a method for processing business configuration is provided. The execution subject of this method can be a terminal device or a server, etc. The terminal device can be a mobile terminal device such as a mobile phone or tablet computer, a computer device such as a laptop or desktop computer, or an IoT device (specifically, a smartwatch, in-vehicle device, etc.). The server can be a single server or a server cluster composed of multiple servers. The server can be a backend server in fields such as finance or online shopping, or a backend server of an application. This embodiment uses a server as the execution subject for detailed description. For the case where the execution subject is a terminal device, please refer to the following server case processing, which will not be repeated here. The method may specifically include the following steps: In step S202, service requirement information for the target service is received.

[0018] The target business can be any business requiring configuration processing. This configuration processing can involve adjusting the configurations of one or more business systems simultaneously when one institution or business connects to another. For example, for credit businesses such as credit card repayment and installment payments, when an institution connects to these businesses, it needs to simultaneously adjust the configurations of multiple core systems, including heterogeneous systems such as DRM systems, databases, parameter centers, and permission management platforms. This involves numerous changes and verifications of configuration items. Business requirement information can also be information related to the configuration requirements of the target business. This information can be determined based on user-inputted text data (e.g., user-inputted text data can be used as business requirement information), or it can be determined based on user-inputted voice data (e.g., user-inputted voice data can be converted into text data and used as business requirement information). The specific details can be set according to the actual situation.

[0019] In practice, when an organization or business needs to access another business (i.e., the target business), it can determine the business requirements for the target business based on the organization or business to be accessed and the relevant information of the target business. Then, through a designated webpage or application, the user can input the business requirements for the target business. After input, the user's terminal device can obtain the input business requirements for the target business and provide it to the server. The server can receive the business requirements for the target business.

[0020] In step S204, based on the aforementioned business requirement information, intent analysis is performed using the first major model to generate business configuration information for the target business.

[0021] The primary model can be constructed using BERT or a large language model, depending on the specific circumstances. The primary model can be a large model used for intent analysis of business requirements. It can be a pre-trained model obtained directly from a specified database; it can also be an architecture built using a specified algorithm and / or machine learning network, trained with a large amount of sample data; or it can be a pre-trained large model, fine-tuned using a certain amount of sample data, resulting in the primary model. The specific configuration can be determined based on the actual situation.

[0022] In implementation, corresponding prompts can be generated based on the aforementioned business requirement information. These prompts can be text input into the primary model, guiding it to generate outputs that meet the requirements. A prompt can be a question, an instruction, or a piece of context, helping the primary model better understand and respond to various queries. Prompts can include explicit instruction-type prompts, context-supplementary prompts, and example-guided prompts. By providing detailed background information and examples, prompts help the primary model generate more relevant and accurate outputs. Both the aforementioned prompts and the business requirement information can be input into the primary model. The prompts guide the model to extract keywords from the business requirement information. These keywords can then be used for requirement parsing to determine the corresponding configuration items and their configuration information. Finally, based on these determined configuration items and their configuration information, the target business configuration information can be generated.

[0023] In step S206, based on the business configuration information of the target business, scenario rules that match the business configuration information of the target business are obtained from the preset scenario rule library, and the business configuration information of the target business is subjected to risk verification processing through the obtained scenario rules to obtain the corresponding risk verification results.

[0024] Scenario rules are rules used to perform risk verification on configuration items (or scenarios) corresponding to specified configuration information in business configuration information. Corresponding scenario rules can be set based on the attribute information of the configuration item (or scenario). Furthermore, scenario rules can be added or removed based on actual business needs. Scenario rules can be determined based on actual business characteristics and / or expert experience. Scenario rules can include dedicated, customized rules, as well as general rules. For example, scenario rules can include verification of whether the generated business configuration information matches the business requirement information, whether there are any omissions in business configuration information, and whether there are any errors in business configuration information. Specific rules can be set according to the actual situation.

[0025] In implementation, a correspondence between business configuration information and scenario rules can be pre-built. When setting the above correspondence, a correspondence can be established between the configuration items (such as the identifier of the configuration items) in the business configuration information and the corresponding scenario rules. Alternatively, an intermediate item can be set for the business configuration information and scenario rules, and a correspondence can be established between the intermediate item and the business configuration information and the scenario rules respectively, thereby associating the business configuration information with the scenario rules. Alternatively, the business configuration information can be subjected to specified processing to obtain the corresponding processing result, and a correspondence can be established between the processing result and the scenario rules. The specific settings can be set according to the actual situation.

[0026] After establishing the correspondence between business configuration information and scenario rules using the above method, the scenario rules matching the target business's business configuration information can be searched from a pre-set scenario rule library based on the obtained business configuration information. Specifically, this involves determining the configuration information corresponding to one or more different configuration items included in the target business's configuration information and obtaining the scenario tag information corresponding to each configuration item. The scenario rule library pre-stores the correspondence between different scenario tag information and scenario rules, allowing the acquisition of scenario rules corresponding to the scenario tag information in the scenario rule library based on the scenario tag information corresponding to the configuration information of each configuration item in the business configuration information. Based on this process, business configuration information can correspond to one scenario rule or multiple different scenario rules.

[0027] Risk verification processing can be performed on the business configuration information of the target business by obtaining the scenario rules. Specifically, the risk verification processing of the business configuration information of the target business can be performed by the executable script (such as Groovy script) corresponding to the scenario rule. The configuration information of different configuration items can be processed for risk verification using their corresponding scenario rules. In this way, the result of risk verification processing of the corresponding configuration information by each scenario rule can be obtained. The results obtained above can be summarized to obtain the corresponding risk verification result.

[0028] In step S208, based on the obtained risk verification results and the service configuration information of the target service, the service configuration processing of the target service is performed.

[0029] In implementation, based on the information recorded in the obtained risk verification results, configuration information in the target service that exhibits inconsistencies, errors, or mismatches can be adjusted. Then, the adjusted service configuration information can be subjected to risk verification processing using the scenario rules obtained above, yielding the corresponding risk verification results. If the risk verification result indicates no risk, the adjusted service configuration information can be used as the final service configuration information for the target service. Then, based on the final service configuration information, the target service's service configuration processing can be executed to complete the service configuration. If the risk verification result indicates risk, the above risk verification processing can continue until the risk verification result indicates no risk.

[0030] In practical applications, the specific process of adjusting the business configuration information of the target business based on the information recorded in the obtained risk verification results can be implemented through a large model. A specified prompt message can be generated based on the obtained risk verification results and the business configuration information of the target business. This prompt message can be input into the large model, which will guide the large model to adjust the business configuration information of the target business based on the obtained risk verification results, and finally obtain the final business configuration information of the target business.

[0031] This specification provides a method for processing service configuration. It involves receiving service requirement information for a target service, then performing intent analysis based on this information using a first-level model to generate service configuration information for the target service. Next, based on this service configuration information, it retrieves scenario rules matching the target service's configuration information from a pre-defined scenario rule base. The retrieved scenario rules are then used to perform risk verification processing on the target service's configuration information to obtain corresponding risk verification results. Finally, based on the obtained risk verification results and the target service's configuration information, it executes the service configuration processing for the target service. For heterogeneous configuration scenarios across multiple systems, a unified business configuration process and risk verification mechanism are established. When a new institution connects, it only needs to fill in its business requirements information. The large model automatically generates business configuration information and triggers risk verification of the business configuration information, enabling risk control over the entire process of institution access configuration from multiple dimensions. This improves access efficiency and security. Moreover, through automated detection and prompting mechanisms, even non-technical personnel can complete standardized configuration, lowering the access threshold. It can cover the entire chain of pre-emptive prevention, in-process reminders, and post-event verification, reducing manual input costs, minimizing configuration errors, ensuring stable business operation, and possessing high efficiency, replicability, and promotional value.

[0032] In practical applications, the specific processing method of step S208 can vary. The following provides another optional processing method, which may specifically include the processing of steps S2082 to S2086. Based on this, in the above... Figure 2 Based on this, the specific steps included in this method can be as follows: Figure 3 As shown.

[0033] In step S2082, if the risk detection result indicates that there is configuration information for a risk configuration item in the above-mentioned business configuration information, then the configuration information for the risk configuration item is sent to the administrator.

[0034] Among them, risk configuration items can be configuration items with preset risks, which may include configuration information errors, inconsistencies or mismatches.

[0035] In implementation, such as Figure 4 As shown, a requirements management platform can be pre-configured. This platform receives business requirements for a target business and triggers the first major model to generate the business configuration information for that target business. Subsequently, the requirements management platform can also generate configuration work orders, which can be submitted to the parameter center or the DRM real-time link for approval. If the risk detection results indicate the presence of risky configuration items in the aforementioned business configuration information, an early warning can be issued. Specifically, the configuration information for the risky configuration item can be sent to the management.

[0036] In step S2084, the corrected configuration information returned by the management is received, and the service configuration information of the target service is updated based on the corrected configuration information to obtain the updated service configuration information.

[0037] In step S2086, the service configuration processing of the target service is performed based on the updated service configuration information.

[0038] In practical applications, in addition to the business requirement-based triggering methods in steps S202 to S208 above, risk verification processing can also include other triggering methods, as detailed in steps A2 to A6 below.

[0039] In step A2, when a change is detected in the first configuration information of the target service's service configuration information, the first scenario tag information corresponding to the changed first configuration information is determined.

[0040] The first configuration information can be the configuration information of any configuration item in the business configuration information. The first scenario tag information can include one or more of the following: business customization, general business, general resource installment, customized resource installment business, resource repayment, and resource installment solution access.

[0041] In implementation, the processing of steps S202 to S208 above is triggered by business requirement information. In practical applications, it can also include risk verification processing triggered by configuration information changes that are not related to business requirements. Based on this, such as Figure 4 As shown, a perception platform can be pre-configured in the server to detect changes in configuration information in real time. When the perception platform detects a change in the first configuration information in the business configuration information of the target business, it can obtain the first scene tag information corresponding to the changed first configuration information and perform tagging processing on the changed first configuration information so that the changed first configuration information has the first scene tag information.

[0042] In step A4, based on the first scene tag information, the first scene rule corresponding to the first scene tag information is obtained from the preset scene rule library, and the risk verification processing of the changed first configuration information is performed through the first scene rule to obtain the corresponding first risk verification result.

[0043] In implementation, such as Figure 5 As shown, based on the first scene label information (such as...) Figure 5 The resource installment plan is general, the transaction plan is general, the resource installment plan is customized, and the business is customized, etc., from the preset scenario rule base (such as...). Figure 5The system retrieves the first scenario rule corresponding to the first scenario tag information from the general rules, new pricing scheme rules, and old pricing scheme rules. The modified first configuration information can then be subjected to risk verification using the executable script corresponding to the first scenario rule (such as a Groovy script). Specific processing methods are detailed in the aforementioned content and will not be repeated here. The first risk verification result obtained as described above can indicate that the modified first configuration information is risk-free or that it presents a risk.

[0044] In step A6, the first risk verification result is sent to the management.

[0045] In implementation, the first risk verification result (including risk configuration items and corresponding configuration information, etc.) can be sent in real time through the message broker Msgbroker and routed to the corresponding management party through the business configuration to effectively reach the risk work order.

[0046] Based on the processing in steps A2 to A6 above, the configuration information can be made more reasonable and standardized, including the reasonableness of the enumerated values ​​of specific fields, the numerical value, and the standardization of the traffic switching configuration. Moreover, through the above processing, unexpected change points can be detected in real time, such as abnormal pricing scheme configurations. In addition, the risk of changes in configuration information corresponding to information other than business requirement information can be intercepted.

[0047] In practical applications, in addition to the triggering methods of the business requirement dimension in steps S202 to S208 and the triggering methods of the real-time change dimension in steps A2 to A6, risk verification processing can also include the triggering method of the inspection dimension. For details, please refer to the processing of steps B2 to B6 below.

[0048] In step B2, when the preset inspection cycle is reached, the business configuration information of the target business is subjected to risk verification processing based on the acquired scenario rules. If a change in the second configuration information in the business configuration information is detected during the risk verification process, the second scenario tag information corresponding to the changed second configuration information is determined.

[0049] The inspection cycle can be set according to actual conditions, such as 12 hours, 1 day, or 7 days. The second configuration information can be the configuration information of any configuration item in the business configuration information. The second scenario tag information can include one or more of the following: customized transaction card business, general business, general resource installment, customized resource installment business, resource repayment, and resource installment solution access.

[0050] In implementation, such as Figure 4As shown, an inspection cycle can be preset. When the preset inspection cycle is reached, the business configuration information of the target business is subjected to risk verification processing based on the acquired scenario rules. For details, please refer to the aforementioned related content. During the risk verification processing of the above-mentioned business configuration information, configuration information that is not perceived in real time can be monitored. When a change in the second configuration information in the business configuration information is detected, the second scenario tag information corresponding to the changed second configuration information can be obtained, and the changed second configuration information can be tagged so that the changed second configuration information has the second scenario tag information.

[0051] In step B4, based on the second scene tag information, the second scene rule corresponding to the second scene tag information is obtained from the preset scene rule library, and the risk verification processing of the changed second configuration information is performed through the second scene rule to obtain the corresponding second risk verification result.

[0052] In implementation, such as Figure 5 As shown, based on the second scene label information (such as...) Figure 5 The resource installment plan includes general, general business, and customized business scenarios, etc., based on a pre-defined scenario rule base (such as...). Figure 5 The second scenario rule corresponding to the second scenario tag information can be obtained from the general verification rules, new pricing scheme rules, old pricing scheme rules, etc. The risk verification of the changed second configuration information can be performed through the executable script corresponding to the second scenario rule (such as Groovy script, etc.). For specific processing methods, please refer to the relevant content mentioned above, which will not be repeated here.

[0053] In step B6, the second risk verification result is sent to the management.

[0054] Based on the processing in steps B2 to B6 above, the configuration information can be made more reasonable and standardized, including the reasonableness of the enumerated values ​​of specific fields, the numerical value, and the standardization of the traffic switching configuration. Moreover, through the above processing, unexpected change points can be detected in real time, such as abnormal pricing scheme configurations. In addition, the risk of changes in configuration information corresponding to information other than business requirement information can be intercepted.

[0055] In practical applications, the target business is a resource-related business. The scenario tag information corresponding to the business configuration information of the target business includes one or more of the following: business customization, general business, general resource installment, customized resource installment business, resource repayment, and resource installment scheme access. The scenario rules in the scenario rule base include one or more of the following: scenario customization verification rules, general verification rules, consistency verification rules, new pricing scheme rules, old pricing scheme rules, model inference verification rules, and traffic comparison verification rules.

[0056] In practical applications, the scene rules in the scene rule base can also be adjusted according to the actual situation. The following is an optional processing method, which can include the following steps C2 and C4.

[0057] In step C2, an adjustment request for scene rules in the scene rule base is received. The adjustment request includes one or more of the following: adding scene rules, deleting scene rules, and modifying scene rules.

[0058] During implementation, scene rules can be adjusted based on business needs or organizational access change type verification customization mechanisms. At this time, a request to adjust scene rules in the scene rule library can be sent to the server through terminal devices. This adjustment request can be used to trigger one or more of the following requirements: adding scene rules, deleting scene rules, or modifying scene rules.

[0059] In step C4, based on the above adjustment request, the scene rules in the scene rule base are adjusted accordingly.

[0060] During implementation, new scenario rules can be added to the scenario rule base according to the above adjustment requests, or specified scenario rules can be deleted from the scenario rule base, or specified scenario rules in the scenario rule base can be modified, etc. The specific settings can be made according to the actual situation.

[0061] In practical applications, the specific processing methods for performing risk verification on the business configuration information of the target business using the acquired scenario rules in step S206 to obtain the corresponding risk verification results can vary. The following provides another optional processing method, which may specifically include the processing steps S2062 and S2064. Based on this, in the above... Figure 2 Based on this, the specific steps included in this method can be as follows: Figure 6 As shown.

[0062] In step S2062, target data for risk verification is obtained from a preset data source. The data in the data source is obtained after data cleaning and data aggregation processing of the pre-acquired source data.

[0063] In practice, to process the various types of data mentioned above, a data layer can be set up. The data layer is used to clean and aggregate data involving business relationships, and transform it into a format that the verification layer can understand. This allows the source data to be obtained when performing risk verification. Specifically, source data can be obtained from a preset data source. Then, the obtained source data can be cleaned and aggregated to obtain valid data. Target data for risk verification can be obtained from the obtained valid data.

[0064] In step S2064, based on the target data, the business configuration information of the target business is subjected to risk verification processing through the acquired scenario rules to obtain the corresponding risk verification results.

[0065] In implementation, the acquired scenario rules can be used to execute the corresponding executable scripts (such as Groovy scripts). The executable scripts can then be used to perform risk verification on the business configuration information of the target business based on the target data, and obtain the corresponding risk verification results.

[0066] In practical applications, the above source data can be determined in the following way, as detailed in steps D2 and D4 below.

[0067] In step D2, the method of obtaining source data is determined according to the business attributes of the target business. This method includes one or more of offline import, real-time change and active query. Offline import is to collect the historical data corresponding to the business attributes of the target business into a preset data table. Real-time change is based on the data change log and supplements the changed data recorded in the data change log into the preset data table.

[0068] In implementation, the information sources for the data layer can include three parts. Relevant businesses can choose the most suitable data acquisition method based on their own business attributes: offline import, real-time modification, and active query. For offline import, the data comes from offline tables, used to aggregate historical data into a preset data table to avoid the loss of historical change data. This data table can be used for multi-data source dimension validation, for example, in scenarios where a change in table A requires a certain value to exist in table B. This data table can be obtained after aggregation, for example... Figure 7 As shown, data tables A, B, and C are derived from the pre-defined data tables by decomposing common indexes. Subsequent data can be retrieved using index queries. For real-time changes, the data originates from data change logs generated by DB or OB changes (such as binary logs, binlogs). The real-time changed data is added to the pre-defined data tables to ensure consistency between the data source and the change source data. For proactive queries, the data source is directly connected to the server interface. For some single-dimensional risk verification processing, without relying on other data sources, proactive queries are more convenient than queries using the pre-defined data tables.

[0069] In step D4, source data is obtained based on the determined source data acquisition method.

[0070] Additionally, it should be noted that successful integration cases can be compiled into standard configuration templates and compliance checklists, forming a "one-click integration" capability. Furthermore, "experience assetization" can be achieved, accumulating expert experience and automating its implementation to lower the business configuration threshold.

[0071] This specification provides a method for processing service configuration. It involves receiving service requirement information for a target service, then performing intent analysis based on this information using a first-level model to generate service configuration information for the target service. Next, based on this service configuration information, it retrieves scenario rules matching the target service's configuration information from a pre-defined scenario rule base. The retrieved scenario rules are then used to perform risk verification processing on the target service's configuration information to obtain corresponding risk verification results. Finally, based on the obtained risk verification results and the target service's configuration information, it executes the service configuration processing for the target service. For heterogeneous configuration scenarios across multiple systems, a unified business configuration process and risk verification mechanism are established. When a new institution connects, it only needs to fill in its business requirements information. The large model automatically generates business configuration information and triggers risk verification of the business configuration information, enabling risk control over the entire process of institution access configuration from multiple dimensions. This improves access efficiency and security. Moreover, through automated detection and prompting mechanisms, even non-technical personnel can complete standardized configuration, lowering the access threshold. It can cover the entire chain of pre-emptive prevention, in-process reminders, and post-event verification, reducing manual input costs, minimizing configuration errors, ensuring stable business operation, and possessing high efficiency, replicability, and promotional value.

[0072] In addition, it can automatically compare the consistency of key configuration items (such as organization codes, permission policies, and routing rules) across different platforms, identify omissions, conflicts, or accidental deletions, and achieve "one-stop change, global awareness," reducing business anomalies caused by inconsistent cross-system business configurations. Moreover, scenario rules are easy to plug and play, and can be customized and modified according to different business scenarios. Furthermore, successful access cases can be accumulated into standard configuration templates and compliance checklists, forming a "one-click access" capability. It can also realize "experience assetization," accumulating expert experience and automating empowerment, lowering the threshold for business configuration.

[0073] The above describes the service configuration processing method provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a service configuration processing system, such as... Figure 8 As shown.

[0074] The processing system configured for this service includes: a verification layer, a data layer, and a verification trigger layer, wherein: The verification trigger layer receives business requirement information for the target business. The verification layer, based on the business requirement information, performs intent analysis using the first major model to generate business configuration information for the target business; based on the business configuration information of the target business, it retrieves scenario rules matching the business configuration information of the target business from a preset scenario rule base, and performs risk verification processing on the business configuration information of the target business using the retrieved scenario rules to obtain the corresponding risk verification results; based on the obtained risk verification results and the business configuration information of the target business, it executes the business configuration processing of the target business. The data layer cleanses and aggregates data related to business relationships, transforming it into a format that the verification layer can understand, so that the source data can be obtained when performing risk verification processing.

[0075] In practical applications, such as Figure 9 As shown, the verification trigger layer may also include DB (Database), DRM (Digital Rights Management), CICADA database, ROCOCO database, and an institutional access requirement management platform, etc.

[0076] In practical applications, such as Figure 9 As shown, the data layer can include a business data module, a DRC (Data Replication Center) module, and a data table module. The business data module can include business data related to resource repayment, business gateways, and resource phase-out. This business data can be stored in the DRC module or platform database through offline import, real-time modification, and active querying. Data from the DRC module can be aggregated into the data table module, which can provide capabilities such as organizational aggregation and model transformation. Furthermore, it can also offer data subscription functionality. The DRC module can include DDPS (Distributed Dynamic Points Storage), OB (OceanBase), and relational databases such as ORCAL. In addition, real-time change processing can be performed for data changes from platforms like CICADA to obtain the updated data.

[0077] In practical applications, such as Figure 9 As shown, the verification layer can include a data processing module, a scene dynamic engine, and a risk notification module. When the verification layer receives a verification trigger from the verification trigger layer (including business requirement information trigger, real-time change perception, and inspection, etc.), the data processing module can perform data model transformation and scene parsing. The scene dynamic engine can perform scene tag matching, data completion, script loading, and rule decision-making. Finally, the risk trigger module can provide work order notification and risk handling.

[0078] The specific processing of the above-mentioned verification trigger layer, verification layer and data layer can be found in the aforementioned related content, and will not be repeated here.

[0079] also, Figure 9 The system also includes configuration error points, which can be used to record the locations where risks or errors are likely to occur during business configuration. These can include things like accidental deletion or omission of DB, DRM omission, parameter center configuration errors, inconsistencies between business requirement information and business configuration information, and omission of deployment configuration.

[0080] This specification provides a service configuration processing system. It receives service requirement information for a target service, then performs intent analysis based on this requirement information using a first-level model to generate service configuration information for the target service. Next, based on this service configuration information, it retrieves scenario rules matching the target service's configuration information from a pre-set scenario rule base. The retrieved scenario rules are then used to perform risk verification processing on the target service's configuration information to obtain corresponding risk verification results. Finally, based on the obtained risk verification results and the target service's configuration information, it executes the service configuration processing for the target service. For heterogeneous configuration scenarios across multiple systems, a unified business configuration process and risk verification mechanism are established. When a new institution connects, it only needs to fill in its business requirements information. The large model automatically generates business configuration information and triggers risk verification of the business configuration information, enabling risk control over the entire process of institution access configuration from multiple dimensions. This improves access efficiency and security. Moreover, through automated detection and prompting mechanisms, even non-technical personnel can complete standardized configuration, lowering the access threshold. It can cover the entire chain of pre-emptive prevention, in-process reminders, and post-event verification, reducing manual input costs, minimizing configuration errors, ensuring stable business operation, and possessing high efficiency, replicability, and promotional value.

[0081] In addition, it can automatically compare the consistency of key configuration items (such as organization codes, permission policies, and routing rules) across different platforms, identify omissions, conflicts, or accidental deletions, and achieve "one-stop change, global awareness," reducing business anomalies caused by inconsistent cross-system business configurations. Moreover, scenario rules are easy to plug and play, and can be customized and modified according to different business scenarios. Furthermore, successful access cases can be accumulated into standard configuration templates and compliance checklists, forming a "one-click access" capability. It can also realize "experience assetization," accumulating expert experience and automating empowerment, lowering the threshold for business configuration.

[0082] Based on the same idea, embodiments of this specification also provide a service configuration processing device, such as... Figure 10 As shown.

[0083] The processing device for this service configuration includes: a service requirement module 1001, a configuration generation module 1002, a first verification module 1003, and a configuration module 1004, wherein: Business Requirements Module 1001 receives business requirements information for the target business. The configuration generation module 1002, based on the business requirement information, performs intent analysis through the first major model to generate the business configuration information of the target business; The first verification module 1003, based on the business configuration information of the target business, obtains the scenario rules that match the business configuration information of the target business from a preset scenario rule library, and performs risk verification processing on the business configuration information of the target business through the obtained scenario rules to obtain the corresponding risk verification results. The configuration module 1004 performs the business configuration processing of the target service based on the obtained risk verification result and the business configuration information of the target service.

[0084] In this embodiment of the specification, the configuration module 1004 includes: If the risk detection result indicates that there is configuration information for a risk configuration item in the service configuration information, the risk sending unit sends the configuration information for the risk configuration item to the management party. The update unit receives the corrected configuration information returned by the management party, and updates the service configuration information of the target service based on the corrected configuration information to obtain the updated service configuration information. The configuration unit performs the service configuration processing of the target service based on the updated service configuration information.

[0085] In the embodiments described in this specification, the device further includes: When the detection module detects a change in the first configuration information in the service configuration information of the target service, it determines the first scenario tag information corresponding to the changed first configuration information. The second verification module, based on the first scene tag information, obtains the first scene rule corresponding to the first scene tag information from the preset scene rule library, and performs risk verification processing on the changed first configuration information through the first scene rule to obtain the corresponding first risk verification result; The first result sending module sends the first risk verification result to the management.

[0086] In the embodiments described in this specification, the device further includes: The inspection module performs risk verification processing on the business configuration information of the target business by acquiring scenario rules when the preset inspection cycle is reached. If a change in the second configuration information in the business configuration information is detected during the risk verification process, the second scenario tag information corresponding to the changed second configuration information is determined. The third verification module, based on the second scene tag information, retrieves the second scene rule corresponding to the second scene tag information from the preset scene rule library, and performs risk verification processing on the changed second configuration information through the second scene rule to obtain the corresponding second risk verification result; The second result sending module sends the second risk verification result to the management.

[0087] In the embodiments of this specification, the scene rules in the scene rule base include one or more of the following: scene-customized verification rules, general verification rules, consistency verification rules, model inference verification rules, and traffic comparison verification rules.

[0088] In the embodiments described in this specification, the device further includes: The adjustment request module receives adjustment requests for scene rules in the scene rule base, and the adjustment request includes one or more of the following: adding scene rules, deleting scene rules, and modifying scene rules. The rule adjustment module adjusts the scene rules in the scene rule base according to the adjustment request.

[0089] In this embodiment of the specification, the first verification module 1003 includes: The data acquisition unit acquires target data for risk verification from a preset data source, wherein the data in the data source is obtained after data cleaning and data aggregation processing of the pre-acquired source data; The verification unit, based on the target data, performs risk verification processing on the business configuration information of the target business through the acquired scenario rules, and obtains the corresponding risk verification results.

[0090] In the embodiments described in this specification, the device further includes: The data acquisition method determination module determines the acquisition method of the source data based on the business attributes of the target business. The acquisition method includes one or more of offline import, real-time change and active query. The offline import is to collect the historical data corresponding to the business attributes of the target business into a preset data table. The real-time change is based on the data change log and supplements the changed data recorded in the data change log into the preset data table. The data acquisition module acquires the source data based on the determined acquisition method of the source data.

[0091] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more embodiments of this specification, the functions of each module or unit can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative; the division of each module and unit is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or modules can be combined or integrated into another system, or some features can be ignored or not executed, etc.

[0092] This specification provides a service configuration processing device. It receives service requirement information for a target service, then performs intent analysis based on this information using a first model to generate service configuration information for the target service. Next, it retrieves scenario rules matching the target service's configuration information from a preset scenario rule base, and performs risk verification processing on the target service's configuration information using these rules to obtain corresponding risk verification results. Finally, based on the obtained risk verification results and the target service's configuration information, it executes the service configuration processing for the target service. For heterogeneous configuration scenarios across multiple systems, a unified business configuration process and risk verification mechanism are established. When a new institution connects, it only needs to fill in its business requirements information. The large model automatically generates business configuration information and triggers risk verification of the business configuration information, enabling risk control over the entire process of institution access configuration from multiple dimensions. This improves access efficiency and security. Moreover, through automated detection and prompting mechanisms, even non-technical personnel can complete standardized configuration, lowering the access threshold. It can cover the entire chain of pre-emptive prevention, in-process reminders, and post-event verification, reducing manual input costs, minimizing configuration errors, ensuring stable business operation, and possessing high efficiency, replicability, and promotional value.

[0093] In addition, it can automatically compare the consistency of key configuration items (such as organization codes, permission policies, and routing rules) across different platforms, identify omissions, conflicts, or accidental deletions, and achieve "one-stop change, global awareness," reducing business anomalies caused by inconsistent cross-system business configurations. Moreover, scenario rules are easy to plug and play, and can be customized and modified according to different business scenarios. Furthermore, successful access cases can be accumulated into standard configuration templates and compliance checklists, forming a "one-click access" capability. It can also realize "experience assetization," accumulating expert experience and automating empowerment, lowering the threshold for business configuration.

[0094] The above describes the service configuration processing apparatus provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide a service configuration processing device, such as... Figure 11 As shown.

[0095] The processing equipment for the service configuration can be a terminal device or a server, as described in the above embodiments.

[0096] The processing device configured for the service can vary significantly due to differences in configuration or performance. It may comprise a communication interface 1102, a user interface 1104, a processor 1106, and data storage 1108. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 1110. The communication interface 1102 enables the processing device 1100 configured for the service to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 1102 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 1102 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 1102 may also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 1102 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0097] User interface 1104 includes receiving user input and providing output to the user. Therefore, user interface 1104 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 1104 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 1104 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, service-configured processing device 1100 may support remote access from other devices via communication interface 1102 or another physical interface (not shown). User interface 1104 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 1104 can also be configured as a display device for rendering or displaying text fragments.

[0098] Processor 1106 may include one or more general-purpose processors and / or special-purpose processors.

[0099] Data storage 1108 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 1106. Data storage 1108 may include removable and non-removable components.

[0100] Processor 1106 is capable of executing program instructions 1118 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 1108 to perform the various functions described herein. Data storage 1108 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by the service-configured processing device 1100, enable the service-configured processing device 1100 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 1118 by processor 1106 may result in processor 1106 using data 1112.

[0101] For example, program instructions 1118 may include an operating system 1122 (e.g., an operating system kernel, device drivers, and / or other modules) and one or more applications 1120 (e.g., a browser, social application, or game application) installed on the processing device 1100 in the business configuration. Similarly, data 1112 may include operating system data 1116 and application data 1114. Operating system data 1116 is primarily accessible to the operating system 1122, while application data 1114 is primarily accessible to one or more applications 1120. Application data 1114 may reside in a file system that is visible or hidden from the user of the processing device 1100 in the business configuration.

[0102] Application 1120 can communicate with operating system 1112 through one or more application programming interfaces (APIs). These APIs help application 1120 read and / or write application data 1114, transmit or receive information via communication interface 1102, receive or display information on user interface 1104, etc.

[0103] In some terminology, application 1120 may be simply referred to as "app". Furthermore, application 1120 can be downloaded to the business-configured processing device 1100 through one or more online app stores or app markets. However, the application can also be installed on the business-configured processing device 1100 in other ways, such as through a web browser or a physical interface on the business-configured processing device 1100 (e.g., a USB port).

[0104] Specifically, in this embodiment, the service configuration processing device 1100 includes a data storage 1108 and one or more program instructions 1118, wherein one or more program instructions 1118 are stored in the data storage 1108, and one or more program instructions 1118 are configured to be executed by one or more processors. The one or more program instructions include computer-executable instructions for performing the following: Receive business requirement information for the target business; Based on the aforementioned business requirement information, intent analysis is performed using the first major model to generate the business configuration information for the target business. Based on the business configuration information of the target business, scenario rules that match the business configuration information of the target business are obtained from a preset scenario rule base, and the business configuration information of the target business is subjected to risk verification processing through the obtained scenario rules to obtain the corresponding risk verification results. Based on the obtained risk verification results and the business configuration information of the target business, the business configuration processing of the target business is performed.

[0105] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for processing devices with service configurations are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0106] This specification provides a service configuration processing device. It receives service requirement information for a target service, then performs intent analysis based on this requirement information using a first major model to generate service configuration information for the target service. Next, based on this service configuration information, it retrieves scenario rules matching the target service's configuration information from a preset scenario rule base. The retrieved scenario rules are then used to perform risk verification processing on the target service's configuration information to obtain corresponding risk verification results. Finally, based on the obtained risk verification results and the target service's configuration information, it executes the service configuration processing for the target service. For heterogeneous configuration scenarios across multiple systems, a unified business configuration process and risk verification mechanism are established. When a new institution connects, it only needs to fill in its business requirements information. The large model automatically generates business configuration information and triggers risk verification of the business configuration information, enabling risk control over the entire process of institution access configuration from multiple dimensions. This improves access efficiency and security. Moreover, through automated detection and prompting mechanisms, even non-technical personnel can complete standardized configuration, lowering the access threshold. It can cover the entire chain of pre-emptive prevention, in-process reminders, and post-event verification, reducing manual input costs, minimizing configuration errors, ensuring stable business operation, and possessing high efficiency, replicability, and promotional value.

[0107] Furthermore, based on the above Figures 1 to 7 This specification also provides a storage medium for storing computer-executable instruction information in one or more embodiments. In one specific embodiment, the storage medium may be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by a processor, it can realize the following process: Receive business requirement information for the target business; Based on the aforementioned business requirement information, intent analysis is performed using the first major model to generate the business configuration information for the target business. Based on the business configuration information of the target business, scenario rules that match the business configuration information of the target business are obtained from a preset scenario rule base, and the business configuration information of the target business is subjected to risk verification processing through the obtained scenario rules to obtain the corresponding risk verification results. Based on the obtained risk verification results and the business configuration information of the target business, the business configuration processing of the target business is performed.

[0108] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described storage medium embodiment is basically similar to the method embodiment, so the description is relatively simple; relevant parts can be referred to the description of the method embodiment.

[0109] This specification provides a storage medium that receives business requirement information for a target business. Based on this information, it performs intent analysis using a first large model to generate business configuration information for the target business. Then, based on this configuration information, it retrieves matching scenario rules from a pre-defined scenario rule base and performs risk verification on the target business configuration information using these rules, obtaining corresponding risk verification results. Finally, based on the obtained risk verification results and the target business configuration information, it executes the target business configuration process. This establishes a unified business configuration process and risk verification mechanism for heterogeneous configuration scenarios across multiple systems. When a new organization connects, it only needs to fill in business requirement information. The large model automatically generates business configuration information and triggers risk verification of the business configuration information, achieving full-process, multi-dimensional risk control for organization access configuration. This improves access efficiency and security. Furthermore, through automated detection and prompting mechanisms, even non-technical personnel can complete standardized configuration, lowering the access threshold. It covers the entire chain of pre-emptive prevention, in-process reminders, and post-process verification, reducing manual input costs, minimizing configuration errors, ensuring stable business operation, and possessing high efficiency, replicability, and promotional value.

[0110] Furthermore, based on the above Figures 1 to 7 This specification also provides one or more embodiments of a computer program product, including a computer program, which, when executed by a processor, can perform the following processes: Receive business requirement information for the target business; Based on the aforementioned business requirement information, intent analysis is performed using the first major model to generate the business configuration information for the target business. Based on the business configuration information of the target business, scenario rules that match the business configuration information of the target business are obtained from a preset scenario rule base, and the business configuration information of the target business is subjected to risk verification processing through the obtained scenario rules to obtain the corresponding risk verification results. Based on the obtained risk verification results and the business configuration information of the target business, the business configuration processing of the target business is performed.

[0111] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the above-described embodiment of a computer program product is relatively simple in description because it is fundamentally similar to the method embodiment; relevant parts can be referred to the description of the method embodiment.

[0112] This specification provides a computer program product that receives business requirement information for a target service. Based on this information, it performs intent analysis using a first major model to generate business configuration information for the target service. Then, based on this configuration information, it retrieves matching scenario rules from a pre-set scenario rule base and performs risk verification processing on the target service's configuration information using these rules, obtaining corresponding risk verification results. Finally, based on the obtained risk verification results and the target service's configuration information, it executes the target service's configuration processing. For heterogeneous configuration scenarios across multiple systems, a unified business configuration process and risk verification mechanism are established. When a new institution connects, it only needs to fill in its business requirements information. The large model automatically generates business configuration information and triggers risk verification of the business configuration information, enabling risk control over the entire process of institution access configuration from multiple dimensions. This improves access efficiency and security. Moreover, through automated detection and prompting mechanisms, even non-technical personnel can complete standardized configuration, lowering the access threshold. It can cover the entire chain of pre-emptive prevention, in-process reminders, and post-event verification, reducing manual input costs, minimizing configuration errors, ensuring stable business operation, and possessing high efficiency, replicability, and promotional value.

[0113] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than those shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are possible or may be advantageous. Moreover, although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only execution order. Therefore, when method steps are involved in the claims, adjustments to the order of those steps, or parallelism between steps, are also within the scope of protection of the claims.

[0114] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0115] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0116] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0117] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0118] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0119] The embodiments described herein are illustrated with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0120] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0121] These computer program instructions may also be loaded onto a computer or other programmable device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0122] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0123] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0124] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0125] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical or equivalent elements in the process, method, article, or apparatus that includes said element. Furthermore, "a," "an," and "the" are not specifically singular and may also include plural. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to distinguish objects. For example, "first server" and "second server" usually refer to two servers; to distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server. Moreover, in this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can be indirect receiving and sending (i.e., receiving and sending indirectly through one or more entities). Similarly, in this specification, unless otherwise stated, the relationships between structures can be direct or indirect.

[0126] Furthermore, the specific terms used in this specification to describe embodiments, such as "an embodiment," "one embodiment," or "some embodiments," refer to a particular feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. Moreover, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples, without contradiction.

[0127] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0128] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0129] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0130] The above description is merely an embodiment of this specification and is not intended to limit this document. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims in this document.

Claims

1. A method for processing business configuration, the method comprising: Receive business requirement information for the target business; Based on the aforementioned business requirement information, intent analysis is performed using the first major model to generate the business configuration information for the target business. Based on the business configuration information of the target business, scenario rules that match the business configuration information of the target business are obtained from a preset scenario rule base, and the business configuration information of the target business is subjected to risk verification processing through the obtained scenario rules to obtain the corresponding risk verification results. Based on the obtained risk verification results and the business configuration information of the target business, the business configuration processing of the target business is performed.

2. The method according to claim 1, wherein the step of performing the service configuration processing of the target service based on the obtained risk verification result and the service configuration information of the target service includes: If the risk detection result indicates that there is configuration information for a risky configuration item in the business configuration information, then the configuration information for the risky configuration item will be sent to the administrator. Receive the corrected configuration information returned by the management party, and update the service configuration information of the target service based on the corrected configuration information to obtain the updated service configuration information; The target service's service configuration processing is performed based on the updated service configuration information.

3. The method according to claim 1, further comprising: When a change is detected in the first configuration information of the target service's service configuration information, the first scenario tag information corresponding to the changed first configuration information is determined. Based on the first scene tag information, the first scene rule corresponding to the first scene tag information is obtained from the preset scene rule library, and the risk verification processing of the changed first configuration information is performed through the first scene rule to obtain the corresponding first risk verification result. The first risk verification result is sent to the administrator.

4. The method according to claim 1, further comprising: When the preset inspection cycle is reached, the business configuration information of the target business is subjected to risk verification processing based on the acquired scenario rules. If a change in the second configuration information in the business configuration information is detected during the risk verification process, the second scenario tag information corresponding to the changed second configuration information is determined. Based on the second scenario tag information, the second scenario rule corresponding to the second scenario tag information is obtained from the preset scenario rule library, and the risk verification processing of the changed second configuration information is performed through the second scenario rule to obtain the corresponding second risk verification result; The second risk verification result is sent to the management.

5. The method according to claim 3 or 4, wherein the scene rules in the scene rule base include one or more of scene-customized verification rules, general verification rules, consistency verification rules, model inference verification rules, and traffic comparison verification rules.

6. The method according to claim 1, further comprising: Receive an adjustment request for scene rules in the scene rule base, the adjustment request including one or more of adding scene rules, deleting scene rules, and modifying scene rules; Based on the adjustment request, the scene rules in the scene rule base are adjusted accordingly.

7. The method according to claim 1, wherein the step of performing risk verification processing on the business configuration information of the target business through the acquired scenario rules to obtain the corresponding risk verification result includes: Target data for risk verification is obtained from a preset data source, wherein the data in the data source is obtained after data cleaning and data aggregation processing of the pre-acquired source data; Based on the target data, the business configuration information of the target business is subjected to risk verification processing through the acquired scenario rules to obtain the corresponding risk verification results.

8. The method according to claim 7, further comprising: Based on the business attributes of the target business, the method of obtaining the source data is determined. The method of obtaining the data includes one or more of offline import, real-time modification and active query. Offline import is to collect the historical data corresponding to the business attributes of the target business into a preset data table. Real-time modification is based on the data change log and supplements the changed data recorded in the data change log into the preset data table. The source data is obtained based on the determined method of obtaining the source data.

9. A service configuration processing apparatus, the apparatus comprising: The business requirements module receives business requirements information for the target business. The configuration generation module, based on the business requirement information, performs intent analysis through the first major model to generate the business configuration information for the target business; The first verification module, based on the business configuration information of the target business, obtains scenario rules that match the business configuration information of the target business from a preset scenario rule library, and performs risk verification processing on the business configuration information of the target business through the obtained scenario rules to obtain the corresponding risk verification results; The configuration module performs the business configuration processing of the target service based on the obtained risk verification results and the business configuration information of the target service.

10. A service configuration processing device, the service configuration processing device comprising: processor; as well as A memory configured to store computer-executable instructions, which, when executed, cause the processor to: Receive business requirement information for the target business; Based on the aforementioned business requirement information, intent analysis is performed using the first major model to generate the business configuration information for the target business. Based on the business configuration information of the target business, scenario rules that match the business configuration information of the target business are obtained from a preset scenario rule base, and the business configuration information of the target business is subjected to risk verification processing through the obtained scenario rules to obtain the corresponding risk verification results. Based on the obtained risk verification results and the business configuration information of the target business, the business configuration processing of the target business is performed.

Images