Enterprise content management data processing method and apparatus

Abstract

The embodiment of the application provides a kind of enterprise content management data processing method and device, method includes: through three-tier architecture model, including library type layer, content type layer and content instance layer, respectively for defining business scenario, dynamically defining content type in library and storing specific content data, library type layer and content type layer are respectively associated with independent configuration table, and the dynamic expansion of business scenario and content type can be realized by inserting configuration data;Unified content storage table is constructed, and all content data is uniformly stored in single table by taking library type identifier and content type identifier as logical isolation label, without predefining data structure to support flexible content type;Meanwhile, a general processing interface decoupled from the library type and the content type is constructed, forming a highly reusable capability framework, enabling unified processing and reuse of all content data in different business scenarios, which can improve the efficiency of enterprise content management and reduce implementation costs.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a method and apparatus for processing enterprise content management data. Background Technology

[0002] In the wave of enterprise digital transformation, content management has become an indispensable part of enterprise operations. With the diversification of business scenarios, the types of content that enterprises need to manage are also becoming increasingly diverse, including but not limited to product information, marketing materials, industry-specific data (such as recipes and formulas in the food industry), and celebrity management information. However, existing technological solutions have significant limitations and shortcomings in addressing these management needs across multiple business scenarios and content types.

[0003] Existing technical solutions have significant limitations in meeting the management needs of enterprises with multiple business scenarios and multiple content types.

[0004] On the one hand, it requires developing a separate system for each business scenario, resulting in high development costs. Each system needs to repeatedly build basic functions such as permissions, search, and approval. Moreover, the maintenance of multiple systems is complex and the code is redundant. When adding new business scenarios, it is necessary to start from scratch, and data sharing and integration are extremely difficult.

[0005] On the other hand, traditional CMS / DAM (Content Management System / Digital Asset Management System) architectures are rigid, making it difficult to expand across business scenarios. Content types are fixed, and adding new types relies on plugin development or code modification, with insufficient support for multi-tenant customization. Furthermore, while Headless CMS supports flexible content type configuration, it lacks library-level isolation and configuration capabilities, limiting the reusability of general capabilities and providing insufficient support for complex business logic such as multi-level content types and dynamic validation. These issues collectively constrain the efficiency and flexibility of enterprise content management, highlighting the urgent need to develop a unified, dynamic management system.

[0006] Based on the above problems, there is an urgent need for a data processing method for enterprise content management that can improve the efficiency of enterprise content management and reduce implementation costs. Summary of the Invention

[0007] To address the problems in the prior art, this application provides a method and apparatus for processing enterprise content management data, which can improve the efficiency of enterprise content management and reduce implementation costs.

[0008] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a method for processing enterprise content management data, including: A hierarchical data processing model is defined based on preset configuration information. The hierarchical data processing model includes a library type layer, a content type layer, and a content instance type layer. The library type layer is used to define different business scenarios. The content type layer is used to define content types under the logical isolation of each library type layer. The content instance type layer is used to store the specific content data of the library type and content type. The library type layer and the content type layer are respectively associated with independent configuration tables for inserting configuration data. A structured data table is constructed, and each content instance data of the content instance layer is stored in the structured data table with its library identifier and content type identifier as logical isolation tags. The structured data table includes fixed fields for storing the logical isolation tags and general fields for storing the content instance data in a dynamic format. In response to an enterprise's request to create a content type for a specific library type, a unique content type identifier is generated. The content type identifier, the content type name, and the library identifier corresponding to the content type are associated and persistently stored in the content type configuration table in the form of a configuration record. The library type configuration table is updated synchronously to realize the update of data content types. A general processing interface is constructed to decouple library types and content types, and a business logic extension processor is registered for each library type. The corresponding data reuse framework is determined, and data processing operations are performed on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests to realize enterprise content instance data management.

[0009] Furthermore, the step of performing data processing operations on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests includes: In response to an enterprise's request to create content instance data for a specific library type and content type, the following creation operations are performed according to the content creation interface in the data reuse framework: Verify the validity of the library identifier and content type identifier in the content instance creation request; Obtain the corresponding field template configuration based on the content type identifier, and based on the field template configuration, encapsulate the field data in the content instance creation request into structured data that conforms to a general field format; The structured data is subjected to business uniqueness verification based on the configuration information of a specific library, wherein the verification rules and verification fields for the business uniqueness verification are defined by the configuration information of the specific library. If the verification passes, the encapsulated structured data, the library identifier, and the content type identifier will be persisted as a new record to the structured data table.

[0010] Furthermore, the step of performing data processing operations on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests also includes: The content query operation receives a query request from the content query interface in the data reuse framework. The query request specifies at least one library identifier and / or content type identifier as a filter condition. Based on the filter condition, the structured data table is queried, and a corresponding list of content instances is returned. The content update operation receives an update request from the content update interface in the data reuse framework, calls the business logic extension processor associated with the library type to which the update request belongs to perform data compliance verification before the update, and then executes the update operation.

[0011] Furthermore, the library type layer and the content type layer are each associated with independent configuration tables, including: An independent library configuration table is associated with each library type layer to store and manage the configuration strategies for each library type. Each record in the library configuration table uniquely corresponds to a library type and stores at least one of the following: library identifier, supported natural language list, default permission policy, extended configuration information related to specific business processes, and view display configuration information for that library type. An independent content type configuration table is associated with the content type layer to define and manage each content type. The records in the content type configuration table are uniquely identified by a combination of a library identifier and a content type identifier, and store at least one of the content type name and its enabled status. The content type identifier is a unique string encoding.

[0012] Furthermore, after defining the hierarchical data processing model based on preset configuration information, wherein the hierarchical data processing model includes a library type layer, a content type layer, and a content instance type layer, it includes: A preset template configuration, which is used to define the specific data structure of the content instance; The template configuration is associated with one or more library type layers or content type layers, and is used to wrap the content instance according to the template configuration when the content instance is created or edited.

[0013] Furthermore, after constructing the structured data table, the following steps are included: Database indexes are created or jointly created for the library identifier and content type identifier in the structured data table to achieve data partitioning and retrieval; The searchable data in the general fields is synchronized to an independent full-text search engine, and a mapping relationship is established with the primary key of the records in the structured data table for full-text retrieval.

[0014] Furthermore, the step of generating a unique content type identifier in response to an enterprise's content type creation request for a specific library type includes: In response to an enterprise's request to create content for a specific library type, a random string generation algorithm is invoked to determine the corresponding string composed of alphabetic characters of a preset length; Use this string as a unique content type identifier.

