Model service owner updating method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of data governance, can be applied to the fields of scientific and technological finance and digital medical treatment, and discloses a model business owner updating method and device, an electronic device and a storage medium. The method comprises the following steps: acquiring and analyzing model business owner updating trigger information, determining a target model identifier and a trigger type; according to the target model identifier, extracting current business owner information, model use association information, organization association information and updating rules from model metadata and associated configuration data of a data center; according to the trigger type and the updating rules, performing matching verification on the current business owner information to determine candidate business owner information; generating business owner change information and sending the business owner change information to a corresponding approval node; after the approval is passed, updating business owner information of a target model, synchronizing associated objects according to the model use association information, and generating business owner updating records and results. The method improves the accuracy, traceability and cross-scene collaboration of model business owner updating.

Description

Technical Field

[0001] This application relates to the field of data governance technology and can be applied to the fields of fintech / digital healthcare, particularly to a model business owner update method, apparatus, electronic device, and storage medium. Background Technology

[0002] As data platforms are increasingly applied in fintech, healthcare, and other business sectors, model objects such as data models, indicator models, and dimensional models are typically invoked by multiple business systems, analytics platforms, and application processes. The maintenance responsibility information for these model objects becomes crucial for problem feedback, data quality handling, model iteration, and business collaboration. Traditional data platforms, in managing model objects, typically focus more on technical information such as model structure, field definitions, lineage, and invocation status, while neglecting the timeliness, consistency, and traceability of updating model responsibility information. When business departments adjust, personnel positions change, model maintenance responsibilities are transferred, or models are reused across multiple scenarios, the model responsibility information can easily deviate from the actual maintenance relationship. This leads to unclear problem localization paths, inconsistent information displayed across systems, inaccurate anomaly feedback targets, and difficulty in verifying historical change processes. For example, in fintech scenarios, core indicator models are called by multiple reports and risk control analysis processes. If the information on model responsibility is delayed, data anomalies may not be able to be quickly located to the actual maintenance party. In healthcare scenarios, diagnostic and statistical models or operational analysis models are used by multiple departments. If the responsibility information is inconsistent with the actual division of business, it may affect the confirmation of data standards and the efficiency of model maintenance. Summary of the Invention

[0003] The main technical problems addressed by the implementation method of this application are: untimely updates of business owners in traditional data middleware models, difficulty in tracing change processes, and insufficient collaboration with downstream usage scenarios.

[0004] To address the aforementioned technical problems, the first technical solution adopted in this application is: providing a model business owner update method, comprising: acquiring model business owner update trigger information; parsing the update trigger information; determining a target model identifier and trigger type based on the parsing result; extracting the target model's current business owner information, model usage association information, organizational association information, and business owner update rules from model metadata and associated configuration data in the data platform based on the target model identifier; performing matching verification on the current business owner information based on the trigger type, the current business owner information, the organizational association information, and the business owner update rules; determining candidate business owner information corresponding to the target model based on the verification result; and determining the target model's current business owner information, candidate business owner information, and model usage association information based on the current business owner information, the candidate business owner information, and the model usage association information. The system uses associated information to generate business owner change information and sends the business owner change information to the approval node corresponding to the trigger type; it receives the approval result returned for the business owner change information, and when the approval result indicates that the approval is passed, it updates the business owner information of the target model according to the candidate business owner information to obtain owner update status information; based on the owner update status information and the model usage associated information, it determines the associated objects that have a usage relationship with the target model, and performs business owner information synchronization processing on the associated objects to obtain synchronization processing results; based on the business owner change information, the owner update status information, and the synchronization processing results, it generates a business owner update record and outputs the business owner update record and the synchronization processing results as the model business owner update result.

[0005] To solve the above-mentioned technical problems, the second technical solution adopted in this application is: providing a model business owner update device, comprising: a trigger information parsing module, used to obtain model business owner update trigger information, parse the update trigger information, and determine the target model identifier and trigger type based on the parsing result; an associated data extraction module, used to extract the current business owner information, model usage association information, organization association information, and business owner update rules of the target model from the model metadata and associated configuration data of the data platform based on the target model identifier; an owner matching and verification module, used to perform matching and verification on the current business owner information based on the trigger type, the current business owner information, the organization association information, and the business owner update rules, and determine the candidate business owner information corresponding to the target model based on the verification result; and a change information sending module, used to send change information based on the current business owner information, the candidate business owner information, and the trigger information; and to determine the target model's current business owner information, model usage association information, organization association information, and business owner update rules based on the change information; and a change information sending module, used to send change information based on the change information, the change information, and the change type. The system uses the information and model usage association information to generate business owner change information and sends the business owner change information to the approval node corresponding to the trigger type. The owner information update module receives the approval result returned for the business owner change information. When the approval result indicates approval, it updates the business owner information of the target model according to the candidate business owner information to obtain owner update status information. The associated object synchronization module determines the associated objects that have a usage relationship with the target model based on the owner update status information and the model usage association information, and performs business owner information synchronization processing on the associated objects to obtain a synchronization processing result. The update record output module generates a business owner update record based on the business owner change information, the owner update status information, and the synchronization processing result, and outputs the business owner update record and the synchronization processing result as the model business owner update result.

[0006] To solve the above-mentioned technical problems, the third technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the model business owner update method as described above.

[0007] To solve the above-mentioned technical problems, the fourth technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by an electronic device, the electronic device performs the model service owner update method as described above.

[0008] Unlike related technologies, this application establishes a complete data processing chain around model business owner changes. By parsing update trigger information, the target model and trigger type can be clearly identified, reducing model identification omissions caused by inconsistent change sources. By combining model metadata, organizational association information, model usage association information, and business owner update rules, the validity of the current business owner can be matched and verified, and candidate business owners that better fit the model maintenance relationship can be identified, improving the accuracy of owner determination. Furthermore, business owner change information is generated and matched with approval nodes before the owner information is updated, providing a foundation for process control in the change process. After the owner information update is completed, business owner information synchronization processing can be performed on downstream related objects based on model usage association information, reducing the risk of inconsistencies between model metadata and downstream usage scenarios. Therefore, this application can improve the accuracy, process controllability, cross-scenario consistency, and change traceability of model business owner updates. Attached Figure Description

[0009] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0010] Figure 1 This is a schematic diagram of the operating environment of the model business owner update method provided in the embodiments of this application.

[0011] Figure 2 This is a schematic diagram of the execution flow of the model business owner update method provided in the embodiments of this application.

[0012] Figure 3 This is a schematic diagram of the execution flow for determining candidate business owner information in the model business owner update method provided in this application embodiment.

[0013] Figure 4 This is a schematic diagram of the execution flow of obtaining the synchronization processing result in the model business owner update method provided in the embodiments of this application.

[0014] Figure 5 This is a schematic diagram of the system structure of the model service owner update device provided in the embodiments of this application.

[0015] Figure 6 This is a schematic diagram of the hardware structure of an electronic device for the execution model business owner update method provided in the embodiments of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Software tools, components, or servers not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0017] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0018] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0019] To facilitate understanding of this embodiment, a detailed description of a model business owner update method disclosed in this application embodiment will be provided first. Please refer to [link / reference]. Figure 1 , Figure 1 This is a schematic diagram of the operating environment for the model service owner update method provided in the embodiments of this application, such as... Figure 1 As shown, the execution subject of the model service owner update method provided in this application embodiment is generally an electronic device with a certain computing power, such as a computer device. In some possible implementations, this model service owner update method can be implemented by the processor calling computer-readable instructions stored in the memory. Figure 1 The computer equipment mentioned can be a server. A server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. This can be understood as... Figure 1 The number of computer devices shown is merely illustrative and can be expanded to any number as needed.

[0020] Please continue reading. Figure 2 , Figure 2 This is a schematic diagram of the execution flow of the model business owner update method provided in the embodiments of this application, such as... Figure 2 As shown, it includes the following steps: S1. Obtain the update trigger information of the model business owner, parse the update trigger information, and determine the target model identifier and trigger type based on the parsing results.

