Method, device, storage medium and program product for scheduling menu function based on configuration

Abstract

Embodiments of the present application provide a kind of based on the menu function scheduling method of configuration, equipment, storage medium and program product, it is related to computer software technical field.The method includes: reading structured configuration file;According to the service module classification indicated by service scheduling identifier, the mapping relationship between service module identifier and service processing object is established;In response to the operation request for target menu item, determine the context information related to processing operation request;Based on context information, obtain target service module identifier and target service function identifier from structured configuration file;According to target service module identifier, obtain the service processing object corresponding to target service module identifier from mapping relationship;Based on service processing object, the business function associated with target menu item is executed.The method of the present application realizes the decoupling of menu configuration and business logic, improves the expansibility of system.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a configuration-based menu function scheduling method, device, storage medium, and program product. Background Technology

[0002] In enterprise-level software systems (such as database management systems), the dynamic association between multi-level menus and backend business functions is a core requirement. Each menu item needs to accurately trigger specific business logic operations (such as data import and access control). As the system scales up and its functions iterate, the menu structure becomes increasingly complex, highlighting the high coupling between menu management and function calls, which severely restricts the system's maintainability and scalability.

[0003] In existing technologies, the binding of menus to business functions typically employs hard coding or static configuration based on the strategy pattern. Specifically, developers need to explicitly define the mapping relationship between menu items and corresponding business logic modules in the code, or write independent implementation logic for each menu function in the strategy class. When a user triggers a menu operation on the front-end interface, the back-end system calls the corresponding business service through a predefined mapping mechanism.

[0004] However, the above approach means that any changes to the menu structure will affect the backend business logic code, increasing the instability of the system during its continuous evolution. Summary of the Invention

[0005] This application provides a configuration-based menu function scheduling method, device, storage medium, and program product to solve the technical problem of system instability during continuous evolution.

[0006] In a first aspect, embodiments of this application provide a configuration-based menu function scheduling method, the method comprising:

[0007] Read the structured configuration file, which contains the hierarchical relationship information of the menu items and the business scheduling identifier corresponding to each menu item;

[0008] Based on the business module classification indicated by the business scheduling identifier, establish a mapping relationship between business module identifiers and business processing objects;

[0009] In response to an action request for a target menu item, determine the context information related to processing the action request;

[0010] Based on context information, the business scheduling identifier corresponding to the target menu item is parsed from the structured configuration file to obtain the target business module identifier and the target business function identifier;

[0011] Based on the target business module identifier, obtain the business processing object corresponding to the target business module identifier from the mapping relationship;

[0012] Based on the business processing object, the business method that matches the target business function identifier is called to execute the business function associated with the target menu item.

[0013] In this embodiment, by pre-managing menu hierarchy information and business scheduling identifiers in a structured configuration file, the menu display logic and backend business logic are effectively separated. This allows adjustments and expansions to menu functions to be made only by modifying the configuration file, without affecting the core business code, thereby reducing system maintenance costs and improving scalability. Simultaneously, the chained business scheduling identifier design combined with a module-level instance caching mechanism forms an efficient dynamic binding and invocation path, improving business scheduling flexibility while reducing runtime object creation overhead and optimizing system performance. Furthermore, by integrating context information processing into the scheduling process, a unified and scalable execution entry point is provided for the integration of functions such as permission verification and multi-language adaptation, enhancing system security and scenario adaptability.

[0014] In one possible implementation, a mapping relationship between business module identifiers and business processing objects is established based on the business module classification indicated by the business scheduling identifier, including:

[0015] Based on predefined interfaces, multiple business processing classes are obtained through scanning.

[0016] Determine the business module identifier corresponding to each business processing class;

[0017] The business module identifier is associated with the corresponding business processing class instance to establish a mapping relationship.

[0018] In this implementation, through the steps of interface scanning, identifier acquisition, and instance association storage described above, this embodiment provides an easy-to-maintain method for constructing mapping relationships. This avoids hard-coding mapping entries in the code. When a new business module is added, the developer only needs to create a new predefined interface implementation class and correctly return the module identifier. The system can automatically add it to the mapping relationship on the next startup, thereby enhancing the system's scalability and ensuring that the mapping relationship is updated synchronously with the business code.

[0019] In one possible implementation, the service scheduling identifier includes a service module identifier portion and a service function identifier portion connected by a predetermined separator;

