A multi-dimensional view object replication and synchronization method based on a low-code platform

Abstract

The present application provides a multi-dimensional view object replication and synchronization method based on a low-code platform, which belongs to the field of software development and data management technology, including: performing dimension level judgment on dimension information to confirm target dimension information, and collecting source view object metadata based on the target dimension information; performing conflict check on the target dimension information and the source view object metadata to obtain a pre-check result; performing incremental replication and synchronization processing based on the pre-check result, the source view object metadata and the change increment to obtain extended view object metadata and mapping relationship.

Description

Technical Field

[0001] This application belongs to the field of software development and data management technology, and specifically relates to a multi-dimensional view object replication and synchronization method based on a low-code platform. Background Art

[0002] As enterprise application systems continue to grow in complexity, especially with the widespread adoption of low-code development platforms, metadata management between view objects (VOs) and business entities (BEs) has become a crucial aspect of system development and maintenance. In actual development, users often need to copy the view object structure from one dimension to another, such as copying the card dimension in a form to the list dimension, to reuse the interface layout or expand functionality.

[0003] The traditional approach is to fully copy the entire view object structure and manually adjust the fields, nodes, and mapping relationships. While this method is simple and straightforward, it has significant drawbacks in practice: on the one hand, full copying is inefficient, especially when the metadata volume is large and the structure is complex; on the other hand, it can easily lead to problems such as field name conflicts, node duplication, and BE mapping errors, which can cause system operation anomalies or functional failures. Furthermore, existing technologies lack an effective verification mechanism for the existing metadata of the target dimension, making it impossible to identify potential conflicts before copying, which increases the workload of subsequent debugging and repair. Summary of the Invention

[0004] In order to solve at least one technical problem existing in the background technology, the present application provides a multi-dimensional view object replication and synchronization method based on a low-code platform.

[0005] The technical solutions adopted in this application are:

[0006] The first embodiment of the present application provides a multi-dimensional view object replication and synchronization method based on a low-code platform, including:

[0007] Performing dimension level judgment on the dimension information to confirm target dimension information, and collecting source view object metadata based on the target dimension information;

[0008] Performing a conflict check on the target dimension information and the source view object metadata to obtain a pre-check result;

[0009] Incremental replication and synchronization are performed based on the pre-check result, the source view object metadata and the change increment to obtain the extended view object metadata and the mapping relationship.

[0010] According to one embodiment of the present application, the dimension level determination is performed on the dimension information to confirm the target dimension information, and source view object metadata is collected based on the target dimension information, specifically:

[0011] The current dimension level is determined based on the dimension information to obtain the target dimension information;

[0012] The dimension information is information of a specific dimension level, and the target dimension information is information of the target dimension to be copied to.

[0013] The source view object metadata is all extended fields and node information of the information currently to be copied to the target dimension.

[0014] According to an embodiment of the present application, the conflict check includes: view object metadata existence check and business entity metadata existence check.

[0015] According to one embodiment of the present application, the view object metadata existence check is specifically as follows:

[0016] Check whether the target dimension information already exists in the extended view object metadata:

[0017] If it exists, check whether the extended fields and nodes conflict with the source view object metadata;

[0018] The conflicts include duplication of field labels, numbers, and names, and duplication of node numbers and names.

[0019] According to one embodiment of the present application, the business entity metadata existence check is specifically as follows:

[0020] Check whether the target dimension information contains extended business entity metadata, including:

[0021] Cards and lists use the same business entity metadata for the same dimension;

[0022] Checks the business entity for fields and nodes that conflict with the source view object metadata.

[0023] According to one embodiment of the present application, the incremental replication and synchronization processing is performed based on the pre-check result, the source view object metadata, and the change increment to obtain the extended view object metadata and the mapping relationship, specifically:

[0024] Extracting a change increment between the source view object metadata and the source view object metadata's parent view object;

[0025] Process newly added objects and fields, add them to the target view object, correct parent object references, and remove specific prefixes and suffixes;

[0026] Update the mapping relationship between the newly added objects and fields to ensure that they point to the target business entity metadata;

[0027] Synchronously add new objects and fields to the extended business entity.

[0028] According to an embodiment of the present application, the method further includes: saving the extended view object metadata and other associated view object metadata.

[0029] According to one embodiment of the present application, after saving the extended view object metadata and other associated view object metadata, it also includes: cleaning up related caches in abnormal situations, wherein the related caches include caches of extended view object metadata, business entity metadata and other associated view object metadata.

[0030] A computer-readable storage medium stores a program, which implements the steps of the method when executed by a processor.

[0031] An electronic device comprises a memory, a processor and a program stored in the memory and executable on the processor, wherein the steps in the method are implemented when the processor executes the program.

[0032] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows:

[0033] This application performs hierarchical analysis of the input dimension information to accurately identify the target dimension of the current operation and collect metadata of the source view object accordingly. This provides a clear context for subsequent copy operations, ensuring the targeted and accurate copy process and avoiding the resource waste and logical confusion caused by blind copying.

[0034] This application effectively identifies and records potential conflict points by performing conflict detection on the target dimension's existing metadata and the source metadata before copying, including field labels, numbers, names, and node information. This mechanism significantly reduces the risk of system anomalies caused by duplicate field names and nodes, and improves the security and stability of the copy operation.

[0035] This application performs replication based on incremental changes, processing only the changes between the source VO and its parent VO. This significantly improves replication efficiency and reduces unnecessary data transmission and processing overhead. Furthermore, the mapping between VO and BE is automatically updated during the replication process, ensuring that the newly generated extended VO is correctly associated with the business entity, thus ensuring the consistency and integrity of the system logic. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0037] Figure 1 A flowchart of a multi-dimensional view object replication and synchronization method based on a low-code platform provided in an embodiment of the present application;