[0021] The model business owner update trigger information can be understood as a data-driven event or business request that initiates the owner update process. This type of information typically originates from organizational relationship adjustments, changes in job responsibilities, model maintenance handover, or owner change applications initiated proactively by the business side. It can also originate from business data interactions between organizational relationship data sources such as HR, LDAP, and OA model business owner updates and data platform platforms such as DataWorks, DataArts Studio, and DataHub. Upon receiving this type of information, structured fields such as personnel identifier, model identifier, and change type are parsed to convert the change information in organizational management or business flow into model object information and process type information that the data platform can recognize. The target model identifier mainly serves to locate the model, enabling subsequent processing to accurately target the model object that needs to be determined or updated for business ownership. The trigger type mainly serves to divert the process, enabling subsequent processes to perform differentiated information extraction, rule matching, and approval node selection based on different change reasons. For example, in a fintech scenario, when a maintenance worker for a business analysis model experiences an organizational change due to a job reassignment, resulting in an update to the model's business owner (either an HR model update or an LDAP model update), the system can use the worker's identifier to reverse-engineer the model objects they are responsible for, thus identifying the update as triggered by an organizational change. In a digital healthcare scenario, when a diagnostic statistics model is transferred from the original maintenance team to a new department, the system can directly locate the corresponding model using the model identifier field, and identify the update as triggered by a model maintenance handover based on the change type field. Through this field parsing and model location processing, omissions and errors in owner updates caused by inconsistent trigger information sources and inaccurate model object identification can be reduced.

[0022] As an optional implementation, the execution process of step S1 may further include the following sub-steps S11 to S15.

[0023] S11. Receive organizational relationship change events, model maintenance handover events, or business owner change requests, and set the received events or requests as model business owner update trigger information.

[0024] In step S11, the organizational relationship change event, model maintenance handover event, and business owner change request are different types of owner update initiation conditions. The organizational relationship change event mainly reflects changes in organizational data such as personnel positions, departments, and employment status; the model maintenance handover event mainly reflects the transfer of model maintenance responsibilities between different business personnel or organizational nodes; and the business owner change request mainly reflects owner adjustment needs initiated proactively by the business side. By uniformly setting events or requests from different sources as model business owner update trigger information, change data of different formats and sources can enter a unified data processing flow, providing standardized input for subsequent field parsing and model positioning.

[0025] S12. Parse the fields of the model business owner update trigger information and extract the personnel identifier, model identifier, and change type fields.

[0026] In step S12, field parsing is the process of structuring the model business owner update trigger information. The personnel identifier is used to represent the personnel objects involved in the trigger information, the model identifier field is used to represent whether the trigger information directly carries the model to be processed, and the change type field is used to represent the business reason for this owner update. By extracting the personnel identifier, model identifier, and change type fields, the original event or request can be transformed into data fields that can subsequently participate in querying, matching, and judgment, avoiding the impact of information format differences from different business sources on the continuity of the owner update process.

[0027] S13. When the model identifier field is empty, query the associated model in the model metadata of the data platform according to the personnel identifier, and set the model identifier of the queried associated model as the target model identifier.

[0028] In step S13, when the triggering information does not carry a specific model object, the personnel identifier can serve as the retrieval entry point for model location. The model metadata in the data platform typically records the relationship between the model and the business owner, maintenance personnel, or responsible organization. Therefore, relevant model objects can be retrieved in reverse based on the personnel dimension. This approach can cover scenarios where organizational relationship change events only reflect personnel changes without directly specifying the model object, avoiding interruptions to the owner update process due to missing model location information.

[0029] S14. When the model identifier field is not empty, set the model identifier corresponding to the model identifier field as the target model identifier.

[0030] In step S14, when the triggering information already carries clear model location information, the model object to be processed can be directly determined based on this location information, avoiding the need for personnel to perform reverse association queries on the model. This processing method can shorten the model location path and reduce the identification bias caused by multiple model associations, enabling model maintenance handover or business-side proactive change requests to enter the subsequent owner verification process more quickly.

[0031] S15. Determine the trigger type based on the change type field.

[0032] In step S15, the "Change Type" field is used to distinguish the triggering reasons for model business owner updates. Triggering types can include organizational relationship changes, model maintenance handover, and business owner change requests. Determining the triggering type through the "Change Type" field provides a basis for subsequent business owner update rule matching, candidate business owner identification, and approval node selection. Different triggering types may have different verification focuses and processing paths; therefore, determining the triggering type improves the targeting and accuracy of subsequent owner update processing.

[0033] As an example, a data governance platform in the fintech sector receives a personnel job adjustment message from either the HR (Business Owner Update) or LDAP (LDAP Business Owner Update) model owner update. This message indicates that a business employee has been moved from the business analysis team to the risk management team. The message includes the employee's identifier and the reason for the change, but not the specific model identifier. Parsing the fields in this message allows identification of the original business employee corresponding to the identifier, and identifies this change as an organizational relationship change. Since the message lacks a clear model location field, the platform can retrieve the model object currently maintained by that employee from the model metadata in the data platform based on the employee identifier, and use the retrieved model identifier as the target model identifier for subsequent owner update processing. Similarly, in the digital healthcare field, a department's operational analysis model generates a business owner change request due to a handover of maintenance responsibilities. The request already includes the model identifier and the reason for the change. In this case, the corresponding model object can be directly determined based on the model location field in the request, and the reason for the change can be used to identify that this change is a model maintenance handover type, thus providing a clear data foundation for subsequent owner information extraction, rule verification, and approval node matching.

[0034] Through steps S11 to S15 above, organizational change information, model maintenance handover information, and business owner change requests from different sources can be uniformly converted into model business owner update trigger information. By parsing fields, locating target models, and identifying trigger types, a standardized input basis for the owner update process is established, thereby improving the accuracy of target model identification and reducing the risk of missing owner updates due to missing model identifiers or inconsistent source formats in the trigger information.

[0035] S2. Based on the target model identifier, extract the current business owner information, model usage association information, organizational association information, and business owner update rules of the target model from the model metadata and associated configuration data of the data platform.

[0036] Step S2 involves data extraction and processing. Model metadata can include data describing the model object, such as model name, model type, field definitions, model status, and current business owner field. Related configuration data can include relationship data formed when the model is called by reports, BI, application processes, and data quality alarm processes. Current business owner information reflects the maintenance responsibility object currently recorded by the target model. Model usage association information reflects the calling relationship between the target model and downstream users. Organizational association information can come from organizational relationship data sources such as HR, LDAP, and OA model business owner updates. Business owner update rules can be understood as a set of rules formed around owner validity, candidate owner screening, and approval node matching. For example, in a fintech scenario, an indicator analysis model may be called by both a business analysis dashboard and a risk analysis process, requiring the extraction of the model owner, calling relationship, and scope of impact. In a digital healthcare scenario, a diagnostic statistics model may be used by departmental operational analysis, quality evaluation, and hospital management reports, requiring the extraction of the model's corresponding usage scenario and organizational node information. Through the above data extraction and processing, a structured data foundation can be provided for subsequent verification, approval, and synchronization.

[0037] As an optional implementation, the execution process of step S2 may further include the following sub-steps S21 to S25.

[0038] S21. Based on the target model identifier, query the model basic attributes, current business owner field, and model status field corresponding to the target model in the model metadata of the data platform.

[0039] In step S21, the model metadata serves as the data foundation for the data platform to uniformly manage model objects. It can include information such as model name, model type, business scope, field structure, lifecycle status, release status, and maintenance status. By retrieving the model metadata through the target model identifier, the model object requiring processing can be accurately located, and the owner field and model status field currently recorded in the data platform can be obtained. The basic model attributes reflect the business domain to which the model belongs, the model type, and the model's usage characteristics. The current business owner field reflects the currently registered maintenance responsibility object for the model, and the model status field reflects whether the model is in a state of availability, disuse, pending release, or maintenance, providing foundational data for subsequent owner validity verification and candidate owner matching.

[0040] S22. Based on the current business owner field, extract the current business owner identifier, the organization node to which the current business owner belongs, and the current business owner position status from the target model as the current business owner information.

