Application service fusion and user migration method and device, equipment and medium

Abstract

The invention relates to the technical field of big data and the field of financial science and technology, and discloses an application service fusion and user migration method, which comprises the following steps of: configuring and storing index information packets applied at two ends, synchronizing data to a third data table, configuring a data query source to read the data in the third data table, and integrating service logics at the two ends to generate fusion service. And executing migration operation of the user information, migrating the user information to the fusion service, and sending a request and querying data by judging whether the user information is migrated or not. According to the method, the index information packets of the mobile terminal application and the desktop terminal application are synchronized to the unified third data table, so that centralized management and consistency guarantee of data are realized; and by integrating service logics at two ends to generate a fusion service, the business processing of the system is more simplified and efficient. The smooth migration strategy of the user information ensures that the user experience is not influenced in the system integration process, and the user request processing is seamlessly connected.

Description

Technical Field

[0001] The present invention relates to the fields of big data technology and financial technology, and in particular to an application service integration and user migration method, device, equipment and storage medium. Background Art

[0002] In the current financial field, with the complexity of business and the diversification of applications, microservice architecture has gradually become one of the important technologies for application system development and maintenance. Microservice is a service-oriented architecture variant that splits a single application into a set of small service components that coordinate and cooperate with each other to ultimately provide users with complete services. Each microservice component focuses on a specific business function and has a high degree of independence and flexibility, allowing the system to be better expanded and maintained.

[0003] However, due to the different design styles, technical backgrounds, and business needs of architects, there are also large differences in the splitting strategies of microservices. In some scenarios, over-designed or unreasonable splitting methods gradually show problems, especially in the long-term maintenance and system evolution process.

[0004] Excessive splitting of microservices may lead to complex dependencies between service components in the system, increasing the difficulty of development and maintenance. Especially in cross-platform or cross-system application scenarios, coordination between different service components often requires additional management and scheduling mechanisms.

[0005] Due to historical reasons or the independent development and maintenance of different application systems, a large number of redundant resources have been created, especially in data storage, service scheduling, and user management. This redundancy not only affects the utilization of server resources, but also increases maintenance costs.

[0006] Data between different systems or application platforms are often isolated and lack effective integration mechanisms. This data isolation will result in the inability to communicate user data, transaction data, and indicator data in various systems, which in turn affects the overall business analysis and decision support of the system.

[0007] For systems that have been running for many years, how to achieve system integration and user migration without affecting the existing user experience has always been a major challenge facing the financial sector. The smooth migration of user data and the seamless integration of the system are not only related to the implementation of technology, but also require a balance in data consistency, system stability and service continuity. At present, there is a lack of effective reference solutions in the industry to deal with such complex user migration needs. Summary of the invention

[0008] The main purpose of the present invention is to provide an application service integration and user migration method, device, equipment and storage medium, aiming to solve the technical problem that the existing technology cannot effectively achieve unified data management and imperceptible user migration during multi-platform application system integration and user migration, resulting in increased system complexity, waste of resources and decreased user experience.

[0009] To achieve the above object, the present invention provides an application service integration and user migration method, comprising:

[0010] Configuring an indicator information package of the mobile application through a background processing module of the mobile application;

[0011] Storing the indicator information package of the mobile terminal application in a first data table of a mobile terminal application database;

[0012] Based on the indicator information package in the first data table, calling the background processing module of the desktop application to configure the indicator information package of the desktop application;

[0013] Storing the indicator information package of the desktop application in a second data table of the desktop application database;

[0014] Synchronize the indicator information packages in the first data table and the second data table to the third data table;

[0015] Configuring the data query sources of the mobile application and the desktop application to read data from the third data table;

[0016] Integrate the service logic of the mobile application and the desktop application to generate a fusion service;

[0017] Performing user migration operations to migrate user information from mobile applications and desktop applications to the fusion service;

[0018] Obtaining a user request, and determining whether user information in the user request has been migrated to the fusion service;

[0019] If the user information has been migrated to the fusion service, the user request is sent to the fusion service, and the fusion service queries the target indicator data from the third data table.

[0020] Furthermore, to achieve the above-mentioned purpose, the present invention provides an application service integration and user migration device, comprising:

[0021] A mobile terminal processing module, used to configure the indicator information package of the mobile terminal application through the background processing module of the mobile terminal application;

[0022] A mobile terminal database module, used to store the indicator information package of the mobile terminal application in a first data table of a mobile terminal application database;

[0023] A desktop processing module, configured to call a background processing module of a desktop application to configure an indicator information package of the desktop application based on the indicator information package in the first data table;

[0024] A desktop database module, used to store the indicator information package of the desktop application in a second data table of the desktop application database;

[0025] A data synchronization module, used for synchronizing the indicator information packages in the first data table and the second data table to a third data table;

[0026] A query configuration module, configured to configure the data query source of the mobile application and the desktop application to read data from the third data table;

[0027] A service fusion module, used to integrate the service logic of the mobile application and the desktop application to generate a fusion service;

[0028] A user migration module, used to perform user migration operations and migrate user information in mobile applications and desktop applications to the fusion service;

[0029] A request processing module, used to obtain a user request and determine whether the user information in the user request has been migrated to the fusion service;

[0030] A data query module is used to send the user request to the fusion service if the user information has been migrated to the fusion service, and the fusion service queries the target indicator data from the third data table.

[0031] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and an application service integration and user migration program stored in the memory and executable on the processor, wherein the application service integration and user migration program, when executed by the processor, implements the steps of the application service integration and user migration method as described above.

[0032] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, on which an application service fusion and user migration program is stored, and when the application service fusion and user migration program is executed by a processor, the steps of the application service fusion and user migration method described above are implemented.

[0033] Beneficial effects: The present invention relates to the fields of big data technology and financial technology, and discloses an application service integration and user migration method. The index information package is configured by the background management module of the mobile application, and is stored in the first data table of the mobile application database. The background management module of the desktop application is called to configure the index information package of the desktop application, and it is stored in the second data table of the desktop application database. Then, the index information packages in the first data table and the second data table are synchronized to the third data table, and the data query source of the mobile application and the desktop application is configured to read the data in the third data table, the service logic of the mobile application and the desktop application is integrated, and a fusion service is generated, and a user migration operation is performed, user information is migrated to the fusion service, user requests are obtained, and it is determined whether the user information has been migrated. If it has been migrated, a request is sent to the fusion service and data is queried from the third data table. The present invention realizes centralized management and consistency guarantee of data by synchronizing the index information packages of the mobile application and the desktop application to a unified third data table; and generates a fusion service by integrating the service logic at both ends, so that the business processing of the system is simplified and efficient. The smooth migration strategy of user information ensures that the user experience is not affected during the system integration process, and the user request processing is seamlessly connected. It not only simplifies the operation and maintenance management of multi-platform systems, but also reduces the redundancy of server resources and system complexity, improves system performance and resource utilization, and achieves the effect of efficient integration and imperceptible migration. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0035] Figure 1 A schematic diagram of an application environment of an application service integration and user migration method in an embodiment of the present invention;

[0036] Figure 2 A flow chart of an embodiment of the method for application service integration and user migration of the present invention;

[0037] Figure 3 A schematic diagram of functional modules of a preferred embodiment of the application service integration and user migration device of the present invention;

[0038] Figure 4 A schematic diagram of the structure of a computer device in one embodiment of the present invention;

[0039] Figure 5 FIG. 4 is another schematic diagram of the structure of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0040] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0041] The application service integration and user migration method provided by the embodiment of the present invention can be applied in Figure 1 In an application environment, the user terminal communicates with the server terminal through a network. The server terminal can configure the indicator information package through the user terminal using the background management module of the mobile terminal application, store it in the first data table of the mobile terminal application database, call the background management module of the desktop terminal application to configure the indicator information package of the desktop terminal application, and store it in the second data table of the desktop terminal application database. Then synchronize the indicator information packages in the first data table and the second data table to the third data table, configure the data query source of the mobile terminal application and the desktop terminal application to read the data in the third data table. Integrate the service logic of the mobile terminal application and the desktop terminal application, generate a fusion service, and perform user migration operations to migrate user information to the fusion service. Obtain a user request, determine whether the user information has been migrated, and if it has been migrated, send a request to the fusion service and query data from the third data table. The present invention realizes centralized management and consistency guarantee of data by synchronizing the indicator information packages of the mobile terminal application and the desktop terminal application to a unified third data table; generate a fusion service by integrating the service logic of both ends, so that the business processing of the system is simplified and efficient. The smooth migration strategy of user information ensures that the user experience is not affected during the system integration process, and the user request processing is seamlessly connected. It not only simplifies the operation and maintenance management of multi-platform systems, but also reduces the redundancy of server resources and the complexity of the system, improves system performance and resource utilization, and achieves the effect of efficient integration and imperceptible migration. Among them, the user end can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server end can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0042] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of the application service integration and user migration method provided by the present invention. It should be noted that although the logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that here.

[0043] like Figure 2 As shown, the application service integration and user migration method proposed in the present invention includes the following steps:

[0044] S10, configuring an indicator information package of the mobile application through a background processing module of the mobile application;

[0045] In this embodiment, the background processing module of the mobile application first needs to read data related to the indicator information package from a specific configuration data source (e.g., a database, a configuration file, or an external interface). The indicator information package may include multiple configuration items, such as indicator name, value, unit, display format, calculation rules, etc. These configuration items are used to determine how the mobile application displays and processes data.

