A platform generation method and system based on micro-front and business middle platform

Abstract

The application discloses a platform generation method and system based on micro front end and business middle platform, and belongs to the field of intelligent business systems. The business middle platform generates menu configuration according to the tenant information and identity information of the user, in combination with menu-subapplication mapping relationship, permission information and subapplication registration information; the base application automatically generates platform main menu, route configuration and permission control relationship accordingly, and dynamically loads a target subapplication according to user operation, and transmits tenant information, identity information and permission information through a preset secure transmission mechanism; the subapplication renders a business page after internal authentication. The application can realize platform dynamic assembly and unified permission management in a multi-tenant environment, and realize low-code integration based on configuration when the subapplication meets a preset access specification. The application significantly reduces deployment and operation and maintenance costs, realizes unified permission and menu management, improves system security and user experience, and greatly improves platform expansion capability.

Description

Technical Field

[0001] This invention belongs to the field of intelligent business systems. Specifically, this invention relates to a platform generation method and system based on micro-frontends and business middleware. Background Technology

[0002] As enterprises deepen their IT infrastructure development, they typically build multiple independent business systems, such as Lead to Cash (LTC) systems, Issue to Resolution (ITR) systems, and user centers. These systems are often developed independently by different teams at different times, with varying technology stacks and isolated deployment environments. For enterprises with multiple business units, each business unit needs to deploy and maintain a separate system, leading to wasted hardware resources, high maintenance costs, and increasingly serious data silos. Furthermore, users need to repeatedly log in and switch between multiple systems, resulting in cumbersome operations and a poor user experience.

[0003] In recent years, micro-frontend architecture has gradually emerged as a technical solution to address the aggregation problem of frontend applications. It breaks down large frontend applications into multiple independently developable and deployable sub-applications, which are then combined into a whole through a base application. Currently, common micro-frontend implementations include frameworks based on Web Components and frameworks based on application loading. Summary of the Invention

[0004] This invention aims to overcome the shortcomings of existing technologies and proposes a platform generation method and system based on micro-frontends and business middleware to achieve the following objectives: to achieve a single codebase for multi-tenant reuse, significantly reducing deployment and maintenance costs; to achieve unified permission and menu management, improving system security and user experience; and to achieve low-code integration based on configuration when sub-applications conform to preset access specifications, enhancing platform scalability.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] This invention provides a platform generation method based on micro-frontends and a business middleware platform. Platform generation, as referred to in this application, means that the base application automatically generates the platform's main menu, routing configuration, and permission control relationships based on the menu configuration, permission information, and sub-application registration information returned by the business middleware platform, and dynamically loads the corresponding sub-applications. The method includes:

[0007] Step S1: Initialize the base application and obtain the tenant information and identity information of the currently logged-in user;

[0008] Step S2: The business middle platform queries the user roles and permission information under the current tenant based on the tenant information and identity information, and generates the corresponding menu configuration based on the pre-configured menu-sub-application mapping relationship and sub-application registration information.

[0009] Step S3: The base application automatically generates the platform main menu, routing configuration, and permission control relationship between menu items and page elements based on the menu configuration and permission information.

[0010] Step S4: The base application listens for user operation events on menu items to obtain the routing information and identifier of the target sub-application corresponding to the menu item;

[0011] Step S5: The base application obtains the entry URL of the target sub-application through the micro-frontend loader based on the identifier of the target sub-application and dynamically loads the target sub-application. The sub-application mounting is completed without modifying the base application loading logic for each sub-application. Tenant information, identity information and permission information are transmitted to the target sub-application through a preset secure transmission mechanism.

[0012] Step S6: The sub-application receives and parses the information transmitted by the base application, and renders the business page after internal authentication.

[0013] Furthermore, in step S1, the base application initialization operation includes loading common styles, initializing global state management, and setting request interceptors.

[0014] Furthermore, the business middle platform includes a permission center, a configuration center, and a tenant center, wherein:

[0015] The permission center is used to store the mapping relationship between users, roles, and permissions;

[0016] The configuration center is used to store the menu-sub-application mapping relationship and sub-application registration information under multi-tenancy.

[0017] The tenant center is used for storing and isolating tenant information.

[0018] Furthermore, in the configuration center, the menus are organized in a tree structure, including multiple menu items, each associated with a sub-application identifier and a routing path.

[0019] Furthermore, step S2 includes:

[0020] The business middle platform obtains tenant information and identity information sent by the base application;

[0021] The business middle platform verifies the validity of identity information and parses out the user ID;

[0022] The business middle platform queries the permission center based on the user ID and tenant information to obtain all roles and permission information of the user under the current tenant;

[0023] The business middle platform queries the configuration center based on tenant information and user roles to obtain the menu configuration corresponding to the user role under that tenant;

[0024] The business middle platform combines the menu configuration and permission information and returns it to the base application.

[0025] Furthermore, in step S3, after the base application receives the menu configuration returned by the business middle platform, it dynamically generates the platform's main navigation menu using the front-end routing library and UI component library; during rendering, the base application combines permission information to hide or disable menu items that the user does not have permission for.

[0026] Furthermore, the base application, in conjunction with permission information, hides or disables menu items that the user does not have permission to access, including:

[0027] For each menu item, check if its associated permission code exists in the user's permission point list;

[0028] If it exists, the menu item will be rendered normally; if it does not exist, it will be hidden or disabled according to the configuration policy.

[0029] Furthermore, for submenus, a recursive decision is made: the parent menu is only displayed if at least one submenu item has permission.

[0030] Furthermore, step S4 includes:

[0031] When a user clicks a menu item, the base application's menu click event handler is triggered, and this handler performs the following operations:

[0032] Get the sub-application identifier and route associated with the clicked menu item;

[0033] Check if the sub-application has been loaded; if not, proceed to step S5 to execute the loading process; if it has been loaded, switch directly to the corresponding route page.

[0034] Furthermore, step S5 includes:

[0035] Based on the sub-application identifier, the loader requests the entry URL of the sub-application from the business middle platform;

[0036] The loader creates a custom element for mounting the target sub-application, setting its name attribute to the sub-application identifier and its url attribute to the entry URL;

[0037] The base application can pass the current tenant information, identity information, and permission information to the sub-application through the data attribute of this tag or a custom event.

[0038] Furthermore, the loader employs a pre-connection strategy: when the user hovers the mouse over a menu item, it resolves the DNS of the sub-application entry domain name in advance and establishes a TCP connection.

[0039] Furthermore, the data transmission between the base application and the sub-application adopts a preset secure transmission mechanism, and the sub-application verifies the integrity of the received data.

[0040] Furthermore, the secure transmission mechanism includes encrypting the transmitted data using the AES symmetric encryption algorithm and verifying the data integrity using MAC or digital signature.

[0041] Furthermore, step S6 includes:

[0042] After receiving the information from the base application, the sub-application parses out the tenant information and identity information, and verifies the integrity of the data.

[0043] After verification, the identity information is stored in its own request interceptor for subsequent API calls with its own backend; thereafter, all API requests issued by the sub-applications will automatically carry this identity information.

[0044] Furthermore, in step S6, the authentication operation includes: the sub-application maintains a route-permission code mapping table. When a user attempts to access any route, the sub-application retrieves the corresponding permission code by looking up the table, and then checks whether the permission point list passed by the base application contains the corresponding permission code; if it does, access is allowed; otherwise, access is denied.

[0045] This invention also provides a platform generation system based on micro-frontends and business middleware. Using the aforementioned platform generation method based on micro-frontends and business middleware, the system includes a user layer, an application layer, a sub-application layer, and a business middleware layer, wherein:

[0046] The user layer is used to receive user operations and provide the application layer with the current user's tenant information and identity information;

[0047] The application layer is used to deploy the base application and perform the following tasks: communicate with the business middle platform, obtain menu configuration, permission information and sub-application registration information corresponding to the current tenant and user role, automatically generate the platform main menu, routing configuration and permission control relationship, listen to the user's operation events on menu items to obtain the routing information and identifier of the target sub-application, and dynamically load the target sub-application and transmit tenant information, identity information and permission information through the micro frontend loader.

[0048] The sub-application layer is used to deploy sub-applications, and the sub-applications are used to receive and parse the information transmitted by the application layer, and render the corresponding business pages after internal authentication.

[0049] The business middle platform layer is used to deploy the business middle platform. The business middle platform is used to store tenant information, user role and permission mapping relationship, menu-sub-application mapping relationship and sub-application registration information, and generate corresponding menu configuration and permission information based on the current user's tenant information and identity information.

[0050] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described platform generation method based on a micro-frontend and a business middle platform.

[0051] The present invention also provides a computer-readable storage medium storing a computer program, characterized in that the computer program is executed by a processor to perform the above-described platform generation method based on a micro-frontend and a business middle platform.

[0052] The technical effects of this invention are as follows:

[0053] 1. Implement a single codebase for multi-tenant reuse, significantly reducing deployment and maintenance costs:

[0054] This invention introduces a business middle platform and a multi-tenant architecture, separating the environment configurations (such as menus, permissions, and data sources) of different business units and customers from the application code and storing them uniformly in the business middle platform. The base application and all sub-applications only need to deploy a single set of code, which can dynamically switch configurations based on tenant information to serve all tenants. This solution effectively avoids the resource waste and high costs associated with deploying and maintaining an entire system separately for each tenant in the traditional model, achieving efficient reuse of core business logic.

[0055] 2. Implement unified permission and menu management to improve system security and user experience:

[0056] This invention moves the permission and menu management functions, which were previously scattered across various sub-applications, to the business middle platform and base applications. The middle platform centrally obtains users' global permission information, and the base applications dynamically generate and render menus, achieving a unified platform-level view. By moving permission control points forward to the base level, it is possible to pre-block unauthorized access to functions, preventing invalid requests and unauthorized access, thereby significantly improving user experience while enhancing system security.

[0057] 3. Enable low-code integration based on configuration, provided the sub-applications conform to preset access specifications, thereby improving platform scalability:

[0058] This invention leverages the configuration capabilities of a business middle platform to abstract integration operations such as new sub-application registration, menu mounting, and permission configuration into configurable items. When integrating a new system, developers or operations personnel only need to perform visual configuration in the business middle platform (e.g., filling in the sub-application name, entry URL, assigning menu permissions, etc.), without modifying the code of the base application or the new system. The base application can automatically recognize and load the sub-application, achieving "plug-and-play" expansion capabilities, greatly reducing the integration threshold, and significantly improving the platform's flexibility and scalability. Attached Figure Description

[0059] Figure 1 A flowchart of a platform generation method based on micro-frontend and business middle platform provided for embodiments of the present invention;

[0060] Figure 2 A platform generation system architecture diagram based on micro-frontend and business middleware is provided for embodiments of the present invention;

[0061] Figure 3 This is a timing diagram of the interaction between the base application and sub-applications provided in an embodiment of the present invention. Detailed Implementation