[0041] In step S22, the current business owner field does not simply represent a person's name, but can be associated with multi-dimensional information such as person identifier, organizational node, and job status. The current business owner identifier can uniquely locate the currently registered owner object; the organizational node to which the current business owner belongs can reflect the business department, team, or organizational level to which the owner belongs; and the current business owner's job status can reflect whether the owner is still in a current position, transferred, resigned, frozen, or unmaintainable state. By extracting the structured data from the current business owner field, a single owner field can be expanded into a data set that can participate in rule validation, thereby improving the accuracy of subsequent judgments on whether the current owner is still suitable for maintaining the target model.

[0042] S23. Based on the target model identifier, query the downstream object identifier, call relationship type, and usage scenario identifier of the target model in the associated configuration data, and use them as model usage association information.

[0043] In step S23, the associated configuration data records the calling relationship between the target model and downstream objects. This can include users such as reports, BI model business owner update pages, application interfaces, data quality tasks, indicator services, or analysis processes. Downstream object identifiers can pinpoint the specific associated objects using the target model. The calling relationship type reflects whether the relationship between the target model and downstream objects is a direct call, indirect reference, indicator dependency, or quality monitoring. The usage scenario identifier reflects whether the target model is applied to scenarios such as business analysis, risk identification, operational statistics, or quality evaluation. By extracting model usage association information, the downstream scope that may be affected by changes in business owner can be clearly identified, providing a basis for subsequent generation of change information, matching approval nodes, and executing synchronous processing.

[0044] S24. Based on the current business owner identifier and the organization node to which the current business owner belongs, extract the corresponding organizational level information, job change information, and organization node status information as organizational association information.

[0045] In step S24, the organizational association information can originate from organizational relationship data sources such as HR, LDAP, and OA model business owner updates, or from pre-maintained organizational mapping data in the data platform. Organizational hierarchy information reflects the hierarchical relationship between the current business owner's organizational node and its superior, peer, and business lines. Job change information reflects whether the current business owner has undergone job adjustments, responsibility migrations, or changes in maintenance relationships. Organizational node status information reflects whether the corresponding organizational node is valid, merged, deactivated, or has undergone affiliation adjustments. By extracting the above organizational association information, owner update judgment can not only rely on static fields in the model metadata but also be dynamically validated in conjunction with organizational structure changes.

[0046] S25. Based on the model's basic attributes, model status fields, and trigger type, match the corresponding owner verification rules, candidate owner determination rules, and approval node matching rules to serve as the business owner update rules.

[0047] In step S25, the business owner update rule is a set of rules configured for different model types, model states, and trigger types. It can include owner verification rules, candidate owner determination rules, and approval node matching rules. Owner verification rules primarily determine whether the current business owner meets the conditions for continuing to maintain the target model. Candidate owner determination rules primarily determine how to select candidate objects from organizational levels, job changes, and business relationships when the current owner does not meet the conditions. Approval node matching rules primarily determine the approval processing nodes corresponding to different change types and different impact ranges. By having the model's basic attributes, model state fields, and trigger types participate in rule matching, subsequent verification, candidate owner determination, and approval workflows can have a unified rule basis.

[0048] As an example, in a fintech scenario, a business analysis model is invoked by multiple management dashboards and risk analysis processes. Based on the model's identifier, the business domain to which the model belongs, the model status, and the currently registered business owner field can be read from the data platform. Furthermore, the personnel identifier, organizational node, and job status of the current business owner can be parsed. Simultaneously, the downstream dashboards, indicator services, or data quality tasks that invoke the model can be identified from the associated configuration data, determining the corresponding invocation relationships and usage scenarios. If the current business owner has undergone a job adjustment during model business owner updates (HR model business owner update or LDAP model business owner update), then organizational hierarchy, job change, and organizational node status can be combined to match owner verification rules, candidate owner determination rules, and approval node matching rules applicable to the model status and trigger type. In digital healthcare scenarios, a certain diagnosis and treatment statistical model is jointly used by the hospital's operational dashboard and departmental quality evaluation reports. Based on the model identifier, the basic attributes of the model, the currently maintained department, and the model status can be read. Combined with the model business owner update OA model business owner update or organizational relationship data source, it can be determined whether the department where the current business owner is located has been adjusted, thereby providing data basis for subsequent owner validity judgment, candidate owner screening, and approval process.

[0049] Through steps S21 to S25, a structured relationship can be formed around the target model, connecting the current business owner, model usage relationships, organizational relationships, and update rules. This allows business owner updates to no longer rely solely on a single owner field, but rather to make a comprehensive judgment based on model status, downstream calling relationships, organizational changes, and rule configurations. Therefore, subsequent matching verification, candidate business owner determination, approval node matching, and downstream synchronization processing can all obtain clear data support, thereby improving the accuracy, controllability, and synergy with downstream usage scenarios in business owner update processing.

[0050] S3. Based on the trigger type, current business owner information, organization association information, and business owner update rules, perform matching and verification of the current business owner information, and determine the candidate business owner information corresponding to the target model based on the verification results.

[0051] Step S3 involves matching verification and candidate business owner determination. Trigger types can differentiate between various business reasons, such as organizational relationship changes, model maintenance handover, and business owner change requests. The verification logic and candidate owner selection logic can differ for different trigger types. The matching verification of the current business owner information combines the current business owner identifier, the organization node to which it belongs, the job status, the organization node status, and the owner update rules to determine whether the current business owner still meets the conditions for model maintenance and business collaboration. When the current business owner has left their post, the organization node to which they belong has been adjusted, or the maintenance responsibilities have been transferred, candidate business owners can be selected based on organizational hierarchy information, job change information, and basic model attributes. For example, in a fintech scenario, if the original maintenance personnel of a risk indicator model are transferred from their original business line, new candidate owners can be selected based on job change information and the business line to which the model belongs. In a digital healthcare scenario, when the department corresponding to a diagnostic statistics model is adjusted, candidate business owners can be determined based on the new department organization node and model maintenance responsibilities. Through the above verification process, the accuracy and interpretability of the candidate owner determination process can be improved.

[0052] As an alternative implementation method, please continue reading. Figure 3 , Figure 3 This is a schematic diagram of the execution flow for determining candidate service owner information in the model service owner update method provided in this application embodiment, as shown below. Figure 3 As shown, the specific steps include S31 to S35.

[0053] S31. Based on the trigger type, determine the corresponding owner verification rule and candidate owner determination rule from the business owner update rule.

[0054] In step S31, the trigger type serves to distribute rules. Different trigger types correspond to different reasons for updating business owners, and therefore require different validation focuses and candidate selection logic. When an organizational relationship change triggers, the rule focus can be on the current owner's job status, organizational node status, and changes in responsibilities. When a model maintenance handover triggers, the rule focus can be on whether the handover object has a model maintenance matching relationship. When a business owner change request triggers, the rule focus can be on the compatibility between the change request object and the model's business attributes. By selecting rules based on trigger type, the same judgment standard can be avoided for all owner changes, improving the targeting of rule matching.

[0055] S32. Based on the owner verification rules, match and verify the current business owner identifier, the organization node to which the current business owner belongs, the current business owner's job status, and the organization node status information to obtain the owner validity verification result.

[0056] In step S32, the owner validity verification mainly determines whether the current business owner still meets the maintenance conditions of the target model. The current business owner identifier can locate the specific owner object, the organizational node to which the current business owner belongs can reflect the business organization to which the owner belongs, the current business owner's job status can reflect whether the owner still has maintenance responsibilities, and the organizational node status information can reflect whether the organization to which the owner belongs is still valid. By matching and verifying the above information, it is possible to identify whether the current business owner has left their post, been transferred, has an invalid organizational node, or has mismatched responsibilities, so as to provide a clear basis for determining whether it is necessary to re-determine candidate owners.

[0057] S33. When the owner validity verification result is that the current business owner information does not meet the owner verification rules, candidate owner objects are selected from the organizational hierarchy information and job change information according to the candidate owner determination rules.

[0058] In step S33, when the current business owner no longer meets the verification conditions, alternative candidate owners need to be selected from organizational relationships and job change data. Organizational hierarchy information reflects the relationships between superior organizations, peer organizations, and business lines, while job change information reflects the responsibility transfer path and personnel job adjustment results. Screening based on candidate owner determination rules prioritizes objects that match the target model's business domain, maintenance responsibilities, and organizational affiliation, avoiding reliance on manual assignment or simple replacement in the candidate owner determination process.