[0038] Figure 2 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0039] Reference numerals:

[0040] 810 , processor; 820 , communication interface; 830 , memory; 840 , communication bus. DETAILED DESCRIPTION

[0041] In order to more clearly illustrate the overall concept of the present application, a detailed description is given below in an illustrative manner in conjunction with the accompanying drawings.

[0042] The following description sets forth many specific details to facilitate a thorough understanding of the present application. However, the present application may also be implemented in other ways than those described herein, and therefore, the scope of protection of the present application is not limited by the specific embodiments disclosed below. It should be noted that the embodiments of the present application and the features of each embodiment may be combined with each other unless there is a conflict.

[0043] In this application, unless otherwise expressly specified and limited, a first feature "above" or "below" a second feature may be that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in an appropriate manner in any one or more embodiments or examples.

[0044] Example 1

[0045] like Figure 1 As shown, the first embodiment of the present application provides a multi-dimensional view object replication and synchronization method based on a low-code platform, including:

[0046] A dimension level judgment is performed on the dimension information to confirm target dimension information, and source view object metadata is collected based on the target dimension information.

[0047] As mentioned above, the system first receives an input containing dimension information (DimensionInfo). This dimension information describes the specific level or category that the current operation is targeting. For example, in a low-code development platform, this may involve different parts of a form, such as cards, lists, and other different dimensions.

[0048] Next, the system uses this dimension information to determine the specific dimension level of the current operation. This means that the system needs to identify at which specific level the user wants to perform the copy operation. For example, do you want to operate within a specific card or within a list? Clarifying this is crucial for the subsequent steps because it determines which data will be processed and how it will be processed.

[0049] Once the dimension level is determined, the next step is to identify the target dimension information. "Target dimension information" here refers to the specific dimension determined based on the above-mentioned dimension level. For example, if the operation is determined to be on a specific card, then the relevant information about this card (such as its identifier and name) will become part of the target dimension information.

[0050] The process of confirming the target dimension information also includes checking whether the dimension is suitable for the copy operation, that is, verifying whether the dimension exists and meets the expected requirements. This is very important to ensure the accuracy of the operation.

[0051] The final step is to collect relevant Source View Object (VO) metadata based on the confirmed target dimension information. "Collect" here refers to gathering all extended fields and node information related to the dimension. This information includes, but is not limited to, details such as each field's name, type, and ID, as well as the relationship structure between them.

[0052] In this way, the system can obtain all necessary source data, which will be used in subsequent steps to create new replicas or perform other operations, such as checking for conflicts and performing incremental replication. This not only helps maintain data consistency and integrity, but also improves the efficiency of the entire process, allowing developers to more easily manage and adjust their customized content without worrying about data loss or confusion.

[0053] For example, consider an enterprise resource planning (ERP) system that includes a module for managing customer information. Within this module, a form allows users to enter and edit basic customer information, such as name and contact information. Furthermore, this form can be expanded to meet different business needs, such as adding new fields or cards to record more detailed customer preferences.

[0054] Now, the development team wants to copy the existing "Basic Information" card to a new dimension without interfering with existing functions. That is, create a new card specifically for recording "Customer Preferences" and ensure that all related data (such as view objects VO, business entities BE, etc.) can be correctly copied and associated.

[0055] First, the system receives a dimension information (DimensionInfo) indicating that the current operation targets the card dimension in the customer information form. Specifically, this dimension information may include an identifier such as "Basic Information Card".

[0056] Next, the system determines the dimension level based on this dimension information and confirms that the current operation is at the "Basic Information Card" level. This means that the system recognizes that the user wants to perform an operation based on the existing "Basic Information" card.

[0057] Once the dimension level is determined to be the "Basic Information Card," the next step is to identify the target dimension information. In this case, the target dimension information refers to the information related to the new card to be created: the "Customer Preferences" card. The system needs to ensure that this new dimension (the "Customer Preferences" card) is valid and can accept the data copied from the "Basic Information" card.

[0058] At this stage, the system also checks to see if there are any pre-conditions or restrictions, for example, whether multiple cards of the same type can be created within the same form, or if there are any specific naming rules that need to be followed.

[0059] The final step is to collect the relevant source view object (VO) metadata based on the identified target dimension information (i.e., the "Customer Preferences" card). This includes collecting all extended fields and node information related to the "Basic Information" card. For example, if the "Basic Information" card has fields such as name, phone number, and email address, information for these fields will be collected.

[0060] The collected information is not limited to field names and types, but also includes the relationship structure between them, such as which fields belong to the same group and whether there are dependencies. The purpose of this is to ensure that when this data is copied to the "Customer Preferences" card, all fields and their relationships are consistent, without data loss or relationship confusion.

[0061] Through the above steps, the development team was able to successfully copy the content from the "Basic Information" card to the new "Customer Preferences" card while ensuring data consistency and integrity, making the entire system more flexible and easier to maintain.

[0062] It should be noted that in specific implementation scenarios, building on the above solution, a data validation and cleansing step can be implemented after collecting metadata for source view objects. This step ensures that all collected data is valid and conforms to the expected format and standards. For example, this step can check whether field names are unique, data types are correct, and whether any required fields are missing. For data items that do not meet requirements, the system can provide warnings or automatic corrections.