[0062] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. This is to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the inventive concept and technical solutions of the present invention, and to facilitate its implementation. It should be noted that the terms "first," "second," etc., used in this application are only for the convenience of describing the technical solutions and to distinguish components; the corresponding component configurations may be the same or different, and are not intended to limit the scope of this application. To make the technical solutions of the present invention clearer, the present invention will be explained and illustrated through the following embodiments.

[0063] Existing technologies have the following main shortcomings when solving multi-system aggregation problems:

[0064] (1) Low system integration and poor reusability:

[0065] While existing micro-frontend solutions can aggregate multiple sub-applications under the same platform, each sub-application remains an independent code repository and deployment unit, and their core business logic and data models are not integrated. When a complete environment needs to be deployed for a new customer or business unit, each sub-application still needs to be configured, deployed, and maintained separately, failing to achieve true "one codebase, multi-tenant operation".

[0066] (2) Dispersed permissions and menu management, lacking unified control:

[0067] In traditional multi-system integration solutions, each sub-application has its own independent permission model and menu system. After a user logs in, the base application struggles to obtain and integrate the permission information of all sub-applications, resulting in menus that cannot be dynamically generated or requiring repeated authentication operations in each sub-application. This not only increases system complexity but also introduces security vulnerabilities.

[0068] (3) The new system has a high integration threshold and poor scalability:

[0069] When integrating new business systems into an existing platform, developers must thoroughly understand the integration specifications of the base application and perform extensive code modifications and configurations, sometimes even requiring modifications to the original code of the new system for integration. This tightly coupled integration approach is inefficient, cannot achieve "plug-and-play" rapid expansion, and severely restricts the platform's scalability and business response speed.

[0070] The root cause of the aforementioned shortcomings lies in the fact that existing micro-frontend solutions only address the aggregation problem of the front-end interface layer, lacking a unified abstraction and management of the business capability layer. Specifically:

[0071] (1) Lack of a unified application metadata model: Existing solutions treat each sub-application as an independent technical unit, rather than abstracting it into a configurable business capability unit. The lack of a standardized description language for routing, permissions, data models, etc. between sub-applications makes it impossible for the system to automatically identify and assemble the capabilities of each business module.

[0072] (2) Strong coupling between integration mechanism and business logic: The registration, loading, authentication and other logic of sub-applications are usually hard-coded in the base application or depend on complex configuration files. This strong coupling means that every time a new sub-application is added, the base application needs to be modified at the code level, and dynamic expansion cannot be achieved.

[0073] (3) Independent permission systems: Because each subsystem is developed independently, its permission models (such as RBAC, ABAC) and user session management mechanisms are different, lacking a unified permission mapping and synchronization mechanism. The base application cannot uniformly manage the menus and permissions of all subsystems without intruding on the sub-applications.

[0074] To overcome the above-mentioned shortcomings, the following technical challenges need to be addressed simultaneously:

[0075] (1) The challenge of standardized access for heterogeneous systems: The technology stacks, interface protocols and data formats of different subsystems vary greatly. How to achieve unified access and dynamic combination without requiring large-scale transformation of each system is a problem that has not yet been solved by existing technologies.

[0076] (2) Difficulty in heterogeneous integration of permission models: The permission models of each subsystem may be completely different, and data such as user roles and organizational structure are stored in a scattered manner. It is extremely difficult to build a unified permission control layer that can be compatible with multiple permission models while ensuring security and real-time performance.

[0077] (3) The problem of balancing dynamic expansion and performance: Achieving "plug and play" expansion capabilities often requires the introduction of runtime resolution, dynamic loading and other mechanisms, which will increase the complexity of the system and runtime overhead. How to ensure scalability without significantly affecting the first screen loading speed and runtime performance is a very challenging engineering problem.

[0078] (4) The contradiction between multi-tenant isolation and sharing: Under the goal of running a single codebase with multiple tenants, it is necessary to ensure data isolation between different tenants (business units) and to achieve the sharing of common capabilities. The existing micro-frontend architecture lacks the ability to configure and manage resources at the tenant level.

[0079] Due to the aforementioned fundamental reasons and difficulties, existing technical solutions have consistently failed to achieve ideal results in multi-system aggregation and rapid construction of multiple business units. Therefore, this invention provides a platform generation method based on micro-frontends and business middleware, aiming to solve the following technical problems: resource waste and high operation and maintenance costs caused by repeated deployment and maintenance of multiple business systems; fragmented permissions and menus in each subsystem, making it impossible to achieve unified and dynamic permission control and menu generation at the platform level; and the complexity and poor scalability of new system integration processes, making rapid access and dynamic expansion difficult.

[0080] Compared with the prior art, the innovation of the platform generation method based on micro-frontend and business middle platform provided by the embodiments of the present invention is as follows: deep integration of business middle platform and micro-frontend architecture, dynamic switching mechanism of multi-tenant configuration, unified permission and menu management scheme, zero-code integration method of sub-applications, and secure communication and secondary authentication closed loop between the base and sub-applications.

[0081] like Figure 1 As shown in the figure, this invention provides a platform generation method based on micro-frontends and business middleware. The business middleware acts as a separation layer between configuration and business logic, the base application acts as a unified loader and scheduler, and the sub-applications act as pure business execution units. These three components work together to achieve a single codebase, multi-tenant operation, and plug-and-play system integration capabilities. The method includes:

[0082] Step S1: Initialize the base application and obtain the tenant information and identity information of the currently logged-in user;

[0083] Step S2: The business middle platform queries the user roles and permission information under the current tenant based on the tenant information and identity information, and generates the corresponding menu configuration based on the pre-configured menu-sub-application mapping relationship and sub-application registration information.

