Cross-system fusion processing method, apparatus, device, medium, and program product

Abstract

Embodiments of the present application provide a cross-system fusion processing method, device, equipment, medium and program product. The method is applied to a first system of a business system, and the business system further includes a second system; the method includes: in response to an access request generated when a user accesses the second system, transmitting the access request to the second system through a reverse proxy; if an access token returned by the second system is received, obtaining configuration information and menu data of the second system based on the access token; constructing the second system as a sub-application according to the configuration information and the menu data of the second system, and adding the menu data of the second system to a menu tree; when an operation request of the second system is triggered by the user through the menu tree, forwarding the operation request to the second system, so that the second system performs a corresponding processing operation. The present application realizes the interconnection and intercommunication of multiple business systems by dynamically fusing multiple independent business systems, and improves the consistency and flexibility of system operation.

Description

Technical Field

[0001] This application relates to the field of front-end application development technology, and in particular to a cross-system integrated processing method, apparatus, device, medium and program product. Background Technology

[0002] As enterprises continue to digitalize, they typically build multiple business systems, such as corporate banking systems, supply chain systems, and management systems, to support online business operations. While these systems are functionally independent, they are highly interconnected in terms of business processing. However, these multiple business systems are mostly developed independently by different technical teams, using their own technology stacks and deployment architectures. This makes it difficult to achieve efficient interconnection and interoperability between the systems, reducing the continuity of business operations and significantly increasing the overall complexity of operations and maintenance due to the independent operation and maintenance of each system.

[0003] To achieve interoperability between multiple systems, existing technologies use frame embedding, such as iframe (inline frame) technology, to embed pages from other business systems within one business system, thereby enabling calls between different business systems from one system. However, since different business systems are developed independently, it is difficult to guarantee consistency of cross-system interfaces, and cross-domain calls between systems require complex communication mechanisms, which not only consumes system resources but may also lead to system response delays and reduce overall business processing efficiency. Summary of the Invention

[0004] The cross-system fusion processing method, apparatus, device, medium, and program products provided in this application, after user authentication, build another business system as a sub-application in one business system. Based on this architecture, cross-system operations can be performed in one business system, realizing interconnection and interoperability between multiple systems. At the same time, through authentication, it also ensures that the user is authorized to both systems during cross-system operations, thus guaranteeing the data and operational security of each business system.

[0005] Firstly, this application provides a cross-system integrated processing method applied to a first system of a business system, which also includes a second system. The first system communicates with the second system via a reverse proxy. The first system and the second system are base applications based on the same micro-frontend framework. The method includes: responding to an access request generated when a user accesses the second system, passing the access request to the second system via a reverse proxy, so that the second system verifies whether the user is an authorized user, and returns an access token to the user if the user is an authorized user; if the access token returned by the second system is received, obtaining the configuration information and menu data of the second system based on the access token; constructing the second system as a sub-application according to the configuration information and menu data of the second system, and adding the menu data of the second system to a menu tree; when the user triggers an operation request of the second system through the menu tree, forwarding the operation request to the second system so that the second system performs the corresponding processing operation.

[0006] In one possible implementation, when a user triggers an operation request for the second system through a menu tree, forwarding the operation request to the second system includes: when the user triggers a target menu in the menu tree, generating an operation request and a prefix identifier for the operation request based on the target menu, the prefix identifier being used to indicate the business system corresponding to the operation request; if the prefix identifier of the operation request corresponds to the second system, then forwarding the operation request to the second system through a reverse proxy.

[0007] In one possible implementation, the second system is constructed as a sub-application based on the configuration information and menu data of the second system, and the menu data of the second system is added to the menu tree. This includes: registering the sub-application corresponding to the second system in the first system based on the configuration information of the second system, and activating the sub-application; and adding the menu of the sub-application to the menu tree of the first system based on the menu data of the second system, so as to form a navigation interface containing the menus of the first system and the second system.

[0008] In one possible implementation, the business system further includes a content delivery network; the method further includes: generating a public library file based on the public base library of the first system, and deploying it to the content delivery network, so that the first system performs corresponding steps based on the public library file.

[0009] Secondly, this application provides a cross-system integrated processing method applied to a second system of a business system. The business system also includes a first system, which communicates with the second system through a reverse proxy. The first system and the second system are base applications based on the same micro-frontend framework. The method includes: in response to an access request sent by the first system, verifying whether the user corresponding to the access request is an authorized user; if the user is an authorized user, generating an access token for the user and returning the access token to the first system; in response to an operation request sent by the first system, executing the processing operation corresponding to the operation request; and verifying and updating the session state of the first system through a collaborative mechanism.

[0010] In one possible implementation, the business system further includes a content delivery network; the method further includes: generating a public library file based on the public base library of the second system, and deploying it to the content delivery network, so that the second system performs corresponding steps based on the public library file.