[0020] Parse the business scheduling identifier corresponding to the target menu item from the structured configuration file, including: splitting the business scheduling identifier according to a predetermined separator to obtain the target business module identifier and the target business function identifier.

[0021] In this implementation, through structured design and segmentation parsing based on predefined delimiters, the business scheduling identifier becomes a compact and information-complete carrier of scheduling instructions. This not only decouples menu items from business logic but also precisely encodes the scheduling path into a parsable string, enabling the system to extract the necessary information for subsequent retrieval and invocation steps from the configuration in a unified manner. This improves the accuracy and flexibility of the entire scheduling process.

[0022] In one possible implementation, the predefined separator is a colon, and the service scheduling identifier is composed of the service module identifier, a colon, and the service function identifier connected in sequence.

[0023] In this implementation, by employing a specific chained format separated by colons, the business scheduling identifier maintains information integrity while ensuring readability and consistency. Developers can intuitively understand its structure during configuration, and the system can accurately and efficiently decompose the identifier into target parts during parsing (e.g., using the standard string split function), thereby improving the reliability of the scheduling process.

[0024] In one possible implementation, based on the target business module identifier, the business processing object corresponding to the target business module identifier is obtained from the mapping relationship, including:

[0025] Based on the target business module identifier, query mapping relationships;

[0026] If the query finds a match, the corresponding business processing object is obtained from the mapping relationship;

[0027] If the query does not find a match, a business processing object corresponding to the target business module identifier is created using reflection, and the created business processing object is added to the mapping relationship.

[0028] In this implementation, by first querying the cache and then creating and backfilling it via reflection if the cache is not found, the system ensures functional availability (avoiding system errors due to incomplete mapping relationships) while leveraging the performance-enhancing effect of caching. This allows the system to automatically adapt and learn when faced with new business modules or initial access after configuration updates, without requiring restarts or manual intervention, thus achieving a balance between high performance and scalability in the scheduling framework.

[0029] In one possible implementation, the structured configuration file also includes access control identifiers for the menu items;

[0030] Determine the context information related to processing the operation request, including: determining the access permissions of the user who initiated the operation request.

[0031] In this implementation, the above extensions provide the system with a basis for permission determination before parsing the business identifier based on context information and executing business scheduling. This design decouples security logic from business code and centrally manages it through configuration. This not only improves system security but also makes adjusting permission policies as flexible and convenient as modifying the menu structure, without requiring code changes, further enhancing the framework's maintainability.

[0032] In one possible implementation, based on context information, the business scheduling identifier corresponding to the target menu item is parsed from the structured configuration file, including:

[0033] The access permission information is matched and verified against the access control identifier of the target menu item.

[0034] The parsing step is only executed if the matching verification passes.

[0035] In this implementation, by making permission verification a prerequisite for parsing the business scheduling identifier, this embodiment achieves the integration and association of permission control and business scheduling. This design ensures that the execution of any business function is necessarily checked by the configured permission policy, thus avoiding the possibility of unauthorized access from a process perspective and improving the security of the scheduling framework.

[0036] In a second aspect, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

[0037] The memory stores instructions that the computer executes;

[0038] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0039] Thirdly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method of any one of the first aspects.

[0040] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects. Attached Figure Description

[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0042] Figure 1 A schematic diagram illustrating a menu-driven business execution process provided for an embodiment of this application;

[0043] Figure 2 A flowchart illustrating a configuration-based menu function scheduling method provided in this application embodiment;

[0044] Figure 3 This is a schematic diagram of a YAML configuration example provided in an embodiment of this application.

[0045] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0047] It should be noted that the configuration-based menu function scheduling method, device, storage medium, and program product provided in this application can be used in the field of computer software technology, or in any field other than computer software technology. This application does not limit the application field of the configuration-based menu function scheduling method, device, storage medium, and program product.

[0048] This application can be applied to specific scenarios, such as enterprise-level software systems, specifically to application scenarios where user interface menus and backend business functions are associated and invoked within such systems.

[0049] Enterprise-level software systems include, but are not limited to, large and complex software platforms such as database management systems, enterprise resource planning systems, and customer relationship management systems. These systems typically feature a structured, multi-level user interface menu, such as a first-level module menu and a second-level function menu, used to organize and display the system's various functions. Each menu item corresponds to a specific business logic operation that requires backend processing, such as performing data queries, generating analytical reports, importing data, or implementing access control.