[0046] The background processing module extracts the current indicator information configuration items related to the mobile terminal by connecting to the database or accessing the configuration file system. Parse the indicator configuration data read from the data source and convert it into a format recognizable by the mobile terminal for subsequent processing and display. If the data source is a dynamic configuration interface, the system may need to obtain the latest indicator configuration in real time through API requests.

[0047] The read indicator information package may contain a variety of different indicators, and the background processing module needs to parse it to extract specific configuration parameters. During the parsing process, it is necessary to confirm which indicators are required and which are optional, and classify them for subsequent operations.

[0048] Use predefined rules or configuration templates to gradually parse the content of each indicator and extract key configuration parameters, such as name, data type, unit, etc. Process the logic or calculation rules in the configuration to ensure that the relevant values ​​can be directly called or calculated in the application.

[0049] After the analysis is completed, the background processing module generates the indicator configuration items of the mobile application according to the analysis results. The configuration items are used to determine how the mobile application needs to process, display or calculate the indicator data during execution.

[0050] The parsed data is organized into a configuration format that meets the requirements of the mobile application, such as JSON or XML structure. The background processing module generates or updates the configuration file and saves the content of the indicator information package so that the mobile terminal can read it when the application starts.

[0051] After the configuration file is generated, the background processing module needs to deploy the configuration items to the mobile application so that the configuration can take effect during the actual operation. The deployment process may involve the coordination of multiple system modules and services.

[0052] The background processing module pushes the generated configuration file to the specified storage location of the mobile application, usually the application server or database. Update the configuration cache of the mobile application to ensure that the latest indicator information package configuration file can be accessed and loaded by the mobile application. If the application needs to dynamically update the configuration, it can reload the configuration file or restart some services to make the configuration change take effect immediately.

[0053] Example: In a financial data processing system, mobile applications need to display various key financial indicator data, such as user account balances, transaction records, investment returns, etc. These indicator information packages may be frequently updated according to business needs and market changes. The background management module can dynamically or regularly update these financial data indicator information packages, so that mobile applications can display the latest financial data in real time. For example, when the background updates the latest stock market price information, users of the mobile application can see these changes within a few seconds without manually refreshing or restarting the application.

[0054] By configuring the indicator information package through the background processing module of the mobile application, the indicator data can be centrally managed and flexibly configured. The indicator information can be quickly updated through the background module without making large-scale changes to the application, avoiding the risk of manual operation. It helps to improve the maintainability and scalability of the system, especially in large-scale application scenarios, and can effectively reduce the cost and time of system operation and maintenance.

[0055] S20, storing the indicator information package of the mobile terminal application in a first data table of a mobile terminal application database;

[0056] In this embodiment, before storing the indicator information package in the database, it must be ensured that the information package can be effectively processed and stored by the database. Usually, the indicator information package needs to be formatted. The indicator information package may contain data of multiple dimensions, such as the name, value, unit, update time, etc. of the indicator, so it needs to be formatted according to the storage structure of the database.

[0057] After receiving the configured indicator information package, the background processing module formats the information package according to the database storage structure (such as the fields and data types of the table) and converts it into a format that meets the database requirements. For example, the indicator name is mapped to the "Indicator Name" field of the table, the value is stored in the "Indicator Value" field, and the timestamp is stored in the "Update Time" field.

[0058] The premise of storing data is to establish a stable connection with the database of the mobile application. Usually, the application manages the connection with the database through a database connection pool or a database driver.

[0059] Use a database driver (such as JDBC, ODBC, or ORM framework) to establish a connection with the mobile application database. Database connection pools can be used to manage multiple concurrent database connections to ensure that storage requests can be processed effectively under high load.

[0060] When storing data in a database, you need to explicitly select the table to be stored. The "first data table" in the technical solution is used to store the indicator information package of the mobile application. The table may contain multiple fields, each of which corresponds to a different attribute in the indicator information package.

[0061] Through database query statements (such as SQL) or ORM framework APIs, specify the storage target as the "first data table". If the "first data table" does not exist, the system should have the ability to automatically create the table, or perform verification before storage to ensure that the table structure is compatible with the data format of the indicator information package.

[0062] Performing data storage operations is a key step in writing the formatted indicator information package to the database table. This process may involve insert, update, or batch write operations, depending on the business logic and requirements of the system.

[0063] Generate the corresponding SQL insert statement or use the API of the ORM framework to insert the processed data into the first data table. If it is necessary to update the existing indicator data, perform an "insert or update" operation (such as using the INSERT ON DUPLICATE KEYUPDATE statement in SQL) to ensure that the indicator information package is kept up to date in the database.

[0064] Data consistency and integrity need to be ensured during database operations, especially when multiple operations are involved. Transaction management can ensure that a set of database operations are either all successful or all rolled back, avoiding data inconsistency issues.

[0065] When storing data, start a database transaction to ensure data consistency throughout the storage process. Once the storage operation is completed, commit the transaction; if an error or exception occurs during the process, rollback the transaction to prevent incomplete data from being written to the database.

[0066] Example description: In financial applications, mobile applications usually need to display a large amount of dynamic indicator data, such as real-time exchange rates, fund net value, user account balance, etc. These data will be frequently updated according to market changes and user operations. Storing these financial indicator information packages in the first data table of the mobile application database can achieve persistent management and fast query of these data.

[0067] For example, when a user logs into a mobile banking application, the system reads the user's account balance and latest transaction records from the first data table. The backend management module regularly updates these indicator information packages to ensure that the financial data the user sees is always the latest. This storage mechanism not only improves the user's operating experience, but also ensures the accuracy and consistency of financial data through transaction management.

[0068] By storing the indicator information package of the mobile application in the first data table, the system realizes the centralized management and persistent storage of the mobile application configuration data. It ensures that the configuration data can be quickly read during the application operation, and when the indicator information is updated, the real-time and consistency of the data can be guaranteed. Through transaction management technology, the system ensures the integrity of the data during the storage process and avoids the problem of data inconsistency caused by operation interruption.

[0069] S30, based on the indicator information package in the first data table, calling the background processing module of the desktop application to configure the indicator information package of the desktop application;

[0070] In this embodiment, the indicator information package stored in the first data table is read from the database of the mobile terminal application. The information package includes various configuration data of the mobile terminal application, which need to be further transferred to the desktop terminal application.

[0071] The stored indicator information package is read from the first data table using a database query statement (such as an SQL query). Typically, this data is accessed through an API call or a database interface and converted into a processable format (such as JSON or XML). The indicator information package after reading needs to be parsed as necessary to extract specific indicator items, such as name, value, format, etc.

[0072] The indicator information package read from the first data table may contain a variety of data, which needs to be processed and parsed to ensure that the data can be used by the desktop application. During the parsing process, the data format and structure can be adjusted as necessary.

[0073] Process the read indicator information package according to the format and requirements of the desktop application. For example, convert the data from JSON format to XML format, or convert structured data to key-value pairs. In the process of parsing the data, it is necessary to confirm which indicator information can be used directly and which needs to be converted, calculated, etc. before it can take effect in the desktop application.

[0074] In order to apply the indicator information package read and processed from the mobile application to the desktop application, it is necessary to call the background processing module of the desktop application. This module is responsible for receiving the indicator information transmitted from the mobile terminal and configuring it in the desktop application.

[0075] Establish communication with the background processing module of the desktop application through API calls, remote procedure calls (RPC) or HTTP requests. Call the interface of the desktop application and pass the parsed indicator information package. The background processing module of the desktop will receive this information and further process the data according to its own processing logic.

[0076] After receiving the indicator information package from the mobile terminal, the background processing module of the desktop application needs to apply this information to the configuration of the desktop application. Specific configuration items may include the display method and calculation method of the indicator.

[0077] In the background processing module of the desktop application, the system stores the received indicator information package in the configuration database or configuration file of the desktop. According to the needs of the desktop, the system may need to perform some pre-processing operations on the received configuration items, such as data verification, format conversion, default value processing, etc. Finally, the background processing module of the desktop application saves the configuration results to the database or file system to ensure that the new configuration takes effect in the application.

[0078] After the configuration is complete, you need to ensure that the configuration items have been successfully applied in the desktop application and that the generated configuration results are correct. The background processing module may return a confirmation message for further operation.

[0079] After the configuration is completed, the background processing module of the desktop application returns a success or failure status message. If the configuration fails, the system may need to perform error handling or retry. If the configuration is successful, the background processing module will update the configuration status and may return it to the management system of the mobile application to ensure data consistency between the two.

[0080] Example description: In the application scenarios in the financial field, mobile and desktop applications usually need to process consistent indicator data, such as users' investment portfolios, market trend analysis, stock prices and other dynamically changing data. The system can call the desktop processing module based on the configuration of the mobile application to ensure that the data and configuration of the desktop and mobile terminals are consistent. For example, when a user performs investment analysis on the mobile terminal, the desktop application can synchronously display the same financial data and market trend analysis to ensure the consistency of the user experience on different platforms. Through this configuration synchronization mechanism, financial institutions can provide users with a more stable and consistent multi-platform service experience and simplify cross-platform configuration management operations.

[0081] By calling the background processing module of the desktop application based on the indicator information package in the first data table, the system realizes configuration synchronization and data sharing between the mobile terminal and the desktop application. It allows flexible sharing of configuration data between the mobile terminal and the desktop terminal, ensuring that users of different platforms can use consistent indicator information packages, thereby improving the user experience. At the same time, through the effective calling of the background processing module, the system can dynamically adjust the configuration of the desktop terminal according to the needs, ensuring that the desktop application can respond to the latest configuration requirements in a timely manner.

[0082] S40, storing the indicator information package of the desktop application in a second data table of the desktop application database;