[0059] S34. Based on the basic attributes and status fields of the target model, perform model maintenance and adaptation verification on the candidate owner objects, and determine the candidate business owner information based on the model maintenance and adaptation verification results.

[0060] In step S34, after the initial screening of candidate owners, a suitability assessment is needed based on the business attributes and operational status of the target model. Basic model attributes reflect model type, business domain, data scope, and usage characteristics, while the model status field indicates whether the model is running, disabled, awaiting release, or under maintenance. Through model maintenance suitability verification, it can be determined whether the candidate owner is suitable to assume maintenance responsibility for the current model, ensuring that the final selected candidate business owners match not only the organizational relationship but also the actual maintenance needs of the target model.

[0061] S35. When the owner validity verification result shows that the current business owner information meets the owner verification rules, set the current business owner information as the candidate business owner information.

[0062] In step S35, if the current business owner meets the verification conditions, the current business owner can be used as a candidate business owner. This means that although the triggering information has initiated the owner update judgment process, there is no need to actually change the business owner. This approach avoids unnecessary owner adjustments caused by minor changes in organizational information, irrelevant changes, or repeated triggering, while preserving the processing basis for subsequent approvals, records, and result outputs. This allows the owner update process to simultaneously support change processing and validity confirmation.

[0063] As an example, in a fintech scenario, if the current business owner of a risk analysis model leaves their original business line due to a job adjustment, and the trigger type is identified as an organizational relationship change trigger, owner verification rules focusing on job status and organizational node status can be matched. Based on the current business owner identifier, their affiliated organizational node, job status, and organizational node status, it can be determined that the current business owner no longer meets the maintenance conditions. In this case, by combining the organizational hierarchy of the original business line and the job change path, candidate owner objects can be screened from personnel or organizational nodes still responsible for maintaining this type of model. Furthermore, considering the business domain, model type, and operational status of the risk analysis model, it can be determined whether the candidate owner objects are maintenance adaptable, ultimately determining the candidate business owner. In a digital healthcare scenario, if the department of the current business owner of a diagnostic statistics model has not changed, and both the job status and organizational node status remain valid, and the trigger information comes only from a single duplicate business owner change request, after owner validity verification, the current business owner can continue to be used as a candidate business owner, avoiding unnecessary adjustments to the model maintenance relationship due to invalid changes.

[0064] Through steps S31 to S35, corresponding owner verification logic and candidate owner filtering logic can be selected according to different trigger types. A comprehensive judgment is made on whether the current business owner is still suitable to assume model maintenance responsibility, taking into account the current business owner's personnel status, organizational node status, organizational hierarchy, job change information, and target model attributes. When the current business owner does not meet the verification conditions, candidate business owners can be filtered and verified from organizational relationships and job change data. When the current business owner still meets the verification conditions, the current business owner can continue to be used, avoiding unnecessary owner adjustments. Therefore, the accuracy and stability of candidate business owner determination can be improved, reducing the risk of erroneous owner updates due to personnel changes, organizational adjustments, or repeated triggers.

[0065] S4. Based on the current business owner information, candidate business owner information, and model usage association information, generate business owner change information and send the business owner change information to the approval node corresponding to the trigger type.

[0066] Step S4 involves generating business owner change information and matching approval nodes. Business owner change information can be understood as a structured data object representing a single owner change event. This data object can include the owner before the change, the owner after the change, the target model, the number of users, the type of usage scenario, and the scope of related impacts. The scope of related impacts reflects how many downstream objects call the target model, which business scenarios are involved, and which collaborative links may be affected after the change. Approval nodes are not fixed nodes but can be matched based on the trigger type and the scope of related impacts. For example, in a fintech scenario, when a model is called by multiple business analysis and risk analysis processes, the owner change may require matching with business management nodes and data governance nodes. In a digital healthcare scenario, when a model involves the diagnostic and statistical standards of multiple departments, the owner change may require matching with department management nodes and data management nodes. By generating structured change information and sending it to the approval nodes, the arbitrariness of owner changes can be reduced, and the standardization of the change processing can be improved.

[0067] As an optional implementation, the execution process of step S4 may further include the following sub-steps S41 to S45.

[0068] S41. Generate the mapping relationship before and after the change of business owner based on the current business owner information and the candidate business owner information.

[0069] In step S41, the mapping relationship before and after the change of business owner is used to express the change of the responsible object of the target model before and after the owner update. The current business owner information can reflect the existing owner records in the model metadata, and the candidate business owner information can reflect the owner object to be updated after rule verification. By constructing the mapping relationship between the two, the changes in the original owner, target owner, organizational nodes and responsibility assumption involved in this change can be clarified, providing a structured basis for subsequent generation of change information and approval flow.

[0070] S42. Based on the model usage association information, determine the number of users, usage scenario types, and associated impact range of the target model.

[0071] In step S42, the model usage association information reflects the usage relationship between the target model and downstream objects. The number of downstream objects using the model indicates how many downstream objects call or depend on it; the usage scenario type indicates whether the target model is applied to scenarios such as report analysis, indicator services, data quality alarms, or business application processes; and the scope of association impact indicates the business collaboration links and information synchronization range that may be affected by the change of ownership. By statistically analyzing and identifying the above information, the degree of impact of this change of ownership can be determined, avoiding isolated judgments based solely on the model itself.

[0072] S43. Generate business owner change information based on the mapping relationship before and after the business owner change, the number of users, the type of use scenario, and the scope of related impact.

[0073] In step S43, the business owner change information is a structured description of the current owner change. This information includes not only the owner relationship before and after the change, but also the number of users involved in the target model, the type of usage scenario, and the scope of related impacts. By merging the owner change information and the model usage impact information to generate change information, the approval node can obtain a complete change context, making it easier to determine whether the owner adjustment will affect downstream users, business collaboration processes, and subsequent maintenance responsibilities.

[0074] S44. Based on the trigger type and associated impact range, match the target approval node from the preset approval node configuration and set the target approval node as the approval node corresponding to the trigger type.

[0075] In step S44, the preset approval node configuration can include the correspondence between trigger type, scope of impact, and approval nodes. Different trigger types correspond to different approval concerns, and different scopes of impact may correspond to different approval levels. By combining trigger type and scope of impact to match target approval nodes, the approval process for owner changes can no longer follow a fixed workflow, but rather be differentiated based on the reason for the change and the degree of impact, thereby improving the accuracy of approval path matching and the controllability of change processing.

[0076] S45. Send the business owner change information to the approval node.

[0077] In step S45, after the business owner change information is generated and matched with the approval node, the change information is sent to the approval node, enabling the approval node to confirm and process the change based on the structured change content. This sending process can transmit the mapping relationship before and after the owner change, the number of users, the type of use scenario, and the scope of related impact to the corresponding approval node, providing complete data support for the approval process. This process can reduce the information loss caused by relying on offline communication or manual forwarding for owner changes and improve the standardization of the owner change process.

[0078] As an example, in a fintech scenario, when the current business owner of a business analysis model changes from the original business personnel to a new candidate business owner, a pre- and post-change correspondence can be established between the original and candidate business owners. Based on the model's usage association information, the number of times the model is invoked by the business analysis dashboard, risk monitoring processes, and data quality alarm tasks, along with the scenario types and impact scope, can be statistically analyzed. When the model is associated with multiple downstream users, the pre- and post-change correspondence of the owner, the number of users, the usage scenario types, and the associated impact scope can be combined into business owner change information. Based on the organizational relationship change trigger type and the larger associated impact scope, data governance approval nodes or business management approval nodes can be matched, and then the business owner change information can be sent to the corresponding approval node. In a digital healthcare scenario, when a diagnostic statistics model changes from the original department maintenance personnel to a new maintenance personnel, the associated impact scope can be determined based on the model's invocation by the hospital's operational dashboard, departmental quality evaluation reports, and diagnostic statistics applications. The pre- and post-change owner information and downstream usage impact information can be submitted together to the corresponding approval node, allowing the approval process to simultaneously consider the owner change itself and the impact on related business scenarios.