[0050] In a typical application example, let's take a database management system. The system front-end presents users with a menu interface containing items such as "Data Import," "Permission Management," and "Performance Monitoring." When a user selects and triggers a menu item through the front-end interface, the system back-end needs to be able to accurately identify the intent of that menu item and call and execute the corresponding business function module to complete the user's requested operation.

[0051] For the above application scenarios, typical technical solutions for associating menu items with backend business functions can generally include the following:

[0052] One possible implementation is a hard-coded mapping approach. This approach maps the unique identifier of a menu item (e.g., ID or code) to its corresponding business logic directly into the core scheduling or routing code of the backend application, using conditional control statements (e.g., if-else, switch-case) in a programming language.

[0053] When the system receives a user request from the front end and parses out the specific menu identifier, it iterates through or jumps to a preset conditional branch, executes the business code block bound to that branch, and thus completes the corresponding function call. This method tightly couples the menu configuration information with the program's control flow logic.

[0054] Another possible implementation is a network interface-based invocation method. This method follows a client-server architecture, defining and exposing a proprietary web application programming interface (typically an HTTP API) on the backend for each individual menu function. Each menu item in the frontend user interface is statically configured as a Uniform Resource Locator (URL) pointing to the corresponding backend interface. When a user interacts with a menu item, the frontend application directly initiates a network call to this predefined interface address. The backend receives the request, routes it to the corresponding controller method, executes the business logic, and returns the result. This approach establishes a direct and fixed link from user interface elements to the network endpoint.

[0055] Another possible implementation is based on the strategy pattern. This approach introduces an object-oriented design pattern to improve architectural clarity. First, a unified strategy interface is defined, declaring common methods for executing menu functions. Second, independent strategy classes implementing this interface are created for each specific menu function, encapsulating their respective business logic. Finally, a mapping from menu identifiers to corresponding strategy class information is maintained through a centralized factory class or registry. At runtime, the system retrieves the corresponding strategy class instance from the factory based on the menu identifier in the request and executes the function through the methods agreed upon in the interface. This scheme separates function implementation from the calling logic, but functional expansion depends on explicit registration of the central factory mapping.

[0056] Another possible implementation is a dynamic invocation method based on external configuration and reflection. This method aims to decouple the association between menus and functions from the program code. Specifically, the system uses a separate configuration file (such as XML, YAML, or property files) to define the mapping relationship between menu identifiers and specific backend business implementation classes in the form of key-value pairs or structured data. This mapping relationship is specifically associated with the fully qualified class name of the business implementation class and the name of the method to be called.

[0057] During application startup and initialization, the system loads and parses the configuration file, preloading the mapping relationships into the memory data structure. When processing menu requests, the system retrieves the corresponding class and method information from the configuration mapping based on the menu identifier. Then, using the reflection mechanism of the programming language, it dynamically instantiates the target class object and calls the specified method. This implementation externalizes the definition of the association relationship, but the invocation of functionality depends on runtime dynamic lookup and reflection operations.

[0058] However, the solution described above has the following technical problems:

[0059] When using hard-coded mapping, there is a close dependency between the menu management system and the backend business function modules, making it difficult for the two to evolve independently. Any adjustment to the menu structure or function requires direct modification of the core business logic code. This implementation method restricts the scalability of the system and increases the complexity of maintenance.

[0060] While network interface-based calling methods achieve separation of the calling layer, they result in a significant increase in the number of application programming interfaces. Menu items are statically bound to interface addresses, requiring synchronous coordination and modification of interface definitions and all related client-side calling code when business logic parameters or behaviors change, introducing additional management burdens in a distributed collaborative development environment.

[0061] The strategy pattern-based implementation improves code structure by introducing an abstraction layer, but each menu function requires the creation of a separate strategy class, even for simple functions, leading to redundancy in implementation classes. At the same time, the expansion of new functions must manually add mapping entries to the central factory or registry, which cannot adapt to business scenarios that require rapid iteration.

[0062] Dynamic method invocation based on external configuration and reflection externalizes the mapping relationship, but at runtime, it is necessary to frequently instantiate objects and call methods dynamically through the reflection mechanism, which will bring additional performance overhead. In addition, configuration files usually adopt a fixed single structure, which makes it difficult to effectively describe and support complex menu structures with hierarchical relationships or multi-dimensional attributes, and also makes it difficult to conveniently achieve internationalization and multi-language adaptation of menu items and on-demand loading optimization.

