Service system migration method and device based on gateway and storage medium

Abstract

The invention discloses a service system migration method and device based on a gateway and a storage medium, and relates to the technical field of data management, and the service system migration method based on the gateway comprises the steps: receiving and analyzing a service request message of a source system, and extracting a feature tuple of the service request message; based on a migration strategy of a migration batch configuration rule, matching the feature tuple, and determining a corresponding target system; mapping the service request message into a corresponding target request message according to an interface mapping configuration file of the target system, and sending the target request message to the target system; and based on a target response message of the target system and the interface mapping configuration file, reversely mapping the target response message into a final response message of the source system. The technical effect of ensuring continuous execution of the service request in the migration process is achieved.

Description

Technical Field

[0001] The present application relates to the field of data management technology, and in particular to a gateway-based business system migration method, device, and storage medium. Background Art

[0002] In traditional business system migrations, the source system service must be suspended when the migration starts to complete the full migration of historical data. The source system cannot process the newly added business request data, resulting in interrupted business continuity. For high-concurrency real-time systems, long service outages result in low system availability during the migration.

[0003] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a gateway-based business system migration method, device and storage medium, aiming to solve the technical problem of how to ensure the continuous execution of business requests during the migration process.

[0005] To achieve the above objectives, the present application proposes a gateway-based business system migration method, which includes: Receive and parse a service request message from a source system, and extract a feature tuple of the service request message; A migration strategy based on a migration batch configuration rule matches the feature tuple and determines a corresponding target system; According to the interface mapping configuration file of the target system, the service request message is mapped into a corresponding target request message and sent to the target system; Based on the target response message of the target system and the interface mapping configuration file, the target response message is reversely mapped into a final response message of the source system.

[0006] In one embodiment, before the step of receiving and parsing a service request message from a source system and extracting a feature tuple of the service request message, the following steps are included: Generate a stock migration event based on the globally unique primary key of the stock data in the source system and register it in the migration event table; Triggering the source system to scan the stock migration event and obtain the corresponding stock data; The data receiving interface of the target system is called to transplant the stock data into the database of the target system.

[0007] In one embodiment, before the step of receiving and parsing the service request message from the source system and extracting the feature tuple of the service request message, the following step is further included: Monitor the incremental data of the source system, generate corresponding incremental migration events and register them in the migration event table; Triggering the source system to scan the incremental migration event and obtain the corresponding incremental data; The data receiving interface of the target system is called to transplant the incremental data to the database of the target system.

[0008] In one embodiment, the migration strategy based on the migration batch configuration rule, matching the feature tuple, and determining the corresponding target system includes: Loading a preset function switching gateway control rule, and determining an associated migration batch identifier according to the function code of the feature tuple; Based on the migration batch identifier, the target system is determined by using the migration batch configuration rule.

[0009] In one embodiment, the step of mapping the service request message into a corresponding target request message and sending the message to the target system according to the interface mapping configuration file of the target system includes: Load the interface mapping configuration file of the target system and determine the field mapping rules and conversion logic; Based on the field mapping rules and conversion logic, perform field-level mapping conversion of the service request message to generate the target request message compatible with the target system; The target request message is sent to the target system.

[0010] In one embodiment, the step of reversely mapping the target response message to the final response message of the source system based on the target response message of the target system and the interface mapping configuration file includes: Receive and parse the target response message of the target system, and extract the response feature tuple of the target response message; According to the reverse mapping rule in the interface mapping configuration file, the extracted response feature tuple is converted into a message format corresponding to the source system to generate the final response message of the source system.

[0011] In one embodiment, after the step of reversely mapping the target response message to a final response message of the source system based on the target response message of the target system and the interface mapping configuration file, the following steps are included: monitoring the operating state of the target system, and if the operating state is a fault state, analyzing the impact of the fault state; Based on the impact of the fault state, a corresponding rollback operation is triggered.

[0012] In one embodiment, the step of triggering a corresponding rollback operation based on the impact result of the fault state includes: If the impact result is a response message format error, the corresponding service request message is rerouted back to the source system and the fault information is recorded; If the impact result is a partial function failure, the service request message corresponding to the partial function is rolled back to the source system, and the failure information is recorded; If the impact result is that the system cannot operate normally, all service request messages are routed back to the source system, the migration event is closed, and the data synchronization between the source system and the target system is stopped.