[0015] Secondly, this application provides an enterprise content management data processing device, comprising: A hierarchical architecture model determination module is used to define a hierarchical data processing model based on preset configuration information. The hierarchical data processing model includes a library type layer, a content type layer, and a content instance type layer. The library type layer is used to define different business scenarios. The content type layer is used to define content types under the logical isolation of each library type layer. The content instance type layer is used to store the specific content data of the library type and content type. The library type layer and the content type layer are respectively associated with independent configuration tables for inserting configuration data. A unified storage structure determination module is used to construct a structured data table. The content instance data of the content instance layer is stored in the structured data table with its library identifier and content type identifier as logical isolation tags. The structured data table includes fixed fields for storing the logical isolation tags and general fields for storing the content instance data in a dynamic format. The configuration-driven creation module is used to respond to the enterprise's content type creation request for a specific library type, generate a unique content type identifier, associate the content type identifier, the content type name, and the library identifier corresponding to the content type, and persistently store them in the content type configuration table in the form of configuration records, and synchronously update the library type configuration table to realize the data content type update. The data reuse module is used to build a general processing interface that decouples library types and content types, register business logic extension processors for each library type, determine the corresponding data reuse framework, and perform data processing operations on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests to realize enterprise content instance data management.

[0016] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the enterprise content management data processing method described above.

[0017] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the enterprise content management data processing method described above.

[0018] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the enterprise content management data processing method described above.

[0019] As can be seen from the above technical solution, this application provides an enterprise content management data processing method and apparatus. Through a three-layer architecture model, including a library type layer, a content type layer, and a content instance layer, these are used to define business scenarios, dynamically define content types within the library, and uniformly store specific content data, respectively. The library type layer and content type layer are associated with independent configuration tables, and dynamic expansion of business scenarios and content types can be achieved by inserting configuration data. By constructing a unified content storage table, using library type identifiers and content type identifiers as logical isolation tags, all content data is uniformly stored in a single table, supporting flexible content types without the need for predefined data structures. Simultaneously, a general processing interface decoupled from library types and content types is constructed, forming a highly reusable capability framework. This enables unified processing and reuse of all content data under different business scenarios, thereby improving enterprise content management efficiency and reducing implementation costs. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is one of the flowcharts illustrating the enterprise content management data processing method in this application embodiment; Figure 2 This is a structural diagram of the enterprise content management data processing device in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0022] Figure label: Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0025] Considering the high development costs, rigid architecture, and insufficient flexibility and customization support for enterprise content management across multiple scenarios, this application provides an enterprise content management data processing method and apparatus. Through a three-layer architecture model, including a library type layer, a content type layer, and a content instance layer, these are used to define business scenarios, dynamically define content types within the library, and uniformly store specific content data, respectively. The library type layer and content type layer are associated with independent configuration tables, allowing for dynamic expansion of business scenarios and content types by inserting configuration data. By constructing a unified content storage table, using library type identifiers and content type identifiers as logical isolation tags, all content data is uniformly stored in a single table, supporting flexible content types without the need for predefined data structures. Simultaneously, a universal processing interface decoupled from library types and content types is constructed, forming a highly reusable capability framework. This enables unified processing and reuse of all content data across different business scenarios, thereby improving enterprise content management efficiency and reducing implementation costs.

[0026] To improve enterprise content management efficiency and reduce implementation costs, this application provides an embodiment of an enterprise content management data processing method, see [link to embodiment]. Figure 1 The enterprise content management data processing method specifically includes the following: First, during the enterprise's digital transformation process, different business scenarios require managing different types of content, such as: Product management: This involves managing product information, SKUs, specifications, etc. Marketing content: This involves managing social media creatives, ad creatives, and marketing copy. Food industry: Requires management of recipes, formulas, nutritional information, etc. Celebrity manager: This involves managing artist files, performance schedules, and business collaborations.

[0027] Existing technical solutions require the development of separate systems for each scenario. Each system repeatedly implements permission, search, and approval functions, resulting in high development costs, difficult maintenance, poor scalability, and the potential for data silos. Furthermore, CMS / DAM systems suffer from rigid architectures, fixed content types, and limited reusability, failing to provide customized configurations for different clients and thus unable to adapt to enterprise transformation needs.

[0028] To address the above issues, we found that the pain points are that enterprise-level content management systems lack support for multiple business scenarios, dynamic content types, capability reuse, rapid expansion, and customization.

[0029] The core technology for solving the above problems lies in: how to support multiple business scenarios (libraries) in a single system and achieve data logic isolation; how to dynamically create and manage multiple content types within the library without modifying the code or database structure; how to achieve 100% reuse of general capabilities to avoid redundant development; and how to support customized extensions at the library level while maintaining system uniformity.

[0030] We propose a three-tier architecture design that combines configuration-driven and unified storage to achieve unified management of multiple databases and content types.

[0031] Step S101: Define a hierarchical data processing model based on preset configuration information. The hierarchical data processing model includes a library type layer, a content type layer, and a content instance type layer. The library type layer is used to define different business scenarios. The content type layer is used to define content types under the logical isolation of each library type layer. The content instance type layer is used to store the specific content data of the library type and content type. The library type layer and the content type layer are respectively associated with independent configuration tables for inserting configuration data. First, this step establishes a hierarchical and configurable data model to abstract the content management needs of different business scenarios into a unified hierarchical structure, laying the underlying data foundation for the subsequent implementation of dynamic management of multiple databases and multiple content types.

[0032] Three-tier architecture model: Plain Text First layer: Library Type Layer Define business scenarios, such as product library, recipe library, celebrity library. └─ Configure library-level attributes: language, permission policy, card view, etc. Second layer: Content Type Layer └─ Dynamically create content types within the library, such as mobile phones, computers, and home appliances. Each type is associated with different templates and field configurations. The third layer: Content Instance Layer └─ Stores specific content data └─ All libraries and all types share a unified storage structure For example, a hierarchical relationship can be illustrated as follows: Plain Text Product Cloud ├─ Mobile phone │├─ iPhone 15 Pro │├─ Xiaomi 14 Pro │└─ OPPO Find X7 ├─ Computer │├─ MacBook Pro │├─ ThinkPad X1 │└─ Huawei MateBook └─ Home Appliances ├─ Haier Refrigerator └─ Midea Air Conditioner In this embodiment, the core design principle of the model is logical isolation and configuration-driven design.

[0033] Logical isolation can be achieved, ensuring that databases and content types within databases are isolated from each other in terms of business logic and permissions. This is accomplished by using database type identifiers (such as product_cloud) and content type identifiers (such as mobile) as core tags for all data records. During system runtime, these two tags can clearly identify and define the business boundaries of each piece of data.

[0034] Configuration-driven architecture enables the behavior, structure, and rules of the library type layer and content type layer to be managed by independent configuration tables, rather than being hard-coded into the program. Specifically: Library Configuration Table: Stores global configuration information for each library type (such as "Product Library"), including supported languages, default permission policies, card view display methods, translation prompts, etc.

[0035] Content type configuration table: Stores the definition information of specific content types (such as "mobile phone") under each library, including metadata such as type name and activation status.

[0036] Configuration tables are the cornerstone of data management flexibility. When it is necessary to adjust the rules of a database or add a new content type, administrators do not need to modify the system database table structure or core program code. They only need to insert or update a configuration record in the corresponding configuration table.