[0063] The configuration-based menu function scheduling method provided in this application aims to solve the aforementioned technical problems of existing technologies. By employing a hierarchical configuration file to fully define the organizational structure, display attributes, and mapping relationships between the menu system and backend business functions, menu management is decoupled from the implementation of business logic.

[0064] Specifically, by defining chainable business keys in the configuration, a multi-level mapping path is established from front-end menu items to the specific business logic implementation in the back-end. At the same time, the concept of module keys is introduced to logically classify and aggregate business functions, and manage related functions under the same module to reduce the redundancy of functional entities.

[0065] During system runtime, a metadata model for menus and business functions is constructed by parsing configuration files. Based on user actions and context, and utilizing a pre-defined module key caching mechanism, the system enables on-demand loading of menu nodes and business modules, avoiding the overhead of redundant instantiation of business implementation classes. Finally, using the complete business key parsed at runtime, the system locates and invokes the corresponding business method via reflection, completing the dynamic routing from menu operation to function execution.

[0066] This method replaces hard-coded mapping relationships and fixed strategy registration patterns with externalized and structured configuration, enabling flexible expansion of the menu system, convenient reorganization of business functions, and improving the utilization efficiency of system resources and overall response performance.

[0067] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0068] First, combine Figure 1 This paper provides an overview of the overall process of the menu-driven business execution framework provided in the embodiments of this application. Figure 1 This is a schematic diagram of a menu-driven business execution process provided in an embodiment of this application. Figure 1 This demonstrates the complete interaction process from system startup to a user completing a menu operation, showcasing how this solution builds a scalable and efficient enterprise-level menu system through configuration and dynamic scheduling.

[0069] like Figure 1 As shown, the framework begins operation upon application startup. After startup, the system performs two initialization tasks in parallel: one is to read the structured configuration file (e.g., YAML), load all menu metadata into memory, and construct a list of menu entity objects for fast querying; the other is to establish a mapping relationship from business module identifiers to corresponding business processing objects based on the configuration information, providing a foundation for subsequent dynamic scheduling.

[0070] After initialization, the system enters a ready state. When a user accesses the system, the frontend requests the top-level menu. The backend, based on a pre-defined list of menu entities, filters and returns all menu items whose parent identifier is a specific value. The frontend determines the interaction mode of the menu item based on the `isLeaf` attribute in the returned result. The user then clicks a menu item, and the system determines the branch based on whether the menu item is a leaf node.

[0071] If the menu that the user clicks has a submenu, the process of expanding the submenu is triggered: the front end uses the current menu identifier as the parent identifier to request the child item, the back end filters from the menu entity list again and returns the corresponding submenu list, and the front end updates the interface accordingly.

[0072] If the user clicks on a leaf menu item, the core business execution scheduling process begins: the front-end sends a request to execute the menu operation; the back-end locates the target menu item from the menu entity list based on the menu identifier in the request; it parses the business scheduling identifier of the menu item to extract the target business module identifier and the target business function identifier; using the mapping relationship established during the initialization phase, it quickly finds the corresponding business processing object based on the target business module identifier; finally, it calls the business method in the business processing object that matches the target business function identifier through reflection to complete the business operation requested by the user and returns the result.

[0073] pass Figure 1The complete process shown demonstrates that this application constructs a configuration-driven, modular business execution framework. The core lies in externalizing the volatile menu structure and function binding relationships to the configuration, and optimizing performance through preloading and caching mechanisms. This enables the system to maintain high scalability and maintainability while responding to complex user interaction needs and efficiently executing business logic.

[0074] The following will combine Figure 2 and Figure 3 ,right Figure 1 This paper details the core methods for achieving dynamic business scheduling in China. Figure 2 This is a flowchart illustrating a configuration-based menu function scheduling method provided in an embodiment of this application. Figure 3 This is a schematic diagram illustrating the structure of a YAML configuration example provided in an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0075] S201, Read the structured configuration file.

[0076] During system startup or initialization, the system reads and parses a predefined structured configuration file. In this embodiment, YAML format is preferred, for example. Figure 3 As shown, the hierarchical nature of this configuration file, expressed through indentation, closely matches the tree structure of the menu, improving readability and maintainability. This configuration file fully defines the software's menu system and its association with backend business functions in a machine-readable format.