[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a gateway-based business system migration device, which includes: a memory, a processor, and a computer program stored on the memory and runnable on the processor, and the computer program is configured to implement the steps of the gateway-based business system migration method as described above.

[0014] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the gateway-based business system migration method as described above are implemented.

[0015] The present application provides a gateway-based business system migration method. The present application first receives and parses the business request message of the source system and extracts the feature tuple of the business request message; matches the feature tuple based on the migration batch configuration rule, and determines the corresponding target system; maps the business request message to the corresponding target request message according to the interface mapping configuration file of the target system and sends it to the target system; and reversely maps the target response message to the final response message of the source system based on the target response message of the target system and the interface mapping configuration file. The present application extracts the feature tuple of the business request message and determines in real time based on the migration batch configuration rule whether the request should be routed to the source system or the target system, so that the full data migration and incremental business request processing are performed in parallel. The migration strategy based on the migration batch configuration rule can flexibly switch the flow by functional classification or individual function, thereby improving the controllability and flexibility of the migration and improving the efficiency of the migration process. The interface mapping configuration file is used to accurately map the source system request to a compatible format of the target system, ensuring that the data status of the new and old systems are synchronized in real time at the request level granularity, avoiding data version conflicts caused by migration delays, and improving the availability of the system during the migration process. The present application achieves the technical effect of ensuring the continuous execution of business requests during the migration process. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0018] Figure 1 A flowchart of the first embodiment of the gateway-based business system migration method of this application is provided; Figure 2 A flowchart of the second embodiment of the gateway-based business system migration method provided in this application; Figure 3 A flowchart of the third embodiment of the gateway-based business system migration method of this application is provided; Figure 4 A data migration diagram provided for Example 3 of the gateway-based business system migration method of this application; Figure 5 A flowchart of the fourth embodiment of the gateway-based business system migration method of this application is provided; Figure 6 A schematic diagram of the overall process provided for the gateway-based business system migration method of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the gateway-based business system migration method in an embodiment of the present application.

[0019] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0020] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0021] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0022] Currently, in traditional business system migrations, the source system service must be suspended when the migration starts to complete the full migration of historical data. The source system cannot process the newly added business request data, resulting in interrupted business continuity. For high-concurrency real-time systems, long service outages result in low system availability during migration.

[0023] This application extracts the characteristic tuples of the business request message and determines in real time based on the migration batch configuration rules whether the request should be routed to the source system or the target system, so that the full data migration and incremental business request processing are performed in parallel. The migration strategy based on the migration batch configuration rules can flexibly cut the flow by functional classification or single function, which improves the controllability and flexibility of the migration and improves the efficiency of the migration process. The source system request is accurately mapped to a target system compatible format through the interface mapping configuration file, ensuring that the data status of the old and new systems are synchronized in real time at the request level granularity, avoiding data version conflicts caused by migration delays, and improving the availability of the system during the migration process.

[0024] It should be noted that the execution entity of this embodiment can be a gateway application, a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or a control device of a gateway-based business system migration device capable of implementing the above functions, etc. This embodiment does not specifically limit this. The following uses the gateway application as the execution entity as an example to illustrate this embodiment and the following embodiments.

[0025] Example 1 Based on this, this application proposes a gateway-based business system migration method of the first embodiment, please refer to Figure 1 , the gateway-based business system migration method includes: Step S10: receiving and parsing a service request message from a source system, and extracting a feature tuple of the service request message.

[0026] Extract key features of business request messages to match them with the rules in the migration strategy, thereby correctly routing the requests to the target system and ensuring that the business requests can be processed correctly.

[0027] In this embodiment, the source system refers to the original business system that is currently in use and requires business function migration. The business request message is generated by the gateway application of the user interface and contains the message of the user's business operation request. The user interface is the entrance for the user to interact with the system, and the user initiates various business operation requests through this interface. The gateway application of the user interface is responsible for receiving the user's operation request and encapsulating it into a business request message that meets the requirements of the source system, thereby not changing the interface of the user request and ensuring business continuity. The feature tuple is a set of key features extracted from the business request message, which can be a specific field or attribute, used to identify the type, function and other key information of the request.

[0028] As an optional implementation, a service request message is received from a user interface. The service request message is generated based on a format compatible with the source system. Based on the source system compatible message format, the service request message is parsed using a corresponding parser, and information such as the function code is extracted to generate a feature tuple containing the function code. The function code is a key field used to identify the specific operation of the service request.

[0029] Step S20 : Based on the migration strategy of the migration batch configuration rule, the feature tuple is matched to determine the corresponding target system.

[0030] Based on the preset migration strategy, the feature tuples extracted from the business request message are matched with the migration rules to determine the target system to which the request should be routed, ensuring that the business request can be correctly assigned to the corresponding system, thereby achieving smooth migration and fallback of business functions and ensuring business continuity.