[0079] Through steps S41 to S45, the changes in responsible parties, downstream usage of the target model, and the scope of related impacts before and after the change of business owner can be structurally integrated. Based on the trigger type and the scope of related impacts, corresponding approval nodes are matched, ensuring that the change of business owner is no longer treated as a single field modification, but rather as a complete change event encompassing the changed object, the scope of impact, and the approval path. Therefore, the accuracy and controllability of the approval process for changes of business owner can be improved, reducing the risks of unclear responsibility handover, mismatched approval paths, and ambiguous downstream impacts during the change of owner process.

[0080] S5. Receive the approval result returned for the change of business owner information. When the approval result indicates that the approval is passed, update the business owner information of the target model according to the candidate business owner information to obtain the owner update status information.

[0081] Step S5 involves processing the approval results and updating the business owner information. The approval status in the approval results serves as the basis for determining whether to update the model metadata. When the approval status is "approved," the candidate business owner identifier and candidate business owner organization node can be written into the target model's business owner field and owner organization field, respectively. The owner information version number and update timestamp can change synchronously with the field updates. The owner information version number can distinguish between different batches of owner information update results, and the update timestamp can record the effective time of this update in the data platform. For example, in a fintech scenario, after the business owner change of a business analysis model is approved, the owner field in the model metadata can be updated from the original business personnel to the new maintenance personnel. In a digital healthcare scenario, after a diagnosis and treatment statistics model is approved and confirmed to be maintained by a new department, the owner organization field in the model metadata can be synchronously changed to the new department node. Through the above processing, a clear correspondence can be established between the approval results and the model metadata changes, avoiding the direct overwriting of existing data by unconfirmed owner information.

[0082] As an optional implementation, the execution process of step S2 may further include the following sub-steps S51 to S55.

[0083] S51. Receive the approval results returned by the approval node for the change of business owner information, and extract the approval status from the approval results.

[0084] In step S51, the approval result is the process feedback data generated after the business owner change has been processed by the approval node. The approval status is a key field for determining whether subsequent model metadata updates are allowed. By extracting the approval status from the approval result, the approval process can be transformed into a control condition for subsequent data update processes, preventing unapproved candidate business owner information from being directly written into the model metadata, thereby improving the controllability of business owner change processing.

[0085] S52. When the approval status is "approved", read the candidate business owner identifier and candidate business owner organization node from the candidate business owner information.

[0086] In step S52, when the approval status is "approved," it indicates that the candidate business owner has been confirmed by the corresponding approval node, and the model metadata update stage can begin. The candidate business owner identifier is used to locate the business owner object to be written, and the candidate business owner organization node is used to determine the organizational affiliation of the business owner. By reading the above information, a clear data source can be provided for subsequent updates to the business owner field and the owner organization field.

[0087] S53. Based on the candidate business owner identifier and the candidate business owner organization node, update the business owner field and owner organization field in the model metadata of the target model.

[0088] In step S53, the business owner field and the owner organization field in the model metadata together constitute the owner registration information of the target model. The business owner field reflects the maintenance responsibility object currently corresponding to the target model, and the owner organization field reflects the organization node where the maintenance responsibility object is located. By synchronously updating the above two fields, the problem of only updating personnel information while the organization affiliation remains at the old organization node can be avoided, ensuring that the responsibility object and organization affiliation of the target model are consistent.

[0089] S54. Update the owner information version number and update timestamp of the target model based on the updated business owner field and owner organization field.

[0090] In step S54, the owner information version number and update timestamp are used to identify the batch and effective time of changes to the business owner information. After the business owner field and owner organization field are updated, the owner information version number is incremented or regenerated, and the corresponding update timestamp is recorded, which makes the owner update results of different batches distinguishable. This process provides a time and version dimension data foundation for subsequent update record generation, synchronization status verification, and historical change tracing.

[0091] S55. Generate owner update status information based on the field update results of the target model, the owner information version number, and the update timestamp.

[0092] In step S55, the owner update status information is a state-based representation of the model metadata update results. It reflects whether the target model's fields have been written, whether the owner information version number has been updated, and whether an update timestamp has been generated. By integrating field update results, version information, and time information into owner update status information, a basis for judgment can be provided for subsequent synchronization processing of associated objects, and structured result data can be provided for the generation of business owner update records.

[0093] As an example, in a fintech scenario, after the business owner change information of a certain business analysis model is confirmed by the approval node, the approval status can be extracted from the returned results. When the approval status is "approved," the personnel identifier and the business organization node corresponding to the candidate business owner are read, and the personnel identifier is written into the business owner field in the model metadata, and the business organization node is written into the owner organization field. After the fields are written, the version number of the model's owner information can be updated, and the update timestamp of this field change is recorded to form a distinguishable batch of owner changes. In a digital healthcare scenario, after a certain diagnosis and treatment statistics model is confirmed by the department management node to be taken over by a new maintenance personnel, the new maintenance personnel identifier and department organization node can be synchronously written into the model metadata, and the owner update status information is generated by combining the field writing results, version number, and update timestamp, so that subsequent downstream reports, operation dashboards, or quality evaluation applications can continue to perform synchronous processing based on this status information.

[0094] Through steps S51 to S55, the approval status returned by the approval node can be used as a control condition for updating model metadata. After approval, the candidate business owner identifier and candidate business owner organization node are written into the business owner field and owner organization field of the target model, respectively, ensuring consistency between the owner object and organization affiliation of the target model. Simultaneously, by updating the owner information version number and update timestamp, distinguishable and traceable owner update batches can be formed. Therefore, subsequent associated object synchronization processing and business owner update record generation can be performed based on clear field update results, version information, and time information, thereby improving the accuracy, controllability, and traceability of business owner updates.

[0095] S6. Based on the owner update status information and model usage association information, determine the associated objects that have a usage relationship with the target model, and perform business owner information synchronization processing on the associated objects to obtain the synchronization processing result.

[0096] Step S6 involves determining the associated objects and synchronizing business owner information. The associated information reflects the usage relationships between the target model and downstream reports, BI model business owner update pages, application interfaces, data quality alarm tasks, and other associated objects. Owner update status information indicates that the target model's business owner information has been updated. Based on the associated object identifier, associated object type, and call relationship type, the associated objects that need to be synchronized can be determined. Different associated objects may have different synchronization fields and methods. For example, in a fintech scenario, the same indicator model may be called by risk analysis dashboards, operational analysis reports, and data quality alarm tasks. After the owner is updated, it needs to be synchronized to the responsible person field or feedback contact person field corresponding to these associated objects. In a digital healthcare scenario, a diagnosis and treatment statistics model may be called by hospital operation dashboards and departmental quality evaluation reports. After the owner is updated, it needs to be synchronized to the maintenance contact person field in the relevant reports or application processes. This synchronization process reduces the problem of updated model metadata but downstream usage scenarios still displaying old owner information.

[0097] As an alternative implementation method, please continue reading. Figure 4 , Figure 4 This is a schematic diagram of the execution flow of obtaining the synchronization processing result in the model business owner update method provided in the embodiments of this application, as shown below. Figure 4 As shown, the specific steps include S61 to S66.

[0098] S61. When the owner update status information is successfully updated to the business owner information of the target model, extract the associated object identifier, associated object type and call relationship type from the model's associated information.

[0099] In step S61, the owner update status information can serve as the basis for initiating downstream synchronization processing. Only after the target model's business owner field and owner organization field have been effectively updated will the associated object synchronization phase begin. This prevents downstream objects from prematurely receiving old or incomplete owner information before the model's metadata has been updated. The model uses the associated object identifier, associated object type, and call relationship type contained in the associated information to perform object location, object classification, and relationship identification, respectively. The associated object identifier uniquely identifies downstream objects using the target model; the associated object type distinguishes different object types such as reports, BI model business owner update pages, indicator services, application interfaces, and data quality tasks; and the call relationship type reflects whether the relationship between the target model and associated objects is a direct call, indirect dependency, indicator reference, quality monitoring, or service call. By extracting the above information after a successful owner update, synchronization processing can be built upon the already effective model owner update results, ensuring a reliable data foundation for subsequent synchronization scope identification and synchronization strategy determination.