[0011] Thirdly, this application provides a cross-system fusion processing device applied to a first system of a business system, the business system further including a second system, the first system communicating with the second system through a reverse proxy; the first system and the second system are base applications based on the same micro-frontend framework; the device includes: an access request verification module, used to respond to an access request generated when a user accesses the second system, and to pass the access request to the second system through a reverse proxy, so that the second system verifies whether the user is an authorized user, and returns an access token to the user if the user is an authorized user; an information acquisition module, used to obtain the configuration information and menu data of the second system based on the access token if the access token returned by the second system is received; a second system fusion module, used to build the second system into a sub-application according to the configuration information and menu data of the second system, and add the menu data of the second system to the menu tree; and an operation processing module, used to forward the operation request to the second system when the user triggers an operation request to the second system through the menu tree, so that the second system performs the corresponding processing operation.

[0012] Fourthly, this application provides a cross-system integrated processing device applied to a second system of a business system. The business system further includes a first system, which communicates with the second system via a reverse proxy. The first system and the second system are base applications based on the same micro-frontend framework. The device includes: an authentication module, used to verify whether the user corresponding to the access request is an authorized user in response to an access request sent by the first system; an access token generation module, used to generate an access token for the user if the user is authorized, and return the access token to the first system; a request processing module, used to execute the processing operation corresponding to the operation request in response to an operation request sent by the first system; and a state update module, used to verify and update the session state of the first system through a collaborative mechanism.

[0013] Fifthly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided in the first aspect above.

[0014] In a sixth aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method provided in the first aspect above.

[0015] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in the first aspect above.

[0016] The cross-system integration processing method, apparatus, device, medium, and program products provided in this application, when a user initiates an access request to a second system through a first system, the first system forwards the access request to the second system, enabling the second system to verify the user's identity. Upon successful verification, the second system generates and returns an access token, achieving cross-system penetration of user authentication and ensuring the legitimacy of the user's identity when operating between different systems. Then, after successful identity verification, the configuration information and menu data of the second system are obtained, and the second system is built as a sub-application of the first system. The menu of the sub-application is merged into the original menu tree of the first system, achieving cross-system integration. Within the first system, users can directly access and operate services in the second system through the menu tree, avoiding switching between business systems and improving the continuity of business system operations. Simultaneously, the consistency of the system interface after cross-system integration is ensured, eliminating the need for additional page generation and reducing webpage resource consumption. Furthermore, when accessing and operating services in the second system through the menu tree, a reverse proxy forwards operation requests between the first and second systems, solving the cross-domain restriction problem and eliminating the need for complex communication mechanisms. Attached Figure Description

[0017] 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.

[0018] Figure 1 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 1 ;

[0019] Figure 2 A schematic diagram of the structure of a business system provided in an embodiment of this application;

[0020] Figure 3 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 2 ;

[0021] Figure 4 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 3 ;

[0022] Figure 5 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 4 ;

[0023] Figure 6 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 5 ;

[0024] Figure 7 A schematic diagram of a cross-system fusion processing device provided in an embodiment of this application;

[0025] Figure 8 A schematic diagram of another cross-system fusion processing device provided in this application embodiment;

[0026] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0027] 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

[0028] 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.

[0029] This application applies to scenarios involving the collaboration of multiple business systems. In the context of enterprise digital transformation, companies in many sectors often design and develop multiple independent business systems, such as corporate online banking systems, supply chain systems, and management systems, to enable online business transactions. For example, a corporate online banking system replaces traditional offline counter operations, helping companies complete internal financial transactions conveniently and efficiently. A supply chain system integrates the relationships between different levels of the supply chain, thereby optimizing business process management.

[0030] Multiple independent business systems are often developed independently by different technical teams, using their own commonly used technology stacks and deployment architectures. Therefore, different business systems may have different technology stacks and entry points, and cannot directly communicate with each other. In actual enterprise operations, although the business processes corresponding to these multiple systems are independent, they often involve related operations. For example, when a user handles settlement business, they need to first log in to the corporate online banking system to complete account operations, and then switch to the supply chain system to process order and logistics information. In this scenario, the operation is cumbersome, and because the two systems are not interconnected and cannot achieve real-time synchronization, repeated operations may be necessary, further reducing operational efficiency.

[0031] To achieve interoperability among multiple business systems, existing technologies employ framework embedding, such as iframes, to embed sub-business systems within the main business system, allowing access to the sub-business systems through the embedded framework. However, embedded sub-business systems and the main business system often use independent style sheets and style rules, easily leading to issues like duplicate style class names and style hierarchy overriding, making it difficult to guarantee consistency across system interfaces. Furthermore, since the main and sub-business systems are cross-domain systems, complex communication methods are required, and embedding sub-business systems consumes dedicated memory and CPU resources, potentially causing issues like interface lag and response delays in the main business system.