[0031] In this embodiment, migration batch configuration rules are predefined in the gateway application. They are used to divide migration batches and specify the migration conditions and timeframes for each batch. These rules clarify the order and method for migrating different functions or data within different timeframes. A migration policy is a specific action plan developed based on the migration batch configuration rules, determining how to migrate service requests from the source system to the target system. The target system is the final destination of the service request during the migration process.

[0032] Optionally, in the gateway application, the function switching gateway control table and the migration batch configuration table are pre-loaded. The function switching gateway control table includes fields such as function code, function description, function classification, migration batch and associated migration batch. The batch to which a specific function belongs and its associated migration batch are configured by loading the function switching gateway control table. The migration batch configuration table includes fields such as migration batch, migration version date, switch range expression, business start blocking time, new system activation time and migration version description. The migration of specific batches is controlled by the migration batch configuration table. Each batch can be configured for multiple migrations according to the migration version date. The specific migration strategy is controlled by the switch range expression, and the business blocking and activation of the maintenance function are controlled by configuring the blocking time. Among them, the switch range expression is a regular expression, so as to achieve more dimensional switching granularity.

[0033] As an optional implementation, load the migration batch configuration rules and match the function codes in the extracted feature tuples against the migration batch configuration rules. If a match is successful, determine whether to send the service request to the source system or the target system based on the target system identifier defined in the rule.

[0034] As another optional implementation, the migration batch configuration rules are loaded, and the business parameter values in the extracted feature tuples are used to determine the target system by verifying the regular expression based on the mapping relationship between the regular expression of the business parameters defined in the migration batch configuration and the target system.

[0035] Optionally, if the feature tuple does not match any rule, the request is sent to the source system according to the default policy.

[0036] Optionally, step S20 includes: Step S21 : loading a preset function switching gateway control rule, and determining an associated migration batch identifier according to the function code of the feature tuple.

[0037] It should be noted that the function switching gateway control rules are a set of preset rules that define the mapping between function codes and migration batch identifiers. The gateway application obtains the function switching gateway control rules by pre-loading the function switching gateway control table. The function code is a function identifier extracted from the service request message and is used to identify the specific operation type of the service request. The migration batch identifier is a unique identifier used to identify a specific migration batch. Each migration batch can contain multiple functions, and the migration batch identifier can be used to associate with the specific migration batch configuration.

[0038] As an optional implementation, according to the function switching gateway control rule loaded in the gateway application, a migration batch identifier matching the extracted function code is searched.

[0039] Step S22: Based on the migration batch identifier, determine the target system using the migration batch configuration rule.

[0040] It should be noted that migration batch configuration rules are a set of preset rules that define the specific configuration of each migration batch, including the target system, migration version date, and switch range expression. The gateway application obtains the migration batch configuration rules by pre-loading the migration batch configuration table.

[0041] As an optional implementation manner, according to the determined migration batch identifier, the corresponding migration batch configuration rule is searched, and according to the matched migration batch configuration rule, the target system of the business request is determined.

[0042] For example, when an account query request is received, the function code "QUERY_ACCOUNT" is extracted from the service request message. Based on the function switching gateway control rules, the migration batch ID associated with this function is determined to be "BATCH_A." Based on the migration batch ID "BATCH_A," the corresponding migration batch configuration rule is searched. Based on the configuration rule, the target system is determined to be "NEW_SYS." The account ID is then checked to see if it meets the switching range expression. If so, the account query request is sent to "NEW_SYS" for processing. If not, it is sent to the source system "OLD_SYS" according to the default policy.

[0043] Optionally, the feature tuple also includes the time information when the user triggers the business request. The time information is compared with the migration version date in the migration batch configuration rule. If the time when the user triggers the business request is after the migration version date, the business request is sent to the target system; otherwise, it is sent to the source system.

[0044] Step S30: Map the service request message into a corresponding target request message according to the interface mapping configuration file of the target system and send the message to the target system.

[0045] Convert business request messages into a request message format that the target system can understand, ensuring that business requests can be correctly processed in the target system. Through the interface mapping configuration file, interface adaptation between the source and target systems is achieved to ensure data consistency.

[0046] In this embodiment, the interface mapping configuration file is a preset configuration file that defines the field mapping relationship, format conversion rules, etc. between the source system business request message and the target system request message. The interface mapping configuration file is stored in the gateway application, including field-level mapping rules, format compatibility processing, and custom logic extensions. The content of the interface mapping configuration file specifies the one-to-one mapping relationship between all fields of the input and output interfaces of the source system message and the new system interface fields. Simple conversion logic is also specified in the configuration file. For complex mapping logic, customized processing is performed through custom mapping logic. The business request message is the original request message received from the user interface, which contains the data and information required for the business operation. The target request message is the request message converted according to the interface mapping configuration file, meets the interface requirements of the target system, and can be correctly parsed and processed by the target system.