[0077] like Figure 3 For example, each menu item, as a configuration entry, contains key fields such as `id` and `parentId` to build hierarchical relationships, as well as a globally unique `businessKey` field as a business scheduling identifier. For instance, a leaf menu item's `businessKey` might be configured in the format "data:import". After parsing this configuration file, the system loads its contents into memory, typically transforming it into a list of menu entity objects (e.g., `MenuEntity`) for management, providing the data foundation for subsequent steps.

[0078] S202. Based on the business module classification indicated by the business scheduling identifier, establish a mapping relationship between business module identifiers and business processing objects.

[0079] This step is performed during the system preparation phase and aims to build an efficient module-level index. The system first iterates through all configured businessKeys, parses them according to predetermined rules (such as using colons ":" as delimiters), and extracts the business module identifier indicated by the businessKey, for example, extracting "data" from "data:import".

[0080] Meanwhile, the system obtains all business processing classes that implement predefined unified interfaces (such as Handler) by scanning class paths and other methods. These classes can return corresponding module identifiers, and the system creates business processing objects by instantiating these processing classes.

[0081] Subsequently, the system associates the extracted business module identifiers with the created business processing object instances and stores these associations in a global memory mapping structure (e.g., Map).<String,Handler> This mapping resides as a cache during system runtime, enabling subsequent access to the initialized processing object via the module identifier. This avoids the overhead of repeated instantiation with each request, thereby optimizing performance.

[0082] S203. In response to an operation request for a target menu item, determine the context information related to processing the operation request.

[0083] When a user triggers an action on a specific menu item (i.e., the target menu item) on the front-end interface, the system receives the request. Before executing the business logic, the system first needs to collect and determine the context information related to processing this request. This context information constitutes the background and environment for business execution, and may include, for example, the current user's identity and access permissions, the client's language preferences, session state, or other runtime parameters. Determining the context information provides the necessary input and judgment basis for subsequent scheduling and security control.

[0084] S204. Based on context information, parse the business scheduling identifier corresponding to the target menu item from the structured configuration file to obtain the target business module identifier and the target business function identifier.

[0085] The system utilizes the established context information to begin processing the core business scheduling logic. First, based on the target menu item identifier specified in the request, it retrieves the businessKey corresponding to that target menu item identifier from the configuration data loaded in S201.

[0086] Next, the businessKey is parsed according to the same rules used to extract the module identifier in S202 (e.g., separated by colons ":"). The parsing yields two key pieces of information: one is the target business module identifier (the part before the colon, e.g., "data"), used to locate the processor in the mapping relationship established in S202; the other is the target business function identifier (the part after the colon, e.g., "import"), used to specify the specific business method to be invoked. This parsing process can be influenced by contextual information; for example, user permission information in the contextual information can be used to determine whether access to this function is permitted.

[0087] S205. Based on the target business module identifier, obtain the business processing object corresponding to the target business module identifier from the mapping relationship.

[0088] After successfully resolving the target business module identifier, the system uses this identifier as a key to query the mapping relationship established and cached in S202. Since the instantiated business processing object is directly stored in this mapping relationship, this step can directly obtain the immediately available target business processing object instance with low overhead (e.g., a single hash lookup), which improves the efficiency of business scheduling.

[0089] S206. Based on the business processing object, call the business method that matches the target business function identifier to execute the business function associated with the target menu item.

[0090] The system utilizes the business processing object instance obtained in S205, combined with the target business function identifier parsed in S204, to invoke the business method on the business processing object that matches the target business function identifier through reflection or similar dynamic invocation techniques. This method encapsulates specific business logic (e.g., performing data import), and executing this business logic completes the business function associated with the menu item. Finally, the system encapsulates and returns the execution result of the business method, thus completing a full and dynamic scheduling process from user interface operation to backend business logic execution.

[0091] The configuration-based menu function scheduling method provided in this embodiment effectively separates menu display logic from backend business logic by pre-managing menu hierarchy information and business scheduling identifiers in a structured configuration file. This allows adjustments and expansions to menu functions to be made only by modifying the configuration file, without affecting core business code, thereby reducing system maintenance costs and improving scalability. Simultaneously, the chained business scheduling identifier design combined with a module-level instance caching mechanism forms an efficient dynamic binding and invocation path, improving business scheduling flexibility while reducing runtime object creation overhead and optimizing system performance. Furthermore, by integrating context information processing into the scheduling process, a unified and scalable execution entry point is provided for the integration of functions such as permission verification and multi-language adaptation, enhancing system security and scenario adaptability.