[0063] In specific implementation scenarios, building on the above solution, when some metadata already exists for the target dimension, field or node conflicts may arise. Beyond simple conflict detection, automated conflict resolution mechanisms can be developed. For example, based on predefined rules, duplicate fields can be automatically renamed, similar fields can be merged, or the user can be prompted to manually select a solution. This reduces manual intervention and improves operational efficiency.

[0064] In specific implementation scenarios, building on the above solution, a metadata version control system can be introduced to better manage metadata changes across versions. Each time a copy operation is performed, the system automatically generates a new version number and records all change details. This not only helps track historical changes but also allows for rollbacks. Furthermore, version control helps team members collaborate better and avoids data loss caused by multiple people editing simultaneously.

[0065] A conflict check is performed on the target dimension information and the source view object metadata to obtain a pre-check result.

[0066] As mentioned above, before copying metadata from a source view object (VO) to a target dimension, the system first verifies that the data exists without conflicts within the target dimension. This prevents conflicts between the newly added data and existing data, such as duplicate field names or numbering conflicts, thereby ensuring system stability and data consistency.

[0067] The system first learns the specific situation of the current target dimension based on the target dimension information, including but not limited to all the extended VO metadata and business entity (BE) metadata that already exist under the dimension.

[0068] Next, the system prepares metadata for the source view object to be copied. This data includes all extended fields and node information. For example, all fields under a card dimension and their properties (such as field label, number, type, etc.)

[0069] Field conflict detection: The system checks each field in the source view object to see if the same or similar field already exists in the target dimension. Specifically, it compares key attributes such as field label, number, and name to see if there are any duplications.

[0070] Node conflict detection: Similarly, a similar check is performed on the node information to see if there is the same node number or name.

[0071] Business Entity (BE) conflict detection: Since VOs are often associated with BEs, the system also needs to check the BE metadata under the target dimension to ensure that the newly added VO fields do not conflict with existing BE fields. This is especially important when the same BE is used in the same dimension.

[0072] Based on the results of these checks, the system generates a pre-check report. This report details all detected conflicts and their corresponding recommended actions. For example, if a field name is duplicated, the report may recommend renaming the field; if a node number conflict exists, it may recommend adjusting the node number.

[0073] Pre-check results not only help developers understand potential problems, but also provide a basis for subsequent manual adjustments or automatic corrections.

[0074] For example, let's say you're developing an online education platform that includes a module for creating and managing courses. Within this module, a form allows administrators to enter basic course information (such as the course title and description), and supports expanding the course details based on different needs, such as adding new fields to record the course's learning objectives or intended audience.

[0075] Now, the development team wants to copy the existing "Basic Information" card to a new dimension - that is, create a new card specifically for recording "Learning Objectives" and ensure that all related data (such as view objects VO, business entities BE, etc.) can be copied correctly and will not conflict with existing data.

[0076] Goal dimension information: The goal dimension here refers to the "Learning Goal" card that will be created. This card will store specific information about the course learning objectives.

[0077] Source View Object Metadata: These are metadata from the Basic Information card, including but not limited to information on fields such as Course Name and Course Description. Each field has its own specific properties, such as field label, number, type, etc.

[0078] For example, in the Basic Information card, there is a field named "Course Overview" with the field number "001". When you try to copy this field to the Learning Objectives card, the system will check whether a field with the same name or number already exists in the Learning Objectives card.