[0047] As an optional implementation, if the transfer target system is a new system, the target system's interface mapping configuration file is loaded. The extracted feature tuple and the service request message content are used to parse the fields and values that need to be converted. Based on the interface mapping configuration file, the fields in the service request message are mapped to the target system's fields. Data type and format conversion is performed, and the converted fields and values are combined into the target system's request message format. The generated target request message is then sent to the target system's interface.

[0048] Optionally, the interface mapping configuration file is static data and is loaded lazily. When the gateway application starts, the interface mapping configuration file is not loaded immediately. When a service request message is received and interface mapping is required, the system checks whether the corresponding interface mapping configuration file has been loaded. If not, the system triggers a loading process, reads the configuration file from the storage location, and parses it into a format that the gateway application can use, thereby reducing the startup time of the gateway application.

[0049] Optionally, if the target system for transfer is the source system, the service request message is directly sent to the source system.

[0050] Optionally, step S30 includes: Step S31: Load the interface mapping configuration file of the target system and determine the field mapping rules and conversion logic.

[0051] Load the target system's interface mapping configuration file and parse the field mapping rules and conversion logic therein to ensure that the gateway application can correctly understand and perform message conversion, converting the source system's business request message into a format that the target system can understand.

[0052] It should be noted that field mapping rules define the correspondence between source system fields and target system fields, including field name, data type, length, etc. Conversion logic defines how to convert field values in the source system to field values in the target system, including simple data type conversion, format conversion, and complex business logic conversion.

[0053] For example, when message conversion is required, the gateway application loads the interface mapping configuration file from a storage location, parses the configuration file content, and extracts the field mapping rules and conversion logic. The interface mapping configuration file is stored in a storage location accessible to the gateway application.

[0054] Step S32: Based on the field mapping rules and conversion logic, perform field-level mapping conversion of the service request message to generate the target request message compatible with the target system.

[0055] Based on field mapping rules and conversion logic, the business request message of the source system is converted into a request message format that can be understood by the target system to ensure data accuracy and consistency.

[0056] As an optional implementation, the value of each field is extracted from the business request message, and the source system field is mapped to the target system field according to the field mapping rules. The conversion logic is applied to perform data type and format conversion, and the converted fields and values are combined into the request message format of the target system.

[0057] Step S33: Send the target request message to the target system.

[0058] Exemplarily, the gateway application establishes a communication connection with the target system, and sends the generated target request message to the target system through the established connection.

[0059] Optionally, if the function corresponding to the function code in the feature tuple of the business request message is a query function, due to the high real-time requirements of the query function, it is necessary to determine whether the corresponding maintenance function has been migrated, and compare the function code with the list of migrated maintenance functions. If the corresponding maintenance function has not been migrated, it is decided whether to penetrate into the source system for query based on the migration progress of the migration event. Based on the data identifier in the feature tuple, the migration progress of the data corresponding to the query request is obtained from the migration event table. If the corresponding data has been migrated, the target system will continue to execute the query request; if the migration of the corresponding data is not completed, the request will be forwarded to the source system to obtain real-time data, and the response message received from the source system will be directly returned to the user without the need for further processing through the target system.

[0060] Step S40: Based on the target response message of the target system and the interface mapping configuration file, reversely map the target response message into a final response message of the source system.

[0061] The response message returned by the target system is converted into the response message format of the source system so that it can be directly returned to the user interface, ensuring that the user interface can seamlessly receive and process the response without the need for additional format conversion on the user side, thereby ensuring business continuity.

[0062] In this embodiment, the target response message is the response message returned by the target system after processing the service request, including the processing result and related data. The final response message is the response message format that meets the requirements of the source system after reverse mapping conversion.

[0063] As an optional implementation, the gateway application receives the response message from the target system, loads the interface mapping configuration file, extracts the field values from the response message returned by the target system, maps the target system fields back to the source system fields according to the field mapping rules in the interface mapping configuration file, and performs data type conversion and format adjustment to ensure that the response message conforms to the source system's format requirements. The converted fields and values are combined into the response message format corresponding to the source system, and the generated final response message is directly returned to the user interface, completing the response processing during the entire migration process.

[0064] Optionally, step S40 includes: Step S41: receiving and parsing a target response message from the target system, and extracting a response feature tuple from the target response message.