[0092] Optionally, the preferred implementation method for establishing the mapping relationship between business module identifiers and business processing objects will be described below.

[0093] Specifically, the process of establishing mapping relationships can be accomplished through a mechanism based on convention and discovery.

[0094] First, the system scans and obtains multiple business processing classes based on a predefined interface. This predefined interface (e.g., named Handler) acts as a rule that all business processing classes in the system must follow. This interface typically defines a method to return the business module identifier corresponding to the implementing class (e.g., String getModuleKey()). During application startup or initialization, the system uses a framework (e.g., Spring's component scanning) or a custom classpath scanning tool to obtain all classes that implement the Handler interface, such as GeneralHandler and DataHandler, thus obtaining a collection of business processing classes.

[0095] Next, the system needs to determine the business module identifier corresponding to each obtained business processing class. For each class that implements the Handler interface, the system can obtain a specific string identifier, such as "general" or "data," by calling the getModuleKey() method. This identifier is the business module identifier associated with that business processing class.

[0096] Finally, the system performs the operation of associating the business module identifier with the corresponding instance of the business processing class. For each business processing class obtained in the previous step, the system instantiates the business processing class, creating a business processing object. Subsequently, the system uses the obtained business module identifier as the key and the created business processing object as the value, storing this association in a globally accessible in-memory data structure, such as a ConcurrentHashMap.<String,Handler> Example. This data structure constitutes the mapping relationship mentioned above.

[0097] Through the above steps, the system completes the binding from logical module identifiers to entity processing objects during the startup phase, providing a foundation for fast object lookup at runtime.

[0098] Through the steps described above—interface scanning, identifier acquisition, and instance association storage—this embodiment provides an easy-to-maintain method for constructing mapping relationships. This avoids hard-coding mapping entries in the code. When a new business module is added, the developer only needs to create a new predefined interface implementation class and correctly return the module identifier. The system can then automatically add it to the mapping relationship upon the next startup, thereby enhancing the system's scalability and ensuring that the mapping relationship is updated synchronously with the business code.

[0099] Optionally, the following section will describe the specific implementation of the key steps in parsing the service scheduling identifier.

[0100] Upon receiving an operation request for the target menu item, the system needs to parse the business scheduling identifier corresponding to the menu item from the structured configuration file and extract the core information required for scheduling.

[0101] Specifically, the service scheduling identifier used in this embodiment has a specific structure, including a service module identifier part and a service function identifier part connected by a predetermined separator. For example, a typical service scheduling identifier is presented in the format "moduleKey:functionName", where the colon ":" is the predetermined separator, "moduleKey" is the service module identifier part, and "functionName" is the service function identifier part.

[0102] Based on this structure, the parsing process specifically involves segmenting the business scheduling identifier according to a predetermined delimiter. After obtaining the original identifier string corresponding to the target menu item, the system performs a string segmentation operation using the predetermined delimiter (such as a colon) as the boundary. This operation divides the complete identifier into two substrings. The first substring obtained after segmentation is identified as the target business module identifier and will be used to find the corresponding business processing object in the established mapping relationship; the second substring obtained after segmentation is identified as the target business function identifier and will be used to determine the specific business method to be called on the found business processing object.

[0103] Through this structured design and segmentation parsing based on predefined delimiters, the business scheduling identifier becomes a compact and information-complete carrier of scheduling instructions. This not only decouples menu items from business logic but also precisely encodes the scheduling path into a parsable string, enabling the system to extract the necessary information for subsequent retrieval and invocation steps from the configuration in a unified manner. This improves the accuracy and flexibility of the entire scheduling process.

[0104] Optionally, this embodiment further specifies the format of the predefined separator and the service scheduling identifier, which will be explained below.

[0105] In a preferred embodiment of this application, the predetermined separator is explicitly a colon (i.e., the English half-width character ":"). This character is widely used in the fields of programming and data exchange as a separator between key-value pairs or hierarchies.

[0106] Accordingly, the format of the service scheduling identifier is specifically defined as follows: it consists of a service module identifier, a colon, and a service function identifier connected in sequence. In other words, a complete service scheduling identifier that conforms to this format is a string, and its structure can be uniformly expressed as "[service module identifier]:[service function identifier]".

[0107] For example, in Figure 3 In the configuration example, the businessKey configured for the "Data Import" menu item is "data:import". Here, "data" is the business module identifier, followed by a colon ":" which is a fixed separator, and "import" is the business function identifier. These three elements are strictly connected in the order of "identifier-separator-identifier" to form a complete and parsable scheduling instruction.

[0108] By adopting this specific chained format separated by colons, the business scheduling identifier maintains information integrity while ensuring readability and consistency. Developers can intuitively understand its structure during configuration, and the system can accurately and efficiently decompose the identifier into target parts during parsing (e.g., using the standard string split function), thereby improving the reliability of the scheduling process.

[0109] Optionally, the above details how to parse out the target business module identifier. After obtaining this identifier, the system needs to retrieve the corresponding business processing object from the mapping relationship based on the target business module identifier. The specific implementation process is as follows:

[0110] First, the system queries the mapping relationship based on the target business module identifier. At this point, the system uses the parsed target business module identifier (e.g., "data") as the key, and then uses the global mapping relationship (e.g., Map) established during the initialization phase.<String,Handler> Search within )