[0032] On the other hand, existing technologies allow multiple business systems to operate within a single system by merging their codebases. However, as these business systems are continuously updated and their functionality expanded, they become increasingly complex. Merging the codebases of multiple business systems can lead to system bloat and maintenance difficulties.

[0033] The cross-system integration processing method provided in this application achieves interconnection and interoperability among multiple business systems by merging them. Specifically, when a user accesses other business systems from one business system, and that user is an authorized user of the other business systems, the other business systems are built as sub-applications within that business system. This achieves dynamic integration of multiple independent business systems without affecting their independent operational capabilities.

[0034] 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.

[0035] Figure 1A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 1 .like Figure 1 As shown, the method provided in this embodiment includes the following steps:

[0036] Step S101: In response to the access request generated when the user accesses the second system, the access request is passed to the second system through a reverse proxy so that the second system can verify whether the user is an authorized user and return the user's access token if the user is an authorized user.

[0037] The method provided in this application is applied to the first system of the business system. Figure 2 This is a schematic diagram of the structure of a business system provided in an embodiment of this application. For example... Figure 2 As shown, the business system provided in this application includes a first system and a second system. The first system communicates with the second system through a reverse proxy. The first system and the second system are base applications based on the same micro-frontend framework.

[0038] A reverse proxy is an intermediary component deployed between a first system and a second system, used to forward requests between the two business systems, such as nginx. During communication between the two business systems, direct communication is impossible because they are across domains. By forwarding requests from either the first or second system through a reverse proxy, communication between the two systems can be achieved.

[0039] Micro-frontend frameworks are frontend frameworks that support a main application-sub-application architecture pattern. They allow for the flexible combination of multiple independently developed and deployed sub-applications within a single base application. The base application is a main application or sub-application built on the micro-frontend framework and has the ability to dynamically register and load sub-applications.

[0040] In one example, the first and second systems can be developed using the same micro-frontend framework, making the first and second systems base applications based on the same micro-frontend framework.

[0041] In another example, if the first system and the second system are not based on the same micro-frontend framework during development, the first system and the second system will be transformed into base applications of the same micro-frontend framework before executing the method provided in this application, such as modifying the common base library used to the same version and the same configuration.

[0042] The first system and the second system in this application are independent and can operate independently. For example, the first system can be a corporate online banking system, and the second system can be a supply chain system. It should be noted that there can be at least one second system.

[0043] The user is the one who successfully logged in and accessed the first system.

[0044] In this application, the first system's page includes an access path to the second system. For example, the first system may include a shortcut icon for the second system, or the first system may have a corresponding main menu for the second system within its menu tree. The shortcut icon and the main menu for the second system are associated with the entry point to the second system.

[0045] When a user needs to access the second system, the user can initiate an access request by triggering the quick access icon of the second system or by triggering the main menu of the second system.

[0046] In this step, after initiating an access request, the frontend of the first system responds to the access request generated when the user accesses the second system by calling the backend interface and sending the access request to the reverse proxy. The reverse proxy then forwards the access request to the second system. The second system verifies whether the user corresponding to the access request is also an authorized user of the second system, i.e., a legitimate user.

[0047] In some embodiments, the access request carries user identification information. In one example, this user identification information may be the identity information of the user who initiated the access request when logging into the first system. In another example, the user identification information may also be the identity information entered by the user when accessing the second system through the first system.

[0048] For example, when a user triggers the shortcut icon of the second system, or triggers the main menu of the second system, the first system pops up a dialog box to instruct the user to enter identity information, such as a user account and password.