[0065] It should be noted that the response feature tuple is a set of key features extracted from the target response message, which is used for subsequent reverse mapping conversion, including business processing results, etc.

[0066] Exemplarily, a response message returned by the target system is received, and a corresponding parser is used to parse the message content according to the format of the target response message, extract key fields and values therein, and form a response feature tuple.

[0067] Step S42: converting the extracted response feature tuple into a message format corresponding to the source system according to the reverse mapping rule in the interface mapping configuration file, and generating the final response message of the source system.

[0068] It should be noted that the reverse mapping rules define the rules for how to convert the response fields of the target system into the response fields of the source system, including field name conversion, data type conversion, format adjustment, etc.

[0069] Exemplarily, the interface mapping configuration file is loaded, the reverse mapping rules therein are parsed, field conversion and format adjustment are performed according to the extracted response feature tuple and the reverse mapping rules in the interface mapping configuration file, and the converted fields and values are combined into the response message format of the source system.

[0070] This embodiment provides a gateway-based business system migration method. This embodiment first extracts the characteristic tuple of the business request message, and determines in real time based on the migration batch configuration rules whether the request should be routed to the source system or the target system, so that the full data migration and incremental business request processing are performed in parallel. The migration strategy based on the migration batch configuration rules can flexibly cut the flow by functional classification or single function, which improves the controllability and flexibility of the migration and improves the efficiency of the migration process. The source system request is accurately mapped to a target system compatible format through the interface mapping configuration file, ensuring that the data status of the old and new systems are synchronized in real time at the request-level granularity, avoiding data version conflicts caused by migration delays, and improving the availability of the system during the migration process.

[0071] Based on Example 1, Example 2 of this application proposes a gateway-based business system migration method, referring to Figure 2 , before step S10, including: Step A10: Generate a stock migration event based on the globally unique primary key of the stock data in the source system and register it in the migration event table.

[0072] Stock migration events are generated using the globally unique primary key of the stock data in the source system and registered in the migration event table. This ensures that the migration process of each data record can be tracked and managed, providing a foundation for subsequent data migration and synchronization.

[0073] It should be noted that the source system is an existing business system containing existing data that needs to be migrated. Existing data refers to the existing data that needs to be migrated from the source system to the target system during the migration process. A globally unique primary key uniquely identifies each data record in the source system, ensuring that each data record is globally unique. An existing migration event is a migration event generated for existing data in the source system. The migration event table is a table stored in the database that records and manages all existing migration events.

[0074] Exemplarily, in response to a data migration instruction, the trigger source system extracts the globally unique primary key of each data record from the existing data, generates a corresponding existing migration event based on the extracted globally unique primary key, registers the generated existing migration event in the migration event table, and records the status of the event.

[0075] Step A20: trigger the source system to scan the inventory migration event and obtain the corresponding inventory data.

[0076] Exemplarily, the source system is triggered to scan the migration event table through the gateway application, so that the source system reads the existing migration events in the migration event table and obtains the globally unique primary key of the data record that needs to be migrated. Based on the globally unique primary key, the source system obtains the corresponding existing data from the database, and then receives the existing data of the source system through the data interface.

[0077] Step A30: calling the data receiving interface of the target system to transplant the stock data to the database of the target system.

[0078] For example, the data receiving interface of the target system is called by the gateway application, and the acquired inventory data is sent to the target system through the interface. After the target system receives the data, it stores it in the database of the target system.

[0079] Optionally, the status of the corresponding event in the migration event table is updated to "completed", and information related to the migration time, such as the migration version date, of the corresponding migration event is updated.

[0080] This embodiment provides a gateway-based business system migration method. This embodiment first generates an existing migration event and registers it in a migration event table, providing real-time status information for data migration, facilitating monitoring and management of the migration process. By pre-transferring existing data from the source system to the new target system, the entire migration process can be performed without disrupting the normal operation of the source system. This allows data migration to be completed while the source system continues to provide services, minimizing service interruption and improving system availability.

[0081] Based on the first and second embodiments, the third embodiment of the present application proposes a gateway-based business system migration method, referring to Figure 3 , before step S10, further comprising: Step A40: monitor the incremental data of the source system, generate corresponding incremental migration events, and register them in the migration event table.

[0082] Monitor the incremental data generated in the source system in real time and automatically generate corresponding incremental migration events to ensure that the incremental data can be identified and processed in a timely manner, thereby achieving real-time data synchronization.

[0083] It should be noted that incremental data refers to new or updated data records generated after the existing data in the source system during the migration process. Incremental migration events are migration events corresponding to incremental data generated in the source system.