[0084] Step S3: The base application automatically generates the platform main menu, routing configuration, and permission control relationship between menu items and page elements based on the menu configuration and permission information.

[0085] Step S4: The base application listens for user operation events on menu items to obtain the routing information and identifier of the target sub-application corresponding to the menu item;

[0086] Step S5: The base application obtains the entry URL of the target sub-application through the micro-frontend loader based on the identifier of the target sub-application and dynamically loads the target sub-application. The sub-application mounting is completed without modifying the base application loading logic for each sub-application. Tenant information, identity information and permission information are transmitted to the target sub-application through a preset secure transmission mechanism.

[0087] Step S6: The sub-application receives and parses the information transmitted by the base application, and renders the business page after internal authentication.

[0088] The business platform is pre-configured with menu-sub-application mapping relationships, user role permissions, and sub-application registration information (including sub-application entry addresses, dependent resources, etc.) in a multi-tenant environment. For example, for a lead-to-sales system, its core functions such as "lead management," "opportunity management," and "contract management" can be configured as independent menu items, each associated with a different route in the lead-to-sales system sub-application; for an after-sales problem-solving system, "work order creation" and "work order query" can be configured as menu items, associated with the after-sales problem-solving system sub-application.

[0089] Existing micro-frontend solutions (such as qiankun and single-spa) only solve the problem of loading and unloading sub-applications, but do not address the issues of dynamic configuration, unified permissions, and reuse of business capabilities in a multi-tenant environment. This invention introduces a business middleware layer between the base application and sub-applications, centrally storing and managing metadata such as environment configurations, permission models, and menu structures that were originally scattered across various sub-applications, fundamentally changing the system integration approach.

[0090] The following detailed description of the implementation methods and innovations of this invention, in conjunction with specific steps, provides a comprehensive overview.

[0091] Referring to step S1, initialize the base application and obtain the tenant information and identity information of the currently logged-in user. In this embodiment, step S1 introduces a multi-tenant identity recognition mechanism during the base application startup phase, using tenant information (tenantId) as the core identifier for all subsequent configuration acquisition and permission judgment, which differs from the traditional approach of focusing only on user identity while ignoring tenant context.

[0092] The reason for introducing a multi-tenant identity recognition mechanism during the base application startup phase is that, in a multi-tenant architecture, the tenant is the most basic unit for data and configuration isolation. In traditional enterprise application development, single-tenant architectures often use user identity as a unique identifier, with all configurations and permissions revolving around the user. However, in the information systems of large enterprise groups, the same user may have completely different roles, permissions, and business configurations under different tenants. For example, a manager at the group headquarters may have full access to view data in business unit A, but may only have read-only access to view data in business unit B. If the system only determines permissions based on user identity without considering tenant context, it is impossible to implement differentiated configurations between different tenants on the same codebase. Ultimately, a separate system must be deployed for each tenant, resulting in huge resource waste and operational costs. Therefore, embedding the tenant identifier (tenantId) as a core identifier into the base application initialization process is the fundamental prerequisite for achieving multi-tenant data isolation and dynamic configuration switching.

[0093] Specifically, when a user accesses the unified entry URL of the base application in a browser, the base application begins to load. After loading, initialization operations are performed first, including but not limited to: loading common styles, initializing global state management (such as Redux and Vuex), and setting request interceptors.

[0094] Crucially, the base application retrieves the tenant ID and user identity information (token) of the currently logged-in user from local storage or the login callback. For example, after a user successfully logs in, the backend service returns a JWT (JSON Web Token) containing the tenant ID and token, which the base application stores in a cookie or LocalStorage. Here, the tenant ID can represent an independent business unit, a customer company, or a business function; it is the foundation for achieving multi-tenant data isolation and configuration switching.

[0095] Step S1 automatically obtains tenant and identity information upon startup, laying the foundation for subsequent personalized configuration and access control. Compared to traditional solutions where each sub-application maintains its own user session, step S1 in this embodiment achieves single sign-on and global session sharing, avoiding repeated logins for users across multiple subsystems and significantly improving the user experience.

[0096] Referring to step S2, the base application, through the unified interface provided by the business middle platform, obtains the complete menu configuration and permission information of the currently logged-in user under the current tenant information, based on the tenant information and identity information. Step S2 in this embodiment designs a three-layer business middle platform architecture, including a permission center, a configuration center, and a tenant center. This architecture centrally manages all menu structures, permission mappings, and sub-application registration information that were originally scattered across various sub-applications. The base application dynamically obtains configurations from the business middle platform through the unified interface, achieving complete separation of configuration and code.

[0097] The reason for designing a three-tier business middleware architecture and completely separating configuration from code is that in traditional application development models, menu structures, permission rules, and sub-application registration information are often hard-coded in the front-end code or scattered across the back-end services of various sub-applications. Whenever business requirements change, such as adding a menu item, adjusting the permission scope of a role, or changing the deployment address of a sub-application, code modification, recompilation, and redeployment are required, a process that can take hours or even days. In a multi-tenant environment, different tenants may require different menu structures and permission configurations. If this information is hard-coded into the code, it is impossible to achieve personalized configuration for each tenant; instead, a separate code branch must be maintained for each tenant, and the maintenance cost will increase exponentially with the number of tenants.

[0098] like Figure 2 As shown, the platform system architecture in this embodiment, based on the traditional platform architecture, further introduces a business middle platform layer, including a user layer, an application layer, a sub-application layer, and a business middle platform layer. The business middle platform layer further includes a permission center, a configuration center, and a tenant center.