[0083] In this embodiment, before storing the data, the indicator information package of the desktop application needs to be formatted according to the structure of the desktop application database. The information package may contain multiple different configuration items, such as indicator name, value, unit, update time, etc. These configuration items must match the fields in the second data table.

[0084] The background processing module first converts the indicator information package of the desktop application according to the table structure of the desktop database. For example, it determines which fields store indicator names, which fields store data values, and which fields are used to record timestamps. After formatting, the generated indicator information will be converted into a format that meets the requirements of the database, usually each field in the table structure corresponds to a specific configuration item.

[0085] In order to store data, the system needs to establish a connection with the desktop application's database. The connection may be managed through a database driver or API.

[0086] Use a database driver (such as JDBC, ODBC) or an ORM framework (such as Hibernate) to connect to the database of the desktop application. Ensure that after the connection is established, the system can access and operate the tables in the database, especially the target storage table "second data table". The database connection pool can be used to manage concurrent requests and ensure stable connections during large-scale storage operations.

[0087] When performing a storage operation in a database, the correct storage target table must be selected. Here, the "second data table" is a table specifically used to store the indicator information package of the desktop application, and the table contains multiple fields for storing different indicator data.

[0088] Use database query languages ​​(such as SQL) or ORM frameworks to specify the target table as the "second data table". Check whether the second data table exists. If not, the system can automatically create the table or prompt the administrator to create it. Check whether the table structure matches the data format to be stored, and ensure that the field definition and data type are consistent with the indicator information to be stored.

[0089] Data storage is the process of writing the formatted indicator information package to the secondary data table. This may involve inserting new data, updating existing data, or batch write operations, depending on the needs of the system.

[0090] The processed indicator information is inserted into the corresponding fields of the second data table by performing storage operations through SQL insert statements (such as INSERT INTO) or ORM API interfaces. If an existing indicator information package needs to be updated, an "insert or update" statement (such as INSERT ON DUPLICATE KEYUPDATE) can be used to ensure that the data in the desktop application database is always kept up to date.

[0091] In order to ensure the consistency and integrity of data, especially when there may be interruptions or errors in the storage process, the system needs to use database transaction management to ensure the integrity of the data. Transactions ensure that all storage operations are either fully successful or rolled back in case of failure.

[0092] Before performing a storage operation, start a database transaction (BEGIN TRANSACTION). After the storage is completed, commit the transaction (COMMIT). If an error occurs during the operation, the system rolls back the transaction (ROLLBACK) to avoid inconsistencies caused by partial data being written to the database.

[0093] Example description: In the financial field, desktop applications usually need to display complex financial data indicators, such as stock prices, return on investment, risk assessment, etc. The system can store these financial indicator information packages in the database of the desktop application (i.e., the second data table). For example, when the background of a financial institution updates the latest stock price and market volatility data, these data will be stored in the database of the desktop application in the form of indicator information packages. When the desktop application is loaded, it can read these latest indicator data from the second data table and display them to the user.

[0094] By storing the indicator information package of the desktop application in the second data table, the system can efficiently manage and maintain the configuration data of the desktop application. This ensures that the indicator information package of the desktop application is persistently stored, which is convenient for subsequent query and use. Through transaction management technology, the reliability of storage operations and data consistency are guaranteed, avoiding configuration errors or losses caused by partial storage failure or interruption.

[0095] S50, synchronizing the indicator information packages in the first data table and the second data table to the third data table;

[0096] In this embodiment, the first step of the synchronization operation is to read all stored indicator information packages from the first data table of the mobile application and the second data table of the desktop application respectively. These information packages may contain relevant configuration and indicator data in the respective application systems.

[0097] Using a database query statement (such as a SQL SELECT statement) or an ORM (object relational mapping) framework, the indicator information package is read from the first data table and the second data table respectively. The reading operation can be performed according to certain conditions, such as the latest data or data updated within a specified time period.

[0098] The indicator information packets read from the first data table and the second data table may contain the same or overlapping indicator data. In order to ensure the consistency of the data, these same indicators need to be merged to avoid repeated storage or conflict.

[0099] Compare the indicator information packages read from the two data tables and determine which indicators are the same based on predefined standards (such as indicator name, data source, update time, etc.). For the same indicator information packages, merge their contents, such as retaining the latest value or adopting a higher priority configuration. The merge can be performed based on custom rules, such as data version control, timestamp comparison, etc.

[0100] Different indicator information packages refer to indicators that exist in the first data table but not in the second data table, or exist in the second data table but not in the first data table. For these different indicator information packages, their respective characteristics need to be retained and synchronized to the third data table.

[0101] Unmatched indicator information packages (ie, different indicators) are marked as independent entries and are not merged. The characteristics of each different indicator information package, such as its name, value, unit, etc., are retained and prepared for synchronization to the third data table.

[0102] Once the same and different indicator information packages are processed, these data need to be stored in the third data table. The third data table is a new storage location for unified management of all indicator information packages on the mobile and desktop terminals.

[0103] The processed indicator information package is written into the third data table through a database insert statement (such as SQL INSERT INTO statement) or an ORM framework. For the merged indicator information package, insert or update the existing record to ensure that the data in the third data table is up-to-date and complete. For different indicator information packages, insert them into the third data table as new records.

[0104] Synchronization operations involve reading, processing, and writing new data from multiple data sources, which requires ensuring the transactional nature of the operation. Through transaction management, the entire synchronization process can be guaranteed to be either completely successful or rolled back when an error occurs, preventing some data from being synchronized incorrectly.

[0105] Before starting the synchronization operation, start a database transaction (BEGIN TRANSACTION) to ensure that all synchronization operations are performed in one transaction. Once all operations are successfully completed, commit the transaction (COMMIT). If an error or exception occurs midway, roll back the transaction (ROLLBACK) to avoid inconsistencies caused by partial data writing. At the same time, record the log of each synchronization operation to facilitate subsequent debugging and troubleshooting.

[0106] Example: In the financial field, desktop and mobile applications process different user data and market indicator data, such as fund net value, stock price, risk assessment, etc. In order to integrate these scattered data, the system needs to synchronize these indicator information packages into a unified third data table.

[0107] The system can read different indicator information packages from the desktop and mobile applications respectively, and merge the same indicator data. For example, the desktop application and the mobile application may display the yield data of the same fund at the same time. The system will merge these data, keep the latest data, and store them in the third data table. For indicators unique to the desktop (such as detailed risk assessment reports) or user interaction data unique to the mobile terminal, they are stored as independent records in the third data table. In this way, financial institutions can provide users with a unified data display interface, reducing the trouble of users obtaining inconsistent data on different platforms.

[0108] By synchronizing the indicator information packages in the first data table and the second data table to the third data table, the system realizes the centralized management of multi-source data. The operation of merging the same indicator information package ensures the consistency of data, while the processing of different indicator information packages retains the characteristics of each application. Through the unified third data table, the system can reduce data redundancy, improve query efficiency, and provide a unified data source for subsequent data display and analysis. Transaction management during the synchronization process ensures the reliability and integrity of data synchronization operations and avoids the risk of data inconsistency or loss.

[0109] S60, configuring the data query source of the mobile application and the desktop application to read data from the third data table;

[0110] In this embodiment, before reconfiguring the data query source, the system needs to identify and record the data query source currently used by the mobile application and the desktop application. This is to ensure that the current system operation status will not be affected when making a new configuration, and can be rolled back or compared as needed.

[0111] The system checks the configuration files or databases of mobile and desktop applications to determine the existing data query source. The system records the current configuration for subsequent comparison and verification operations, or for rollback when necessary.

[0112] The new data query source needs to point to the third data table, which is a data source that integrates all indicator information of mobile and desktop applications. Generating new configuration items can ensure that both mobile and desktop terminals can read information from the same data table.

[0113] In the system configuration file or database, a new query source configuration item is generated or updated to update the query source that originally pointed to each independent data table to point to the third data table. The new configuration item needs to include the connection information, access rights, and query field definition of the third data table to ensure that the data can be read correctly.

[0114] Once a new query source configuration item is generated, it must be updated in the configuration files or configuration databases of the mobile application and desktop application to ensure that these two systems can use the new query source.

[0115] For mobile and desktop configuration files, the system can update the new query source configuration by modifying the storage path of the configuration file or writing it directly to the database. For the configuration database, the query source field in the configuration table can be updated through SQL statements or ORM tools. Make sure that after the configuration is updated, the new query source points to the third data table and the old query source is no longer used.

[0116] Before the new query source configuration takes effect, the system needs to verify that both the mobile and desktop applications can correctly read data from the third data table. The verification process can be completed by testing the query and comparing the data reading results.

[0117] Execute a test query to try to read data from the third data table and compare whether the read data is consistent with the expected results. In the mobile and desktop applications, verify whether the new query source correctly points to the third data table and ensure that the application can correctly display the indicator information obtained from the third data table. If the verification passes, the new query source configuration can be officially effective; if there is a problem, the system can roll back to the previous configuration.

[0118] Mobile and desktop applications may run on multiple nodes or servers, so the new query source configuration needs to be synchronized to all relevant service nodes to ensure that the entire system can uniformly read the data in the third data table.

[0119] Use configuration management tools or scripts to synchronize the updated query source configuration files to all service nodes. Ensure that the configuration files of each node are consistent with the central configuration, or synchronize the query source configuration in the configuration database. If necessary, reload the configuration or restart the relevant services so that the new query source configuration takes effect on all service nodes.

[0120] Example description: In the financial field, mobile and desktop applications often need to access real-time updated financial data, such as exchange rates, stock prices, investment portfolios, etc. By configuring the data query source on the mobile and desktop terminals to read data from a third data table, financial institutions can achieve centralized management of data sources.