[0084] For example, data changes can be captured in real time by setting a data change trigger in the source system. This trigger extracts the globally unique primary key of the incremental data record from the incremental data. Based on the extracted globally unique primary key, a corresponding incremental migration event is generated. The generated incremental migration event is registered in the migration event table, and the event status is recorded.

[0085] Step A50: trigger the source system to scan the incremental migration event and obtain the corresponding incremental data.

[0086] Exemplarily, the gateway application triggers the source system to scan the migration event table. The source system reads the incremental migration event in the migration event table and obtains the globally unique primary key of the data record to be migrated. Based on the globally unique primary key, the source system retrieves the corresponding incremental data from the database. The source system then receives the incremental data from the source system through the data interface.

[0087] Step A60: calling the data receiving interface of the target system to transplant the incremental data to the database of the target system.

[0088] The acquired incremental data is transplanted into the database of the target system through the data receiving interface of the target system, ensuring that the incremental data is accurately migrated from the source system to the target system and realizing real-time synchronization of the incremental data.

[0089] Exemplarily, the gateway application calls the data receiving interface of the target system and sends the acquired incremental data to the target system through the interface. After the target system receives the data, it stores it in the database of the target system.

[0090] As an example of this embodiment, please refer to Figure 4 , registering the old-to-new event for the migration of existing data based on a globally unique primary key. The old-to-new event is scanned by the old system, and the existing data is obtained based on the registered event information. The old-to-new receiving program of the new system is called to achieve the goal of migrating the existing data from the old database to the new database of the new system. At the beginning of the existing data migration, the old-to-new event is also registered for incremental data changes. This allows the old system to provide normal services while the new system can also synchronously receive data changes, ultimately maintaining data consistency between the old and new systems. The old system is the source system for data migration, and the new system is the target system for migration.

[0091] It should be noted that the incremental data migration steps in this embodiment are performed on the basis of the full data migration in Example 2. Incremental data migration and full data migration achieve complete lifecycle management of data migration through a shared migration event table, a primary key-driven mechanism, and automated processing logic. In this application, it is only necessary to control the first migration event initialized by the full data. Subsequent incremental data migration events can be automatically generated based on the logic of the full data migration, without the need to create a new migration process for the incremental data. In other words, incremental data migration is not a new process independent of the full migration, but an automated extension based on the full migration framework.

[0092] This embodiment provides a gateway-based business system migration method. By monitoring incremental data in the source system in real time and automatically generating incremental migration events, this method promptly captures data changes and triggers the migration process, ensuring that data in the target system remains synchronized with the source system. While the source system continues to operate and generate new data, incremental data migration allows data migration to proceed without disrupting normal business operations, ensuring business continuity.

[0093] Based on Example 1, Example 4 of this application proposes a gateway-based business system migration method, referring to Figure 5 , after step S40, including: Step S50: monitoring the operating state of the target system, and if the operating state is a fault state, analyzing the impact of the fault state.

[0094] Real-time monitoring of the target system's operating status allows for timely detection of faults and analysis of their scope and extent of impact, ensuring prompt action when a fault occurs to minimize the impact on the business.

[0095] It's important to note that the operating status refers to the current operating condition of the target system, including normal and faulty states. A faulty state refers to a state where the target system experiences a fault and is unable to provide some or all services. The impact refers to the scope and extent of the fault's impact on business processing, including the affected functions.

[0096] For example, the gateway application's built-in monitoring functionality is used to periodically send health check requests to the target system. The target system's response to the check request is received, and the target system's operational status is evaluated based on metrics such as response time, error rate, and availability. If an abnormal response is detected, the target system is deemed to have entered a fault state. The impact of the fault state on the business is analyzed to determine which functions are affected.

[0097] Step S60: triggering a corresponding rollback operation based on the impact of the fault state.

[0098] According to the impact of the fault status, the corresponding rollback operation is triggered to ensure that the business can be quickly restored and reduce the impact of the fault on the business.

[0099] For example, a corresponding fallback strategy is pre-defined based on different fault impacts. The fault status is analyzed, the corresponding impact is determined, and corresponding fallback actions are triggered, including rerouting service requests to the source system and stopping sending new requests to the target system.

[0100] Optionally, step S60 includes: Step S61: if the impact result is a response message format error, the corresponding service request message is rerouted back to the source system, and the fault information is recorded.

[0101] When it is detected that the response message format returned by the target system is incorrect, the relevant business request is promptly rerouted back to the source system to ensure that the business request can be processed correctly, and the fault information is recorded for subsequent analysis and repair.