[0099] in:

[0100] The permissions center stores the mapping relationship between users, roles, and permissions, supports the RBAC (Role-Based Access Control) model, and extends to the multi-tenant dimension. For example, user "Zhang San" has the role of "Sales Manager" under tenant "Business Unit A", which has permissions such as "viewing LTC leads" and "creating ITR tickets".

[0101] The configuration center stores the menu-sub-application mapping relationships and sub-application registration information under multi-tenancy. Menus are organized in a tree structure, including multiple menu items, each associated with a sub-application identifier (appId) and a route path (route). For example, the sub-application identifier associated with the "Opportunity Management" menu item is "ltc-app," and the route is " / opportunity." The configuration center also stores metadata such as the sub-application's entry URL, dependent resources, and loading strategies.

[0102] The tenant center is used for storing and isolating tenant information, including basic tenant information, data source configuration, theme styles, etc.

[0103] The base application communicates with the business middle platform through a unified interface to obtain the menu and permission configurations of users under the current tenant. Specifically, the base application uses the tenant information (tenantId) and identity information (token) obtained in step S1 to call the unified API interface provided by the business middle platform 200, such as / api / platform / menu / permissions. The request header of this interface carries Authorization: Bearer {token} to indicate the user's identity.

[0104] After receiving a request from the base application, the business middle platform executes the following processing logic:

[0105] The business middle platform obtains tenant information and identity information sent by the base application;

[0106] The business middle platform verifies the validity of the identity information (token) and parses out the user ID;

[0107] The business middle platform queries the permission center based on the user ID and tenant information (tenantId) to obtain all roles and permission information of the user under the current tenant; permission information refers to a list of permission points, that is, a set of permission codes;

[0108] The business middle platform queries the configuration center based on tenant information and user roles to obtain the menu configuration corresponding to the user role under the tenant; the menu tree generation algorithm adopts dynamic pruning based on weight: the system predefines a complete business menu forest, performs visibility determination on each menu node based on the user permission code, and retains only the nodes that have permission to access and their ancestor nodes to form a personalized menu tree.

[0109] The business middle platform combines the menu configuration and permission information and returns it to the base application.

[0110] Step S2 of this embodiment separates the menu and permission configurations from each sub-application and centrally stores them in the business platform, realizing centralized management and dynamic retrieval of configurations. Compared with the existing technology where each sub-application independently maintains a permission table and hard-codes the menu, the implementation of this invention significantly reduces repetitive configuration work and supports dynamic adjustment of permissions and menus at runtime without restarting any services.

[0111] Referring to step S3, the base application dynamically renders the platform's main menu according to the menu configuration and performs permission control on menu items and page elements based on the permission information. In this embodiment, step S3 moves the permission control point forward to the menu rendering stage of the base application, achieving fine-grained control that makes unauthorized entry points invisible, reducing the risk of users directly accessing unauthorized pages via URLs, and forming the first line of defense for security.

[0112] The reason for moving the access control point to the menu rendering stage is that in traditional access control schemes, permission verification often occurs after the user clicks the menu to enter a sub-application, where the sub-application itself determines whether the user has permission to access the current page. This post-verification method has serious security vulnerabilities: even if the sub-application denies access to an unauthorized user, the user can still see the entry point for the function in the navigation menu. This not only exposes the system's functional structure but may also be exploited by malicious users.

[0113] In this embodiment, after receiving the menu tree data returned by the business middle platform, the base application dynamically generates the platform's main navigation menu using front-end routing libraries (such as React Router and Vue Router) and UI component libraries (such as Ant Design and Element UI).

[0114] During rendering, the base application uses the permission point list to hide or disable menu items that the user does not have permission for. The specific algorithm is as follows:

[0115] For each menu item, check if its associated permission code (such as ltc:report:view) exists in the user's permission point list;

[0116] If the menu item exists, it is rendered normally; if it does not exist, it is hidden or disabled according to the configuration policy. Furthermore, for submenus, a recursive determination is used: the parent menu is only displayed if at least one submenu item has the necessary permissions.

[0117] For example, if the user's permission list does not contain ltc:report:view, the "View Report" menu item will not be rendered. Thus, a customized, integrated workbench that combines multiple subsystem function entry points is presented.

[0118] Step S3 in this embodiment implements unified menu rendering and entry-level permission control at the platform level, effectively blocking functional entry points that users are not authorized to access. Compared to the traditional solution where authentication is performed by sub-applications only after the user clicks the menu (leading to invalid requests and interface flickering), step S3 in this embodiment reduces invalid page loading and requests caused by authentication failures, improving system security and user experience.

[0119] Referring to steps S4 and S5, the base application listens for user interaction events with menu items. When a user clicks on a menu item, it obtains the routing information and identifier of the target sub-application corresponding to that menu item. Based on the identifier of the target sub-application, the base application dynamically loads and mounts the corresponding sub-application through a micro-frontend loader (e.g., micro-app).

[0120] In this embodiment, steps S4 and S5 design an on-demand loading mechanism based on a micro frontend loader, and securely pass the session context (token, tenantId, permission information) of the base application to the sub-application during loading, thereby enabling seamless access and context sharing for the sub-application.

[0121] Specifically, step S4 includes:

[0122] When a user clicks a menu item, the base application's menu click event handler is triggered, and this handler performs the following operations:

[0123] Get the sub-application identifier (e.g., appId: 'ltc-app') and route (e.g., / opportunity) associated with the clicked menu item;

[0124] Check if the sub-application has been loaded; if not, proceed to step S5 to execute the loading process; if it has been loaded, switch directly to the corresponding route page.