[0121] For example, when the latest stock market data is updated in the background, this data will be stored in the third data table. When mobile users view their portfolios through the app, the system will read the latest stock prices directly from the third data table. Similarly, desktop applications will also obtain data from the same data source to ensure that users see consistent financial information on different platforms. Through this unified query source configuration, financial institutions can significantly reduce data synchronization issues, improve system response speed, and provide users with a consistent multi-platform service experience.

[0122] By configuring the data query source of mobile and desktop applications to read data from the third data table, the system realizes unified management and centralized query of data sources. It effectively reduces data redundancy and avoids errors caused by inconsistent data between different platforms. The configuration of unified query source simplifies the data management process and improves the query efficiency and maintainability of the system. By synchronizing the configuration to all service nodes, it ensures that both mobile and desktop applications can obtain consistent indicator information from the same data source, further improving the stability and consistency of the system.

[0123] S70, integrating the service logic of the mobile application and the desktop application to generate a converged service;

[0124] In this embodiment, the first step in integrating service logic is to analyze and understand the service logic of each mobile and desktop application. This includes user request processing flow, data storage and query methods, business processing logic, etc. The service logic of each platform may be different, so detailed analysis is required based on their respective characteristics.

[0125] Collect and analyze the existing service logic of mobile and desktop applications to understand how each platform handles user requests and performs business processing. Identify the common parts (such as business rules, user permission control) and independent parts (such as different user interface interaction methods) in the applications on both ends.

[0126] After the analysis is completed, it is necessary to extract the common business logic in the mobile and desktop applications. The common part is the business functions that need to be executed on both ends, such as data verification, user authentication, basic data processing, etc. These common business logics will serve as the core content of the integrated service.

[0127] Extract the duplicate service logic in mobile and desktop applications and design them into modules that can be reused in the converged service. For example, user identity authentication, data query logic, error handling logic, etc. can be integrated into the converged service as independent modules.

[0128] In addition to common business logic, mobile and desktop applications may also have some differentiated service logic, such as different UI interactions, terminal adaptation, data processing procedures, etc. These differentiated logics need to be retained and properly processed in the integrated service to ensure the experience of different terminal users.

[0129] Define interfaces or configuration items for differentiated logic so that it can dynamically adapt to different platforms in converged services. For example, mobile applications may focus on low bandwidth and real-time performance, while desktop applications focus on batch data processing and complex calculations. Design extension points to support differentiated requirements of mobile and desktop applications through configuration, policy, or plug-in mode in converged services.

[0130] Converged services need to define a unified interface to serve both mobile and desktop applications. The interface should be compatible with requests from both platforms and be able to handle differences between platforms through an adaptation layer to ensure that converged services can flexibly respond to the needs of different terminals.

[0131] Design a unified service interface to ensure that mobile and desktop clients can call the converged service through the same interface. For example, design a service interface based on RESTful API to support HTTP requests from different platforms, and return a unified response format after the converged service performs business processing. The interface should support scalability so that new application platforms (such as the Web client) can be added in the future without significantly modifying the converged service.

[0132] Once the logical design and interface definition of the converged service are completed, the system needs to actually generate and deploy the converged service. The generated converged service should have the ability to uniformly process mobile and desktop application requests while retaining the differentiated logic of both ends.

[0133] Write service code, integrate common business logic and differentiated logic, and implement interaction with different platforms through interfaces. Use containerization technology (such as Docker) or microservice architecture to deploy converged services to ensure good scalability and high availability. After the converged service is deployed, dynamically route user requests to the converged service through a service gateway or load balancing, thereby uniformly processing requests from mobile and desktop terminals.

[0134] After the converged service is generated, functional verification is required to ensure that it can correctly handle requests from mobile and desktop applications. Verification should cover all parts of the business process, including request processing, data query, user authentication, etc.

[0135] In the test environment, initiate requests from the mobile terminal and the desktop terminal respectively to verify that the converged service can normally receive and process requests from different terminals. Test the performance and stability of the converged service to ensure that it can efficiently handle concurrent requests and there is no obvious performance loss when processing differentiated logic. Record the test results to troubleshoot and resolve potential errors or performance bottlenecks.

[0136] Example: In the financial field, mobile and desktop applications may provide different services to users. For example, mobile applications focus on real-time stock quotes and lightweight trading operations, while desktop applications are more inclined to batch data analysis and portfolio management. The system can integrate the service logic of mobile and desktop applications to generate a unified integrated service.

[0137] For example, when a user queries stock prices through a mobile terminal, the fusion service can query the backend data through a unified interface and return the real-time price; and when a desktop user initiates a complex portfolio analysis request, the fusion service can also call the backend analysis module through the same interface. Through this integration, financial institutions can provide users with a consistent service experience, simplify system maintenance, and reduce development and operation costs.

[0138] By integrating the service logic of mobile and desktop applications and generating converged services, the system implements a unified service processing mechanism across platforms. Converged services not only simplify the business logic that was originally repeated on multiple platforms, but also enhance the scalability and maintainability of the system by defining a unified interface. The reasonable processing of differentiated service logic ensures the consistency and flexibility of the user experience of each terminal. Ultimately, converged services improve the overall performance of the system and reduce maintenance costs.

[0139] S80, performing a user migration operation to migrate user information in the mobile application and the desktop application to the fusion service;

[0140] In this embodiment, before migrating user information, it is necessary to collect user information from the mobile application and the desktop application respectively. The user information may include user ID, user name, account information, preference settings and other related data. The key to this step is to ensure that all necessary user data is accurately extracted so that the migration can be complete and error-free.

[0141] Collect all user information that needs to be migrated by querying the user database of mobile and desktop applications. This data can be obtained through SQL statements, API interfaces, or export tools. Filter out the user information that needs to be migrated based on business needs to ensure that the migration scope meets expectations. For inactive or expired users, you can choose not to migrate.

[0142] To ensure the smooth progress of the migration process, the system needs to distinguish which user information has been successfully migrated to the converged service and which has not yet been migrated. Marking the status of user information helps monitor the entire migration process and avoid duplicate migration or omissions.

[0143] Add a migration status field (such as "migrated" or "not migrated") to each user information record. These fields can be stored in the user information database or in a dedicated migration log file. When the migration is successful, update the status of the user information to "migrated"; if the migration fails, keep the "not migrated" status for reprocessing.

[0144] In order to optimize the migration process, it is very important to formulate a reasonable user migration strategy. The strategy includes how to perform migration operations in batches or time periods, or set the migration order according to user types to minimize the impact on the system and ensure user experience.

[0145] Determine the batches and time periods for migration based on system load and business needs. For example, perform large-scale migration during off-peak periods, or prioritize high-activity users based on user activity. When formulating policies, you can set priorities based on user types (such as VIP users and ordinary users) to ensure that migration of key users is completed first.

[0146] Migrating user information is the core of this step. User information needs to be migrated from the original database of mobile and desktop applications to the integrated service. Migration operations usually involve data format conversion and verification to ensure that user data can be used correctly in the new system.

[0147] Export user information from mobile and desktop applications in a predetermined format by writing scripts or using migration tools. Use API interfaces, database replication, data import tools, etc. to import user information in batches into Fusion Services. Before data import, it may be necessary to perform necessary format conversion or field mapping to ensure that the migrated data meets the data structure requirements of Fusion Services. Verify the migrated user information to ensure data integrity and accuracy.

[0148] After the migration operation is completed, a data consistency check is required to ensure that the migrated user information in the fusion service is consistent with the data in the original system. This step is to ensure that there is no data loss or error during the migration process.

[0149] Compare user data before and after migration to ensure that each user's key information (such as user ID, account balance, personal settings, etc.) is consistent with the original data in the fusion service. Use database logs or difference detection tools to compare data changes and troubleshoot possible missing or erroneous data during migration.

[0150] During or after the migration, system errors or performance issues may occur, so a rollback mechanism is required. When the migration process fails or the data in the fusion service is found to be incorrect, the system should be able to quickly roll back the migrated user information to the original system to ensure service stability.

[0151] At the beginning of the migration operation, a backup of the user information of the original system is generated for quick recovery in case of problems. If an error is detected during the migration process or a failure occurs in the fusion service, a rollback operation is automatically triggered to restore the migrated user information to the original system on the mobile or desktop side. Ensure that the rollback mechanism is fast and seamless enough that users will not notice any service interruption.

[0152] Example: In the financial sector, the migration of user data usually involves sensitive data such as account information, transaction records, and investment portfolios. The system can migrate user account information and transaction data in mobile applications and desktop applications to the converged service. For example, when a financial institution is ready to manage customer account information in a unified manner, the system can gradually migrate user account data from mobile and desktop databases to the new converged service based on the migration strategy. After the migration is complete, users can access their account information through a unified service platform, regardless of whether they use mobile or desktop applications. This migration operation not only improves the user experience, but also simplifies cross-platform data management.

[0153] By performing user migration operations, the system can smoothly migrate user information from mobile and desktop applications to the converged service, ensuring the integrity and consistency of user information and minimizing the impact on system performance through batch migration or real-time migration strategies.

[0154] S90, obtaining a user request, and determining whether the user information in the user request has been migrated to the fusion service;

[0155] In this embodiment, the system first needs to capture user requests. User requests can come from mobile or desktop applications, and usually include user identity information, requested operation type, and other relevant request data. User requests are the basic unit of interaction between the system and the user, and users perform operations through the request, such as querying data, submitting forms, and conducting transactions.