[0102] It should be noted that a response message format error means that the response message returned by the target system does not conform to the expected format specifications, including missing fields, incorrect data types, etc. Rerouting redirects business requests from the target system to the source system to ensure that the request can be processed correctly.

[0103] For example, the gateway application performs a format check on the target system response message received. If it detects that the response message format does not meet the expected format, it identifies it as a response message format error and reroutes the corresponding service request message back to the source system to ensure that the request can be processed by the source system.

[0104] Optionally, record detailed fault information, including error type, occurrence time, request ID, etc., for subsequent analysis.

[0105] Step S62: If the impact result is a partial function failure, the service request message corresponding to the partial function is rolled back to the source system, and the failure information is recorded.

[0106] When a failure is detected in some functions of the target system, the relevant business requests are rolled back to the source system to ensure that these requests can be processed correctly.

[0107] For example, the gateway application detects a failure in some functions of the target system through a monitoring mechanism, determines the specific functions affected, and rolls back the service request messages corresponding to the affected functions to the source system. It then routes subsequent service requests for related functions to the source system for processing.

[0108] Step S63: If the impact result is that the system cannot operate normally, all service request messages are routed back to the source system, the migration event is closed, and the data synchronization between the source system and the target system is stopped.

[0109] For example, the gateway application detects that the target system is not functioning properly through its monitoring mechanism and routes all service request messages back to the source system to ensure that service requests can be processed. It then updates the migration event table, marking all incomplete migration events as "stopped," halting data synchronization between the source and target systems. All subsequent service requests are then routed back to the source system for processing.

[0110] This embodiment provides a gateway-based business system migration method. When a system failure occurs, the rollback operation can be performed in any dimension and at any granularity, ensuring the continuous and stable operation of the business and improving the adaptability and reliability of the system.

[0111] For example, in order to help understand the implementation process of the gateway-based business system migration method obtained by combining this embodiment with the above embodiment 1, please refer to Figure 6 , Figure 6 This article provides a brief flowchart of a gateway-based business system migration method. Specifically: The gateway application receives service request messages from the source system and uses a parser to parse the message content according to the message format, extracting key information such as the function code. It then determines whether the service request message should be processed by the source system or the target system based on the preset migration batch configuration rules.

[0112] For a new system that makes its first business request, it is necessary to load the corresponding interface mapping configuration file to obtain the message mapping configuration. In subsequent business requests, the message mapping configuration can be obtained without repeated loading.

[0113] Furthermore, according to the message mapping configuration, the service request message of the source system is converted into a request message format that can be understood by the target system, and the converted request message is sent to the target system.

[0114] Optionally, for query functions requiring high real-time performance, before the corresponding maintenance function is migrated, the progress of the migration event can be used to determine whether the request needs to be passed through to the source system for processing. If the pass-through conditions are met, the service request message is directly forwarded to the source system for processing.

[0115] After the source system processes the request, the gateway application receives the response message from the source system. If the request is processed by the target system, after the target system returns the response message, the gateway application converts the target system's response message into the source system's response message format according to the reverse mapping rules in the interface mapping configuration file.

[0116] The converted final response message is returned to the user interface to complete the response processing during the entire migration process, ensuring that the user interface can seamlessly receive and process the response.

[0117] Through the above process, the entire business system migration method realizes the flexible routing of business requests, the conversion and processing of messages, and the correct return of responses, ensuring the smooth progress of the migration process and the continuity of business.

[0118] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the gateway-based business system migration method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0119] The present application provides a gateway-based business system migration device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the gateway-based business system migration method in the above-mentioned embodiment one.

[0120] Reference below Figure 7 , which shows a schematic diagram of the structure of a gateway-based service system migration device suitable for implementing embodiments of the present application. The gateway-based service system migration device in embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptops, personal digital assistants (PDAs), and tablet computers (PADs), as well as fixed terminals such as digital TVs and desktop computers. Figure 7 The gateway-based business system migration device shown is merely an example and should not impose any limitations on the functions and scope of use of the embodiments of the present application.

[0121] like Figure 7As shown, the gateway-based business system migration device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the gateway-based business system migration device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to I / O interface 1006: input device 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and communication device 1009. Communication device 1009 may allow the gateway-based business system migration device to communicate with other devices wirelessly or by wire to exchange data. While the figure illustrates the gateway-based business system migration device with various systems, it should be understood that implementation or provision of all illustrated systems is not required. More or fewer systems may alternatively be implemented or provided.

[0122] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are performed.