[0125] In step S5, the base application calls the micro-frontend loader (e.g., a loader based on a micro-app wrapper) to execute the loading process; including:

[0126] Based on the sub-application identifier, the loader requests the entry URL of the sub-application from the business middle platform. To improve performance, the loader adopts a pre-connection and resource pre-loading strategy: when the user hovers the mouse over a menu item, the DNS of the sub-application entry domain name is resolved in advance and a TCP connection is established.

[0127] The loader creates a new loader tag, for example <micro-app>The tag or similar custom element has its name attribute set to the sub-application identifier and its url attribute set to the entry URL.

[0128] The base application transmits current tenant information, identity information, and necessary permission information to the sub-application via the tag's data attribute or a custom event. Data transmission between the base application and the sub-application employs a preset secure transmission mechanism, with the sub-application verifying the integrity of the received data. In this embodiment, the secure transmission mechanism includes encrypting the transmitted data using the AES symmetric encryption algorithm and verifying data integrity using MAC or digital signatures.

[0129] Steps S4 and S5 in this embodiment enable on-demand loading and dynamic mounting of sub-applications, avoiding excessive resource loading on the first screen. Simultaneously, a unified transmission mechanism ensures that sub-applications obtain the necessary context information. Compared to existing technologies where each sub-application needs to independently handle login and sessions, steps S4 and S5 in this embodiment enable automatic session injection. Sub-applications do not need to concern themselves with user identity acquisition logic, reducing the development complexity of sub-applications.

[0130] Referring to step S6, the sub-application receives and parses the information transmitted by the base application, and renders the corresponding business page after completing internal permission verification. Step S6 in this embodiment constructs a dual security loop of base entry authentication and sub-application secondary authentication. The base application addresses the issue of whether the entry point is visible, while the sub-application addresses the issue of whether specific functions can be operated. The two are independent yet complementary, achieving defense in depth.

[0131] like Figure 3 As shown in the diagram, the interaction between the base application and the sub-application follows the message sequence illustrated in the sequence diagram. After a user logs in, the base application requests menu and permission configurations from the business middle platform. When the user clicks a menu item, the base application creates a sub-application instance through the micro-frontend loader and passes the current user's tenant information, identity token, and permission information to the sub-application.

[0132] The child application starts in its own independent runtime environment and receives data from the base application through lifecycle functions provided by the micro-app (such as mount and unmount) or global objects on the window. After receiving the data, the child application performs the following steps:

[0133] After receiving the information from the base application, the sub-application parses out the tenant information and identity information, and verifies the integrity of the data (e.g., verifying MAC or digital signature).

[0134] After verification, the identity information is stored in its own request interceptor for subsequent API calls with its own backend. After that, all API requests issued by the sub-applications will automatically carry this identity information to ensure that the backend service can identify the user's identity.

[0135] Furthermore, although the base application has implemented entry permission control, the sub-application still needs to verify the access permissions of specific pages. The sub-application can call its own backend service or, based on the permission information passed by the base application, determine whether the user has permission to access the current route (e.g., / opportunity), thereby achieving secondary authentication. In this embodiment, the authentication operation includes: the sub-application maintaining a route-permission code mapping table; when a user attempts to access any route, the sub-application retrieves the corresponding permission code by looking up the table, and then checks whether the permission point list passed by the base application contains the corresponding permission code; if it does, access is allowed; otherwise, access is denied. Secondary authentication ensures a secure closed loop for permission control; even if an attacker bypasses the base application and directly accesses the sub-application's URL, the sub-application's secondary authentication will deny access.

[0136] Step S6 in this embodiment combines unified access control of the base application with secondary authentication of the sub-applications to form a dual-verification security loop. This ensures unified management at the platform level while also taking into account the independent security needs of each subsystem. Simultaneously, sub-applications do not need to implement login and session management themselves, reducing repetitive development work for these functions. Furthermore, all sub-applications adhere to the same security standards, mitigating the risk of security vulnerabilities caused by implementation differences.

[0137] Based on steps S1 to S6 above, this embodiment achieves low-code system integration by configuration when the sub-applications conform to the preset access specifications. The integration of new sub-applications is completed entirely through visual configuration in the business middleware platform; the base application does not need to modify its loading logic for each sub-application; and new sub-applications conforming to the preset access specifications do not require additional adaptation code. This approach reduces code modification, rebuilding, and deployment work, thereby shortening the system integration cycle.

[0138] When a new business system (such as a financial system) needs to be integrated, operations and maintenance personnel or developers only need to log in to the management interface of the business platform:

[0139] In the sub-application management module, add a new record, fill in the sub-application identifier finance-app, the application name "Financial System", set the entry URL to "https: / / subapps.finance.com / ", and the optional loading strategy (such as whether to preload, whether to enable sandbox isolation, etc.).

[0140] In the menu management module, create one or more menu items for the financial system, select the associated sub-application as finance-app, and configure the menu item's icon, sort weight, routing path, etc.

[0141] In the access control module, assign permissions to specific roles (such as the CFO) to access these new menu items. Permission assignment supports batch operations and inheritance relationships; for example, the CFO role can inherit all the permissions of the Finance Manager and additionally gain the permission to export financial statements.

[0142] After completing the above configuration, no code modifications are required to the base application or the financial system. When a user with the CFO role refreshes the base application page, the base application will re-call the API interface of the business middle platform to obtain the latest menu and permission configurations. Since the menu item for the financial system has been added to the configuration center, and the permission center has assigned the corresponding permissions to this role, the newly integrated financial system menu item will automatically appear in the user interface, allowing users to seamlessly access it with a single click.