[0037] Step S102: Construct a structured data table, and store each content instance data of the content instance layer in the structured data table with its library identifier and content type identifier as logical isolation tags. The structured data table includes fixed fields for storing the logical isolation tags and general fields for storing the content instance data in a dynamic format. Optionally, in this embodiment, a structured data table is constructed to hold various content instance data under all business scenarios (libraries). Its core design idea is to achieve structured storage and efficient management of data from multiple libraries and multiple content types within a single physical data table by introducing logical isolation tags.

[0038] Specifically, create a unified content table named nebula_content. This table's structure contains two main categories of fields: Fixed fields: These are used to store structured metadata information common to all content instances. These fields are predefined and fixed. They include the logical isolation tags library_type (library type identifier) ​​and content_type (content type identifier) ​​as well as general metadata.

[0039] General dynamic field: Establish a field named content_info, whose data type is long text (such as LONGTEXT), specifically for storing variable detailed data of different content types in JSON format.

[0040] For example, the unified content table (nebula_content): SQL CREATE TABLE `nebula_content` ( `id` bigint PRIMARY KEY COMMENT 'Content ID', `library_type` varchar(20) NOT NULL COMMENT 'library type', `content_type` varchar(20) NOT NULL COMMENT 'Content type', `biz_id` varchar(50) COMMENT 'Unique Business Identifier', `name` varchar(255) COMMENT 'Content Name', `template_code` varchar(50) COMMENT 'Template encoding', `primary_language` varchar(10) COMMENT 'primary language', The `content_languages` text COMMENT 'List of supported languages ​​(JSON)', `content_info` longtext COMMENT 'Content information (JSON format)', `content_status` tinyint COMMENT 'Content status', `importance` tinyint COMMENT 'scope of permissions', `create_user` bigint COMMENT 'Creator', `create_time` datetime COMMENT 'Creation Time', `update_user` bigint COMMENT 'Updater', `update_time` datetime COMMENT 'Update time', `status` tinyint COMMENT 'Deletion status: 0 - Normal; 1 - Deleted', KEY `idx_library_type` (`library_type`), KEY `idx_content_type` (`content_type`), KEY `idx_biz_id` (`biz_id`) COMMENT='Uniform Content Store Table'; When the system needs to store a specific content instance (such as an "iPhone 15 Pro" product), perform the following operations: First, determine the library_type (e.g., product_cloud) and content_type (e.g., mobile) of the instance based on its business affiliation.

[0041] Secondly, all the unique attributes of the instance (such as brand, model, color, price, etc.) are assembled into a structured JSON object according to predefined template rules.

[0042] Finally, the library_type, content_type, and the assembled JSON object (stored in content_info), along with other common metadata, are inserted as a complete record into the unified nebula_content table. All libraries and all types of content follow this process, achieving centralized physical storage of data.

[0043] Through this step, library_type + content_type achieves logical isolation through dual identification, and content_info (JSON) enables flexible storage of different types of field data without the need for predefinition. At the same time, all libraries share common fields such as create_user and status.

[0044] Unified structured storage ensures that all content data has a consistent access interface and storage paradigm. This makes it possible to build unified functional modules such as permission verification, search indexes, approval processes, and multi-language processing at the upper layer. These modules can be configured with policies based on library_type and content_type without needing to worry about the differences in the underlying data, thereby maximizing the reusability and standardized management of system capabilities.

[0045] Step S103: In response to the enterprise's request to create a content type for a specific library type, a unique content type identifier is generated. The content type identifier, the content type name, and the library identifier corresponding to the content type are associated and persistently stored in the content type configuration table in the form of a configuration record. The library type configuration table is updated synchronously to realize the data content type update. Optionally, in this embodiment, a content type is created under any library type, and a completely new data category is defined by inserting records into the configuration table, without any backend code modification or database table structure adjustment.

[0046] Specifically, enterprise administrators initiate a "Add Content Type" operation in a selected target library (such as a "Product Library") through the system management interface. When the system receives this request, its core parameters include the unique identifier of the target library (library_type, such as product_cloud) and the name of the new content type to be created (such as "Smartwatch").

[0047] The system's backend service call algorithm automatically generates a globally unique short code as the technical identifier (content_type) for this new content type. This identifier is a string of random letters (such as "aBcDeF"), and its core function is to serve as a key index for identifying, routing, and associating all data of this type within the system. It plays a crucial role in database associations, cache key generation, and API calls.

[0048] The system combines the key information of this operation—library_type, content_type, and content_type name—into a complete configuration record.

[0049] This record was then persistently inserted into the proprietary "Content Type Configuration Table" (nebula_library_content_config). The creation of this record registered a new data type named "Smartwatch" under the "Product Library," with the technical code "aBcDeF."

[0050] The system then queries the overall configuration record of the library (stored in the "library configuration table," such as nebula_library_config), updates the "list of contained content types" field maintained by it, and adds the newly generated content_type ("aBcDeF") to the list. This operation ensures that the library can perceive all the content types it contains from its perspective.

[0051] After the configuration data is updated, the system will proactively clear the configuration cache associated with that library (such as cache keys in Redis). The next time any service or interface needs to load the configuration information of this library, it will reread the complete list containing the new content types from the database. At this point, the new content types take effect immediately and are available for use.

[0052] For example, the algorithm flow for the dynamic content type generation mechanism is as follows: Plain Text Step 1: Receive requests for new content types Input: library_type, type_name Step 2: Generate a unique content_type encoding content_type = Randomly generate 6 letters (e.g., "aBcDeF") Step 3: Save content type configuration INSERT INTO nebula_library_content_config (library_type, content_type, name, enable_flag) VALUES (library_type, content_type, type_name, 1) Step 4: Update the type list in the library configuration. SELECT content_types FROM nebula_library_config WHERE library_type =? content_types.add(content_type) UPDATE nebula_library_config SET content_types = ? WHERE library_type= ? Step 5: Synchronize and create metadata options INSERT INTO metadata_attrs_options (attr_code, option_code, option_name) VALUES ('nebula_content_type', content_type, type_name) Step 6: Clear cache DELETE FROM redis WHERE key = 'library_config:' + library_type Step 7: Success is returned Return: content_type_id, content_type_code This step enables the system to break through the limitations of fixed content types in traditional CMS systems. Enterprises can create new content types at any time within any library (such as adding "Smartwatch" or "Router" under the "Product Library"), achieving on-demand, online, and dynamic expansion of the data model.

[0053] The newly created content type is strictly confined to a specific business library context by being identified by both `library_type` and `content_type`, thus achieving logical data isolation. Simultaneously, all concrete data (content instances) under this type will use the same `content_type` identifier in the future and will be stored in the same unified content table along with data from all other libraries and of all types. This perfectly balances the needs for "flexible expansion" and "unified architecture".

[0054] Step S104: Construct a general processing interface that decouples library types and content types, register business logic extension processors for each library type, determine the corresponding data reuse framework, and perform data processing operations on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests to realize enterprise content instance data management.

[0055] Optionally, in this embodiment, a customizable business logic execution layer is built on top of the unified storage architecture in step S102. This aims to address the key contradiction of "how to flexibly support the unique rules of each business library while ensuring a high degree of consistency in general capabilities." Its implementation path can be decomposed into three stages: interface abstraction and standardization, dynamic registration and assembly of business logic, and finally, unified scheduling and execution.

[0056] First, the system designs and defines a set of highly abstract, general processing interfaces. These interfaces specify the processing steps and input / output contracts that all content data must follow throughout its core lifecycle (such as creation, update, query, and deletion), laying the foundation for subsequent reuse and scheduling. Through technical decoupling, the core processes no longer depend on any specific library type.

[0057] Next, the system will implement and register a dedicated business logic extension processor for each library type with specific business rules. Developers will write concrete classes that implement the aforementioned general interface for each specific library. These classes only need to implement the library-specific business rules, such as "FG code uniqueness verification" for the product library or "artist name duplicate check" for the celebrity library. The system uses the dependency injection mechanism of an inversion of control container (such as the Spring framework) to automatically discover these implementation classes and register them in a centralized processor map, using the library type identifier as the key.

[0058] This process enables business decoupling and hot-swappability: the business logic of each library is encapsulated in an independent component, without interfering with each other; adding a rule to a new library only requires adding a processor to implement and register it, without modifying any core process code. The system's scalability is thus greatly enhanced.

[0059] Finally, when the enterprise frontend or API initiates a specific data management request (such as "create a product record"), the system enters the unified scheduling phase. The core service (such as ContentSaveService) acts as the scheduling center, performing the following operations in sequence: 1) Executing common fixed processes shared by all libraries (such as parameter validation, permission checks, and basic data assembly); 2) Dynamically retrieving the corresponding business logic extension processor from the processor mapping table based on the library_type carried in the request; 3) At key extension points in the general process (such as "before save"), calling specific methods in the processor (such as beforeSave) to execute library-specific validation or logic; 4) Continuing to complete subsequent general operations (such as data persistence and index synchronization); 5) At another extension point (such as "after save"), calling the processor again for subsequent processing (such as business ID generation and associated data updates).