[0111] Subsequently, the system executes branching logic based on the query results:

[0112] If the query finds a match, meaning an entry with the target business module identifier as the key already exists in the mapping relationship, the system directly retrieves the corresponding instantiated business processing object from the mapping relationship. This path has low overhead, equivalent to only one hash table lookup, which is the ideal state for the system to handle high-frequency requests, demonstrating the performance advantages brought by pre-caching.

[0113] If the query fails to find a match, meaning the corresponding key does not exist in the mapping, the system will dynamically create a business processing object corresponding to the target business module identifier using reflection. For example, the system can instantiate the business processing class using reflection APIs (such as Class.forName().newInstance()) based on the convention between the identifier and the class name (e.g., the identifier "data" corresponds to the class DataHandler).

[0114] After the object is successfully created, the system adds the newly created business processing object to the mapping relationship, that is, it stores the new object in the mapping relationship with the identifier of the target business module as the key. This operation not only meets the processing needs of the current request, but also completes the runtime backfilling of the mapping relationship, so that subsequent requests for the same module can hit the cache.

[0115] By first querying the cache and then using reflection to create and populate the cache if a match is not found, the system ensures functional availability (avoiding system errors due to incomplete mapping relationships) while leveraging the performance-enhancing effect of caching. This allows the system to automatically adapt and learn when faced with new business modules or initial access after configuration updates, without requiring restarts or manual intervention, thus achieving a balance between high performance and scalability in the scheduling framework.

[0116] Optionally, the above embodiments fully construct a configuration-driven business scheduling process. Building upon this, this embodiment further introduces access control, a core enterprise-level security requirement, into the framework. By adding dimensions to the configuration and performing permission checks before scheduling, system security is enhanced. The specific implementation includes the following two levels of extension:

[0117] First, at the data configuration level, the structured configuration file, when defining menu items, includes an access control identifier in addition to the hierarchical relationship and business scheduling identifier. This identifier is used to define the permission conditions required to access this menu item. For example, it can be configured as follows: Figure 3 In the YAML configuration structure shown, an `authKey` field is added to each menu item. The value of this field can be a role name (e.g., "admin"), a permission code (e.g., "DATA_IMPORT"), or a more complex permission expression. This allows the visibility and accessibility rules of menu items to be configured and managed externally along with the menu structure.

[0118] Secondly, at the runtime logic level, the step of determining the context information related to processing the operation request in the above embodiments is specified. In this embodiment, this step includes: determining the access permission information of the user initiating the operation request. When the system responds to the user's operation, it obtains the set of permissions of the currently verified user from the user session, security context, or permission service, such as a list of roles or directly granted permission codes. This information is encapsulated and passed to subsequent processing flows as an important part of the context information.

[0119] Through the above extensions, the system now has a basis for permission determination before parsing business identifiers based on context information and executing business scheduling. This design decouples security logic from business code and centrally manages it through configuration. This not only improves system security but also makes adjusting permission policies as flexible and convenient as modifying a menu structure, without requiring code changes, further enhancing the framework's maintainability.

[0120] Optionally, this embodiment further specifies how to implement access control using permission information in the step of parsing the service scheduling identifier, thereby forming a complete security verification process.