[0049] This method allows for the integration of different business systems when user authentication information is inconsistent (e.g., user A's account is xxxx1 in the first system and xxxx2 in the second system), improving the applicability of the method while ensuring the independence of each business system.

[0050] In some embodiments, the access request may also carry a unique identifier of a second system. Using the unique identifier of the second system, the reverse proxy forwards the access request to the system corresponding to the unique identifier.

[0051] If the second system verifies that the user initiating the access request is an authorized user, the second system generates an access token and returns the access token to the backend port of the first system through a reverse proxy. After receiving the access token, the backend port of the first system transmits the access token to the frontend of the first system.

[0052] An access token is a digital credential generated by the secondary system and used to represent a user's identity and permissions within that system.

[0053] By generating and transmitting access tokens, a pass-through authentication of user identities between multiple business systems is achieved. This not only ensures the legitimacy of users during operations and guarantees the security of system operations, but also eliminates the need for frequent verification of user authorization by the second system, reducing redundant operations and improving overall operational efficiency.

[0054] Step S102: If an access token is received from the second system, the configuration information and menu data of the second system are obtained based on the access token.

[0055] The configuration information for the second system consists of the configuration information for the micro-frontend sub-applications of the second system, including the loading path of the sub-applications, dependency library versions, etc. The menu data for the second system consists of the menu data for the micro-frontend sub-applications of the second system, including the menu item names, icons, paths, etc.

[0056] The configuration information and parameter data of the second system are preset in the configuration file of the second system.

[0057] In this step, if an access token is received from the second system, indicating that the user is an authorized user of the second system and can operate it, an acquisition command carrying the access token is generated and forwarded to the second system via a reverse proxy. Upon receiving the acquisition command, the second system reads its configuration information and menu data, and then returns this information to the first system.

[0058] Step S103: Based on the configuration information and menu data of the second system, the second system is built into a sub-application, and the menu data of the second system is added to the menu tree.

[0059] In this context, a sub-application is an application that has independent functionality within the first system. A menu tree is a hierarchical navigation component based on a tree structure used to organize the entry points to functions within the first system. A sub-application typically corresponds to a menu branch within the menu tree.

[0060] In this step, based on the configuration information of the second system, the first system builds the functions of the second system into a sub-application of the first system, and adds the menu data of the second system to the menu tree, that is, adds the menu branch corresponding to the second system to the menu tree.

[0061] Specifically, based on the configuration information of the second system, the second system can be registered and activated through the base project of the first system, making the second system a sub-application of the first system.

[0062] The foundation project is a collection of components configured for the first system. The foundation project includes components such as a sub-application registration management module, a cross-system communication module, an identity authentication penetration module, and a front-end resource loading module. The foundation project also defines standardized sub-application access protocols, including configuration information format specifications, interface call protocols, and data interaction formats, to ensure that different business systems can access the system according to a unified standard.

[0063] The menu data of the second system is added to the menu tree. Specifically, the base project of the first system, based on the menu data of the second system, mounts the menus of the sub-applications corresponding to the second system to the menu tree of the first system according to the hierarchical relationship. For example, they can be mounted under the existing main menu of the second system in the menu tree of the first system; or new branches can be generated in the menu tree, and the menus of the sub-applications corresponding to the second system can be mounted on the new branches.

[0064] By building the corresponding sub-application of the second system in the first system only when there is a need for cross-system access, the dynamic integration of multiple business systems is achieved, avoiding redundancy in the functional and architectural design of the first system when there is no need for cross-system access, and improving resource utilization.

[0065] Step S104: When the user triggers an operation request for the second system through the menu tree, the operation request is forwarded to the second system so that the second system can perform the corresponding processing operation.

[0066] When a user triggers a menu item in the menu tree, the first system generates a corresponding operation request to instruct the business system to execute the operation corresponding to that menu item. The second system's operation request is for a menu item triggered by the user that corresponds to the menu data added by the second system. The second system's operation request is used to execute the operation corresponding to that menu item in the second system.

[0067] Specifically, when a user triggers the menu of the sub-application corresponding to the second system in the menu tree, the first system generates an operation request for the second system. In response to this operation request, the first system forwards it to the second system via a reverse proxy. Upon receiving the operation request, the second system executes the corresponding processing operation.

[0068] For example, when a user triggers an operation request for the second system through the menu tree, the operation request is forwarded to the second system through the reverse proxy configured on the web server of the first system in order to obtain the HTML resources on the web server of the second system.

[0069] In some embodiments, the menu corresponding to the second system includes a main menu and specific function menus. The main menu corresponds to the entry point of the second system and is used to initiate communication with the second system. The specific function menus correspond to the specific functions of the second system and are used to enable the second system to perform the corresponding processing operations.

[0070] In some embodiments, the operation request from the second system may further include an access token. Upon receiving the operation request, the second system verifies whether the user is an authorized user based on the access token. If the user is authorized, the system performs the corresponding processing operation. If the user is unauthorized, the system does not perform the corresponding processing operation. By including an access token in the operation request, unauthorized users are prevented from obtaining or using the data or functions of the second system through the first system, thus ensuring the security of the second system.

[0071] In some embodiments, when a user logs into the first system, the first system creates a session and executes a cross-system integration processing method within that session. When the session is disconnected, such as when the user logs out or has not operated for a long time, the corresponding sub-application of the second system can be uninstalled to release the resources of the first system and improve resource utilization.

[0072] The cross-system integration processing method provided in this application allows a user to initiate an access request to a second system through a first system. The first system forwards the access request to the second system, enabling the second system to verify the user's identity. Upon successful verification, the second system generates and returns an access token, achieving cross-system penetration of user authentication and ensuring the legitimacy of the user's identity when operating across different systems. Then, after successful identity verification, the configuration information and menu data of the second system are obtained, and the second system is built as a sub-application within the first system. The menu of the sub-application is merged into the original menu tree of the first system, achieving cross-system integration. Within the first system, users can directly access and operate services in the second system through the menu tree, avoiding switching between business systems and improving the continuity of business system operations. Simultaneously, it ensures the consistency of the system interface after cross-system integration, eliminating the need for additional page generation and reducing webpage resource consumption. Furthermore, when accessing and operating services in the second system through the menu tree, a reverse proxy forwards operation requests between the first and second systems, resolving cross-domain restrictions and eliminating the need for complex communication mechanisms.

[0073] In one possible implementation, the business system further includes a content delivery network; the method further includes: generating a public library file based on the public base library of the first system, and deploying it to the content delivery network, so that the first system performs corresponding steps based on the public library file.

[0074] A Content Delivery Network (CDN) is a distributed network architecture that accelerates resource loading by deploying cache nodes at the edge to distribute static or dynamic content of a business system to the cache nodes.

[0075] Specifically, common base libraries (such as Vue, axios, and element-ui) are extracted from the base library of the first system. These common base libraries are packaged into independent common library files and deployed to the content delivery network (CDN). In the base project of the first system, the common base libraries are loaded from the CDN through configuration of externals, etc. This method supports the complete operation of the first system, ensuring that the first system, based on the common library files, executes the corresponding steps normally, such as steps S101-S104. This achieves the reuse of common base libraries.

[0076] One way to extract a common base library from the base library of the first system is to extract the base library marked as common in the configuration file of the base library.

[0077] By introducing a content delivery network, the reuse of common base libraries is achieved, which can effectively reduce the repeated loading of common base libraries. This can optimize the page rendering speed and interaction response speed of the first system, and solve problems such as lag or reduced page rendering speed of the first system after building the corresponding sub-applications of the second system. It improves page loading performance and thus enhances the user experience.

[0078] Figure 3 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 2 The method provided in this embodiment is... Figure 1 Based on the illustrated embodiment, a more detailed explanation of steps S103 and S104 is provided. For example... Figure 3 As shown, the method provided in this embodiment includes:

[0079] Step S301: In response to the access request generated when the user accesses the second system, the access request is passed to the second system through a reverse proxy so that the second system can verify whether the user is an authorized user and return the user's access token if the user is an authorized user.

[0080] Step S302: If an access token is received from the second system, the configuration information and menu data of the second system are obtained based on the access token.

[0081] Step S303: Based on the configuration information of the second system, register the corresponding sub-application of the second system in the first system and activate the sub-application.

[0082] For example, the first system checks whether the configuration information of the second system conforms to the preset sub-application access protocol. If it conforms, the sub-application corresponding to the second system is registered. That is, the sub-application is marked as pending activation in the first system's configuration library, and an association mapping relationship between the sub-application, front-end resource address, and back-end port is established based on the configuration information, forming a sub-application access routing table. After registration, the sub-application corresponding to the second system is activated, and the sub-application is marked as activated in the first system's configuration library.

[0083] Step S304: Based on the menu data of the second system, add the menu of the sub-application to the menu tree of the first system to form a navigation interface containing the menus of the first system and the second system.

[0084] For example, based on the menu data of the second system, the menu name, style, and hierarchical relationship of the menu items of the sub-application are determined. Based on the menu name, style, and hierarchical relationship of the menu items of the sub-application, the menu of the sub-application is added to the menu tree of the first system. The menu tree after adding the menu of the sub-application includes menus corresponding to each function of the first system, as well as menus corresponding to each function of the second system, forming a unified navigation interface.

[0085] Step S305: When the user triggers the target menu in the menu tree, an operation request and a prefix identifier of the operation request are generated based on the target menu. The prefix identifier is used to indicate the business system corresponding to the operation request.

[0086] The target menu is the menu in the menu tree that the user clicks, in order to execute the function corresponding to that menu. The prefix identifier is a unique identifier used to indicate the business system corresponding to the operation request when the operation request is generated. For example, when the prefix identifier is / epw-tbp, it corresponds to the supply chain system.

[0087] In this step, when a user triggers a target menu item in the menu tree, the first system generates an operation request based on the target menu item, such as an HTML resource retrieval request. A prefix identifier for the operation request is generated based on the business system corresponding to the target menu item, and this prefix identifier is added to the operation request.

[0088] Step S306: If the prefix identifier of the operation request corresponds to the second system, then the operation request is forwarded to the second system through the reverse proxy.

[0089] In this step, the first system identifies the prefix identifier of the operation request. If the prefix identifier corresponds to the second system, the operation request is forwarded to the corresponding reverse proxy, and the reverse proxy forwards the operation request to the second system.

[0090] For example, the web server of the first system is configured with reverse proxy rules, which can forward operation requests carrying prefix identifiers to the business system corresponding to the prefix identifiers through the reverse proxy.

[0091] In this step, the operation request to add the prefix identifier can also be sent directly to the reverse proxy, so that the reverse proxy can identify the business system corresponding to the prefix identifier based on the reverse proxy rules and forward the operation request to that business system.

[0092] In this embodiment, by adding a prefix identifier when generating an operation request, the operation request can be quickly and directly forwarded to the corresponding second system. This solves the cross-domain restriction and enables precise routing, ensuring the stability and security of cross-domain interactions. At the same time, by registering and activating sub-applications and merging their menus into the menu tree of the first system, a unified navigation interface is formed. Users can directly run the functions of the first and second systems through this navigation interface, avoiding the user's perception of switching between business systems and improving the user experience.

[0093] Figure 4 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 3 To better understand the method provided in this embodiment, this embodiment provides a detailed description of the cross-system fusion processing method. For example... Figure 4 As shown, the method provided in this embodiment includes:

[0094] Step S401: In response to the access request generated when the user accesses the second system, the access request is passed to the second system through a reverse proxy.

[0095] Step S402: Based on the return result from the second system, determine whether the user is an authorized user. If the user is an authorized user, proceed to step S403; otherwise, proceed to step S406.

[0096] In this step, if an access token is received from the second system, the user is determined to be an authorized user. If no access token is received from the second system within a preset time, or if the information returned by the second system indicates that the user is not an authorized user, the user is determined to be an unauthorized user.

[0097] Step S403: Based on the access token, obtain the configuration information and menu data of the second system.

[0098] Step S404: Based on the configuration information of the second system, register the corresponding sub-application of the second system in the first system and activate the sub-application.

[0099] Step S405: Add the menu of the sub-application to the menu tree of the first system based on the menu data of the second system.

[0100] Step S406: Add a fill submenu under the main menu of the menu tree of the first system.

[0101] The populated submenu is a custom-added submenu used to indicate in the first system that the user is not an authorized user.

[0102] In some embodiments, the fill submenu may also include prompts such as "Incorrect password" or "Unregistered user" to prompt the user to confirm and correct the authentication information.

[0103] In this embodiment, a processing flow for unauthorized users accessing the second system is added, and the cross-system integration processing method is further improved by generating a populated sub-menu.

[0104] Figure 5 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 4 The method provided in this embodiment is applied to a second system of the business system, such as... Figure 2 The second system in the system, the business system also includes the first system, which communicates with the second system through a reverse proxy; the first system and the second system are base applications based on the same micro-frontend framework. For example... Figure 5 As shown, the method provided in this embodiment includes:

[0105] Step S501: In response to the access request sent by the first system, verify whether the user corresponding to the access request is an authorized user.

[0106] In this step, the second system responds to the access request sent by the first system and verifies whether the user corresponding to the access request is an authorized user based on the information in the access request.

[0107] Specifically, the second system responds to the access request sent by the first system and retrieves the authentication information corresponding to the access request from the access request information. Based on the authentication information, it verifies whether the user corresponding to the access request is an authorized user.

[0108] In step S502, if the user is an authorized user, an access token is generated for the user and returned to the first system.

[0109] In this step, if the user is verified as authorized, an access token is generated. This access token eliminates the need for repeated authentication in subsequent operations. The access token is then returned to the primary system via a reverse proxy.

[0110] Step S503: In response to the operation request sent by the first system, perform the processing operation corresponding to the operation request.

[0111] In this step, when a user triggers an operation request for the second system through the first system, the first system forwards the operation request to the second system. The second system responds to the operation request sent by the first system by creating or updating a session for the second system and executing the processing operation corresponding to the operation request.

[0112] In some embodiments, if the operation request sent by the first system is the user's first operation request, the second system will first log in, create a session after logging in, and perform the corresponding processing operation.

[0113] Step S504: Verify and update the session state of the first system through a collaborative mechanism.

[0114] The collaboration mechanism is a predefined set of interaction rules and operations between the second system and the first system, such as calling the backend interface of the first system through a reverse proxy.

[0115] Session state refers to the collection of contextual information recorded during the interaction process, used to save the operation trajectory and business status.

[0116] In this step, when the second system performs the processing operation corresponding to the operation request, it communicates with the first system through a coordination mechanism to verify and update the session state of the first system.

[0117] For example, the session identifier can be passed through a reverse proxy to verify and update the session state of the first system.

[0118] Verifying and updating the session state of the first system can be done by checking whether the session of the first system exists, and if it does, updating the session state of the first system.

[0119] In some embodiments, through a pre-set collaboration mechanism, the second system can establish a long-lived connection with the backend of the first system via WebSocket. When the second system executes the processing operation corresponding to the operation request, the backend of the second system notifies the backend of the first system to update the session state (such as the operation timestamp) in real time via WebSocket. The frontend of the first system listens for WebSocket events and dynamically refreshes the interface state.

[0120] Through a collaborative mechanism, it can be effectively ensured that the login session state of the first system will not expire due to timeout when operating in the second system for an extended period of time. When the user switches back to operating the first system, the user does not need to log in again, thus achieving seamless connection and synchronization of cross-system operations.

[0121] Optionally, the first system and the second system are base applications based on the same micro-frontend framework; the business system also includes a content delivery network; the method further includes: generating a public library file based on the public base library of the second system, and deploying it to the content delivery network, so that the second system can perform the corresponding steps based on the public library file.

[0122] Specifically, a common base library is extracted from the base library of the second system, packaged into an independent common library file, and deployed to the content delivery network. In the base project of the second system, the common base library is loaded from the content delivery network through configuration of externals, etc. This method supports the complete operation of the second system, ensuring that the second system, based on the common library file, executes the corresponding steps normally, such as steps S501-S504. This achieves the reuse of the common base library.

[0123] One way to extract a common base library from the base library of the second system is to extract the base library marked as common in the configuration file of the base library.

[0124] In conjunction with the above embodiments, the common base libraries of both the second system and the first system are configured on the content delivery network. When the first system and the second system rely on the common base libraries, they can be directly referenced, which greatly reduces the repeated loading of resources, significantly reduces the rendering and response time of pages, and thus improves the user experience.

[0125] Figure 6 A flowchart illustrating a cross-system fusion processing method provided in this application embodiment. Figure 5 To better understand the interaction process between the first and second systems in the cross-system fusion processing method, this embodiment provides a detailed explanation of the system interaction process. For example... Figure 6 As shown, after building the second system into a sub-application based on its configuration information and menu data, and adding its menu data to the menu tree, the interaction process between the first and second systems when operating the second system across systems includes:

[0126] When a user triggers the second system through the menu tree (i.e., clicks the main menu of the second system), but no specific function is triggered at this time, the first system checks whether a session exists in the first system. If it does not exist, a new session is created. It also checks whether the user has the necessary permissions for the second system, i.e., whether the access token is valid. If the session exists and the access token is valid, an operation request is generated and forwarded to the second system through a reverse proxy.

[0127] Log in to the second system based on the access token and create a session in the second system. After creation, update the session state of the first system based on the collaboration mechanism and load the page.

[0128] When a user triggers an operation request for the second system through the menu tree (i.e., clicks on the corresponding function menu in the second system), the operation request is forwarded to the second system. The second system updates its session state and executes the corresponding processing operation. Simultaneously, a collaborative mechanism verifies the existence of a session in the first system. If a session exists, the session state of the first system is updated, and a response is displayed on the first system's page.

[0129] Figure 7 This is a schematic diagram of a cross-system fusion processing device provided in an embodiment of this application. The cross-system fusion processing device provided in this embodiment is applied to a first system of a business system. The business system also includes a second system. The first system communicates with the second system through a reverse proxy. The first system and the second system are base applications based on the same micro-frontend framework. Figure 7 As shown, the cross-system fusion processing device provided in this embodiment includes an access request verification module 701, an information acquisition module 702, a second system fusion module 703, and an operation processing module 704.

[0130] The access request verification module 701 is used to respond to the access request generated when a user accesses the second system. Through a reverse proxy, it forwards the access request to the second system so that the second system can verify whether the user is an authorized user and return an access token to the user if the user is an authorized user. The information acquisition module 702 is used to obtain the configuration information and menu data of the second system based on the access token if it receives the access token returned by the second system. The second system integration module 703 is used to build the second system into a sub-application according to the configuration information and menu data of the second system and add the menu data of the second system to the menu tree. The operation processing module 704 is used to forward the operation request to the second system when the user triggers an operation request to the second system through the menu tree so that the second system can perform the corresponding processing operation.

[0131] Optionally, the operation processing module 704 is specifically used for:

[0132] When a user triggers a target menu in the menu tree, an operation request and a prefix identifier for the operation request are generated based on the target menu. The prefix identifier is used to indicate the business system corresponding to the operation request. If the prefix identifier of the operation request corresponds to a second system, the operation request is forwarded to the second system through a reverse proxy.

[0133] Optionally, the second system fusion module 703 is specifically used for:

[0134] Based on the configuration information of the second system, the corresponding sub-application of the second system is registered in the first system and activated; based on the menu data of the second system, the menu of the sub-application is added to the menu tree of the first system to form a navigation interface that includes the menus of the first and second systems.

[0135] Optionally, the business system also includes a content delivery network; the cross-system fusion processing device provided in this embodiment further includes a common library generation module, which is used for:

[0136] Based on the public base library of the first system, a public library file is generated and deployed to the content delivery network so that the first system can perform the corresponding steps based on the public library file.

[0137] The cross-system fusion processing apparatus provided in this application embodiment can be used to execute the technical solution of the cross-system fusion processing method provided in any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be repeated here.

[0138] Figure 8 This is a schematic diagram of another cross-system fusion processing device provided in an embodiment of this application. The cross-system fusion processing device provided in this embodiment is applied to a second system of a business system. The business system also includes a first system, which communicates with the second system through a reverse proxy. The first system and the second system are base applications based on the same micro-frontend framework. Figure 8 As shown, the cross-system fusion processing device provided in this embodiment includes an authentication module 801, an access token generation module 802, a request processing module 803, and a status update module 804.

[0139] The authentication module 801 is used to respond to the access request sent by the first system and verify whether the user corresponding to the access request is an authorized user; the access token generation module 802 is used to generate the user's access token if the user is an authorized user and return the access token to the first system; the request processing module 803 is used to respond to the operation request sent by the first system and execute the processing operation corresponding to the operation request; the state update module 804 is used to verify and update the session state of the first system through a coordination mechanism.

[0140] Optionally, the business system also includes a content delivery network; the cross-system fusion processing device provided in this embodiment further includes a common library generation module, which is used for:

[0141] Based on the public base library of the second system, a public library file is generated and deployed to the content delivery network so that the second system can perform the corresponding steps based on the public library file.

[0142] The cross-system fusion processing apparatus provided in this application embodiment can be used to execute the technical solution of the cross-system fusion processing method provided in any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be repeated here.

[0143] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device of this embodiment may include: at least one processor 901; and a memory 902 communicatively connected to at least one processor; wherein the memory 902 stores instructions that can be executed by at least one processor 901, and the instructions are executed by at least one processor 901 to cause the electronic device to perform the method as described in any of the above embodiments.

[0144] Optionally, the memory 902 can be either standalone or integrated with the processor 901. When the memory 902 is configured independently, the device also includes a bus for connecting the memory 902 and the processor 901.

[0145] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0146] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the methods provided in any of the foregoing embodiments can be implemented.

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