[0060] This step achieves a balance between standardization and customization in enterprise data processing. All data is processed through the same high-quality core pipeline, while each business database can be seamlessly injected with its specific needs through "pluggable modules," satisfying the diversity of business operations.

[0061] This example demonstrates how this embodiment, based on a three-tier architecture design, achieves unified management of multiple databases and content types by combining configuration drivers and unified storage.

[0062] As described above, the enterprise content management data processing method provided in this application embodiment can utilize a three-layer architecture model, including a library type layer, a content type layer, and a content instance layer. These layers are used to define business scenarios, dynamically define content types within the library, and uniformly store specific content data. The library type layer and the content type layer are associated with independent configuration tables, allowing for dynamic expansion of business scenarios and content types by inserting configuration data. By constructing a unified content storage table, using library type identifiers and content type identifiers as logical isolation tags, all content data is uniformly stored in a single table, supporting flexible content types without the need for predefined data structures. Simultaneously, a universal processing interface decoupled from library types and content types is constructed, forming a highly reusable capability framework. This enables unified processing and reuse of all content data under different business scenarios, thereby improving enterprise content management efficiency and reducing implementation costs.

[0063] In one embodiment of the enterprise content management data processing method of this application, it may further include the following: Step S201: In response to the enterprise's request to create content instance data for a specific library type and a specific content type, perform the following creation operations according to the content creation interface in the data reuse framework: Step S202: Verify the validity of the library identifier and content type identifier in the content instance creation request; Step S203: Obtain the corresponding field template configuration according to the content type identifier, and based on the field template configuration, encapsulate the field data in the content instance creation request into structured data that conforms to a general field format; Step S204: Perform a business uniqueness check on the structured data according to the configuration information of a specific library, wherein the check rules and check fields for the business uniqueness check are defined by the configuration information of the specific library; Step S205: If the verification passes, the encapsulated structured data, the library identifier, and the content type identifier are persisted as a new record to the structured data table.

[0064] Optionally, in this embodiment, this step describes a configurable, complete processing flow triggered when an enterprise user creates a new piece of content of a specific type in a specific business library.

[0065] The system receives a creation request from the frontend or API, which explicitly carries the target library type (library_type, such as product_cloud), the target content type (content_type, such as mobile), and specific field data. The system then calls the unified content creation interface to initiate the subsequent process.

[0066] The system first validates the library identifier and content type identifier in the request. This step involves querying the relevant configuration table to confirm whether the requested library type exists, is enabled, and whether the requested content type is defined and allowed to be created in that library. This is access control, ensuring that all operations are performed within a defined and controllable business scope, preventing invalid or unauthorized requests from entering the core logic.

[0067] The system dynamically retrieves a predefined "field template configuration" based on the verified content type identifier. This template defines which fields should be included in this type of content (such as "product name," "specifications," and "price"), the data type of each field, and whether they are required. Using this template, the system cleans, transforms, and assembles the scattered, raw field data in the request, ultimately encapsulating it into a structured content_info object, typically in JSON format. This step is a crucial data normalization process; it unifies the diverse forms of business data into a universal format that the system can recognize and process, forming the foundation for unified storage and retrieval.

[0068] The encapsulated structured data will undergo core business rule verification—business uniqueness verification—defined by a specific library. Based on the library's configuration information, the system will determine the fields requiring uniqueness constraints (e.g., "FGCode" in the product library, "artist name" in the celebrity library), and extract the corresponding field values ​​from the newly encapsulated `content_info`, performing deduplication verification in a unified storage table. Verification rules (e.g., whether to differentiate between languages, whether to consider deleted data) are also dynamically defined by the library configuration. This step demonstrates the system's business adaptability, embedding configurable, library-level business logic control points into the general process.

[0069] After all validations pass, the system will perform the final data write operation. It will use the encapsulated `content_info` (structured data), `library_type` (library identifier), and `content_type` (content type identifier) ​​as core fields, along with other common metadata (such as creator, creation time, and status), to insert a new record into the "structured data table" (i.e., the unified content table `nebula_content`). At this point, a new content instance has been officially created in the system.

[0070] Through step S205, this embodiment achieves the unification of standardization and customizability in the creation process. By dynamically loading template configurations and business verification rules, the system adapts to the differentiated data structures and core business constraints of different business scenarios.

[0071] In one embodiment of the enterprise content management data processing method of this application, it may further include the following: Step S301: Content query operation. Receive a query request according to the content query interface in the data reuse framework. The query request specifies at least one library identifier and / or content type identifier as a filtering condition. Query the structured data table based on the filtering condition and return the corresponding list of content instances. Step S302: Content update operation. Receive update request according to the content update interface in the data reuse framework, call the business logic extension processor associated with the library type to which the update request belongs to perform data compliance verification before the update, and execute the update operation.

[0072] Optionally, in this embodiment, the process of performing content retrieval in the entire unified dynamic management system is first defined.