[0156] When a user initiates a request through a mobile or desktop application, the system captures the user's request data through an API interface or a request listener. When obtaining a request, the system parses the request and extracts relevant information, such as user ID, request content, timestamp, etc.

[0157] After receiving the user request, the system needs to parse the user information in the request. User information usually includes user ID, account information, permission level, etc. This information is an important basis for determining whether the user has been migrated to the integrated service.

[0158] Parse the data packet or request body of the user's request and extract the user's key information, usually including the user's unique identifier (such as user ID, user name). Based on the request type, further extract other information related to the current request, such as the specific operation requested or the query content.

[0159] After parsing the user information, the system needs to determine whether the user information has been migrated to the fusion service. Usually, the user migration status will be marked accordingly in the system, and the judgment logic can be completed by looking up the user's migration record or database status.

[0160] The system checks the migration status of the user by querying the database or cache that stores the user information. The migration status of the user can be stored in a special migration log to record whether each user has been successfully migrated to the fusion service. Query the "Migration Status" field in the database or cache. If the field is marked as "Migrated", it means that the user information has been successfully migrated. If the user information exists in the user database of the fusion service and the migration is marked as "Completed", it is determined that the user has been migrated.

[0161] If the system determines that the user information has not been migrated to the converged service, the user request needs to continue to be processed by the old mobile or desktop service. The system can route the request to the original service to ensure that the requests of non-migrated users are not affected.

[0162] When it is detected that the user information has not been migrated, the system can forward the request to the old service system for processing. For example, the old mobile or desktop database can still provide services for the user. The system can call the original API interface or business logic to continue processing the user's operation request.

[0163] If the user information has been migrated to the fusion service, the user request will be processed by the fusion service. The system needs to redirect the request to the fusion service to ensure that the migrated users can enjoy the service functions of the new system.

[0164] When it is detected that the user information has been migrated, the system will forward the user request to the Fusion Service. The Fusion Service processes the request through the corresponding business logic and returns the result. During the request processing, the Fusion Service will perform corresponding operations based on the user's identity and request content, and query or operate the Fusion Service database.

[0165] Example: In a financial services application, users may perform operations through mobile and desktop terminals, such as viewing account balances, transaction history, investment portfolios, etc. During the process of migrating users to the converged service, the system needs to be able to handle requests from both migrated and non-migrated users.

[0166] For example, when a user inquires about his account balance through a mobile terminal, the system first captures the user request and parses the user information. The system checks whether the user has been migrated to the fusion service. If the user information has been migrated, the system will forward the request to the fusion service, which will query the latest account information and return it to the user; if the user has not been migrated, the system will route the request to the old mobile service to continue processing the user's request. Through this process, financial institutions can ensure that user services will not be affected during the migration of user information, improve customer satisfaction and ensure a smooth transition of the system.

[0167] By obtaining user requests and determining whether user information has been migrated to the fusion service, the system can seamlessly process user requests during the migration process. Regardless of whether user information has been migrated, the system can ensure that user requests are processed quickly and correctly. For migrated users, the system can redirect requests to the fusion service to enjoy more efficient services; for non-migrated users, the system can maintain the normal operation of the old system to avoid service interruptions during the migration process. Ultimately, the solution improves system stability and user experience through a flexible migration judgment and processing mechanism.

[0168] S100: If the user information has been migrated to the fusion service, the user request is sent to the fusion service, and the fusion service queries the target indicator data from the third data table.

[0169] In this embodiment, the system first needs to check the migration status of the user information to determine whether the user has been migrated to the fusion service. This step ensures that only the migrated user information will use the fusion service for subsequent data query operations.

[0170] After receiving a user request, the system determines whether the user has been migrated by querying the migration status of the user information (such as the migration mark stored in the database or the status in the cache). If the user information is marked as "migrated", it means that the user has been successfully migrated from the old service to the fusion service, and subsequent requests can be processed by the fusion service.

[0171] If the user information is confirmed to have been migrated to the Fusion Service, the system needs to forward the user's request to the Fusion Service to process the request. As the core module of the new system, the Fusion Service can process all requests of the migrated users.

[0172] The system redirects or forwards the user's request from the old system to the entrance of the fusion service through the internal routing mechanism or API call. The API interface of the fusion service receives the user request and parses the content in the request, such as query conditions, operation type, etc., and prepares to execute the corresponding business logic.

[0173] After receiving the user request, the fusion service needs to parse the query conditions in the request. These conditions usually include the specific indicator data that the user wants to obtain, filtering conditions (such as time range, data type), etc. Parsing the request is the prerequisite for data query.

[0174] The fusion service extracts the query conditions in the user request, such as query target, time range, data classification, etc., by parsing the HTTP request body or request parameters of the request. The parsed query conditions will be used to construct subsequent database query statements or filter conditions to ensure that the system can accurately obtain the required indicator data.

[0175] The fusion service obtains the target indicator data from the third data table according to the parsed query conditions. The third data table stores all indicator information synchronized from the mobile terminal and the desktop terminal, so it is the main data source for system queries.

[0176] The system uses SQL query statements or ORM framework to retrieve corresponding indicator data from the third data table based on the query conditions in the user request. Data query may involve multiple condition filtering operations, such as based on user ID, query time period or indicator category, to ensure that the query results meet user needs.

[0177] Once the system successfully queries the target indicator data from the third data table, the fusion service needs to return the query results to the user who initiated the request. This process ensures that the user can obtain the required information in a timely manner.

[0178] Fusion services format query results, usually converting them into JSON or XML format, so that user applications can parse and display them. Through the API interface of the fusion service, the query results are returned to the user's terminal device (mobile or desktop) for the user to view.

[0179] In order to facilitate subsequent debugging and monitoring, the system needs to record the processing of each user request. This includes information such as request content, query conditions, query time, and returned results. Logging is essential for analyzing system performance and troubleshooting.

[0180] Fusion Services automatically records detailed information about each user request, such as the timestamp of the request, the user ID of the request, the query conditions, and the query results. Log information can be stored in a database or log file for operation and maintenance personnel to analyze or troubleshoot problems in the system.

[0181] Example description: In financial application scenarios, users may initiate query operations to view indicator data such as account balances, transaction records, or market trends. For example, when a user queries an investment portfolio through a mobile application, the system will first check whether the user information has been migrated. If the user has been migrated to the fusion service, the system forwards the user request to the fusion service. The fusion service parses the user's query conditions (such as investment category, time range), retrieves relevant investment data from the third data table, and finally returns the query results to the user. Through this mechanism, financial institutions can provide customers with efficient and accurate cross-platform query services, improve user experience and ensure data consistency.

[0182] The present invention relates to the fields of big data technology and financial technology, and discloses an application service fusion and user migration method. The index information package is configured by the background management module of the mobile application, and stored in the first data table of the mobile application database. The background management module of the desktop application is called to configure the index information package of the desktop application, and the index information package is stored in the second data table of the desktop application database. Then, the index information packages in the first data table and the second data table are synchronized to the third data table, and the data query source of the mobile application and the desktop application is configured to read the data in the third data table, the service logic of the mobile application and the desktop application is integrated, and a fusion service is generated, and a user migration operation is performed, user information is migrated to the fusion service, a user request is obtained, and it is determined whether the user information has been migrated. If it has been migrated, a request is sent to the fusion service and data is queried from the third data table. The present invention realizes centralized management and consistency guarantee of data by synchronizing the index information packages of the mobile application and the desktop application to a unified third data table; and generates a fusion service by integrating the service logic at both ends, so that the business processing of the system is simplified and efficient. The smooth migration strategy of user information ensures that the user experience is not affected during the system integration process, and the user request processing is seamlessly connected. It not only simplifies the operation and maintenance management of multi-platform systems, but also reduces the redundancy of server resources and system complexity, improves system performance and resource utilization, and achieves the effect of efficient integration and imperceptible migration.

[0183] In one embodiment, the above S70 includes:

[0184] S701, integrating the business logic of the mobile application and the desktop application to generate a unified business processing logic;

[0185] S702, integrating the data access methods of the mobile application and the desktop application to generate a unified data access interface to access the data in the third data table;

[0186] S703, integrating the user request processing logic of the mobile application and the desktop application into a unified request processor, wherein the request processor is used to parse and process user requests from the mobile application and the desktop application;

[0187] S704, deploying a fusion service, wherein the fusion service accesses the data in the third data table through a unified data access interface and processes user requests from the mobile application and the desktop application.

[0188] In this embodiment, the mobile and desktop applications may each have different business processing logics to adapt to different user interaction methods and data processing requirements. In order to create a converged service, the business logics of the applications on both ends need to be integrated into a unified business processing logic. This process ensures that the business functions of the two platforms can run in a unified system, avoiding repeated design and development.

[0189] Analyze the existing business logic of mobile and desktop applications to find out the common parts (such as common user authentication, data processing flow, etc.) and the differences (such as UI adaptation or terminal-specific processing logic). Extract and design the common business logic into reusable modules and integrate them into the unified business processing logic. Modularize the differentiated logic to allow the business processing functions of specific platforms to be loaded in the converged service through configuration or plug-in.

[0190] Mobile and desktop applications may use different methods to access data (such as database structure, API call method, etc.). In order to ensure that the fusion service can access the unified data source (that is, the third data table), it is necessary to integrate these data access methods and generate a unified data access interface. The unified data access interface ensures that applications on both ends can share the same data source.

[0191] Analyze the existing data access logic for mobile and desktop terminals to find out the differences in access methods, such as different database connection methods or API structures. Design a unified data access interface to shield the access differences between different platforms and ensure that both mobile and desktop terminals access the third data table through the same interface. The data access interface ensures efficient and secure access to the third data table by encapsulating the functions of the data access layer. The interface should support basic operations such as addition, deletion, modification and query, and have good scalability.