[0148] 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.

[0149] 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.

[0150] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0151] 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.

[0152] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0153] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0154] 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.

[0155] 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.

[0156] 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 cross-system fusion processing method, characterized in that, A first system applied to a business system, the business system further including a second system, the first system communicating with the second system via a reverse proxy; the first system and the second system are base applications based on the same micro-frontend framework; the method includes: In response to an access request generated when a user accesses the second system, the access request is passed to the second system through the reverse proxy, so that the second system can verify whether the user is an authorized user, and return the user's access token if the user is an authorized user; If the access token returned by the second system is received, the configuration information and menu data of the second system are obtained based on the access token; Based on the configuration information and menu data of the second system, the second system is built into a sub-application, and the menu data of the second system is added to the menu tree; When the user triggers an operation request to the second system through the menu tree, the operation request is forwarded to the second system so that the second system can perform the corresponding processing operation.

2. The method according to claim 1, characterized in that, When the user triggers an operation request to the second system through the menu tree, forwarding the operation request to the second system includes: When the user triggers the target menu in the menu tree, an operation request and a prefix identifier of the operation request are generated based on the target menu. The prefix identifier is used to indicate the business system corresponding to the operation request. If the prefix identifier of the operation request corresponds to the second system, then the operation request is forwarded to the second system through the reverse proxy.