[0123] The gateway-based business system migration device provided in this application, employing the gateway-based business system migration method of the aforementioned embodiment, can solve the technical problem of ensuring the continuous execution of business requests during the migration process. Compared to the prior art, the beneficial effects of the gateway-based business system migration device provided in this application are the same as those of the gateway-based business system migration method provided in the aforementioned embodiment. Other technical features of the gateway-based business system migration device are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0124] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0125] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0126] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the gateway-based business system migration method in the above-mentioned embodiment.

[0127] The computer-readable storage medium provided herein may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including, but not limited to, wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0128] The computer-readable storage medium may be included in the gateway-based business system migration device; or may exist independently without being assembled into the gateway-based business system migration device.

[0129] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the gateway-based business system migration device, the gateway-based business system migration device can write computer program codes for performing the operations of the present application in one or more programming languages or a combination thereof. The programming languages include object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user computer, partially on the user computer, as an independent software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, through the Internet using an Internet service provider).

[0130] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0131] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0132] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned gateway-based business system migration method. This computer-readable storage medium addresses the technical problem of ensuring the continuous execution of business requests during the migration process. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are similar to those of the gateway-based business system migration method provided in the aforementioned embodiments, and are not further elaborated here.

[0133] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A gateway-based business system migration method, characterized in that: The gateway-based business system function migration method includes: Receive and parse a service request message from a source system, and extract a feature tuple of the service request message; A migration strategy based on a migration batch configuration rule matches the feature tuple and determines a corresponding target system; According to the interface mapping configuration file of the target system, the service request message is mapped into a corresponding target request message and sent to the target system; Based on the target response message of the target system and the interface mapping configuration file, the target response message is reversely mapped into a final response message of the source system.

2. The gateway-based business system migration method according to claim 1, characterized in that: Before the step of receiving and parsing the service request message from the source system and extracting the feature tuple of the service request message, the method includes: Generate a stock migration event based on the globally unique primary key of the stock data in the source system and register it in the migration event table; Triggering the source system to scan the stock migration event and obtain the corresponding stock data; The data receiving interface of the target system is called to transplant the stock data into the database of the target system.

3. The gateway-based business system migration method according to claim 1, characterized in that: Before the step of receiving and parsing the service request message from the source system and extracting the feature tuple of the service request message, the method further includes: Monitor the incremental data of the source system, generate corresponding incremental migration events and register them in the migration event table; Triggering the source system to scan the incremental migration event and obtain the corresponding incremental data; The data receiving interface of the target system is called to transplant the incremental data to the database of the target system.

4. The gateway-based business system migration method according to claim 1, wherein: The migration strategy based on the migration batch configuration rule, matching the feature tuple, and determining the corresponding target system includes: Loading a preset function switching gateway control rule, and determining an associated migration batch identifier according to the function code of the feature tuple; Based on the migration batch identifier, the target system is determined by using the migration batch configuration rule.

5. The gateway-based business system migration method according to claim 1, wherein: The step of mapping the service request message into a corresponding target request message and sending the message to the target system according to the interface mapping configuration file of the target system includes: Load the interface mapping configuration file of the target system and determine the field mapping rules and conversion logic; Based on the field mapping rules and conversion logic, perform field-level mapping conversion of the service request message to generate the target request message compatible with the target system; The target request message is sent to the target system.

6. The gateway-based business system migration method according to claim 1, characterized in that: The step of reversely mapping the target response message to the final response message of the source system based on the target response message of the target system and the interface mapping configuration file includes: Receive and parse the target response message of the target system, and extract the response feature tuple of the target response message; According to the reverse mapping rule in the interface mapping configuration file, the extracted response feature tuple is converted into a message format corresponding to the source system to generate the final response message of the source system.

7. The gateway-based business system migration method according to claim 1, characterized in that: After the step of reversely mapping the target response message to a final response message of the source system based on the target response message of the target system and the interface mapping configuration file, the method further includes: monitoring the operating state of the target system, and if the operating state is a fault state, analyzing the impact of the fault state; Based on the impact of the fault state, a corresponding rollback operation is triggered.

8. The gateway-based business system migration method according to claim 7, characterized in that: The step of triggering a corresponding rollback operation based on the impact result of the fault state includes: If the impact result is a response message format error, the corresponding service request message is rerouted back to the source system and the fault information is recorded; If the impact result is a partial function failure, the service request message corresponding to the partial function is rolled back to the source system, and the failure information is recorded; If the impact result is that the system cannot operate normally, all service request messages are routed back to the source system, the migration event is closed, and the data synchronization between the source system and the target system is stopped.

9. A gateway-based business system migration device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the gateway-based business system migration method according to any one of claims 1 to 8.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the gateway-based business system migration method according to any one of claims 1 to 8 are implemented.

Images