[0192] The user request processing logic of mobile and desktop applications may be different, which is manifested in differences in request format, verification process, response time, etc. By integrating these logics, the system can generate a unified request processor to parse and process user requests from different platforms to ensure service consistency.

[0193] Analyze the user request processing logic of mobile and desktop terminals, and understand the processing differences between different platforms, such as request parameter format, verification process, timeout control, etc. Design a unified request processor that can accept requests from both ends and execute appropriate processing procedures based on conditions such as request type and user identity. The request processor needs to support cross-platform parsing functions to ensure that requests from both mobile and desktop terminals can be correctly parsed and processed. Strategy mode or plug-in mechanism can be used to adapt to the special needs of different platforms.

[0194] When the business logic, data access interface and user request processing logic are integrated, the system needs to deploy these integrated functional modules as a converged service. The converged service not only provides unified business processing and data access, but also can handle user requests from mobile and desktop terminals.

[0195] Write and deploy the fusion service to ensure that it can connect to the third data table through a unified data access interface and handle user requests from mobile and desktop terminals. The fusion service can be deployed through containerization (such as Docker) or microservice architecture to improve the scalability and flexibility of the system. The load balancing mechanism should be configured to ensure that requests from different platforms can be processed efficiently. The fusion service runs in parallel with the original service to ensure that the system remains stable during the switch process and supports the coexistence of the new and old systems.

[0196] This embodiment integrates the service logic of mobile and desktop applications to generate converged services, and the system successfully implements unified business processing across platforms. The converged service effectively avoids the repeated development and maintenance work of two independent platforms, and simplifies the data management and operation process of the system through a unified data access interface. The uniformity of user request processing enables users to enjoy a consistent service experience on different terminal devices, while improving the scalability and maintainability of the system. The deployment of converged services enables the system to flexibly respond to requests from different terminals, improving the overall performance of the system and user satisfaction.

[0197] In one embodiment, the above S50 includes:

[0198] S501, classifying the indicator information packages in the first data table and the second data table into the same indicator information packages and different indicator information packages;

[0199] S502, merging the same indicator information packages according to a preset priority rule to generate a single indicator information entry, and storing the indicator information entry in the third data table;

[0200] S503: Store the different indicator information packages into the third data table.

[0201] In this embodiment, the first step of the synchronization operation is to classify the indicator information packages from the first data table and the second data table. The same indicator information package refers to indicators with the same content or consistency in the two data tables, and different indicator information packages have differences in content or definition.

[0202] The system extracts all indicator information packets from the first data table and the second data table, and compares their contents (such as indicator name, value, timestamp, etc.) one by one. Use algorithms (such as hash comparison or field matching) to automatically detect which information packets are the same in the two tables and which are different. Mark the same indicator information packets into one category and the different indicator information packets into another category to prepare for subsequent processing.

[0203] The same indicator information packages need to be merged according to the preset priority rules to ensure that the data in the third data table is unique and standardized. For example, when the same indicator information package exists in both the first data table and the second data table, the priority rules determine which data source to use. The result of the merge is a unique indicator information entry.

[0204] Determine the priority of merging based on the business rules of the system. For example, you can select the merged content based on the weight of the source data table (such as desktop data takes precedence over mobile data) or the latest update time of the data. Merge the same indicator information packages into a single indicator information entry to remove redundant information while retaining valuable data. The merged indicator information entry will contain the complete indicator name, value, timestamp, and other relevant fields. Write the merged single indicator information entry into the third data table to ensure that it can be accessed by subsequent queries.

[0205] Different indicator information packages are not merged, but are retained in the third data table respectively. These different indicators may reflect personalized indicators or specific business scenario requirements in the two application systems.

[0206] The system directly stores the different indicator information packages extracted from the first data table and the second data table into the third data table, maintaining their original characteristics. Each different indicator information package retains an independent record in the third data table, recording its complete name, value, timestamp and other data fields. At the same time, appropriate tags or metadata are added to the third data table to indicate the source of the indicator information package (such as from a mobile or desktop application), so that the source of the data can be distinguished during subsequent data display and processing.

[0207] In this embodiment, the system realizes unified management and integration of cross-platform data by synchronizing the indicator information packages in the first data table and the second data table to the third data table. By classifying the same and different indicator information packages and merging the same data by priority, the uniqueness and accuracy of the data in the third data table are ensured. Different indicator information packages meet the needs of personalized display by retaining their independence. This synchronization solution not only reduces data redundancy, but also improves the efficiency and consistency of data management, and ultimately provides users with a unified data access interface, optimizing the system's maintenance and operation processes.

[0208] In one embodiment, the above S80 includes:

[0209] S801, collecting and classifying user information in mobile applications and desktop applications, and marking migrated and non-migrated user information;

[0210] S802, formulating a user migration strategy, wherein the user migration strategy includes a migration batch, a migration time period, and / or a migration sequence of user information;

[0211] S803, based on the user migration policy, migrate the unmigrated user information from the mobile application and the desktop application to the converged service in a predetermined format;

[0212] S804, when a failure occurs during the migration process or in the converged service, the migrated user information is rolled back to the mobile application and the desktop application.

[0213] In this embodiment, before performing user migration, the system needs to collect user information from the mobile and desktop applications. The user information may include user ID, account information, permission information, settings, etc. In order to track the migration process, it is also necessary to classify the user information and mark which users have been migrated and which users have not yet migrated. The system extracts all user information from the mobile and desktop databases or services. Classify the user information and mark the migrated and non-migrated users. This can be achieved by adding a migration status field to the database or saving the status in the cache. The marking information helps to manage subsequent migrations, ensuring that the completed user information will not be migrated repeatedly, and further operations can be performed based on the migration status.

[0214] The user migration strategy defines how, when, and in what order to migrate user information. The strategy includes determining the migration batch, migration time period, and the priority order of user migration. A reasonable migration strategy can reduce system load, optimize migration efficiency, and ensure that user experience is not affected.

[0215] For example: Migration batches: Determine the number of users to be migrated each time based on system capacity or load. For example, migrate in batches based on user ID, registration time, or activity. Migration time period: Select a time period with low system load to migrate to avoid affecting normal services. Large-scale migration is usually performed at night or on weekends. User migration order: Based on the importance or activity of users, prioritize important users or highly active users to ensure that key users can use the converged service as soon as possible.

[0216] The system dynamically adjusts the migration process based on these policy parameters to ensure the smooth completion of the migration task.

[0217] According to the established migration strategy, the system needs to migrate the unmigrated user information from the mobile application and desktop application to the fusion service. The consistency of the data format needs to be ensured during the migration process so that the fusion service can correctly process and use the migrated user data. The system selects the user data to be migrated from the user information marked as "not migrated" according to the batches and time periods determined by the migration strategy. Format the user information to ensure that the data structure from the original system (mobile or desktop) to the fusion service is consistent. The data format conversion can be completed through scripts or data conversion tools. Write the migrated user information to the database or user information management module of the fusion service. After each migration is completed, update the migration status of the user information and mark it as "migrated".

[0218] During the migration process or when the fusion service is running, failures or anomalies may occur. In order to avoid data loss or affect the user experience, a rollback mechanism needs to be provided. The rollback mechanism allows the system to restore user information to the mobile or desktop application when a problem occurs to ensure service continuity. Before migrating user information, the system creates a backup of the user information or retains undeleted user data in the old system so that it can be rolled back when needed. When a failure occurs during the migration process or in the fusion service, the system automatically triggers the rollback mechanism to restore the migrated user information to the original database on the mobile or desktop. The rollback process ensures that users can continue to use the original service without service interruption or data corruption due to failures in the migration. After the rollback is completed, the system records a log of the rollback operation so that operation and maintenance personnel can analyze and troubleshoot the problem.

[0219] By performing the user migration operation in this embodiment, the system can smoothly migrate user information from mobile and desktop applications to the fusion service. Classifying and marking user information ensures the controllability of the migration process, and formulating a migration strategy optimizes the efficiency of migration and system load management. At the same time, the fault rollback mechanism enhances the fault tolerance of the system, and can quickly restore data when problems occur in the migration or fusion service to ensure service continuity. Ultimately, the user migration operation achieves unified management across platforms, reduces operation and maintenance costs, and improves the flexibility and reliability of the system.

[0220] In one embodiment, the above S60 includes:

[0221] S601, identifying and recording data query sources currently used by the mobile application and the desktop application;

[0222] S602, updating the configuration files of the mobile application and the desktop application, and configuring the currently used data query sources to read data from the third data table;

[0223] S603, synchronizing the updated configuration file to all application nodes, and making the configuration change effective by reloading the configuration or restarting the application instance.

[0224] In this embodiment, before switching the data query source, the system first needs to identify the data query source currently used by the mobile and desktop applications. The data query source may point to different databases or data tables. Understanding the current query source helps to prepare for rollback and avoid configuration errors during the switching process. The system identifies the current data query source of the mobile and desktop by querying the application configuration file, database connection configuration, or application log. Record this query source information and store it in a dedicated log file or configuration management tool so that the new and old configurations can be compared and verified when updating or switching.

[0225] In order to ensure that all data query operations are uniformly read from the third data table, the system needs to update the application configuration file. The goal of this step is to point the data source in the mobile and desktop applications to the third data table, ensuring that applications on different platforms access the same source when reading data, so as to achieve data unification. Through automated configuration management tools (such as Ansible, Puppet) or manually editing configuration files, find the existing data source configuration (such as database connection URL or data table name), and update it to point to the configuration of the third data table. Make sure that the data source configuration file includes the correct third data table path, connection information, data format and other necessary parameters.