[0143] Clearly, this embodiment achieves zero-code or low-code integration of new business systems, significantly lowering the integration threshold. Compared to traditional integration methods that require modifying base code, rebuilding and redeploying, and coordinating multiple teams, this invention reduces code modification and redeployment work during the integration process and supports loading new sub-applications at runtime. The platform's flexibility and scalability are qualitatively improved.

[0144] In summary, this invention uses a business middle platform as a separation layer between configuration and logic, breaking the limitations of traditional micro-frontend solutions that only address frontend aggregation while neglecting the reuse of business capabilities. By extracting and centrally managing metadata such as environment configuration, permission models, and menu structures from the code, the platform possesses dynamic configuration, multi-tenant isolation, and configuration-based extension capabilities, providing a novel technical solution for the rapid construction and unified management of enterprise-level multi-business units. Specifically, this invention has the following technical effects:

[0145] (1) Implement a single codebase for multi-tenant reuse, significantly reducing deployment and maintenance costs:

[0146] This invention introduces a business middle platform and a multi-tenant architecture, separating the environment configurations (such as menus, permissions, and data sources) of different business units and customers from the application code and storing them uniformly in the business middle platform. The base application and all sub-applications only need to deploy a single set of code, which can dynamically switch configurations based on tenant information to serve all tenants. This solution effectively avoids the resource waste and high costs associated with deploying and maintaining an entire system separately for each tenant in the traditional model, achieving efficient reuse of core business logic.

[0147] (2) Implement unified permission and menu management to improve system security and user experience:

[0148] This invention moves the permission and menu management functions, which were previously scattered across various sub-applications, to the business middle platform and base applications. By centrally acquiring users' global permission information through the middle platform and dynamically generating and rendering menus through the base applications, a unified platform-level view is achieved. Moving the permission control point forward to the base level allows for the pre-screening of unauthorized access to functions, preventing invalid requests and unauthorized access, thereby significantly improving user experience while enhancing system security.

[0149] (3) Achieve "zero-code" or "low-code" integration of new business systems, significantly improving the platform's scalability:

[0150] This invention leverages the configuration capabilities of a business middle platform to abstract integration operations such as new sub-application registration, menu mounting, and permission configuration into configurable items. When integrating a new system, developers or operations personnel only need to perform visual configuration in the business middle platform (e.g., filling in the sub-application name, entry URL, assigning menu permissions, etc.), without modifying the code of the base application or the new system. The base application can automatically recognize and load the sub-application, achieving "plug-and-play" expansion capabilities, greatly reducing the integration threshold, and significantly improving the platform's flexibility and scalability.

[0151] This invention also provides a platform generation system based on micro-frontends and business middleware. Using the aforementioned platform generation method based on micro-frontends and business middleware, the system includes a user layer, an application layer, a sub-application layer, and a business middleware layer, wherein:

[0152] The user layer is used to receive user operations and provide the application layer with the current user's tenant information and identity information;

[0153] The application layer is used to deploy the base application and perform the following tasks: communicate with the business middle platform, obtain menu configuration, permission information and sub-application registration information corresponding to the current tenant and user role, automatically generate the platform main menu, routing configuration and permission control relationship, listen to the user's operation events on menu items to obtain the routing information and identifier of the target sub-application, and dynamically load the target sub-application and transmit tenant information, identity information and permission information through the micro frontend loader.

[0154] The sub-application layer is used to deploy sub-applications, and the sub-applications are used to receive and parse the information transmitted by the application layer, and render the corresponding business pages after internal authentication.

[0155] The business middle platform layer is used to deploy the business middle platform. The business middle platform is used to store tenant information, user role and permission mapping relationship, menu-sub-application mapping relationship and sub-application registration information, and generate corresponding menu configuration and permission information based on the current user's tenant information and identity information.

[0156] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described platform generation method based on a micro-frontend and a business middle platform.

[0157] The present invention also provides a computer-readable storage medium storing a computer program, characterized in that the computer program is executed by a processor to perform the above-described platform generation method based on a micro-frontend and a business middle platform.

[0158] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.

Claims

1. A platform generation method based on micro-frontends and business middleware, characterized in that: The method includes: Step S1: Initialize the base application and obtain the tenant information and identity information of the currently logged-in user; Step S2: The business middle platform queries the user roles and permission information under the current tenant based on the tenant information and identity information, and generates the corresponding menu configuration based on the pre-configured menu-sub-application mapping relationship and sub-application registration information. Step S3: The base application automatically generates the platform main menu, routing configuration, and permission control relationship between menu items and page elements based on the menu configuration and permission information. Step S4: The base application listens for user operation events on menu items to obtain the routing information and identifier of the target sub-application corresponding to the menu item; Step S5: The base application obtains the entry URL of the target sub-application through the micro-frontend loader based on the identifier of the target sub-application and dynamically loads the target sub-application. The sub-application mounting is completed without modifying the base application loading logic for each sub-application. Tenant information, identity information and permission information are transmitted to the target sub-application through a preset secure transmission mechanism. Step S6: The sub-application receives and parses the information transmitted by the base application, and renders the business page after internal authentication.

2. The platform generation method based on micro-frontend and business middle platform according to claim 1, characterized in that: In step S1, the base application initialization operation includes loading common styles, initializing global state management, and setting request interceptors.