[0100] S62. Based on the associated object identifier, associated object type, and call relationship type, determine the associated objects that have a usage relationship with the target model.

[0101] In step S62, the determination of associated objects is based on a structured confirmation of the usage relationship of the target model using object identifiers, object types, and call relationship types. Since the same target model may be reused by multiple downstream objects, or referenced multiple times by the same object through different call relationships, it is necessary to combine multiple dimensions to deduplicate, classify, and merge the relationships of associated objects. The associated object identifier identifies the specific synchronization target; the associated object type determines whether the object belongs to a presentation, service, task, or process class; and the call relationship type determines whether the owner information synchronization needs to be directly written to the associated object or passed to the relevant configuration via a dependency link. Through the above identification process, a set of synchronization objects corresponding to the target model can be formed, ensuring that subsequent business owner information synchronization is not limited to the model metadata itself, but covers the downstream usage scope where the target model actually has a business impact.

[0102] S63. Generate business owner synchronization data corresponding to the target model based on the owner update status information.

[0103] In step S63, the business owner synchronization data is a structured synchronization payload generated for downstream related objects. It can carry information such as the latest business owner identifier, owner organization node, owner information version number, update timestamp, and update result status of the target model. This synchronization data is not a simple copy of candidate business owner information, but is generated based on the owner update status information that the target model has already updated. This ensures that the owner information received by downstream objects is consistent with the effective information in the model metadata. The owner information version number helps related objects determine whether the synchronized data is the latest version, the update timestamp helps related objects record the effective time of the owner information, and the update result status helps related objects determine whether to perform field overwriting or status confirmation. By generating business owner synchronization data in a unified format, synchronization failures or field parsing errors caused by inconsistent data formats among different downstream objects can be reduced.

[0104] S64. Based on the associated object type and the call relationship type, determine the synchronization fields and synchronization methods corresponding to the associated object.

[0105] In step S64, different types of associated objects have different storage fields and receiving methods for business owner information. Therefore, it is necessary to determine differentiated synchronization strategies based on object type and call relationship type. For the business owner update page of a report or model, the business owner information may correspond to the responsible person field, feedback contact person field, or maintainer field in the display configuration. For application interfaces or indicator services, the business owner information may correspond to interface metadata, service responsible person field, or call chain configuration. For data quality tasks, the business owner information may correspond to alarm receiver field, problem handler field, or task maintainer field. The call relationship type also affects the synchronization method. For example, direct call relationships can use the direct field update method, indirect dependency relationships can use the associated configuration update method, and quality monitoring relationships can use the alarm responsibility field update method. By matching the synchronization fields and synchronization methods, the synchronization of business owner information can be made more suitable for the data structure and business usage of different downstream objects, avoiding field mismatch or insufficient synchronization scope caused by using a single synchronization method.

[0106] S65. According to the synchronization field and synchronization method, send the business owner's synchronization data to the associated object and obtain the synchronization feedback information returned by the associated object.

[0107] In step S65, synchronization processing is performed according to the determined synchronization fields and methods, ensuring accurate transmission of synchronized data from the business owner to the corresponding associated objects. Synchronization methods can include API calls, configuration table updates, message pushes, task queue distribution, or internal synchronization tasks within the data platform. The specific method can be determined based on the data receiving capabilities of the associated objects and the type of call relationship. Synchronization fields are used to limit the target fields to be written or updated in this synchronization, preventing irrelevant fields from being overwritten. Synchronization feedback information reflects the processing results of the associated objects on the synchronized data, such as whether reception was successful, whether fields were successfully updated, whether versions are consistent, and whether there are any field mapping anomalies or object unreachability. By receiving synchronization feedback information, a closed-loop synchronization process can be formed, providing a basis for subsequent synchronization status judgment and anomaly compensation.

[0108] S66. Based on the synchronization feedback information, determine the synchronization status of the associated objects, and generate the synchronization processing result based on the associated objects and the synchronization status.

[0109] In step S66, the synchronization feedback information, after parsing, forms the synchronization status for each associated object. Synchronization status can include types such as synchronization successful, synchronization failed, partial field synchronization successful, version conflict, object unreachable, field not found, or waiting for retry. By binding associated objects and synchronization status, synchronization processing results for downstream use scenarios can be obtained. These results reflect whether each downstream object has completed its corresponding owner information update after the target model owner is updated. This processing supports the subsequent generation of business owner update records and provides a basis for compensation processing of abnormal synchronization objects. For example, when some associated objects fail to synchronize, the failed object, failed field, and failure reason can be located based on the synchronization processing results, and then a retry or manual review process can be triggered. Through the above processing, model business owner updates no longer stop at field updates within the data platform but further form a consistency maintenance capability across downstream use scenarios, thereby improving the consistency, traceability, and collaborative processing efficiency of model owner information between the data platform and associated user objects.

[0110] As an example, in a fintech scenario, after the business owner information of a risk analysis model is updated, the associated risk monitoring dashboard, operational analysis report, indicator service, and data quality alarm task can be identified based on the model's associated information. Synchronization strategies are then determined according to the type of the associated object. For the risk monitoring dashboard, the new business owner information can be synchronized to the responsible person field in the page configuration. For the indicator service, the new business owner information can be synchronized to the maintainer field in the service metadata. For the data quality alarm task, the new business owner information can be synchronized to the alarm recipient field or the issue handler field. After synchronization, each associated object returns feedback information such as successful field update, version consistency, or field mapping anomaly. The corresponding synchronization processing result is then generated based on the feedback information. In a digital healthcare scenario, after the business owner information of a medical statistics model is successfully updated, the associated hospital operation dashboard, departmental quality evaluation report, and medical statistics application can be identified. The maintenance contact person field, responsible department field, or feedback handler field that needs to be synchronized can be determined based on the report object, application object, and quality evaluation object, respectively. If some reports are successfully synchronized but a certain application interface fails to synchronize due to inconsistent field mappings, the corresponding associated object and failure status can be recorded in the synchronization processing result to facilitate subsequent retry, verification or manual processing.

[0111] Through steps S61 to S66, after the business owner information of the target model is successfully updated, downstream related objects can be identified based on the model's association information. Differential synchronization fields and methods are determined according to the type of related object and the type of call relationship, enabling the new business owner information to be synchronized to different usage scenarios such as reports, BI pages, application interfaces, indicator services, and data quality tasks. By receiving and parsing the synchronization feedback information returned by related objects, the synchronization status and processing results for each related object can also be generated. Therefore, updating the model's business owner is no longer limited to changes in fields within the model's metadata, but can link downstream users to maintain consistency of responsibility information, thereby reducing the risk of interrupted feedback, unclear maintenance responsibilities, and reduced collaboration efficiency caused by downstream scenarios retaining old owner information.

[0112] S7. Based on the business owner change information, owner update status information, and synchronization processing results, generate a business owner update record and output the business owner update record and synchronization processing results as the model business owner update result.

[0113] Step S7 concerns the generation and output of update records. The business owner update record can be understood as a traceable data record of the entire owner update process. The record content may include business owner change information, owner update status information, synchronization processing results, and synchronization status of related objects. Synchronization processing results reflect whether each related object has completed owner information synchronization, facilitating subsequent anomaly investigation and compensation. For example, in a fintech scenario, if some risk analysis reports are not synchronized after a model owner change, the unsynchronized related objects can be located based on the synchronization processing results. In a digital healthcare scenario, if some departmental operation reports still display the original maintenance personnel after a diagnostic statistics model owner update, the update results and synchronization feedback status can be updated based on the update record verification fields. By generating business owner update records and outputting model business owner update results, the traceability of the owner change process can be enhanced, providing data support for subsequent auditing, review, and anomaly handling.