[0226] The system usually consists of multiple application nodes or servers, so after the configuration file is updated, the changes need to be synchronized to all nodes running mobile and desktop applications. The synchronization operation ensures that all application instances use the same configuration and avoids lagging or unsynchronized configuration of some nodes. Use automated tools (such as Git, Chef) to push the updated configuration file to all relevant application nodes or servers to ensure that the configuration file is synchronized to each node. If you are using a containerized deployment method (such as Kubernetes), you need to ensure that the configuration files in all container instances are correctly updated.

[0227] In order for the application to use the new data query source configuration, it is usually necessary to reload the configuration file or restart the application instance. This ensures that the application instance reads the latest configuration and starts to obtain data from the third data table. By calling the application's reload interface or using command line tools (such as systemctl reload), the application instance can reload the configuration file without restarting. If the application supports hot loading, the system can complete this operation without interrupting the service. If the application does not support hot loading or requires higher reliability guarantees, you can choose to restart the application instance. During the restart process, the system ensures that the service has sufficient redundancy (such as load balancing or cluster backup) to avoid service interruption.

[0228] In this embodiment, the system implements unified data access management by configuring the data query source of the mobile and desktop applications to read data from the third data table. This process reduces the query differences between multiple platforms and ensures the consistency and reliability of the data. By identifying, updating, synchronizing the configuration files and reloading the configuration, the system can complete the data source switching without interrupting the service. Ultimately, the user requests to read data from the unified third data table, which improves the data management efficiency of the system and reduces the maintenance difficulty caused by multi-source queries.

[0229] In one embodiment, the above S30 includes:

[0230] S301, extracting configuration parameters for a desktop application from the indicator information package of the first data table;

[0231] S302, passing the configuration parameters to the desktop application by calling the background processing module interface of the desktop application;

[0232] S303, generating a configuration file of the desktop application based on the configuration parameters, and deploying the configuration file to the desktop application to complete the configuration of the desktop application indicator information package.

[0233] In this embodiment, the system needs to extract configuration information related to the desktop application from the indicator information package in the first data table. These configuration parameters usually contain data related to the business logic of the desktop application, such as indicators displayed on the interface, calculation logic or other setting information. The system first reads the indicator information package in the first data table, analyzes the structure and content of the information package, and identifies the configuration parameters related to the desktop application. The configuration parameters may include field names, display formats, calculation rules, etc., which match the functional requirements of the desktop application. The system will extract these configuration parameters from the indicator information package according to the preset parsing rules, and store them as data objects in a specific format for subsequent processing.

[0234] In order to apply the extracted configuration parameters to the desktop system, the system needs to pass these parameters to the desktop application through the background processing module interface. This is a process of data transmission and calling to ensure that the desktop application receives all necessary configuration data. The system sends a request containing configuration parameters through the background processing module interface of the desktop application. The content of the request includes the extracted configuration parameters, which are passed to the desktop application in the form of an API request or service call. The interface usually supports technologies such as RESTful API and RPC calls. After receiving the configuration parameters, the background processing module will verify them to ensure the integrity and correct format of the configuration data.

[0235] After receiving the configuration parameters, the system needs to generate a configuration file suitable for desktop applications. The configuration file is the basis for desktop applications, which determines how the application displays and processes related indicator data. The system generates a configuration file that meets the requirements of the desktop application based on the passed configuration parameters. The configuration file may be in JSON, XML, YAML and other formats. The generated configuration file will contain all necessary configuration information, such as display rules, data source path, calculation logic, etc.

[0236] After generating the configuration file, the system needs to deploy the configuration file to the desktop application to ensure that the desktop application can read and apply these configurations. After the deployment operation is completed, the desktop application will be able to display and process indicator data according to the new configuration file. The system deploys the generated configuration file to the server or node where the desktop application is located through a file transfer tool or an application management tool. After the deployment is complete, the desktop application is reloaded or restarted to read the new configuration file and operate according to the rules therein. After the configuration file takes effect, the desktop application will use the configuration parameters extracted from the first data table to process and display the corresponding indicator information.

[0237] In this embodiment, the system realizes cross-platform configuration synchronization and management by extracting configuration parameters from the first data table and applying these parameters to the desktop application. Automated configuration file generation and deployment reduces the risk of human configuration errors and improves the flexibility and scalability of the system. At the same time, the desktop application can process and display indicator data according to the new configuration, ensuring the accuracy and consistency of the data.

[0238] In one embodiment, the above S100 includes:

[0239] S1001, if the user information has been migrated to the fusion service, sending the user request to the fusion service;

[0240] S1002, the fusion service parses the query condition in the user request;

[0241] S1003, the fusion service connects to the third data table, and retrieves target indicator data from the third data table based on the query condition;

[0242] S1004, returning the target indicator data to the initiator of the user request, and recording log information of the user request processing.

[0243] In this embodiment, when the system detects that the user information has been migrated to the fusion service, the user's request will be sent to the fusion service for processing. The fusion service will process the request and query the required data from the unified data source. The system first detects whether the user information has been migrated to the fusion service, which can be done by querying the user's migration status field or the mark in the cache. If the user has been migrated, the system forwards the user's query request to the processing interface of the fusion service through an internal API or HTTP request. The user request usually contains user authentication information and parameters required for the query, such as query conditions, data types, etc.

[0244] After receiving a user request, the Fusion Service needs to parse the query conditions in the request to determine which indicator data needs to be retrieved from the database. The query conditions usually include the name of the target indicator, time range, data category, etc. After receiving the request, the Fusion Service extracts the condition information related to the query by parsing the parameters or query string in the request. The query conditions may include fields in the target data table, filter conditions (such as time range, user ID), etc. These conditions are used to construct query statements to ensure that the system can accurately obtain the data required by the user. The parsed query conditions will serve as the basis for subsequent database queries.

[0245] After parsing the query conditions, the Fusion Service needs to connect to the third data table and perform a database query operation based on the extracted query conditions to retrieve the target indicator data. The third data table contains all the integrated mobile and desktop indicator data. The Fusion Service connects to the third data table storing the target indicator data through a database connection pool or ORM framework. Based on the parsed query conditions, the Fusion Service executes an SQL query statement or data retrieval operation to filter out the target indicator data that meets the conditions from the third data table. The query operation may include multiple filtering conditions and sorting to ensure that the retrieved data is accurate and meets the requirements of the user's request.

[0246] After successfully retrieving the target indicator data, the Fusion Service returns the query results to the user who initiated the request, and the system records the relevant log information of the request processing. Logging helps monitor system performance and track the details of request processing. The retrieved target indicator data will be converted into the format required by the user (such as JSON, XML) and returned to the user's client or request initiator through the API interface. The Fusion Service also records the log information of the request processing, including the request time, query conditions, response time, and the status of the returned results. The logs can be stored in the log system or monitoring platform for subsequent analysis and troubleshooting.

[0247] In this embodiment, the system realizes the integration and efficient processing of cross-platform data queries by sending user requests to the fusion service and querying the target indicator data from the third data table. Parsing the query conditions in the user request ensures the accuracy of the query, and the fusion service uniformly processes all requests, reducing the scattered query behaviors of different application platforms. The logging function provides the system with a traceable request processing history, which is convenient for subsequent monitoring and debugging.

[0248] In one embodiment, an application service integration and user migration device is provided, and the application service integration and user migration device corresponds to the application service integration and user migration method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the application service fusion and user migration device of the present invention. Mobile terminal processing module 10, mobile terminal database module 20, desktop terminal processing module 30, desktop terminal database module 40, data synchronization module 50, query configuration module 60, service fusion module 70, user migration module 80, request processing module 90 and data query module 100. The functional modules are described in detail as follows:

[0249] A mobile terminal processing module 10, configured to configure an indicator information package of the mobile terminal application through a background processing module of the mobile terminal application;

[0250] The mobile terminal database module 20 is used to store the indicator information package of the mobile terminal application in the first data table of the mobile terminal application database;

[0251] The desktop processing module 30 is used to call the background processing module of the desktop application to configure the indicator information package of the desktop application based on the indicator information package in the first data table;

[0252] The desktop database module 40 is used to store the indicator information package of the desktop application in the second data table of the desktop application database;

[0253] A data synchronization module 50, configured to synchronize the indicator information packages in the first data table and the second data table to a third data table;

[0254] A query configuration module 60, configured to configure the data query source of the mobile application and the desktop application to read data from the third data table;

[0255] A service fusion module 70, used to integrate the service logic of the mobile application and the desktop application to generate a fusion service;

[0256] A user migration module 80, used to perform user migration operations and migrate user information in mobile applications and desktop applications to the fusion service;

[0257] The request processing module 90 is used to obtain a user request and determine whether the user information in the user request has been migrated to the fusion service;

[0258] The data query module 100 is used to send the user request to the fusion service if the user information has been migrated to the fusion service, and the fusion service queries the target indicator data from the third data table.

[0259] In one embodiment, the service fusion module 70 is specifically configured to:

[0260] Integrate the business logic of mobile applications and desktop applications to generate unified business processing logic;

[0261] Integrate the data access methods of the mobile application and the desktop application to generate a unified data access interface to access the data in the third data table;

[0262] Integrate the user request processing logic of the mobile application and the desktop application into a unified request processor, wherein the request processor is used to parse and process user requests from the mobile application and the desktop application;

[0263] A fusion service is deployed, wherein the fusion service accesses the data in the third data table through a unified data access interface and processes user requests from the mobile application and the desktop application.