3. The platform generation method based on micro-frontend and business middle platform according to claim 1, characterized in that: The business middle platform includes a permission center, a configuration center, and a tenant center, wherein: The permission center is used to store the mapping relationship between users, roles, and permissions; The configuration center is used to store the menu-sub-application mapping relationship and sub-application registration information under multi-tenancy. The tenant center is used for storing and isolating tenant information.

4. The platform generation method based on micro-frontend and business middle platform according to claim 3, characterized in that: In the configuration center, the menu is organized in a tree structure, including multiple menu items, each of which is associated with a sub-application identifier and a routing path.

5. A platform generation method based on micro-frontend and business middle platform according to claim 3 or 4, characterized in that: Step S2 includes: The business middle platform obtains tenant information and identity information sent by the base application; The business middle platform verifies the validity of identity information and parses out the user ID; The business middle platform queries the permission center based on the user ID and tenant information to obtain all roles and permission information of the user under the current tenant; The business middle platform queries the configuration center based on tenant information and user roles to obtain the menu configuration corresponding to the user role under that tenant; The business middle platform combines the menu configuration and permission information and returns it to the base application.

6. The platform generation method based on micro-frontend and business middle platform according to claim 3, characterized in that: In step S3, after the base application receives the menu configuration returned by the business middle platform, it dynamically generates the platform's main navigation menu using the front-end routing library and UI component library. During rendering, the base application uses permission information to hide or disable menu items that the user does not have permission to access.

7. A platform generation method based on micro-frontend and business middle platform according to claim 6, characterized in that: The base application uses permission information to hide or disable menu items that the user does not have permission to access, including: For each menu item, check if its associated permission code exists in the user's permission point list; If it exists, the menu item will be rendered normally; if it does not exist, it will be hidden or disabled according to the configuration policy.

8. The platform generation method based on micro-frontend and business middle platform according to claim 7, characterized in that: For submenus, a recursive decision is made: the parent menu is only displayed if at least one submenu item has the necessary permissions.

9. A platform generation method based on micro-frontend and business middle platform according to claim 1, characterized in that: Step S4 includes: When a user clicks a menu item, the base application's menu click event handler is triggered, and this handler performs the following operations: Get the sub-application identifier and route associated with the clicked menu item; Check if the sub-application has been loaded; if not, proceed to step S5 to execute the loading process; if it has been loaded, switch directly to the corresponding route page.

10. A platform generation method based on micro-frontend and business middle platform according to claim 1, characterized in that: Step S5 includes: Based on the sub-application identifier, the loader requests the entry URL of the sub-application from the business middle platform; The loader creates a custom element for mounting the target sub-application, setting its name attribute to the sub-application identifier and its url attribute to the entry URL; The base application can pass the current tenant information, identity information, and permission information to the sub-application through the data attribute of this tag or a custom event.

11. A platform generation method based on micro-frontend and business middle platform according to claim 10, characterized in that: The loader employs a pre-connection strategy: when the user hovers the mouse over a menu item, it resolves the DNS of the sub-application entry domain name in advance and establishes a TCP connection.

12. A platform generation method based on micro-frontend and business middle platform according to any one of claims 1, 10, and 11, characterized in that: Data transmission between the base application and sub-applications adopts a preset secure transmission mechanism, and the sub-applications verify the integrity of the received data.

13. A platform generation method based on micro-frontend and business middle platform according to claim 12, characterized in that: The secure transmission mechanism includes encrypting the transmitted data using the AES symmetric encryption algorithm and verifying the data integrity using MAC or digital signature.

14. The platform generation method based on micro-frontend and business middle platform according to claim 1, characterized in that: Step S6 includes: After receiving the information from the base application, the sub-application parses out the tenant information and identity information, and verifies the integrity of the data. After verification, the identity information is stored in its own request interceptor for subsequent API calls with its own backend; thereafter, all API requests issued by the sub-applications will automatically carry this identity information.

15. A platform generation method based on micro-frontend and business middle platform according to claim 1, characterized in that: In step S6, the authentication operation includes: the sub-application maintains a route-permission code mapping table. When a user attempts to access any route, the sub-application retrieves the corresponding permission code by looking up the table, and then checks whether the permission point list passed by the base application contains the corresponding permission code; if it does, access is allowed; otherwise, access is denied.

16. A platform generation system based on micro-frontends and business middleware, using a platform generation method based on micro-frontends and business middleware according to any one of claims 1-15, characterized in that: The system comprises a user layer, an application layer, a sub-application layer, and a business middleware layer, wherein: The user layer is used to receive user operations and provide the application layer with the current user's tenant information and identity information; The application layer is used to deploy the base application and perform the following tasks: communicate with the business middle platform, obtain menu configuration, permission information and sub-application registration information corresponding to the current tenant and user role, automatically generate the platform main menu, routing configuration and permission control relationship, listen to the user's operation events on menu items to obtain the routing information and identifier of the target sub-application, and dynamically load the target sub-application and transmit tenant information, identity information and permission information through the micro frontend loader. The sub-application layer is used to deploy sub-applications, and the sub-applications are used to receive and parse the information transmitted by the application layer, and render the corresponding business pages after internal authentication. The business middle platform layer is used to deploy the business middle platform. The business middle platform is used to store tenant information, user role and permission mapping relationship, menu-sub-application mapping relationship and sub-application registration information, and generate corresponding menu configuration and permission information based on the current user's tenant information and identity information.

17. A computer 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 computer program, it implements the platform generation method based on micro-frontend and business middle platform as described in any one of claims 1-15.

18. A computer-readable storage medium storing a computer program thereon, characterized in that, The computer program, when executed by the processor, performs a platform generation method based on micro-frontend and business middleware as described in any one of claims 1-15.

Images