[0121] Specifically, in this embodiment, the process of parsing the business scheduling identifier corresponding to the target menu item from the structured configuration file based on context information is enhanced into a composite operation that includes permission verification. This operation not only extracts the identifier but also acts as a security gateway for access requests. Its execution logic includes the following two steps:

[0122] The first step involves the system executing permission verification logic: matching and verifying access permission information against the access control identifier of the target menu item. Specifically, the system compares the user access permission information obtained from the previous steps with the access control identifier of the target menu item read from the structured configuration file to determine whether the user has permission to access the menu item. For example, the system can verify whether the user's role list (e.g., ["user", "editor"]) meets the conditions defined in the configuration (e.g., authKey: "admin"). This verification rule supports flexible definition; it can be an exact match (e.g., requiring the user to have the specific role "admin") or an inclusion relationship (e.g., requiring the user's role list to contain "editor").

[0123] The second step involves the system determining the process flow based on the verification results: the parsing step is only executed if the matching verification passes. That is, the system will only continue with the subsequent business scheduling identifier parsing operation if the user's permissions meet the access control requirements configured in the menu item, thereby obtaining the target business module identifier and business function identifier.

[0124] If the matching verification fails, the system will interrupt all subsequent business scheduling processes and usually return an insufficient privilege error response to the client without executing any substantive business logic.

[0125] By making permission verification a prerequisite for parsing the business scheduling identifier, this embodiment integrates and correlates permission control with business scheduling. This design ensures that the execution of any business function is necessarily checked by the configured permission policy, thus avoiding the possibility of unauthorized access and improving the security of the scheduling framework.

[0126] The electronic device provided in this application embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0127] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the methods in any of the above method embodiments.

[0128] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the above method embodiments.

[0129] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

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

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

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

[0133] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0134] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0135] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0136] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0137] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0138] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0139] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0140] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A configuration-based menu function scheduling method, characterized in that, The method includes: Read the structured configuration file, which contains the hierarchical relationship information of menu items and the business scheduling identifier corresponding to each menu item; Based on the business module classification indicated by the business scheduling identifier, establish a mapping relationship between business module identifiers and business processing objects; In response to an operation request for a target menu item, determine context information related to processing the operation request; Based on the context information, the business scheduling identifier corresponding to the target menu item is parsed from the structured configuration file to obtain the target business module identifier and the target business function identifier; Based on the target business module identifier, obtain the business processing object corresponding to the target business module identifier from the mapping relationship; Based on the business processing object, the business method that matches the target business function identifier is invoked to execute the business function associated with the target menu item.

2. The method according to claim 1, characterized in that, The step of establishing a mapping relationship between business module identifiers and business processing objects based on the business module classification indicated by the business scheduling identifier includes: Based on predefined interfaces, multiple business processing classes are obtained through scanning. Determine the business module identifier corresponding to each of the aforementioned business processing classes; The business module identifier is associated with and stored with the corresponding instance of the business processing class to establish the mapping relationship.

3. The method according to claim 1, characterized in that, The service scheduling identifier includes a service module identifier and a service function identifier connected by a predetermined separator. The step of parsing the business scheduling identifier corresponding to the target menu item from the structured configuration file includes: segmenting the business scheduling identifier according to the predetermined separator to obtain the target business module identifier and the target business function identifier.

4. The method according to claim 3, characterized in that, The predetermined separator is a colon, and the service scheduling identifier is formed by sequentially connecting the service module identifier, the colon, and the service function identifier.

5. The method according to claim 1, characterized in that, The step of obtaining the business processing object corresponding to the target business module identifier from the mapping relationship based on the target business module identifier includes: The mapping relationship is queried based on the target business module identifier; If the query finds a match, the corresponding business processing object is obtained from the mapping relationship; If the query fails to find a match, a business processing object corresponding to the target business module identifier is created using reflection, and the created business processing object is added to the mapping relationship.

6. The method according to any one of claims 1-5, characterized in that, The structured configuration file also includes access control identifiers for the menu items; The determination of context information related to processing the operation request includes: determining the access permission information of the user who initiated the operation request.

7. The method according to claim 6, characterized in that, The step of parsing the service scheduling identifier corresponding to the target menu item from the structured configuration file based on the context information includes: The access permission information is matched and verified against the access control identifier of the target menu item. The parsing step is only executed if the matching verification passes.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images