[0264] In one embodiment, the data synchronization module 50 is specifically used for:

[0265] classifying the indicator information packets in the first data table and the second data table into the same indicator information packets and different indicator information packets;

[0266] According to a preset priority rule, the same indicator information packages are merged to generate a single indicator information entry, and the indicator information entry is stored in the third data table;

[0267] The different indicator information packages are stored in the third data table.

[0268] In one embodiment, the user migration module 80 is specifically configured to:

[0269] Collect and categorize user information in mobile and desktop applications, and mark which user information has been migrated and which has not;

[0270] Formulate a user migration strategy, wherein the user migration strategy includes a migration batch, a migration time period, and / or a migration sequence of user information;

[0271] Based on the user migration strategy, migrate the unmigrated user information from the mobile application and the desktop application to the fusion service in a predetermined format;

[0272] When a failure occurs during the migration process or in the converged service, the migrated user information is rolled back to the mobile and desktop applications.

[0273] In one embodiment, the query configuration module 60 is specifically used to:

[0274] Identify and record the data query sources currently used by mobile and desktop applications;

[0275] Update the configuration files of the mobile application and the desktop application, and configure the currently used data query sources to read data from the third data table;

[0276] Synchronize the updated configuration files to all application nodes and make the configuration changes take effect by reloading the configuration or restarting the application instance.

[0277] In one embodiment, the desktop processing module 30 is specifically used for:

[0278] Extracting configuration parameters for desktop applications from the indicator information package of the first data table;

[0279] By calling the background processing module interface of the desktop application, the configuration parameters are passed to the desktop application;

[0280] A configuration file of the desktop application is generated based on the configuration parameters, and the configuration file is deployed to the desktop application to complete the configuration of the desktop application indicator information package.

[0281] In one embodiment, the data query module 100 is specifically used to:

[0282] If the user information has been migrated to the fusion service, sending the user request to the fusion service;

[0283] The fusion service parses the query condition in the user request;

[0284] The fusion service connects to the third data table and retrieves target indicator data from the third data table based on the query condition;

[0285] The target indicator data is returned to the initiator of the user request, and log information of the user request processing is recorded.

[0286] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the service side of an application service integration and user migration method.

[0287] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of an application service integration and user migration method

[0288] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0289] Configuring an indicator information package of the mobile application through a background processing module of the mobile application;

[0290] Storing the indicator information package of the mobile terminal application in a first data table of a mobile terminal application database;

[0291] Based on the indicator information package in the first data table, calling the background processing module of the desktop application to configure the indicator information package of the desktop application;

[0292] Storing the indicator information package of the desktop application in a second data table of the desktop application database;

[0293] Synchronize the indicator information packages in the first data table and the second data table to the third data table;

[0294] Configuring the data query sources of the mobile application and the desktop application to read data from the third data table;

[0295] Integrate the service logic of the mobile application and the desktop application to generate a fusion service;

[0296] Performing user migration operations to migrate user information from mobile applications and desktop applications to the fusion service;

[0297] Obtaining a user request, and determining whether user information in the user request has been migrated to the fusion service;

[0298] If the user information has been migrated to the fusion service, the user request is sent to the fusion service, and the fusion service queries the target indicator data from the third data table.

[0299] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0300] Configuring an indicator information package of the mobile application through a background processing module of the mobile application;

[0301] Storing the indicator information package of the mobile terminal application in a first data table of a mobile terminal application database;

[0302] Based on the indicator information package in the first data table, calling the background processing module of the desktop application to configure the indicator information package of the desktop application;

[0303] Storing the indicator information package of the desktop application in a second data table of the desktop application database;

[0304] Synchronize the indicator information packages in the first data table and the second data table to the third data table;

[0305] Configuring the data query sources of the mobile application and the desktop application to read data from the third data table;

[0306] Integrate the service logic of the mobile application and the desktop application to generate a fusion service;

[0307] Performing user migration operations to migrate user information from mobile applications and desktop applications to the fusion service;

[0308] Obtaining a user request, and determining whether user information in the user request has been migrated to the fusion service;

[0309] If the user information has been migrated to the fusion service, the user request is sent to the fusion service, and the fusion service queries the target indicator data from the third data table.

[0310] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0311] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0312] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0313] It should be noted that if software tools or components other than those of the Company appear in the embodiments of the present application, they are only used for illustration and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the above-mentioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents; and these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A method for application service integration and user migration, characterized in that: The following steps are involved: Configuring an indicator information package of the mobile application through a background processing module of the mobile application; Storing the indicator information package of the mobile terminal application in a first data table of a mobile terminal application database; Based on the indicator information package in the first data table, calling the background processing module of the desktop application to configure the indicator information package of the desktop application; Storing the indicator information package of the desktop application in a second data table of the desktop application database; Synchronize the indicator information packages in the first data table and the second data table to the third data table; Configuring the data query sources of the mobile application and the desktop application to read data from the third data table; Integrate the service logic of the mobile application and the desktop application to generate a fusion service; Performing user migration operations to migrate user information from mobile applications and desktop applications to the fusion service; Obtaining a user request, and determining whether user information in the user request has been migrated to the fusion service; If the user information has been migrated to the fusion service, the user request is sent to the fusion service, and the fusion service queries the target indicator data from the third data table.

2. The method for application service integration and user migration according to claim 1, characterized in that: Integrate the service logic of the mobile application and the desktop application to generate a fusion service, including: Integrate the business logic of mobile applications and desktop applications to generate unified business processing logic; Integrate the data access methods of the mobile application and the desktop application to generate a unified data access interface to access the data in the third data table; Integrate the user request processing logic of the mobile application and the desktop application into a unified request processor, wherein the request processor is used to parse and process user requests from the mobile application and the desktop application; A fusion service is deployed, wherein the fusion service accesses the data in the third data table through a unified data access interface and processes user requests from the mobile application and the desktop application.

3. The method for application service integration and user migration according to claim 1, characterized in that: Synchronizing the indicator information packages in the first data table and the second data table to the third data table includes: classifying the indicator information packets in the first data table and the second data table into the same indicator information packets and different indicator information packets; According to a preset priority rule, the same indicator information packages are merged to generate a single indicator information entry, and the indicator information entry is stored in the third data table; The different indicator information packages are stored in the third data table.

4. The method for application service integration and user migration according to claim 1, characterized in that: Performing a user migration operation to migrate user information in the mobile application and the desktop application to the fusion service includes: Collect and categorize user information in mobile and desktop applications, and mark which user information has been migrated and which has not; Formulate a user migration strategy, wherein the user migration strategy includes a migration batch, a migration time period, and / or a migration sequence of user information; Based on the user migration strategy, migrate the unmigrated user information from the mobile application and the desktop application to the fusion service in a predetermined format; When a failure occurs during the migration process or in the converged service, the migrated user information is rolled back to the mobile and desktop applications.

5. The method for application service integration and user migration as claimed in claim 1, characterized in that: Configuring the data query source of the mobile application and the desktop application to read data from the third data table includes: Identify and record the data query sources currently used by mobile and desktop applications; Update the configuration files of the mobile application and the desktop application, and configure the currently used data query sources to read data from the third data table; Synchronize the updated configuration files to all application nodes and make the configuration changes take effect by reloading the configuration or restarting the application instance.

6. The method for application service integration and user migration according to claim 1, characterized in that: Based on the indicator information package in the first data table, calling the background processing module of the desktop application to configure the indicator information package of the desktop application includes: Extracting configuration parameters for desktop applications from the indicator information package of the first data table; By calling the background processing module interface of the desktop application, the configuration parameters are passed to the desktop application; A configuration file of the desktop application is generated based on the configuration parameters, and the configuration file is deployed to the desktop application to complete the configuration of the desktop application indicator information package.

7. The method for application service integration and user migration according to claim 1, characterized in that: If the user information has been migrated to the fusion service, the user request is sent to the fusion service, and the fusion service queries the target indicator data from the third data table, including: If the user information has been migrated to the fusion service, sending the user request to the fusion service; The fusion service parses the query condition in the user request; The fusion service connects to the third data table and retrieves target indicator data from the third data table based on the query condition; The target indicator data is returned to the initiator of the user request, and log information of the user request processing is recorded.

8. An application service integration and user migration device, characterized in that: The application service integration and user migration device comprises: A mobile terminal processing module, used to configure the indicator information package of the mobile terminal application through the background processing module of the mobile terminal application; A mobile terminal database module, used to store the indicator information package of the mobile terminal application in a first data table of a mobile terminal application database; A desktop processing module, configured to call a background processing module of a desktop application to configure an indicator information package of the desktop application based on the indicator information package in the first data table; A desktop database module, used to store the indicator information package of the desktop application in a second data table of the desktop application database; A data synchronization module, used for synchronizing the indicator information packages in the first data table and the second data table to a third data table; A query configuration module, configured to configure the data query source of the mobile application and the desktop application to read data from the third data table; A service fusion module, used to integrate the service logic of the mobile application and the desktop application to generate a fusion service; A user migration module, used to perform user migration operations and migrate user information in mobile applications and desktop applications to the fusion service; A request processing module, used to obtain a user request and determine whether the user information in the user request has been migrated to the fusion service; A data query module is used to send the user request to the fusion service if the user information has been migrated to the fusion service, and the fusion service queries the target indicator data from the third data table.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and an application service integration and user migration program stored in the memory and executable on the processor. When the application service integration and user migration program is executed by the processor, the steps of the application service integration and user migration method as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The storage medium stores an application service integration and user migration program, which, when executed by the processor, implements the steps of the application service integration and user migration method according to any one of claims 1 to 7.

Images