[0073] Content query requests typically encapsulate the query intent initiated by the user or system. A key characteristic is the explicit specification of at least one "logical coordinate" for data filtering—namely, the library identifier (library_type) and / or content type identifier (content_type). For example, a request might specify to query only the "product library," or further limit it to the "mobile phone" type within the "product library."

[0074] Upon receiving a request, the system performs a query based on the design of the "structured data table" (i.e., the nebula_content table). Because this table has pre-defined precise logical indexes on the `library_type` and `content_type` fields, the system can directly use these identifiers as efficient database query conditions. Its underlying implementation typically constructs a dynamic query builder that transforms the filtering conditions in the request (which may also include general field conditions such as keywords, status, and creation time range) into precise SQL queries or Elasticsearch search DSLs on the unified content table. The query engine utilizes composite indexes on the table to quickly locate data rows that meet the conditions.

[0075] The query result is a "list of content instances". Each item in the list is complete data parsed from the content_info JSON field, conforming to the template structure of that content type, and will be accompanied by its uniform metadata (such as ID, name, status, etc.).

[0076] Optionally, in this embodiment, this step also standardizes the process for content modification.

[0077] The key step is that the system doesn't directly execute the update; instead, it first initiates an "extended processor scheduling" process. Based on the library identifier (library_type) of the content to be updated, the system dynamically locates and calls the dedicated business logic extended processor (i.e., a concrete class implementing a unified interface such as ContentSaveHandler) associated with that library type from the registered processor mapping table. The system then calls the processor's pre-update verification method (such as beforeUpdate), passing the original content data and the data to be updated as parameters.

[0078] Within this processor, library-specific data compliance checks are performed. For example, for the "Product Library," the processor checks the uniqueness of the "FG code" to prevent conflicts with other products; for the "Celebrity Library," it checks whether the "Artist Name" is duplicated. These verification logics are completely defined independently by the processor for each library, decoupled from the core update process. The update process will only continue after all specific checks pass.

[0079] Subsequently, the system performs a standardized update operation: merging the validated data into the `content_infoJSON` field of the original content, and updating the timestamp and version information in the unified content table. After completion, the search engine index is typically updated synchronously, and the processor's post-processing methods may be called again for additional processing.