[0114] The model business owner update method provided in this application, through structured identification, rule-based verification, process-based confirmation, and synchronization of related objects for data related to model business owner changes, eliminates reliance on manual maintenance or single-field modifications for updating model business owner information. Instead, it integrates model metadata, organizational relationship data, model usage relationships, and update rules for comprehensive processing. Since the validity of the current business owner can be determined by considering job status, organizational node status, and model attributes, the risk of owner information remaining in the old state after personnel reassignment, organizational adjustment, or transfer of maintenance responsibilities is reduced, improving the accuracy of model business owner information. Because the process of determining candidate business owners incorporates organizational hierarchy, job changes, and model maintenance adaptation relationships, it avoids mismatches in maintenance responsibilities caused by simply replacing owners, improving the rationality of owner succession relationships. Since the business owner change information includes the pre- and post-change relationships and the scope of model usage impact, and can match approval nodes based on trigger type and scope of impact, it enhances the controllability of the owner change process, reducing arbitrariness in changes and mismatches in approval paths. Since the target model can synchronize downstream related objects based on the associated information after the target model completes the owner update, it reduces the possibility of reports, BI pages, application interfaces, indicator services, or data quality tasks retaining old owner information even after the model metadata has been updated, thereby improving the consistency of responsibility information across systems. Because the update process, update status, and synchronization results can form a business owner update record, it can provide data support for subsequent auditing, review, anomaly investigation, and synchronization compensation. Therefore, this method can improve the accuracy, traceability, collaboration, and processing efficiency of model business owner updates in the data platform.

[0115] Please continue reading. Figure 5 , Figure 5 This is a schematic diagram of the system structure of the model service owner update device provided in the embodiments of this application, such as... Figure 5 As shown, the business owner update device 50 of this model includes: a trigger information parsing module 51, an associated data extraction module 52, an owner matching and verification module 53, a change information sending module 54, an owner information update module 55, an associated object synchronization module 56, and an update record output module 57.

[0116] The trigger information parsing module 51 is specifically used to obtain model business owner update trigger information, parse the update trigger information, and determine the target model identifier and trigger type based on the parsing result; the associated data extraction module 52 is specifically used to extract the current business owner information, model usage association information, organization association information, and business owner update rules of the target model from the model metadata and associated configuration data of the data platform based on the target model identifier; the owner matching and verification module 53 is specifically used to perform matching and verification on the current business owner information based on the trigger type, the current business owner information, the organization association information, and the business owner update rules, and determine the candidate business owner information corresponding to the target model based on the verification result; the change information sending module 54 is specifically used to generate a business owner change based on the current business owner information, the candidate business owner information, and the model usage association information. The system receives and sends the business owner change information to the approval node corresponding to the trigger type. The owner information update module 55 is specifically used to receive the approval result returned for the business owner change information. When the approval result indicates that the approval is passed, the system updates the business owner information of the target model according to the candidate business owner information to obtain owner update status information. The associated object synchronization module 56 is specifically used to determine the associated objects that have a usage relationship with the target model according to the owner update status information and the model usage association information, and perform business owner information synchronization processing on the associated objects to obtain synchronization processing results. The update record output module 57 is specifically used to generate a business owner update record according to the business owner change information, the owner update status information and the synchronization processing results, and output the business owner update record and the synchronization processing results as the model business owner update results.

[0117] As an optional implementation, the trigger information parsing module 51 is specifically used to receive organizational relationship change events, model maintenance handover events, or business owner change requests, and set the received event or request as the model business owner update trigger information; perform field parsing on the model business owner update trigger information to extract personnel identifier, model identifier, and change type fields; when the model identifier field is empty, query the associated model in the model metadata of the data platform according to the personnel identifier, and set the model identifier of the queried associated model as the target model identifier; when the model identifier field is not empty, set the model identifier corresponding to the model identifier field as the target model identifier; and determine the trigger type according to the change type field.

[0118] As an optional implementation, the associated data extraction module 52 is specifically used to query the model basic attributes, current business owner field, and model status field corresponding to the target model in the model metadata of the data platform according to the target model identifier; extract the current business owner identifier, the organization node to which the current business owner belongs, and the current business owner position status of the target model according to the current business owner field, as the current business owner information; query the downstream object identifier, call relationship type, and usage scenario identifier that call the target model in the associated configuration data according to the target model identifier, as the model usage association information; extract the corresponding organizational level information, position change information, and organization node status information according to the current business owner identifier and the organization node to which the current business owner belongs, as the organizational association information; and match the corresponding owner verification rules, candidate owner determination rules, and approval node matching rules according to the model basic attributes, the model status field, and the trigger type, as the business owner update rules.

[0119] As an optional implementation, the owner matching and verification module 53 is specifically used to determine the corresponding owner verification rule and candidate owner determination rule from the business owner update rule according to the trigger type; based on the owner verification rule, to match and verify the current business owner identifier, the organization node to which the current business owner belongs, the current business owner's job status, and the organization node status information to obtain the owner validity verification result; when the owner validity verification result indicates that the current business owner information does not meet the owner verification rule, to filter candidate owner objects from the organization level information and the job change information according to the candidate owner determination rule; to perform model maintenance adaptation verification on the candidate owner objects according to the model basic attributes and model status fields of the target model, and to determine the candidate business owner information according to the model maintenance adaptation verification result; when the owner validity verification result indicates that the current business owner information meets the owner verification rule, to set the current business owner information as the candidate business owner information.

[0120] As an optional implementation, the change information sending module 54 is specifically used to generate a mapping relationship before and after a business owner change based on the current business owner information and the candidate business owner information; determine the number of users, usage scenario type, and associated impact range corresponding to the target model based on the model usage association information; generate the business owner change information based on the mapping relationship before and after a business owner change, the number of users, the usage scenario type, and the associated impact range; match a target approval node from a preset approval node configuration based on the trigger type and the associated impact range, and set the target approval node as the approval node corresponding to the trigger type; and send the business owner change information to the approval node.

[0121] As an optional implementation, the owner information update module 55 is specifically used to receive the approval result returned by the approval node for the business owner change information, and extract the approval status from the approval result; when the approval status is approved, read the candidate business owner identifier and candidate business owner organization node from the candidate business owner information; update the business owner field and owner organization field of the target model in the model metadata according to the candidate business owner identifier and the candidate business owner organization node; update the owner information version number and update timestamp of the target model according to the updated business owner field and owner organization field; and generate the owner update status information according to the field update result of the target model, the owner information version number, and the update timestamp.

[0122] As an optional implementation, the associated object synchronization module 56 is specifically used to: extract the associated object identifier, associated object type, and call relationship type from the model usage association information when the owner update status information indicates that the business owner information of the target model has been successfully updated; determine the associated objects that have a usage relationship with the target model based on the associated object identifier, the associated object type, and the call relationship type; generate business owner synchronization data corresponding to the target model based on the owner update status information; determine the synchronization fields and synchronization methods corresponding to the associated objects based on the associated object type and the call relationship type; send the business owner synchronization data to the associated objects according to the synchronization fields and the synchronization methods, and obtain synchronization feedback information returned by the associated objects; determine the synchronization status of the associated objects based on the synchronization feedback information, and generate the synchronization processing result based on the associated objects and the synchronization status.

[0123] It should be noted that the aforementioned model service owner update device can execute the model service owner update method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the model service owner update device can be found in the model service owner update method provided in the embodiments of this application.

[0124] Figure 6 This is a schematic diagram of the hardware structure of the electronic device for the execution model business owner update method provided in the embodiments of this application, such as... Figure 6 As shown, the electronic device 600 includes: One or more processors 610 and memory 620, Figure 6 Take the 610 processor as an example.

[0125] The processor 610 and the memory 620 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0126] The memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the model service owner update method in the embodiments of this application. The processor 610 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 620, thereby implementing the model service owner update method in the above-described method embodiments.

[0127] The memory 620 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the model service owner update device. Furthermore, the memory 620 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 620 may optionally include memory remotely located relative to the processor 610, and these remote memories may be connected to the model service owner update device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0128] The one or more modules are stored in the memory 620. When executed by the one or more processors 610, they perform the model service owner update method in any of the above method embodiments, for example, the method described above. Figure 2 Method steps S1 to S7, Figure 3 Method steps S31 to S35, Figure 4Method steps S61 to S66 are implemented. Figure 5 The functions of modules 51-57 in the document.