3. The method according to claim 1, characterized in that, The step of building the second system into a sub-application based on the configuration information and menu data of the second system, and adding the menu data of the second system to the menu tree, includes: Based on the configuration information of the second system, register the sub-application corresponding to the second system in the first system and activate the sub-application; Based on the menu data of the second system, the menu of the sub-application is added to the menu tree of the first system to form a navigation interface that includes menus from both the first and second systems.

4. The method according to any one of claims 1-3, characterized in that, The business system also includes a content delivery network; the method further includes: Based on the public base library of the first system, a public library file is generated and deployed to the content delivery network so that the first system can perform corresponding steps based on the public library file.

5. A cross-system fusion processing method, characterized in that, A second system applied to a business system, the business system further including a first system, the first system communicating with the second system via a reverse proxy; the first system and the second system are base applications based on the same micro-frontend framework; the method includes: In response to the access request sent by the first system, verify whether the user corresponding to the access request is an authorized user; If the user is an authorized user, an access token is generated for that user, and the access token is returned to the first system. In response to the operation request sent by the first system, perform the processing operation corresponding to the operation request; The session state of the first system is verified and updated through a collaborative mechanism.

6. The method according to claim 5, characterized in that, The business system also includes a content delivery network; the method further includes: Based on the public base library of the second system, a public library file is generated and deployed to the content delivery network so that the second system can perform corresponding steps based on the public library file.

7. A cross-system fusion processing device, characterized in that, A first system applied to a business system, the business system further including a second system, the first system communicating with the second system via a reverse proxy; the first system and the second system are base applications based on the same micro-frontend framework; the device includes: The access request verification module is used to respond to the access request generated when a user accesses the second system, and to pass the access request to the second system through the reverse proxy, so that the second system can verify whether the user is an authorized user, and return the user's access token if the user is an authorized user; The information acquisition module is used to acquire the configuration information and menu data of the second system based on the access token if the access token returned by the second system is received. The second system fusion module is used to build the second system into a sub-application based on the configuration information and menu data of the second system, and add the menu data of the second system to the menu tree; The operation processing module is used to forward the operation request to the second system when the user triggers the operation request of the second system through the menu tree, so that the second system can perform the corresponding processing operation.

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 6.

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 6.

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 6.

Images