[0079] If you discover that there's already a field called "Course Overview" in the "Learning Objectives" card (even if it's numbered differently), or a field numbered "001" (even if it's named differently), that's a conflict.

[0080] Similarly, if some fields in the Basic Information card belong to a specific node (for example, the Basic Information Node), during the copying process, the system will also check whether the same node number or name exists in the Learning Objective card.

[0081] For example, if the "Basic Information Node" is numbered "N1" and there is already a node numbered "N1" in the "Learning Objective" card, a conflict will occur.

[0082] In online education platforms, course information is often closely related to backend business entities (BEs). For example, course title, description, and other information may be directly associated with a specific BE.

[0083] When copying from the "Basic Information" card to the "Learning Objectives" card, the system needs to check if there are any conflicts in the BEs associated with the two cards. For example, if the BE used by the "Learning Objectives" card already has similar fields (such as course overview) as those in the "Basic Information" card, there may be a conflict.

[0084] Based on the results of the above conflict detection, the system generates a pre-check report:

[0085] If conflicts in field names or numbers are found, the report may suggest renaming the fields or adjusting their numbers to avoid conflicts.

[0086] For node conflicts, the report may suggest modifying the node number or name so that each node is unique.

[0087] If there are conflicts at the BE level, the report may provide a detailed comparative analysis, indicating which fields may cause problems and suggesting corresponding solutions, such as merging fields or adjusting field settings.

[0088] It should be noted that in specific implementation scenarios, the system can, in addition to identifying conflicts, provide automated or semi-automated resolution suggestions based on the above solution. For example, when a field name conflict is detected, the system can automatically generate a new field name based on specific rules (such as adding a timestamp or number suffix) and prompt the user to accept the suggestion. This can reduce manual intervention and improve operational efficiency.

[0089] In specific implementation scenarios, building on the above solution, the system can assign a priority to each detected conflict to help users better understand and resolve conflicts. For example, field name conflicts may be more urgent than node number conflicts because they directly affect the user interface. This way, users can resolve the most important conflicts first, thereby gradually optimizing the entire system.

[0090] In specific implementation scenarios, building on the above solution, the system can also record the results of each conflict check and analyze this historical data to identify common conflict patterns. Over time, the system can "learn" and predict the types of conflicts that may arise in the future, providing preventative measures or even optimization suggestions during the design phase to avoid potential problems.

[0091] In specific implementation scenarios, building on the above solution, a user feedback mechanism could be introduced, allowing users to submit their opinions or suggestions when reviewing conflict reports. For example, if a solution provided by the system is not applicable, the user can directly mark it on the interface and explain the reason. This feedback can help improve future conflict detection algorithms and service quality.

[0092] Incremental replication and synchronization are performed based on the pre-check result, the source view object metadata and the change increment to obtain the extended view object metadata and the mapping relationship.

[0093] As mentioned above, the system first carefully analyzes all conflict points in the pre-check report, such as duplicate field names, node number conflicts, etc.

[0094] Develop a solution: Based on the pre-check results, determine how to resolve the conflicts. For example, rename the conflicting fields or adjust the node numbers to avoid conflicts.

[0095] Based on the pre-check results, select fields and node information from the source view object that have no conflicts or have resolved conflicts.

[0096] If the source view objects have changed since the last synchronization, you need to prepare these change deltas (such as newly added objects, fields, etc.) so that only the necessary updated parts are transferred during replication instead of the entire dataset.

[0097] Iterate over the newly added objects in the change set (such as new form items). For each newly added object, add it to the view object under the target dimension and correct its parent object reference to ensure the hierarchy is correct.

[0098] Newly added fields are processed similarly. They are added to the corresponding nodes and any prefixes or suffixes removed as needed (such as the "Ext_" prefix and the "_Lv9" suffix) to conform to the standard format of the target dimension.

[0099] During the replication process, the mapping relationship between VO and BE is automatically maintained. This means that every time a new object or field is added, its corresponding BE mapping relationship needs to be updated to ensure consistency and interoperability between the two.

[0100] Not only must data synchronization from VO to BE be ensured, but also the effectiveness of reverse synchronization must be guaranteed, that is, changes initiated from either VO or BE can be correctly reflected in the other party's data model.

[0101] Synchronize the newly added objects and fields to the extended business entity (BE), ensuring that all relevant business logic and data integrity rules are applied.

[0102] The final step is to verify that all new additions have been correctly added to the target dimension and that all mappings are established and valid.

[0103] Through the above steps, the system generates the metadata for the extended view object and its mapping to the business entities. This includes not only all necessary fields and nodes copied from the source view object, but also all adjustments and optimizations made to accommodate the target dimensions. This incremental replication method significantly improves efficiency because it processes only the actual changes, rather than the entire dataset, while maintaining system stability and data consistency.

[0104] For example, suppose you're developing a customer relationship management system (CRM) that includes a module for recording customer information. Within this module, there's a form that allows users to enter and edit basic customer information, such as name and contact information. Furthermore, this form can be extended to meet different business needs, such as adding new fields or cards to record more detailed customer preferences.

[0105] Now, the development team wants to copy the existing "Basic Information" card to a new dimension - that is, create a new card specifically for recording "Customer Preferences" and ensure that all related data (such as view objects VO, business entities BE, etc.) can be correctly copied and associated.

[0106] Before executing the copy operation, the system performed a conflict check and obtained the following pre-check results:

[0107] Field name conflict: It was discovered that a field named "Notes" already exists in the target dimension (i.e., the "Customer Preferences" card), and there is also a field with the same name in the source view object (the "Basic Information" card).

[0108] Node number conflict: There is a node numbered "N1" in the target dimension, and there is a node with the same number in the source view object.

[0109] No BE conflict: Since the two cards use different business entities (BE), there is no conflict at the BE level.

[0110] The source view object (Basic Information card) includes the following fields:

[0111] Customer Name

[0112] Contact

[0113] Note (name conflict exists)

[0114] and some other fields

[0115] These fields all belong to a node with node number "N1".

[0116] Suppose the Basic Info card has a few new fields since the last sync:

[0117] Customer Source

[0118] Recommender information

[0119] These newly added fields need to be taken into account during the incremental replication process.

[0120] Incremental replication and synchronization

[0121] Resolving conflicts:

[0122] For the field name conflict ("Notes" field), the system recommends renaming the "Notes" field in the source view object to "Other Notes" to avoid the conflict.

[0123] For node number conflicts (node ​​number "N1"), the system recommends adjusting the node number in the source view object to "N2".

[0124] The system selects the fields and node information to be copied, including the modified field names and node numbers.

[0125] Prepare to add new fields (customer source, referrer information) as part of the change increment.

[0126] Copy the fields in the "Basic Information" card (such as customer name, contact information, "Other Notes", etc.) to the "Customer Preferences" card and adjust the corresponding node number to "N2".

[0127] New fields (customer source, referrer information) have also been added to the “Customer Preferences” card to ensure they can be seamlessly integrated into the existing structure.

[0128] During the copy process, the system automatically updates the mapping relationship between each field and node and the corresponding business entity (BE). For example, it ensures that the "Other Notes" field is correctly mapped to the correct BE field.

[0129] Ensure that the data synchronization mechanism from VO to BE is effective so that any subsequent changes are correctly reflected in the other party's data model.

[0130] All newly added objects and fields are synchronized to the extended business entity (BE), ensuring that all relevant business logic and data integrity rules are applied.

[0131] The final step is to verify that all new additions have been correctly added to the target dimension and that all mappings are established and valid.

[0132] It should be noted that in specific implementation scenarios, based on the above solution, an additional data verification and cleanup step can be introduced before performing incremental replication:

[0133] The system automatically verifies that all fields and node information to be copied conforms to expected formats and standards. For example, it checks whether field names are unique and data types are correct. For data items that do not meet requirements, the system can provide warnings or suggest corrective actions, such as automatically removing invalid characters or renaming duplicate fields.

[0134] In specific implementation scenarios, based on the above solution, in addition to manual conflict resolution, you can also develop an automated conflict resolution mechanism:

[0135] The system automatically adjusts conflicting parts based on predefined rules. For example, if a field name conflict occurs, a timestamp suffix (such as "Note_20250516") is automatically added to distinguish different versions. When the system detects a conflict, it provides multiple resolutions for users to choose from and allows users to customize the resolution.

[0136] In specific implementation scenarios, based on the above solution, a version control system can be introduced to better manage metadata changes:

[0137] Each time you perform an incremental copy, the system creates a new version number and records all the change details. This helps track historical changes and allows for rollbacks. A detailed change log is generated, recording the content, time, and operator of each change, facilitating auditing and troubleshooting.

[0138] According to one embodiment of the present application, the dimension level determination is performed on the dimension information to confirm the target dimension information, and source view object metadata is collected based on the target dimension information, specifically:

[0139] The current dimension level is determined based on the dimension information to obtain the target dimension information;

[0140] The dimension information is information of a specific dimension level, and the target dimension information is information of the target dimension to be copied to.

[0141] The source view object metadata is all extended fields and node information of the information currently to be copied to the target dimension.

[0142] As mentioned above, dimension information refers to information about the specific level or category on which the current operation is being performed. For example, in a low-code development platform, this might involve different parts of a form, such as cards, lists, and other dimensions. Providing the necessary contextual information enables the system to identify the specific level at which the user wishes to perform the copy operation.

[0143] Based on the input dimension information (DimensionInfo), the system first needs to determine the specific dimension level at which the current operation is performed. For example, do you want to operate within a specific card or within a list? Clarifying this is crucial for subsequent steps because it determines which data will be processed and how it will be processed.

[0144] The target dimension information refers to the specific dimension determined based on the above dimension level judgment. For example, if the operation is determined to be on a specific card, then the relevant information of this card (such as its identifier, name, etc.) will become part of the target dimension information.

[0145] The system checks whether the dimension is valid and meets the expected requirements. For example, it ensures that the dimension actually exists and can accept data copied from other dimensions.

[0146] Prepare for the upcoming replication operation, including but not limited to clearing the cache and preparing storage space.

[0147] The source view object metadata refers to all the extended fields and node information to be copied to the target dimension. This information includes, but is not limited to, details such as the name, type, and number of each field, as well as the relationship structure between them.

[0148] The system will traverse all extended fields in the source view object, collect their properties (such as name, type, number, etc.), and store this information in a structured manner (such as a HashMap structure of <node number, field list>).

[0149] In addition to field information, node information is also collected, which is the larger structural unit (such as group, card, etc.) to which these fields belong. Node information is usually stored in a list format for easy management and reference.

[0150] The system receives input (DimensionInfo) containing information about a specific dimension level.

[0151] Based on the dimension information, the system determines the specific dimension level of the current operation, for example, whether the operation is performed on the "Basic Information" card or the "Customer Preferences" card.

[0152] The system further confirms the validity of the dimension and prepares the corresponding environment for the copy operation.

[0153] Based on the confirmed target dimension information, the system begins to collect all relevant extended fields and node information, including the field name, type, number, and node information.

[0154] According to an embodiment of the present application, the conflict check includes: view object metadata existence check and business entity metadata existence check.

[0155] As mentioned above, the primary purpose of the view object metadata existence check is to confirm whether the target dimension already contains the same or similar extended fields or node information as the source view object. This step is to avoid duplicate data entries or field conflicts during the copy process.

[0156] Each field name and number in the target dimension is checked to see if there is a field with the same name or number as a field in the source view object.

[0157] If duplicates are found, it could mean there is a potential conflict, as two fields with the same name could cause data to be mixed up or overwritten.

[0158] In addition to fields, node information is also checked. A node is a group of related fields, such as a card or group in a form.

[0159] The system checks whether the target dimension has the same node number or name as the source view object to prevent overlapping or duplicate nodes.

[0160] Furthermore, the system will compare the specific attributes of the fields, such as data type, default value, etc., to ensure that these attributes are also unique or compatible in the target dimension.

[0161] Business entity metadata existence checking ensures that the business entities (BEs) used in the target dimension do not conflict with those in the source view objects. Business entities often contain deeper data structures and logic, so this check is crucial to maintaining data consistency and integrity.

[0162] The system checks whether there is a field name or number in the business entity in the target dimension that is identical to that in the source view object.

[0163] If a conflict is found, such as two fields with the same name but different meanings, the system needs to decide how to handle the situation to avoid data confusion.

[0164] In addition to fields, the relationships between BEs are also checked. For example, in a low-code development platform, a view object (VO) may be associated with multiple business entities (BEs), and there may be dependencies between these BEs.

[0165] The system needs to ensure that these dependencies are also correctly established in the target dimension to avoid isolated or incomplete data structures.

[0166] Ensure that the business logic in the target dimension is consistent with the business logic in the source view object. For example, if a field has a specific validation rule or calculation logic in the source view object, the same rule and logic should be maintained in the target dimension.

[0167] According to one embodiment of the present application, the view object metadata existence check is specifically as follows:

[0168] Check whether the target dimension information already exists in the extended view object metadata:

[0169] If it exists, check whether the extended fields and nodes conflict with the source view object metadata;

[0170] The conflicts include duplication of field labels, numbers, and names, and duplication of node numbers and names.

[0171] As mentioned above, confirm whether the extended view object metadata already exists in the target dimension, and further check whether there are any conflicts between this existing metadata and the source view object metadata to be copied. This check can avoid data confusion or overwriting problems caused by duplicate fields or nodes.

[0172] The system first needs to determine whether extended view object metadata already exists in the target dimension. Here, "extended view object metadata" refers to all customized or extended fields and nodes that already exist in the target dimension.

[0173] If there is no existing extended view object metadata in the target dimension, the copy operation can proceed directly without worrying about conflicts. However, if there is, further checks are required to prevent potential conflicts.

[0174] Once the extended view object metadata is confirmed to exist in the target dimension, the system will perform a more detailed conflict detection. This step mainly includes the following aspects:

[0175] The system compares each field label in the source view object with the existing field labels in the target dimension to see if there are duplicate labels. For example, if the source view object has a field labeled "Notes" and there is a field named "Notes" in the target dimension, then there is a conflict.

[0176] In addition to the labels, the system also checks for identical field numbers. Identical field numbers can cause conflicts even if the field labels are different, as numbers are often unique identifiers.

[0177] Finally, the system checks for duplicate field names. In some cases, for example, field names may be used in programming interfaces or database tables, so uniqueness is also important.

[0178] A node is a larger structural unit, such as a card or grouping, that contains a group of related fields. The system checks whether the node numbers in the source view object are duplicates of the node numbers in the target dimension. For example, if there is a node numbered "N1" in the source view object and there is also a node numbered "N1" in the target dimension, this is considered a conflict.

[0179] Similarly, node names are checked for duplication. Having the same name even if the number is different can cause confusion, especially when displayed in the user interface.

[0180] To better understand what the above checks are doing, here are some specific examples of conflicts:

[0181] The source view object has a field labeled "Customer Name," and a field with the same name already exists in the target dimension. In this case, direct copying will result in field overwriting or data loss.

[0182] There is a field numbered "001" in the source view object, and there is also a field numbered "001" in the target dimension, although they have different labels or names. This conflict may cause an internal reference error in the system.

[0183] If there is a node numbered "N1" in the source view object and a node numbered "N1" in the target dimension, all fields under the node may be overwritten or confused.

[0184] The source view object has a node named "Basic Information" and the target dimension also has a node with the same name. Even though the node numbers are different, the same name may cause confusion in the user interface.

[0185] Once a conflict is detected, the system can automatically handle it according to preset rules or prompt the user to manually resolve it. For example:

[0186] Automatically rename conflicting fields or nodes, and add a timestamp or suffix (such as "Note_20250516") to distinguish different versions.

[0187] Provide multiple solutions for users to choose from and allow users to customize solutions.

[0188] Through this meticulous conflict checking, the system can ensure that each replication operation is safe and effective, thereby maintaining system stability and data consistency.

[0189] According to one embodiment of the present application, the business entity metadata existence check is specifically as follows:

[0190] Check whether the target dimension information contains extended business entity metadata, including:

[0191] Cards and lists use the same business entity metadata for the same dimension;

[0192] Checks the business entity for fields and nodes that conflict with the source view object metadata.

[0193] As mentioned above, confirm whether the extended business entity metadata already exists in the target dimension, and further check whether there are any conflicts between this existing metadata and the source view object metadata to be copied. This check can avoid data confusion or overwriting problems caused by duplicate fields or nodes.

[0194] The system first needs to determine whether extended business entity metadata already exists in the target dimension. Here, "extended business entity metadata" refers to all customized or extended business logic and data structures that already exist in the target dimension.

[0195] If there is no existing extended business entity metadata in the target dimension, you can proceed with the copy operation without worrying about conflicts. However, if there is, further checks are required to prevent potential conflicts.

[0196] Once the extended business entity metadata is confirmed to exist in the target dimension, the system will perform a more detailed conflict detection. This step mainly includes the following aspects:

[0197] Cards and lists use the same business entity metadata for the same dimension

[0198] In a low-code development platform, different view objects (such as cards and lists) may share the same business entity (BE). For example, in a form, cards and lists may use the same business entity to store and manage data.

[0199] The system checks whether the cards and lists in the target dimension use the same business entity metadata.

[0200] If so, the system needs to take special care to ensure that the newly added fields or nodes do not conflict with existing business entity metadata.

[0201] The system compares each field in the source view object with the fields in the business entities in the target dimension to see if they have the same field label, number, or name.

[0202] For example, if the source view object has a field labeled "Customer Name" and a field named "Customer Name" exists in the business entity in the target dimension, a conflict is considered to exist.

[0203] Even if the field labels are different, having the same number can cause conflicts because numbers are usually unique identifiers.

[0204] Uniqueness of field names is also important, especially when referenced in programming interfaces or database tables.

[0205] In addition to fields, the system also checks node information. A node is a larger structural unit, such as a card or group, that contains a group of related fields.

[0206] The system checks whether the node numbers in the source view object are duplicates of the node numbers in the business entities in the target dimension. For example, if there is a node numbered "N1" in the source view object and there is also a node numbered "N1" in the business entity in the target dimension, a conflict is considered.

[0207] Similarly, node names are checked for duplication. Having the same name even if the number is different can cause confusion, especially when displayed in the user interface.

[0208] To better understand what the above checks are doing, here are some specific examples of conflicts:

[0209] The source view object has a field labeled "Memo," and the target dimension business entity also has a field with the same name. In this case, direct copying will result in field overwriting or data loss.

[0210] There is a field numbered "001" in the source view object, and there is also a field numbered "001" in the business entity in the target dimension, although they have different labels or names. This conflict may cause internal reference errors in the system.

[0211] If there is a node numbered "N1" in the source view object and a node numbered "N1" also exists in the business entity in the target dimension, all fields under the node may be overwritten or confused.

[0212] There is a node named "Basic Information" in the source view object, and there is a node with the same name in the business entity in the target dimension. Even though the node numbers are different, the same name may cause confusion in the user interface.

[0213] Once a conflict is detected, the system can automatically handle it according to preset rules or prompt the user to manually resolve it. For example:

[0214] Automatically rename conflicting fields or nodes, and add a timestamp or suffix (such as "Note_20250516") to distinguish different versions.

[0215] Provide multiple solutions for users to choose from and allow users to customize solutions.

[0216] According to one embodiment of the present application, the incremental replication and synchronization processing is performed based on the pre-check result, the source view object metadata, and the change increment to obtain the extended view object metadata and the mapping relationship, specifically:

[0217] Extracting a change increment between the source view object metadata and the source view object metadata's parent view object;

[0218] Process newly added objects and fields, add them to the target view object, correct parent object references, and remove specific prefixes and suffixes;

[0219] Update the mapping relationship between the newly added objects and fields to ensure that they point to the target business entity metadata;

[0220] Synchronously add new objects and fields to the extended business entity.

[0221] As described above, the changes that occurred in the source view object metadata since the last synchronization are identified and extracted using the change delta between the source view object metadata and its parent view object.

[0222] The system compares the metadata of the current source view object with that of its parent view object (i.e., the previous version or parent view object) to identify changes such as newly added objects and fields.

[0223] These incremental changes typically include but are not limited to newly added objects (such as new form items), newly added fields, modified object properties, etc.

[0224] Process the newly added objects and fields, add them to the target view object, correct parent object references and remove specific prefixes and suffixes. Safely add the newly added objects and fields in the change increment to the target view object and ensure that these newly added contents meet the requirements of the target dimension.

[0225] Iterate over the newly added objects in the change delta (for example, newly added form items), add them to the target view object, and correct the parent object reference. This step ensures that the newly added objects are correctly nested under their parent objects, maintaining the correct hierarchy.

[0226] If the newly added object has a parent object, its parent object reference needs to be updated to point to the correct parent object.

[0227] Similarly, newly added fields are processed and added to the corresponding nodes of the target view object.

[0228] Some fields may contain specific prefixes or suffixes (such as "Ext_" and "_Lv9"). These tags may be added to distinguish different versions or environments. During the copy process, these tags are removed to make the field names more concise and consistent.

[0229] Update the mapping relationship of newly added objects and fields to ensure that they point to the target business entity metadata, maintain the mapping relationship between view objects (VO) and business entities (BE), and ensure that newly added objects and fields can be correctly associated with the corresponding parts in the target business entity.

[0230] For each newly added object and field, the system updates its mapping to ensure that it points to the corresponding part in the target business entity. For example, if a new field "Customer Source" is added, the system updates its mapping to point to the corresponding field in the target business entity.

[0231] It is necessary not only to ensure data synchronization from VO to BE, but also to ensure the effectiveness of reverse synchronization, that is, whether the changes initiated from VO or BE can be correctly reflected in the other party's data model.

[0232] Synchronize newly added objects and fields to the extended business entity to ensure that all newly added objects and fields are processed not only at the view object level but also synchronized at the business logic level to maintain data consistency and integrity.

[0233] Synchronize the newly added objects and fields to the extended business entity (BE), ensuring that all relevant business logic and data integrity rules are applied.

[0234] The final step is to verify that all new content has been correctly added to the target dimension and that all mapping relationships have been established and validated. This step ensures system stability and data consistency.

[0235] According to an embodiment of the present application, the method further includes: saving the extended view object metadata and other associated view object metadata.

[0236] As mentioned above, ensure that all processed and adjusted extended view object metadata is securely stored for subsequent use or further operations. By storing this data, the system can ensure that new or modified view objects are displayed correctly in the user interface and that the underlying data structure supports the corresponding business logic.

[0237] The system will collect all newly added objects, fields, and their attribute information, including but not limited to field name, type, number, node information, etc.

[0238] Before saving, the system will validate the metadata to ensure that it conforms to the expected format and standards. For example, it will check whether the field names are unique and the data types are correct.

[0239] Save the collected and validated extended view object metadata to the system's persistent storage, such as a database or a specific file system. This step usually involves converting the metadata into a format suitable for storage and performing the corresponding write operations.

[0240] In addition to saving the metadata of the extended view object, you also need to save the metadata of other related view objects. This is because in a complex system, view objects are often interrelated, and saving a single view object may cause data inconsistency or unavailability in the entire system.

[0241] The system needs to identify which view objects are associated with the current extended view object. For example, in a form, multiple cards or lists may share the same business entity (BE), or some fields may be referenced across multiple view objects.

[0242] For each identified associated view object, the system will update its metadata synchronously. This means that if a field or node in the extended view object changes, the associated view objects also need to be adjusted accordingly.

[0243] Similar to the process of saving extended view object metadata, the system also verifies and persistently stores the metadata of associated view objects to ensure that all associated data can be saved correctly.

[0244] During the storage process, the system also needs to consider possible exceptions and take appropriate measures to maintain data consistency and integrity:

[0245] If any error occurs during the saving process, the system should clean up the relevant cached data to avoid data inconsistency issues caused by some data not being saved successfully.

[0246] Implement a transaction management mechanism so that when saving fails, you can roll back to the previous state to ensure that the system is not in an unstable state.

[0247] According to one embodiment of the present application, after saving the extended view object metadata and other associated view object metadata, it also includes: cleaning up related caches in abnormal situations, wherein the related caches include caches of extended view object metadata, business entity metadata and other associated view object metadata.

[0248] As mentioned above, when the system encounters an exception (such as a network outage, storage failure, or other error) while saving extended view object metadata and associated view object metadata, some data may not be successfully saved or updated. Without proper cleanup, these unfinished operations can lead to data inconsistencies or system instability. Therefore, the primary purpose of cleaning the relevant cache in the event of an exception is to ensure that the system's data state matches the actual stored data. By clearing invalid or expired cached data, the system can resume normal operation.

[0249] The relevant caches that need to be cleared under abnormal circumstances mainly include the following categories:

[0250] The cache of extended view object metadata refers to view object metadata that is added or modified during the current operation. For example, this includes information about newly added fields and nodes. Caching this data improves access efficiency. However, if an exception occurs and this data fails to be successfully saved to persistent storage, it must be removed from the cache to avoid problems with subsequent use.

[0251] The business entity metadata cache refers to the business entity metadata associated with view objects. Business entities often contain deeper data structures and logic, and serve as the supporting infrastructure behind view objects. When view object metadata is processed, business entity metadata is also affected. If business entity metadata is not updated correctly under unusual circumstances, the associated cache must be cleared to prevent inconsistent data from impacting system functionality.

[0252] The cache of metadata associated with other view objects refers to metadata associated with or dependent on the extended view object currently being operated on. For example, this includes different cards or lists that share the same business entity. Because view objects can have complex dependencies, changes to one view object can affect other view objects. If, under unusual circumstances, all related view object metadata is not updated synchronously, this cached data needs to be cleared to ensure that the system does not make decisions based on outdated information.

[0253] The system first needs to be able to identify exceptions, that is, to be able to detect abnormal conditions when a save operation fails. This can be achieved by capturing exception events and checking the returned status code.

[0254] Once an anomaly is detected, the system needs to determine which caches are affected by the operation, including but not limited to the caches of the extended view object metadata, business entity metadata, and other associated view object metadata mentioned above.

[0255] For affected caches, the system performs a cleanup operation, which removes the cached data from memory or marks it invalid. This step ensures that the unsuccessfully saved data will not be used during the next access.

[0256] To facilitate subsequent analysis and debugging, the system usually also records the log of the cleanup operation, including the time of cleanup, the data range involved, and other information.

[0257] In some cases, in addition to clearing the cache, the system may also take further recovery measures, such as attempting to re-execute the failed operation, prompting the user for manual intervention, or automatically rolling back to the previous state.

[0258] A computer-readable storage medium stores a program, which implements the steps of the method when executed by a processor.

[0259] An electronic device comprises a memory, a processor and a program stored in the memory and executable on the processor, wherein the steps in the method are implemented when the processor executes the program.

[0260] Anything not described in this application can be achieved by adopting or drawing on existing technologies.

[0261] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.

[0262] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included in the protection scope of the present application.

Claims

1. A multi-dimensional view object replication and synchronization method based on a low-code platform, characterized in that: include: Performing dimension level judgment on the dimension information to confirm target dimension information, and collecting source view object metadata based on the target dimension information; Performing a conflict check on the target dimension information and the source view object metadata to obtain a pre-check result; Perform incremental replication and synchronization based on the pre-check result, the source view object metadata, and the change increment to obtain the extended view object metadata and mapping relationship; Dimension information describes the specific level or category that the current operation targets.

2. The method according to claim 1, characterized in that The dimension level judgment is performed on the dimension information to confirm the target dimension information, and source view object metadata is collected based on the target dimension information, specifically: The current dimension level is determined based on the dimension information to obtain the target dimension information; The dimension information is information of a specific dimension level, and the target dimension information is information of the target dimension to be copied to. The source view object metadata is all extended fields and node information of the information currently to be copied to the target dimension.

3. The method according to claim 1, characterized in that The conflict check includes: view object metadata existence check and business entity metadata existence check.

4. The method according to claim 3, characterized in that The view object metadata existence check is specifically as follows: Check whether the target dimension information already exists in the extended view object metadata: If it exists, check whether the extended fields and nodes conflict with the source view object metadata; The conflicts include duplication of field labels, numbers, and names, and duplication of node numbers and names.

5. The method according to claim 3, characterized in that The business entity metadata existence check is specifically as follows: Check whether the target dimension information contains extended business entity metadata, including: Cards and lists use the same business entity metadata for the same dimension; Checks the business entity for fields and nodes that conflict with the source view object metadata.

6. The method according to claim 1, characterized in that The incremental replication and synchronization processing are performed according to the pre-check result, the source view object metadata and the change increment to obtain the extended view object metadata and the mapping relationship, specifically: Extracting a change increment between the source view object metadata and the source view object metadata's parent view object; Process the newly added objects and fields, add them to the target view object, correct the parent object reference, and remove the prefix and suffix; Update the mapping relationship between the newly added objects and fields to ensure that they point to the target business entity metadata; Synchronously add new objects and fields to the extended business entity.

7. The method according to claim 1, characterized in that Also includes: The extended view object metadata and other associated view object metadata are saved.

8. The method according to claim 7, characterized in that After saving the extended view object metadata and other associated view object metadata, the method further includes: cleaning up related caches in abnormal situations, wherein the related caches include caches of extended view object metadata, business entity metadata and other associated view object metadata.

9. A computer-readable storage medium having a program stored thereon, characterized in that: When the program is executed by a processor, the steps in the method according to any one of claims 1 to 8 are implemented.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps in the method according to any one of claims 1 to 8 are implemented.

Images