[0080] Understandably, any generic processing rule can be defined through a generic interface, enabling one-time definition and permanent reuse. To define and manage the core configuration components of business automation processes, we built a library process configuration table to store the process rules and triggering logic for content operations (such as creation, update, approval, publication, translation, etc.) under specific library types. An example is as follows: Library process configuration table (nebula_library_process_config) SQL CREATE TABLE `nebula_library_process_config` ( `id` bigint PRIMARY KEY, `library_type` varchar(20) NOT NULL COMMENT 'library type', `content_type` varchar(20) NOT NULL COMMENT 'Content type', `process_type` varchar(50) COMMENT 'Process type', `is_all` int COMMENT 'Whether to apply to all fields', `position_codes` text COMMENT 'List of applied fields (JSON)', `apply_field` varchar(50) COMMENT 'target field', The `extra_info` text COMMENT 'Process Configuration (JSON)', `create_user` bigint, `create_time` datetime COMMENT='Library Process Configuration Table'; Through step S302, this embodiment ensures that all content goes through a reliable and auditable general update pipeline, while accurately executing strong constraint rules under different business scenarios.

[0081] In one embodiment of the enterprise content management data processing method of this application, it may further include the following: Step S401: Associate an independent library configuration table for the library type layer to store and manage the configuration strategies for each library type. Each record in the library configuration table uniquely corresponds to a library type and stores at least one of the following: library identifier, supported natural language list, default permission policy, extended configuration information related to specific business processes, and view display configuration information for that library type. Step S402: Associate an independent content type configuration table with the content type layer to define and manage each content type. The records in the content type configuration table are uniquely identified by a combination of library identifier and content type identifier, and store at least one of the content type name and activation status. The content type identifier is a unique string encoding.

[0082] Optionally, in this embodiment, this step is based on a configuration table-driven system core management mechanism.

[0083] Specifically, each record in the "Library Configuration Table" represents an independent business scenario (library) within the system. It mainly contains the following key configuration information: Library configuration table (nebula_library_config) SQL CREATE TABLE `nebula_library_config` ( `id` bigint PRIMARY KEY, `library_type` varchar(20) NOT NULL UNIQUE COMMENT 'library type', The `content_languages` text COMMENT 'Supported Languages ​​(JSON)', The `translate_languages` text COMMENT 'Translation Languages ​​(JSON)', The `card_view_info` text COMMENT 'Card view configuration (JSON)', `translate_prompt` text COMMENT 'Translation prompt', `default_importance` int COMMENT 'Default permission type', The `extra_info` text COMMENT 'Extended Information (JSON)', `create_user` bigint, `create_time` datetime, `update_user` bigint, `update_time` datetime COMMENT='Library-level Configuration Table'; Specifically, the "Content Type Configuration Table" is hierarchically related to the library configuration table, with records logically nested under the library types. Each record represents a specific content category within a particular library. Its key information includes: Content type configuration table (nebula_library_content_config) SQL CREATE TABLE `nebula_library_content_config` ( `id` bigint PRIMARY KEY, `library_type` varchar(20) NOT NULL COMMENT 'library type', `content_type` varchar(20) NOT NULL COMMENT 'Content type', `name` varchar(255) COMMENT 'Type Name', `enable_flag` tinyint COMMENT 'Enable: 0-No; 1-Yes', The `extra_info` text COMMENT 'Extended Information (JSON)', `create_user` bigint, `create_time` datetime, KEY `idx_library_content_type` (`library_type`, `content_type`) COMMENT='Content Type Configuration Table'; These two configuration tables transform the library attributes and content structure definitions, which originally needed to be hard-coded in the program, into read-write records in the database. When business needs to be adjusted (such as adding language support to a library) or expanded (such as adding a new content type), the system only needs to perform add, delete, and modify operations on the configuration tables. There is no need to stop the system, modify the database table structure, or redeploy the code, achieving true dynamic business logic and immediate effect.

[0084] The library configuration table ensures complete independence of different business scenarios (libraries) at the policy level, allowing each library to have its own set of operating rules. The content type configuration table, through a composite key design of "library identifier + content type identifier," ensures type uniqueness while clearly expressing the dependency relationship between the type and the library, providing precise data anchors for the system's fine-grained management and permission allocation.

[0085] Through step S402, this embodiment successfully established independent metadata management schemes for the library type layer and the content type layer, respectively, extracting business logic from the code and transforming it into configurable and storable data.

[0086] In one embodiment of the enterprise content management data processing method of this application, it may further include the following: Step S501: Preset template configuration, wherein the template configuration is used to define the specific data structure of the content instance; Step S502: Associate the template configuration with one or more library type layers or content type layers, so as to package the content instance according to the template configuration when creating or editing the content instance.

[0087] Optionally, in this embodiment, the template configuration completely liberates the data structure definition of the content from hard coding and transforms it into configurable metadata.

[0088] Specifically, the system pre-creates and defines a series of "templates" through a visual backend interface or configuration tool. Each template is essentially a blueprint for a set of fields and their attribute specifications. These field attributes include: the field's unique code (e.g., recipe_name), display name (e.g., "recipe name"), data type (e.g., text, number, rich text, image, dropdown selection, etc.), whether it is required, default value, validation rules (e.g., regular expressions, length limits), and the field's layout and sorting information in the form.

[0089] The work that traditionally required developers to design table structures at the database level and hard-code form logic in the code is transformed into a standardized operation that is entirely driven by configuration. This allows the system to flexibly adapt to the different data structure requirements of various business scenarios without code release or database migration.

[0090] Next, based on S501, dynamic binding and driving of configuration to specific business was implemented.

[0091] By configuring the template, you can associate it with one or more specific library type layers or content type layers. For example, a template named "Chinese Food Editing Template" can be associated with the specific content type "Chinese Food" under the "Recipe Library".

[0092] When a user creates or edits a content instance of a specific library type on the front end (for example, adding a "Chinese dish" to the "Recipe Library"), the system automatically loads and applies the associated template configuration based on the library type and content type of the content instance. The front end interface dynamically renders the corresponding, structured input form according to the field list, data type, and layout rules defined in the template. After the user submits the form data, the system also validates and assembles the data according to the template, ultimately storing the formatted and structured data (usually packaged as a JSON object) into the general field `content_info`.

[0093] Through step S502, this embodiment successfully ensures that the new data structure can take effect immediately without waiting for the development cycle.

[0094] In one embodiment of the enterprise content management data processing method of this application, it may further include the following: Step S601: Create or jointly create database indexes for the library identifier and content type identifier in the structured data table to achieve data partitioning and retrieval; Step S602: Synchronize the searchable data in the general fields to an independent full-text search engine and establish a mapping relationship with the primary key of the records in the structured data table for full-text retrieval.

[0095] Optionally, in this embodiment, this step uses database indexing technology to solve the problem of efficient data location and performance under a unified storage architecture.

[0096] We employ a tiered indexing strategy. First, we create independent single-column indexes for the `library_type` and `content_type` fields. This allows the system to quickly filter out all records belonging to a specific business library (e.g., "product library") or a specific content type (e.g., "mobile phones"). More importantly, the system creates a composite index for the combination `(library_type, content_type)`. This composite index enables queries to precisely locate a specific subset of content of a specific type within a specific library with extremely high efficiency, such as "all mobile phone products under the product library". From a data organization perspective, these indexes logically function as "data partitions". Although all data is physically stored in the same table, through indexes, the database engine can quickly filter and retrieve data as if accessing logically independent "partitioned tables," avoiding full table scans and significantly improving query performance.

[0097] Next, on top of unified structured storage, how to provide powerful and flexible full-text and keyword search capabilities? The core lies in building an independent but tightly mapped full-text search engine (such as Elasticsearch) cluster as a dedicated query layer.

[0098] Specifically, the system establishes a near real-time data synchronization mechanism. When data in the unified content table (nebula_content) changes (additions, deletions, modifications), the system captures these change events and extracts the core searchable data, assembling it into a document format suitable for full-text search. This document typically includes the content's ID, name, key text extracted from the content_infoJSON field, library type, content type, and other metadata used for filtering. This document is then synchronized to the full-text search engine to create or update its index. During this process, a strict mapping relationship is established with the primary key (such as the id field) of the source data record, ensuring that any result retrieved through the search engine can be traced back to the structured data table within milliseconds to obtain complete and accurate content details via its mapped primary key.

[0099] Through step S602, this embodiment successfully enables end users to perform complex searches beyond simple field matching, such as fuzzy keyword matching, multi-field combination filtering, and semantic relevance ranking, thereby quickly locating targets within massive amounts of heterogeneous content. Simultaneously, because search results are always anchored to a single authoritative data source (database primary key), the consistency and accuracy of data display are ensured. This mechanism allows the system to maintain the truthfulness and maintainability of a single data source while possessing powerful exploratory search capabilities.

[0100] In one embodiment of the enterprise content management data processing method of this application, it may further include the following: Step S701: In response to the enterprise's request to create a content type for a specific library type, a random string generation algorithm is invoked to determine the corresponding string composed of letter characters of a preset length; Step S702: Use this string as a unique content type identifier.

[0101] Optionally, in this embodiment, when the system receives a request to create a new content type, the backend service immediately invokes a preset "random string generation algorithm". This algorithm randomly and irregularly selects characters from a pool of pure letters (usually including uppercase and lowercase) according to a pre-defined length rule (e.g., 6 characters), ultimately generating a completely new string. This process is entirely programmatic and does not rely on manual input or existing data.

[0102] The random string generated in the previous step is then officially adopted by the system and given a core identity—serving as a "unique content type identifier" for this new content type. This identifier will serve as an immutable technical identity credential for this type within the system, permanently written into the content type configuration table, and bound to the library identifier and type name.

[0103] Through step S702, this embodiment successfully decouples technical identification from business logic. The identification code itself has no business meaning, but it avoids a chain reaction of technical modifications caused by changes in business names (such as renaming "smartphone" to "mobile phone"). Finally, this lightweight generation method has extremely low performance overhead and is completed instantly, providing a key technical guarantee for achieving a "second-level creation, instant effect" user experience for content types, making the system's dynamic scalability both efficient and reliable.

[0104] To improve enterprise content management efficiency and reduce implementation costs, this application provides an embodiment of an enterprise content management data processing apparatus for implementing all or part of the enterprise content management data processing method. See [link to embodiment]. Figure 2 The enterprise content management data processing device specifically includes the following components: The hierarchical architecture model determination module 10 is used to define a hierarchical data processing model based on preset configuration information. The hierarchical data processing model includes a library type layer, a content type layer, and a content instance type layer. The library type layer is used to define different business scenarios. The content type layer is used to define content types under the logical isolation of each library type layer. The content instance type layer is used to store the specific content data of the library type and content type. The library type layer and the content type layer are respectively associated with independent configuration tables for inserting configuration data. The unified storage structure determination module 20 is used to construct a structured data table, and to uniformly store each content instance data of the content instance layer in the structured data table with its library identifier and content type identifier as logical isolation tags. The structured data table includes fixed fields for storing the logical isolation tags and general fields for storing the content instance data in a dynamic format. The configuration driver creation module 30 is used to respond to the enterprise's content type creation request for a specific library type, generate a unique content type identifier code, associate the content type identifier code, the content type name and the library identifier corresponding to the content type, and persistently store it in the content type configuration table in the form of a configuration record, and synchronously update the library type configuration table to realize the data content type update. The data reuse module 40 is used to build a general processing interface that decouples library types and content types, register business logic extension processors for each library type, determine the corresponding data reuse framework, and perform data processing operations on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests to realize enterprise content instance data management.

[0105] As described above, the enterprise content management data processing device provided in this application embodiment can utilize a three-layer architecture model, including a library type layer, a content type layer, and a content instance layer. These layers are used to define business scenarios, dynamically define content types within the library, and uniformly store specific content data. The library type layer and the content type layer are associated with independent configuration tables, allowing for dynamic expansion of business scenarios and content types by inserting configuration data. By constructing a unified content storage table, using library type identifiers and content type identifiers as logical isolation tags, all content data is uniformly stored in a single table, supporting flexible content types without the need for predefined data structures. Simultaneously, a universal processing interface decoupled from library types and content types is constructed, forming a highly reusable capability framework. This enables unified processing and reuse of all content data under different business scenarios, thereby improving enterprise content management efficiency and reducing implementation costs.

[0106] To further illustrate this solution, this application also provides a specific application example of using the aforementioned enterprise content management data processing device to implement the enterprise content management data processing method, which specifically includes the following: Optionally, in this embodiment, the unified capability reuse architecture creates a unified content interface as follows:

[0107] Optionally, in this embodiment, a library-specific extension mechanism (Handler pattern) is used. Extension point interface definition: Java /

[0108] Content storage processor interface Each library can implement this interface, extending the library's specific business logic. / public interface ContentSaveHandler { /

[0109] Add pre-verification Extension Point 1: Custom Validation Logic / void beforeAdd( NebulaContentSourceTypeEnum contentSourceType, String libraryType, String contentType, String primaryLanguage, List <string>contentLanguages, JSONObject contentInfo ); /

[0110] Add post-processor Extension Point 2: Custom Post-Processing / void afterAdd( NebulaContentSourceTypeEnum sourceTypeEnum, NebulaContentPO content ); /

[0111] Verification before update Extension Point 3: Custom Update Verification / void beforeUpdate( NebulaContentPO originContent, JSONObject updateContentInfo ); /

[0112] Post-update field processing Extension Point 4: Custom Field Update Logic / void afterUpdateAttrs( NebulaContentPO content, List <rpccontentattrinforeq>attrInfos ); } Example of product library expansion implementation:

[0113] Handler auto-assembly mechanism:

[0114] The complete process of quickly building a new library: Step 1: Create library configuration

[0115] Step 2: Create content type Call via API:

[0116] The system will execute automatically: Generate a unique content_type = "aBcDeF" Insert into the nebula_library_content_config table Update the nebula_library_config.content_types list Create metadata option Step 3: Configure field templates Reuse an existing field or create a new field:

[0117] Step 4: Configure permissions (optional)

[0118] Step 5: Configure the process (optional)

[0119] Step 6: Automatic front-end rendering The front-end automatically generates the UI based on the configuration: List page: Renders field columns based on list_template Details page: Grouped by view_template rendering fields Edit page: Renders the form based on edit_template Search page: Renders filter options based on search_template Complete! New warehouse is online. From configuration to deployment, it only takes 1-2 weeks, which is 80%-90% more efficient than the traditional method (2-3 months).

[0120] Optionally, in this embodiment, scalability and flexibility are illustrated with examples: Supported extended scenarios: Add a new library: Configurable, it will be online in 1-2 weeks. New content type: Online operation, completed in 5 minutes Add a new field: Configure template, completed in 10 minutes. Custom business logic: Implement a Handler, to be completed in 1-2 days. Adjust permission policy: Modify configuration, effective immediately. Change process: Configure the process without modifying the code. Data consistency: A unified storage structure avoids data silos. A unified index structure ensures consistent search performance. Unified transaction management ensures data integrity. Performance metrics: Content creation time: <500ms Content query: <100ms (cache hit) / <200ms (database query) Search response time: <300ms (ES) Concurrency support: >1000 QPS Optionally, in this embodiment, a specific implementation example is provided: Example 1: Building a recipe library Scenario Description: A food company needs to manage three types of recipes: Chinese cuisine, Western cuisine, and baking. Each recipe includes fields such as name, description, ingredients, cooking steps, and cooking time, and supports both Chinese and English.

[0121] Step 1: Create library configuration The administrator logs into the system backend and fills out the library configuration form: Library type code: recipe_cloud Library Name: Recipe Library Supported languages: Chinese (zh_CN), English (en_US) Translation language: Chinese English Default permissions: Visible to all employees in the enterprise System execution:

[0122] Step 2: Create content type The administrator clicks the "Add Content Type" button and enters the type name: Type 1: Chinese food The second type: Western food The third type: Baking System execution (taking "Chinese food" as an example):

[0123] Repeat the above process to create "Western Food" (gHiJkL) and "Baking" (mNoPqR). Step 3: Configure field templates Administrators configure the editing template and select the required fields: Recipe Name (nebula_name): Single-line text, required. Recipe description: Multi-line text, required. Recipe Cover: Image upload, required. Ingredients list: Multi-line text, required. Cooking steps: Rich text, required. Cooking time (cooking_time): Integer, optional Difficulty level: Single choice, optional Target audience (target_audience): Multiple selections, optional. System execution:

[0124] Step 4: Create recipe content Users log in to the front end, click "Add Content", select the "Chinese Food" type, and fill out the form: Recipe Name: Kung Pao Chicken Recipe Description: Classic Sichuan cuisine, fragrant and spicy. Ingredients: 300g chicken breast, 100g peanuts, 50g dried chili peppers... Cooking steps: 1. Dice the chicken... 2. Sauté in hot oil until fragrant... Cooking time: 30 minutes Difficulty level: Medium Suitable for: Families, gatherings System execution:

[0125] Step 5: Verify capability reuse Without any development, the recipe library automatically possesses the following capabilities: Access control: Allows setting visibility to only the user, department, or all members. Search function: Search by name, ingredient, difficulty, etc. Multilingual support: You can switch between Chinese and English to view. Approval process: Configurable approval release Data reports: You can view statistics such as page views and shares. OpenAPI: Enables integration with third-party systems via API. result: Development time: 1 week (mainly configuration) Code length: 0 lines (no business logic code required) Deployment period: 2 weeks (including testing) Compared to traditional methods: Efficiency increased by 85% Example 2: Extending Special Business Logic for the Product Library Scenario description: The product database needs to verify the uniqueness of FG Code (finished product code), which is a business rule specific to the product database.

[0126] Step 1: Implement the ContentSaveHandler interface Developers create the ProductCloudSaveHandler class:

[0127] Step 2: Deploy and Go Online After developers submit code and the system is deployed: Spring automatically scans and registers ProductCloudSaveHandler. Add it to the handlerMap with the key "product_cloud". This Handler is automatically invoked for all creation / update operations in the product library. Step 3: Verify the effect If a user modifies the FG Code when updating the product: The system calls the beforeUpdate method. Perform FG Code uniqueness verification If the error is duplicated, throw an exception and prevent the update. The front end displays a user-friendly error message: "FG Code already exists: XXX" Key innovations: Zero intrusion: No need to modify the core code Hot-swappable: Handlers can be added or removed at any time. High cohesion: Product library logic is concentrated in one class. From a hardware perspective, in order to improve enterprise content management efficiency and reduce implementation costs, this application provides an embodiment of an electronic device for implementing all or part of the enterprise content management data processing method, wherein the electronic device specifically includes the following: The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to realize information transmission between the enterprise content management data processing method and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the enterprise content management data processing method in the present embodiment, and the content of the embodiments of the enterprise content management data processing method is incorporated herein, and repeated details will not be described again.

[0128] Figure 3 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 3 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 3 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0129] In one implementation, the enterprise content management data processing method can be configured separately from the central processing unit 9100. For example, the enterprise content management data processing method can be configured as a chip connected to the central processing unit 9100, and the functions of the enterprise content management data processing method can be realized through the control of the central processing unit.

[0130] like Figure 3 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 3 All components shown; in addition, the electronic device 9600 may also include Figure 3 For components not shown, please refer to existing technologies.

[0131] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the enterprise content management data processing method with a server or client as the execution subject in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the enterprise content management data processing method with a server or client as the execution subject in the above embodiments. Embodiments of this application also provide a computer program product capable of implementing all steps of the enterprise content management data processing method in the above embodiments, where the execution subject is a server or a client. When the computer program / instruction is executed by a processor, it implements the steps of the enterprise content management data processing method.

[0132] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects, and the content of this specification should not be construed as limiting the present invention.< / rpccontentattrinforeq> < / string>

Claims

1. A method for processing enterprise content management data, characterized in that, The method includes: A hierarchical data processing model is defined based on preset configuration information. The hierarchical data processing model includes a library type layer, a content type layer, and a content instance type layer. The library type layer is used to define different business scenarios. The content type layer is used to define content types under the logical isolation of each library type layer. The content instance type layer is used to store the specific content data of the library type and content type. The library type layer and the content type layer are respectively associated with independent configuration tables for inserting configuration data. A structured data table is constructed, and each content instance data of the content instance layer is stored in the structured data table with its library identifier and content type identifier as logical isolation tags. The structured data table includes fixed fields for storing the logical isolation tags and general fields for storing the content instance data in a dynamic format. In response to an enterprise's request to create a content type for a specific library type, a unique content type identifier is generated. The content type identifier, the content type name, and the library identifier corresponding to the content type are associated and persistently stored in the content type configuration table in the form of a configuration record. The library type configuration table is updated synchronously to realize the update of data content types. A general processing interface is constructed to decouple library types and content types, and a business logic extension processor is registered for each library type. The corresponding data reuse framework is determined, and data processing operations are performed on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests to realize enterprise content instance data management.

2. The enterprise content management data processing method according to claim 1, characterized in that, The step of performing data processing operations on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests includes: In response to an enterprise's request to create content instance data for a specific library type and content type, the following creation operations are performed according to the content creation interface in the data reuse framework: Verify the validity of the library identifier and content type identifier in the content instance creation request; Obtain the corresponding field template configuration based on the content type identifier, and based on the field template configuration, encapsulate the field data in the content instance creation request into structured data that conforms to a general field format; The structured data is subjected to business uniqueness verification based on the configuration information of a specific library, wherein the verification rules and verification fields for the business uniqueness verification are defined by the configuration information of the specific library. If the verification passes, the encapsulated structured data, the library identifier, and the content type identifier will be persisted as a new record to the structured data table.

3. The enterprise content management data processing method according to claim 1, characterized in that, The step of performing data processing operations on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests also includes: The content query operation receives a query request from the content query interface in the data reuse framework. The query request specifies at least one library identifier and / or content type identifier as a filtering condition. Based on the filtering condition, the structured data table is queried, and a corresponding list of content instances is returned. The content update operation receives an update request from the content update interface in the data reuse framework, calls the business logic extension processor associated with the library type to which the update request belongs to perform data compliance verification before the update, and then executes the update operation.

4. The enterprise content management data processing method according to claim 1, characterized in that, The library type layer and the content type layer are each associated with independent configuration tables, including: An independent library configuration table is associated with each library type layer to store and manage the configuration strategies for each library type. Each record in the library configuration table uniquely corresponds to a library type and stores at least one of the following: library identifier, supported natural language list, default permission policy, extended configuration information related to specific business processes, and view display configuration information for that library type. An independent content type configuration table is associated with the content type layer to define and manage each content type. The records in the content type configuration table are uniquely identified by a combination of a library identifier and a content type identifier, and store at least one of the content type name and its enabled status. The content type identifier is a unique string encoding.

5. The enterprise content management data processing method according to claim 1, characterized in that, Following the definition of the hierarchical data processing model based on preset configuration information, which includes a library type layer, a content type layer, and a content instance type layer, the following is included: A preset template configuration, which is used to define the specific data structure of the content instance; The template configuration is associated with one or more library type layers or content type layers, and is used to wrap the content instance according to the template configuration when the content instance is created or edited.

6. The enterprise content management data processing method according to claim 1, characterized in that, Following the construction of the structured data table, the following is included: Database indexes are created or jointly created for the library identifier and content type identifier in the structured data table to achieve data partitioning and retrieval; The searchable data in the general fields is synchronized to an independent full-text search engine, and a mapping relationship is established with the primary key of the records in the structured data table for full-text retrieval.

7. The enterprise content management data processing method according to claim 1, characterized in that, The process of generating a unique content type identifier in response to an enterprise's content type creation request for a specific library type includes: In response to an enterprise's request to create content for a specific library type, a random string generation algorithm is invoked to determine the corresponding string composed of alphabetic characters of a preset length; Use this string as a unique content type identifier.

8. An enterprise content management data processing device, characterized in that, The device includes: A hierarchical architecture model determination module is used to define a hierarchical data processing model based on preset configuration information. The hierarchical data processing model includes a library type layer, a content type layer, and a content instance type layer. The library type layer is used to define different business scenarios. The content type layer is used to define content types under the logical isolation of each library type layer. The content instance type layer is used to store the specific content data of the library type and content type. The library type layer and the content type layer are respectively associated with independent configuration tables for inserting configuration data. A unified storage structure determination module is used to construct a structured data table. The content instance data of the content instance layer is stored in the structured data table with its library identifier and content type identifier as logical isolation tags. The structured data table includes fixed fields for storing the logical isolation tags and general fields for storing the content instance data in a dynamic format. The configuration-driven creation module is used to respond to the enterprise's content type creation request for a specific library type, generate a unique content type identifier, associate the content type identifier, the content type name, and the library identifier corresponding to the content type, and persistently store them in the content type configuration table in the form of configuration records, and synchronously update the library type configuration table to realize the data content type update. The data reuse module is used to build a general processing interface that decouples library types and content types, register business logic extension processors for each library type, determine the corresponding data reuse framework, and perform data processing operations on all content instance data in the structured data table according to the data reuse framework and enterprise data management requests to realize enterprise content instance data management.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the enterprise content management data processing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the enterprise content management data processing method according to any one of claims 1 to 7.

Images