[0129] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0130] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 610 can enable the one or more processors to execute the model business owner update method in any of the above method embodiments, for example, to execute the method described above. Figure 2 Method steps S1 to S7, Figure 3 Method steps S31 to S35, Figure 4 Method steps S61 to S66 are implemented. Figure 5 The functions of modules 51-57 in the document.

[0131] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions that, when executed by an electronic device, enable the electronic device to perform the model service owner update method in any of the above method embodiments, for example, to perform the above-described... Figure 2 Method steps S1 to S7, Figure 3 Method steps S31 to S35, Figure 4 Method steps S61 to S66 are implemented. Figure 5 The functions of modules 51-57 in the document.

[0132] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0133] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0134] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0135] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A model business owner update method, characterized in that, include: Obtain the model business owner update trigger information, parse the update trigger information, and determine the target model identifier and trigger type based on the parsing result; Based on the target model identifier, extract the target model's current business owner information, model usage association information, organization association information, and business owner update rules from the model metadata and associated configuration data of the data platform; Based on the trigger type, the current business owner information, the organization association information, and the business owner update rule, the current business owner information is matched and verified, and the candidate business owner information corresponding to the target model is determined based on the verification result. Based on the current business owner information, the candidate business owner information, and the model usage association information, business owner change information is generated, and the business owner change information is sent to the approval node corresponding to the trigger type; Receive the approval result returned for the business owner change information. When the approval result indicates that the approval is passed, update the business owner information of the target model according to the candidate business owner information to obtain the owner update status information. Based on the owner update status information and the model usage association information, identify the associated objects that have a usage relationship with the target model, and perform business owner information synchronization processing on the associated objects to obtain the synchronization processing result; Based on the business owner change information, the owner update status information, and the synchronization processing result, a business owner update record is generated, and the business owner update record and the synchronization processing result are output as the model business owner update result.

2. The model business owner update method according to claim 1, characterized in that, The process of obtaining model service owner update trigger information, parsing the update trigger information, and determining the target model identifier and trigger type based on the parsing results includes: Receive organizational relationship change events, model maintenance handover events, or business owner change requests, and set the received events or requests as the business owner update trigger information for the model; The model business owner update trigger information is parsed to extract the personnel identifier, model identifier, and change type fields; When the model identifier field is empty, the associated model is queried in the model metadata of the data platform according to the personnel identifier, and the model identifier of the queried associated model is set as the target model identifier; When the model identifier field is not empty, the model identifier corresponding to the model identifier field is set as the target model identifier; The trigger type is determined based on the change type field.

3. The model business owner update method according to claim 1, characterized in that, The step of extracting the current business owner information, model usage association information, organizational association information, and business owner update rules of the target model from the model metadata and associated configuration data of the data platform based on the target model identifier includes: Based on the target model identifier, query the model basic attributes, current business owner field, and model status field corresponding to the target model in the model metadata of the data platform; Based on the current business owner field, extract the current business owner identifier, the organization node to which the current business owner belongs, and the current business owner position status of the target model as the current business owner information; Based on the target model identifier, query the downstream object identifier, call relationship type, and usage scenario identifier that call the target model in the associated configuration data, and use them as the model usage association information; Based on the current business owner identifier and the organization node to which the current business owner belongs, extract the corresponding organizational hierarchy information, job change information and organization node status information as the organization association information; Based on the model's basic attributes, the model's state field, and the trigger type, the corresponding owner verification rules, candidate owner determination rules, and approval node matching rules are matched as the business owner update rules.

4. The model business owner update method according to claim 3, characterized in that, The step of matching and verifying the current business owner information based on the trigger type, the current business owner information, the organization association information, and the business owner update rule, and determining the candidate business owner information corresponding to the target model based on the verification result, includes: Based on the trigger type, determine the corresponding owner verification rule and candidate owner determination rule from the business owner update rule; Based on the owner verification rules, the current business owner identifier, the organization node to which the current business owner belongs, the current business owner's job status, and the organization node status information are matched and verified to obtain the owner validity verification result; When the owner validity verification result indicates that the current business owner information does not meet the owner verification rule, candidate owner objects are selected from the organizational hierarchy information and the job change information according to the candidate owner determination rule. Based on the basic attributes and state fields of the target model, the candidate owner object is subjected to model maintenance and adaptation verification, and the candidate business owner information is determined based on the model maintenance and adaptation verification results. When the owner validity verification result indicates that the current business owner information meets the owner verification rules, the current business owner information is set as the candidate business owner information.

5. The model business owner update method according to claim 1, characterized in that, The step of generating business owner change information based on the current business owner information, the candidate business owner information, and the model usage association information, and sending the business owner change information to the approval node corresponding to the trigger type, includes: Based on the current business owner information and the candidate business owner information, generate a mapping relationship before and after the business owner change; Based on the association information of the model, determine the number of users, the type of use scenario, and the scope of association impact corresponding to the target model; The business owner change information is generated based on the mapping relationship before and after the change of business owner, the number of users, the type of usage scenario, and the scope of related impact. Based on the trigger type and the associated impact range, a target approval node is matched from the preset approval node configuration, and the target approval node is set as the approval node corresponding to the trigger type; Send the business owner change information to the approval node.

6. The model business owner update method according to claim 1, characterized in that, The step of receiving the approval result returned for the business owner change information, when the approval result indicates that the approval is passed, updates the business owner information of the target model according to the candidate business owner information to obtain owner update status information, including: Receive the approval result returned by the approval node for the change of business owner, and extract the approval status from the approval result; When the approval status is "approved", read the candidate business owner identifier and candidate business owner organization node from the candidate business owner information; Based on the candidate business owner identifier and the candidate business owner organization node, update the business owner field and owner organization field of the target model in the model metadata; Based on the updated business owner field and owner organization field, update the owner information version number and update timestamp of the target model; The owner update status information is generated based on the field update results of the target model, the owner information version number, and the update timestamp.

7. The model business owner update method according to claim 1, characterized in that, The step of determining the associated objects that have a usage relationship with the target model based on the owner update status information and the model usage association information, and performing business owner information synchronization processing on the associated objects to obtain the synchronization processing result includes: When the owner update status information indicates that the business owner information of the target model has been successfully updated, the associated object identifier, associated object type, and call relationship type are extracted from the model's association information. Based on the associated object identifier, the associated object type, and the call relationship type, determine the associated object that has a usage relationship with the target model; Based on the owner update status information, generate business owner synchronization data corresponding to the target model; Based on the associated object type and the call relationship type, determine the synchronization fields and synchronization method corresponding to the associated object; According to the synchronization field and the synchronization method, the business owner synchronization data is sent to the associated object, and the synchronization feedback information returned by the associated object is obtained; Based on the synchronization feedback information, the synchronization status of the associated object is determined, and the synchronization processing result is generated based on the associated object and the synchronization status.

8. A model business owner update device, characterized in that, include: The trigger information parsing module is used to obtain the model business owner update trigger information, parse the update trigger information, and determine the target model identifier and trigger type based on the parsing result; The associated data extraction module is used to extract the current business owner information, model usage association information, organizational association information, and business owner update rules of the target model from the model metadata and associated configuration data of the data platform based on the target model identifier. The owner matching and verification module is used to match and verify the current business owner information according to the trigger type, the current business owner information, the organization association information and the business owner update rule, and determine the candidate business owner information corresponding to the target model based on the verification result; The change information sending module is used to generate business owner change information based on the current business owner information, the candidate business owner information and the model usage association information, and send the business owner change information to the approval node corresponding to the trigger type; The owner information update module is used to receive the approval result returned for the business owner change information. When the approval result indicates that the approval is passed, the module updates the business owner information of the target model according to the candidate business owner information to obtain owner update status information. The associated object synchronization module is used to determine the associated objects that have a usage relationship with the target model based on the owner update status information and the model usage association information, and to perform business owner information synchronization processing on the associated objects to obtain the synchronization processing result; The update record output module is used to generate a business owner update record based on the business owner change information, the owner update status information, and the synchronization processing result, and output the business owner update record and the synchronization processing result as the model business owner update result.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the model business owner update method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the model service owner update method according to any one of claims 1-7.

Images