Multi-system development and production management methods, device and transaction online management systems

Abstract

This application provides a method, apparatus, and transaction launch management system for the development and production management of multiple systems. The method includes: obtaining information on the preset mapping relationships between published interfaces and transactions to obtain association information; dividing the published interfaces associated with transactions into the same launch window based on the association information to obtain production windows; processing the launch of the published interfaces associated with transactions in each production window, generating a prompt message after the launch processing, and sending the prompt message to the development device. This solution solves the problem in existing technologies where all systems undergo a "one-time synchronous production launch" mode during upgrades, completing system launch at the same time. This approach is prone to causing systemic service interruptions and has low efficiency in launching new systems.

Description

Technical Field

[0001] This application relates to the field of multi-system collaborative work technology, and more specifically, to a multi-system development and production management method, a multi-system development and production management device, a computer program product, and a transaction online management system. Background Technology

[0002] In the process of upgrading large-scale core software systems in banks, traditional technical solutions generally adopt the "one-time simultaneous production deployment of the entire system" model. This model requires all related systems (including core accounting systems, channel systems, payment and settlement systems, data reporting systems, message middleware, etc.) to complete code deployment, configuration updates, and service switching within a unified maintenance window at the same time, and verify the overall business continuity through backend end-to-end testing.

[0003] This model can still operate in environments with a small number of systems and low coupling, but as banks deepen their digital transformation, there are now more than a hundred stakeholders in the core system, and the interface relationships between systems have become increasingly complex and network-like. The transaction chain covers a multi-level architecture including the transaction layer, routing layer, data layer, and message layer, and the traditional synchronous production model has exposed serious technical bottlenecks.

[0004] Currently, all systems are upgraded using a "one-time simultaneous deployment" model, completing the system launch at the same time. This approach is prone to causing systemic service interruptions and has low efficiency in launching new systems. Summary of the Invention

[0005] The main purpose of this application is to provide a multi-system development and production management method, a multi-system development and production management device, a computer program product and transaction online management system, so as to at least solve the problem that in the prior art, all systems are upgraded in the "one-time synchronous production of the whole system" mode, and the system is launched at the same time. This method is prone to system service interruption and low efficiency of new system launch.

[0006] To achieve the above objectives, according to one aspect of this application, a multi-system development and production management method is provided, comprising: obtaining information on a preset mapping relationship between published interfaces and transactions to obtain association information; dividing the published interfaces associated with the transactions into the same online window according to the association information to obtain production windows; performing online processing on the published interfaces associated with the transactions in each production window, generating a prompt message after the online processing, and sending the prompt message to the device on the development end.

[0007] Optionally, the published interfaces associated with the transaction are grouped into the same online window according to the association information to obtain a production window, including: extracting all the published interfaces, and determining in sequence according to the association information whether there is a call dependency relationship between the extracted published interfaces and the transaction; if there is a call dependency relationship between the published interfaces and the transaction, the window where the transaction has not been executed and the published interface corresponding to the transaction has not been used is determined as the production window.

[0008] Optionally, based on the association information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production window, including: obtaining a score of the strength of the preset association dependency between the published interface and the transaction to obtain a dependency strength score; in the case that there is a call dependency relationship between the published interface and the transaction, the window that satisfies the following conditions is determined as the production window: the transaction is not executed, the dependency strength score between the published interface and the transaction is greater than a first preset score, and the published interface whose dependency strength score is greater than the first preset score is not used.

[0009] Optionally, based on the association information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production window, including: obtaining information on the preset transaction association relationship between the transaction and the transaction to obtain business impact information; finding the required associated transactions associated with the transaction based on the business impact information, and finding the published interfaces associated with the associated transactions; if there is a call dependency relationship between the published interfaces and the transaction, determining the window that satisfies the following conditions: the transaction is not executed, the associated transactions are not executed, the published interfaces corresponding to the transaction are not used, and the published interfaces corresponding to the associated transactions are not used, as the production window.

[0010] Optionally, based on the association information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production window, including: finding the transaction system that is pre-associated with the transaction; obtaining a pre-pre-defined complexity score of the mutual dependency between any two transaction systems to obtain a coupling difficulty score; and, in the case where there is a call dependency relationship between the published interface and the transaction, determining the window that satisfies the following conditions: the transaction is not executed, the published interface corresponding to the transaction is not used, and the coupling difficulty score between the two transaction systems corresponding to the transaction is greater than a second pre-preset score and the transaction system is not used, as the production window.

[0011] Optionally, based on the association information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production window, including: splitting the transaction system into multiple transaction subsystems, wherein any two transaction subsystems perform different functions; and, in the case where there is a call dependency relationship between the published interface and the transaction, determining the window that satisfies the following conditions: the transaction is not executed, the published interface corresponding to the transaction is not used, and at least one transaction subsystem associated with the transaction is not used, as the production window.

[0012] Optionally, in each production launch window, the published interfaces associated with the transaction are put into operation, including: if there are multiple published interfaces that need to be put into operation, obtaining the priority of the published interfaces; and putting the published interfaces into operation according to the priority order.

[0013] According to another aspect of this application, a multi-system development and production management device is provided, comprising: an acquisition unit, configured to acquire information on a preset mapping relationship between published interfaces and transactions, thereby obtaining association information; a division unit, configured to divide the published interfaces associated with the transactions into the same online window according to the association information, thereby obtaining a production window; and a processing unit, configured to perform online processing on the published interfaces associated with the transactions in each production window, generate a prompt message after the online processing, and send the prompt message to the development device.

[0014] According to another aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of any of the development and production management methods of the multi-system.

[0015] According to another aspect of this application, a transaction launch management system is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include methods for performing any of the multi-system development and production management methods described above.

[0016] By applying the technical solution of this application, the published interfaces associated with transactions are aggregated into the same production window. The launch time and triggering logic of different production windows are different, so that the system upgrades of different transaction links are staggered in time, avoiding concurrent changes across the entire system. The launch process is carried out only within a single window, and the remaining systems that do not participate in the window continue to run, ensuring the continuity of core business. This is equivalent to a distributed launch, which can avoid systemic service interruptions and thus improve the efficiency of system launch. Attached Figure Description

[0017] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 A hardware structure block diagram of a mobile terminal for implementing a multi-system development and production management method is shown in an embodiment of this application.

[0019] Figure 2 A flowchart illustrating a multi-system development and production management method according to an embodiment of this application is shown.

[0020] Figure 3 A structural block diagram of a multi-system development and production management device provided according to an embodiment of this application is shown.

[0021] The above figures include the following reference numerals:

[0022] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0023] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application:

[0027] Upgrading a bank's core system is a major technological project in the fintech field. Existing technologies generally adopt a system-wide synchronous deployment model, which includes the following technical aspects: using a unified system deployment time window, requiring all related systems to complete version releases and service switching simultaneously within the predetermined maintenance window; relying on a pre-set end-to-end test case set, using a waterfall verification process to conduct centralized testing of the entire system's functions, covering all nodes in the transaction chain; configuring a global rollback mechanism, which triggers a unified rollback command when any system experiences an anomaly after deployment, causing all systems involved in the deployment to revert to the previous stable version; and using an Enterprise Service Bus (ESB) to achieve protocol conversion and message routing between system interfaces, ensuring compatibility of interface calls at the communication layer. However, a dynamic identification, hierarchical management, and collaborative deployment scheduling mechanism for inter-system dependencies has not been established.

[0028] In the current solution, because all systems are changed synchronously within a unified window, any system anomaly may trigger a chain of failures, causing the impact of the failure to spread to multiple systems and significantly increasing the overall production risk. Existing dependency analysis tools are unable to fully identify cross-system call relationships, especially lacking the ability to penetrate and analyze ESB middleware, event-driven architecture, and database-level dependencies, resulting in an actual dependency coverage rate of less than 70%. After a failure occurs, there is a lack of structured link tracing and dependency correlation localization methods, and the root cause investigation requires manual comparison of logs and interface call records from multiple systems, with an average localization time of more than 2 hours.

[0029] As described in the background section, all existing systems are upgraded in a "one-time simultaneous production" mode, with the system going live at the same time. This approach is prone to causing systemic service interruptions and has low efficiency in launching new systems. To address these issues, embodiments of this application provide a multi-system development and production management method, a multi-system development and production management device, a computer program product, and a transaction online management system.

[0030] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0031] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a multi-system development and production management method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0032] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the multi-system development and production management method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one instance, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0033] This embodiment provides a development and production management method for multiple systems running on mobile terminals, computer terminals or similar computing devices. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] Figure 2 This is a flowchart illustrating a multi-system development and production management method according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0035] Step S201: Obtain information on the preset mapping relationship between the published interface and the transaction to obtain the association information;

[0036] Specifically, by collecting metadata of the interfaces that have been launched in each business system, including interface code, business semantic classification (such as payment type, query type), call frequency, transaction link to which it belongs (such as transfer transaction, contract transaction) and how it is referenced by downstream systems, a static mapping relationship table between interfaces and transactions is formed.

[0037] Step S202: Based on the above association information, the above-mentioned published interfaces associated with the above-mentioned transactions are assigned to the same online window to obtain the production window;

[0038] Specifically, based on the above mapping relationship, all published interfaces belonging to the same transaction link are aggregated into an indivisible production unit; for example, the "account inquiry" transaction of personal online banking involves core accounting system interface A, channel gateway interface B, and security authentication interface C, and the three are uniformly classified into the "inquiry transaction window"; different transaction links (such as transfer, wealth management contract signing, and data synchronization) are divided into different production windows because their dependency paths do not overlap.

[0039] Step S203: In each of the above-mentioned production windows, the above-mentioned published interfaces associated with the above-mentioned transactions are put into operation, and a prompt message is generated after the operation is completed and sent to the development device.

[0040] Specifically, during scheduled off-peak business hours (such as every Friday evening from 22:00 to 2:00 the next day), the corresponding interface versions are deployed sequentially according to the window order. After deployment, the system automatically performs lightweight connectivity verification (such as heartbeat detection) and transaction path simulation (simulating 100 typical transactions). After successful verification, a prompt message containing the window number, a list of deployed systems, the verification result (pass / fail), and the reason for failure (such as interface timeout or message format mismatch) can be generated and sent to the device on the development side.

[0041] In this embodiment, published interfaces associated with transactions are aggregated into the same production window. Different production windows have different launch times and triggering logics, which staggers the system upgrades of different transaction links in time, avoids concurrent changes across the entire system, and the launch process is carried out only within a single window. Other systems not participating in this window continue to run, ensuring the continuity of core business. This is equivalent to a distributed launch, which can avoid systemic service interruptions and thus improve the efficiency of system launch.

[0042] Specifically, the technical objectives of this application include: achieving independent production capabilities for core systems and related systems, enabling each system to complete version updates under non-full synchronization conditions, and avoiding global service interruptions due to single system anomalies; constructing a dependency graph covering all levels of the transaction chain, encompassing bidirectional calls and data dependencies between the service interface layer, routing layer, message channel, and database interaction layer; and establishing a hierarchical production decision model based on dependency strength, dynamically generating a production window sequence with time constraints and resource isolation requirements based on the frequency of calls between systems, business coupling, and the scope of rollback impact.

[0043] In the specific implementation process, based on the above-mentioned association information, the above-mentioned published interfaces associated with the above-mentioned transactions are divided into the same online window to obtain the production window. This can be achieved through the following steps: extract all the above-mentioned published interfaces, and determine in turn whether there is a call dependency relationship between the extracted above-mentioned published interfaces and the above-mentioned transactions based on the above-mentioned association information; if there is a call dependency relationship between the above-mentioned published interfaces and the above-mentioned transactions, the window where the above-mentioned transactions have not been executed and the above-mentioned published interfaces corresponding to the above-mentioned transactions have not been used is determined as the above-mentioned production window.

[0044] This solution achieves unique attribution of transaction-level interfaces by accurately identifying the dependencies between interfaces and transactions and intelligently matching them based on window occupancy status. This avoids dependency failures, verification gaps, and rollback difficulties caused by dispersed interface deployment, ensuring the integrity and consistency of changes within each production window.

[0045] "Published Interfaces" refers to system interfaces that are already running in the production environment and providing services to the outside world. Their information comes from the interface registry, routing logs, or middleware service catalog. "Call Dependencies" refers to the logical relationships in which an interface is directly or indirectly called when executing a transaction. This is confirmed by analyzing transaction logs, service call chain logs, and interface call matrices. A comprehensive scan of the actual call paths between all interfaces and transactions ensures that no interface involved in the transaction is missed, thereby avoiding incomplete deployment or operational anomalies due to dependency omissions.

[0046] "Transaction not executed" means that the transaction has not been deployed online in any production window; "Published interface not used" means that the interface has not been assigned to other production windows. This step uses an elimination method to filter out idle windows that neither carry the transaction nor contain the interface related to the transaction from all available windows, ensuring that the interface of each transaction link is deployed centrally and independently in the same window, preventing the interface from being split into multiple windows, which would cause dependency confusion or verification failure.

[0047] Specifically, the solution proposed in this application establishes a multi-level dependency information collection and structured management mechanism covering the entire transaction lifecycle, which includes the following four levels of standardized information registration: (1) service interface layer, (2) ESB routing layer, (3) channel access layer, and (4) transaction initiation layer.

[0048] Service Interface Layer: This layer assigns a unique identifier to each service component within the core system; standardizes and categorizes interface functions according to business semantics, with categorization dimensions including but not limited to payment, query, and account management; and records the version number for each interface, creating a version evolution trajectory for interface changes. This provides clear change signals, mitigating the risk of inconsistent content due to version inconsistencies before production deployment, standardizing processes, and coordinating with all parties involved.

[0049] The ESB routing layer collects and stores the global transaction serial number of each transaction forwarded by the ESB; based on the interface contract comparison mechanism, it automatically identifies the compatibility status of new and old versions of interfaces in terms of parameter structure, data format, and calling protocol; and records the registration information of each access system on the ESB, including communication protocol, authentication method, timeout threshold, and QoS parameters. This provides an accurate and executable benchmark for subsequent production deployment and verification processes. These parameters are directly used to configure the production environment and serve as the root cause basis for monitoring and troubleshooting, ensuring a controllable and traceable data foundation.

[0050] Channel access layer: Assigns a unique channel identifier to each front-end access channel; records the timestamp of each transaction request for link sequence reconstruction; distinguishes channel types, including counter terminals, personal online banking, corporate online banking, mobile APP and third-party platforms, etc.

[0051] Transaction Initiation Layer: Registers the business transaction code of the original transaction request as a unique identifier for the link entry; performs integrity verification on the transaction message, including message header verification, integrity of required fields, and validity of digital signature; associates the transaction with predefined business scenarios, including transfer, payment, account opening, contract signing, and query.

[0052] For long-link calls like A (front-end system) -> B (middle business system) -> C (core component), in principle, when calling a new core component, the standardization should start from system A to generate a global business tracking number, which better supports full-link tracing.

[0053] If A → B undergoes standardization in this phase, a transition period will be implemented:

[0054] In Mode 1, System A invokes the global route to determine whether to call the new or old core. System B provides two sets of interfaces, one new and one old. System A calls the new or old interface based on the call result. System B then calls the new or old core based on the corresponding interface. The funds clearing system uses this method, consistent with the new core for individuals. In the final state, all old interfaces are obsolete.

[0055] In Mode 2, System A calls the global route to determine whether to call the new or old core; System B provides a set of standardized interfaces, and System A needs to generate a sub-transaction sequence number when calling the new core; System B determines whether to call the new or old core based on the existence of the sub-transaction sequence number.

[0056] Solutions for other cases will be discussed on a case-by-case basis.

[0057] If A → B is partially calibrated this time (only the global business tracking number and sub-transaction sequence number are calibrated), refer to Mode 2 above.

[0058] If A → B fails to implement the standard this time, switch to the transition period:

[0059] System B calls the global route to determine whether to call the new or old core; when System B determines to call the new core, it needs to generate a new sub-transaction sequence number.

[0060] Solutions for other cases will be discussed on a case-by-case basis.

[0061] In cases where core processing is called multiple times in a single process, such as when A calls B once in the above chain, and B needs to call C (i.e., the core) multiple times, if a new core is called, B will generate a global business trace number from the second call (Note 1).

[0062] Specifically, for the production deployment window of this solution, several non-overlapping production deployment time periods are divided according to the off-peak business transaction cycle and system dependencies. Each window is configured with a clear start and end time and a reserved rollback operation time window to ensure that the upgrade operation does not affect online core transactions. For the supplementary test triggering mechanism of this solution, high-risk transaction scenarios are automatically identified based on the complexity of the transaction link, the frequency of historical failures, and the number of dependent systems, triggering a mandatory supplementary test process. Test types include, but are not limited to, stress testing, disaster recovery drills, and abnormal traffic injection testing. For the definition of supplementary test indicators of this solution, quantifiable execution parameters are set for each supplementary test, such as concurrent transaction throughput (e.g., not less than 5000 transactions / second), transaction success rate threshold (e.g., not less than 99.95%), and peak system resource utilization rate, which serve as hard standards for passing the test. For the business testing responsibility entity of this solution, a dedicated person from the business department is designated as the test execution person for each transaction link. This person is responsible for verifying the correctness of the function, the completeness of the process, and compliance according to the business scenario. The confirmation result is included in the approval process as a necessary condition before production deployment.

[0063] Specifically, this solution adopts a phased, segmented deployment mechanism, unlike the traditional one-time system-wide shutdown and switchover approach. The more than 130 related systems involved are divided into several independent deployment windows based on transaction links and dependencies. Each window contains 10 to 30 systems, with deployment times staggered to avoid concurrent conflicts in system changes. Systems within each window complete code deployment and basic verification during off-peak business hours. After deployment, the systems are in a "ready but not activated" state, not participating in actual transaction processing, and are only used for verifying interface connectivity, configuration correctness, and rollback feasibility. The deployment windows are divided based on business transaction chains, with each chain corresponding to a set of collaborative deployment windows. The system collection forms a complete "transaction candied hawthorn" unit. If the same system serves multiple transaction links (such as a counter system that supports both personal transfers and corporate settlements), it is split into different windows and deployed independently according to the core interfaces and business scenarios it calls. After all windows have completed pre-verification, when the core system is officially switched over, each window system is activated simultaneously to achieve end-to-end connectivity of the entire transaction path. The original old system continues to run until the new link is running stably and data consistency verification is completed before it can be taken offline. This mechanism ensures that any abnormal deployment of any window will not affect other windows and existing online business, realizing a non-intrusive upgrade path of "deployment is verification, online activation".

[0064] In this solution, the relationships between the published system interfaces and transaction links are obtained. These relationships include interface call relationships, data flow paths, and message distribution links. Based on these relationships, the multiple systems participating in the collaborative upgrade are divided into several independent and controllable production windows. Each production window contains a group of systems with direct or indirect relationships. Within each production window, a phased and constrained gradual production operation is performed. "Production" refers to deploying the new version of the software to the production environment and activating its service capabilities, but not immediately taking over all production transaction traffic. It is only used to verify interface connectivity, data synchronization, and message transmission correctness. The original systems continue to process production transactions. Only after all systems within the window have passed verification can the transaction traffic be switched uniformly at an opportune time.

[0065] The system is organized into groups according to three main links: "transaction line, data line, and message line" to ensure the integrity of business logic; supplementary tests are triggered for high-risk transactions (such as a 5,000 transactions / second concurrent stress test); the business department designates a person in charge to execute the test and confirm the results, realizing a dual-track closed loop of technical verification and business acceptance.

[0066] Specifically, this solution divides the collaborative relationships between systems into three independent but related production links based on the flow of business data, corresponding to transaction flow, data flow and message flow respectively. Each link independently constructs a dependency graph and implements hierarchical production control.

[0067] Transaction line: Starting with customer-initiated business transactions, it covers the end-to-end call chain from channel access and core accounting processing to peripheral service response, such as transfer, query, payment, etc. Production units are divided according to transaction type and core dependency intensity to ensure that critical transaction paths are verified at each level;

[0068] Data line: A batch data synchronization link used to support post-event analysis and regulatory reporting, including transaction details, balance snapshots, risk control events and other data generated by the core system at the end of the day. After processing, the data is pushed to the data warehouse, regulatory reporting system and reporting platform. This link is put into production independently of the transaction line, and the window is divided according to the data consumer dependency relationship and processing timeliness.

[0069] Message line: An asynchronous notification link based on an event-driven architecture, used for inter-system state synchronization and external channel notifications, such as SMS push, APP notification, reconciliation trigger, audit log distribution, etc. Message producers and consumers are decoupled through a unified message bus (such as Kafka, RocketMQ), and production control is carried out in a hierarchical manner according to message topic, number of consumers and reliability requirements.

[0070] The deployment windows for the three links are independently modeled based on their internal system hierarchy, data coupling, recovery timeliness, and business impact scope. They support parallel, interleaved, or serial deployment, ensuring that the upgrade process of each link does not interfere with each other, can be rolled back independently, and can be verified separately.

[0071] In some embodiments, based on the aforementioned association information, the published interfaces associated with the aforementioned transactions are grouped into the same online window to obtain a production window. Specifically, this can be achieved through the following steps: obtaining a score of the preset association dependency strength between the published interfaces and the aforementioned transactions to obtain a dependency strength score; in the case where there is a call dependency relationship between the published interfaces and the aforementioned transactions, the window that satisfies the following conditions is determined as the production window: the transaction has not been executed, the dependency strength score between the published interfaces and the aforementioned transactions is greater than a first preset score, and the published interfaces that have not been used have a dependency strength score greater than the first preset score.

[0072] This solution introduces a dependency strength score as a screening mechanism to accurately identify and isolate high-risk transaction links, allowing the production deployment window to focus on key interface combinations that truly affect system stability, effectively avoiding interference from low-value changes on the verification of high-risk transactions.

[0073] The "Dependency Strength Score" is a quantitative indicator that is assigned a comprehensive value based on the frequency of API calls, criticality, scope of transaction impact, and risk of cascading responses. For example, APIs that are called frequently, involve fund deductions, or trigger compensation logic in multiple systems are assigned a score of 80–100, while APIs that are only used for querying and have no side effects are assigned a score of 20–40. This score is predefined based on historical transaction logs, system monitoring data, and expert review rules, and is used to objectively measure the impact of APIs on the success or failure of transactions.

[0074] The dependency strength score is calculated by weighting five indicators: historical call frequency, transaction impact scope, fund change attributes, number of chain response nodes, and fault recovery cost. Each indicator is scored from 0 to 20 points, with a total score range of 0 to 100 points. For example, a payment interface that involves fund deduction, triggering reconciliation, end-of-day reconciliation, and regulatory reporting has a high call frequency and a wide impact scope, and can score up to 95 points. An interface that is only used to query the balance and has no state changes will score less than 30 points because it has no transaction impact.

[0075] The "first preset score" is a set threshold, such as 70 points, used to distinguish between high-risk and low-risk dependencies. This step only includes interfaces and transaction combinations with a dependency strength higher than 70 points in the production window, excluding low-intensity dependency interfaces, to ensure that high-risk core links are verified first. At the same time, it is required that the window has neither deployed the transaction nor been occupied by other high-intensity dependency interfaces, to ensure that high-risk transaction links complete end-to-end verification in a unique and independent window, avoiding interference caused by mixing with other changes.

[0076] Specifically, this solution constructs a multi-level deployment window scheduling mechanism based on the differences in the strength of dependencies between systems. The window division rules are as follows:

[0077] For highly dependent systems (where interface changes are incompatible (e.g., deleting fields, modifying data types, adding mandatory validation), or involving bidirectional transactions or strong consistency links related to funds, deployment must be coordinated with related systems and implemented in a "callee priority" order, with full-link synchronous recovery during rollback), strict deployment timing constraints should be set, requiring them to be deployed sequentially according to the preset dependency order. For example, the core accounting system must be upgraded before the external clearing system. A minimum of 2 hours of isolation buffer time should be reserved between each highly dependent system group for status verification and abnormal rollback preparation.

[0078] For weakly dependent systems (where the interface changes but remains backward compatible (e.g., adding non-required fields or expanding enumeration values), downstream systems can operate normally without synchronous modifications. This system can be deployed first, and downstream systems can be adapted at a later date), parallel deployment with non-strongly dependent systems is allowed, provided resource isolation is met. Before deployment, resource conflict detection must be performed to ensure that there are no contention conflicts for critical resources such as CPU, database connections, and message queues.

[0079] For independent systems without external dependencies (no interface changes or only internal logic modifications within the system, used only for testing, etc.), they can be deployed independently and are not constrained by the production windows of other systems. They are allowed to choose their own production windows during off-peak business hours and do not participate in unified scheduling.

[0080] The implementation process is as follows: Each system's team submits a standardized form containing: production version information, rollback trigger conditions, step-by-step rollback steps, and dependency verification points; the production command center automatically generates a production execution sequence including timing, resource allocation, and dependency constraints based on the dependency graph and the information submitted by the system, and outputs a visual Gantt chart; a joint review group composed of technical and business representatives conducts final confirmation of the production plan, forming a production instruction document with version control and approval records as the basis for execution.

[0081] In the specific implementation process, based on the aforementioned association information, the published interfaces associated with the aforementioned transactions are grouped into the same online window to obtain the production window. This can be achieved through the following steps: obtaining information on the preset transaction association relationships between the aforementioned transactions to obtain business impact information; finding the required associated transactions associated with the aforementioned transactions based on the aforementioned business impact information, and finding the aforementioned published interfaces associated with the aforementioned associated transactions; in the case where there is a call dependency relationship between the aforementioned published interfaces and the aforementioned transactions, the window that satisfies the following conditions is determined as the aforementioned production window: the aforementioned transaction has not been executed, the aforementioned associated transactions have not been executed, the aforementioned published interfaces corresponding to the aforementioned transactions have not been used, and the aforementioned published interfaces corresponding to the aforementioned associated transactions have not been used.

[0082] This solution expands production deployment from a single transaction to the entire business chain by introducing business relationships between transactions. This ensures that highly dependent transactions and their interfaces are launched collaboratively in a unified window, avoiding business breakpoints and data inconsistencies caused by split deployment of transactions, and improving the completeness of collaborative production deployment across multiple transaction chains.

[0083] "Required related transactions" refers to other transactions that must be completed synchronously or in advance to support the normal operation of the target transaction; "Related published interfaces" refers to all online interfaces that participate in the related transaction; this step traces back all related transactions and their underlying interfaces through business impact information to ensure that when dividing the window, not only the target transaction itself is considered, but also all its dependent upstream and downstream business links are covered, preventing business logic breakage due to the omission of related transactions.

[0084] The above solution ensures that the target transaction and all its related transactions are deployed uniformly within the same window, and that none of its interfaces are occupied by other windows. This avoids data inconsistencies, status errors, or service unavailability caused by the phased launch of related transactions. For example, wealth management contract signing transactions and fund account opening transactions must be launched in the same window. If their respective interfaces are deployed separately, customers will be unable to purchase products after signing the contract.

[0085] The system filters through all available production windows, designating a window as the final production window only if the target transaction and all its required related transactions have not been deployed, and all interfaces involved in these transactions are not occupied by other windows. For example, if window 7 has deployed the "Personal Mobile Banking Account Opening" interface, window 11 has deployed the "Credit Card Application" interface, and window 14 is completely idle, then window 14 is automatically marked as the dedicated production window for this business link when it is confirmed that "Corporate Online Banking Sign-up" and its three required related transactions are not deployed in window 14, and all six of its published interfaces (2 for the target transaction + 4 for related transactions) are not occupied by other windows. All related code and interfaces will be deployed in this window at once, ensuring the complete and effective business loop.

[0086] In some embodiments, based on the aforementioned association information, the published interfaces associated with the aforementioned transactions are grouped into the same online window to obtain a production window. This can be achieved through the following steps: finding the transaction systems that are pre-defined to be associated with the aforementioned transactions; obtaining a pre-defined score for the complexity of the mutual dependence between any two of the aforementioned transaction systems to obtain a coupling difficulty score; and determining the production window as such when there is a call dependency relationship between the published interfaces and the aforementioned transactions, provided that the aforementioned transactions are not executed, the published interfaces corresponding to the aforementioned transactions are not used, and the coupling difficulty score between the two aforementioned transaction systems corresponding to the aforementioned transactions is greater than a second pre-defined score.

[0087] This solution introduces a difficulty score for inter-system coupling, extending the logic for dividing the production window from "transaction association" to the level of "system-level high-risk coupling," ensuring that highly complex interactive systems must be deployed collaboratively within a unified window. This effectively avoids transaction consistency disruptions, data asynchronization, and cascading failures caused by splitting and deploying systems with strong cross-system dependencies, transforming the production behavior of high-risk business links from "passive repair" to "active isolation," significantly improving the stability of multi-system collaborative production deployment.

[0088] "Transaction system" refers to the independent software system that participates in executing the transaction, such as the core accounting system, channel access system, risk control system, and messaging platform; "Preset required associations" is a list of systems that must work together to complete the transaction, as specified in the business process and system architecture documents. For example, the "counter transfer" transaction requires calling three systems: the "core accounting system", the "payment and settlement system", and the "message notification system".

[0089] The "coupling difficulty score" is a quantitative indicator that measures the complexity of interaction between two systems. It is calculated based on five factors: historical call frequency, message format complexity, transaction consistency requirements, scope of cascading impact of failures, and interface version compatibility. The maximum score is 100 points. For example, the "core accounting system" and the "payment and settlement system" need to synchronize fund flows in real time and ensure T+0 reconciliation. The message contains 120 fields and involves multi-level transaction rollbacks, so the coupling difficulty score is 92 points. On the other hand, the "core accounting system" and the "message notification system" only send simple notification events and have no state dependency, so the score is 35 points.

[0090] For example, the second preset score is set to 70 points to identify high-risk coupled system pairs; only when the coupling difficulty score between two systems exceeds 70 points will they be included in the "strong coupling constraint" range.

[0091] Specifically, this plan implements a gradual, risk-driven production sequence control based on the complexity of the transaction chain, the degree of interface coupling, and the scope of system impact.

[0092] The deployment windows are sorted according to the system's "access risk level". Priority is given to deploying systems with simple interface calls, few dependent nodes, and narrow business impact, such as personal online banking and mobile banking, which only call a few query interfaces. This ensures that the connectivity of the basic transaction link and network stability are verified first.

[0093] Highly complex systems, such as counter systems and corporate online banking platforms involving multiple business types (corporate, personal, and card services), multiple interface aggregations, and multiple subsystem linkages, should be decoupled and split according to their internal functional modules and incorporated into different production windows to avoid excessive changes in a single window.

[0094] The deployment sequence of each production window follows the principle of "from low to high" risk progression: first deploy single transaction path, low concurrency, non-core accounting systems, and then gradually introduce complex business links with high concurrency, multiple transactions, and strong consistency requirements.

[0095] The order of system deployment is determined by their topological position in the transaction chain: edge access systems take precedence over core processing systems, single-point call systems take precedence over aggregation platform systems, and non-accounting systems take precedence over accounting and settlement systems, ensuring that the stability of the critical path has been fully verified before high-risk changes in the later stages.

[0096] This incremental deployment strategy effectively reduces the impact of a single deployment on customer perception by controlling the scope of each batch of changes, and avoids business disruptions or public opinion risks caused by large-scale changes.

[0097] Specifically, this solution divides the transaction chain into two categories, "direct connection to the core" and "non-direct connection to the core," based on the interaction method between the transaction request and the core system, and implements differentiated production control strategies accordingly.

[0098] Direct connection to the core transaction refers to a transaction type in which the front-end channel system directly calls the public interface of the core system to complete the business processing. Its call path is clear, the interface boundary is well-defined, and the request-response link is visible from end to end, such as querying balance and single transfer. The production unit of this type of transaction is based on the interface call relationship. The dependency relationship is simple, and it is first included in the low-risk window for verification.

[0099] Non-direct core transactions refer to transaction types where the transaction request is encapsulated, orchestrated, or routed through the middleware business system to indirectly access the core system. The call path is not visible to the front end, and the actual interface of the core system is shielded by the middleware layer. The middleware system undertakes complex logic such as multi-interface collaboration, transaction compensation, and state aggregation. For example, in a contract signing transaction, the wealth management middleware uniformly calls multiple core interfaces such as credit, account, and contract, and implements distributed transaction control of "commit if all succeed, rollback if any fails".

[0100] The deployment of non-directly connected core transactions is managed as an independent unit of the middle platform system. Its internal dependencies are maintained uniformly by the middle platform system team. The deployment window is defined not to penetrate to the underlying interface of the core system, but only to verify the compliance and transaction consistency of the middle platform's input and output contracts. This classification mechanism uses "interface visibility" and "logical encapsulation boundary" as the criteria to achieve decoupling management between the core system and the peripheral system, reduce the complexity of multi-team collaboration, support the independent evolution of the middle platform system, and at the same time ensure the stability and predictability of core system changes.

[0101] Specifically, this solution constructs clear system boundaries and responsibility attribution mechanisms through the vertical decomposition and platform-based encapsulation of business capabilities. Highly complex, cross-system business logic is separated from front-end channels and core accounting systems and centralized into domain-specific platform systems. For example, the wealth management platform uniformly manages the entire lifecycle of wealth management products, including creation, issuance, operation during their term, and termination; the credit platform and precious metals platform are responsible for transaction orchestration, rule verification, and transaction coordination in their respective business domains. Each platform system acts as an independent business service unit, providing standardized interface contracts externally and aggregating calls to multiple core systems internally, achieving the encapsulation capability of "one call, multi-system collaboration." The platform system does not expose the core interface details of its internal calls, but only defines input / output semantics and transaction consistency requirements through contracts.

[0102] Production management uses the middle platform system as the smallest control unit. The scope of interface changes, dependencies, and production windows are all registered and reviewed based on the middle platform contract, avoiding direct intervention in the underlying core system interfaces. Each middle platform system's production plan is independently formulated and verified, and its changes only affect its upstream channels and downstream data consumers. The production content, interface scope, dependencies, and responsible teams for all systems (including the middle platform) are included in a unified production registration ledger. Before production, a secondary verification is performed based on the latest interface version and dependency graph to ensure traceability of changes, identifiable responsible parties, and unambiguous collaboration boundaries. This mechanism achieves standardization of technical collaboration and clarification of organizational responsibilities through "capability encapsulation, contract-driven, and unit management," preventing shirking of responsibility and misoperation due to ambiguous system boundaries, and ensuring the controllability and auditability of multi-team parallel development and production processes.

[0103] In the specific implementation process, based on the aforementioned association information, the published interfaces associated with the aforementioned transactions are assigned to the same online window to obtain the production window. This can be achieved through the following steps: the aforementioned transaction system is split into multiple transaction subsystems, wherein any two of the aforementioned transaction subsystems perform different functions; in the case where there is a call dependency relationship between the aforementioned published interfaces and the aforementioned transactions, the window that satisfies the following conditions is determined as the aforementioned production window: the aforementioned transaction has not been executed, the aforementioned published interfaces corresponding to the aforementioned transactions have not been used, and at least one of the aforementioned transaction subsystems associated with the aforementioned transactions has not been used.

[0104] This solution achieves precise and low-interference deployment of highly complex systems by refining the transaction system into functionally independent subsystems and restricting window allocation to only the subsystems actually invoked. While ensuring the integrity of the highly coupled transaction chain, it significantly reduces window waiting time caused by overall system occupancy, making deployment scheduling more efficient and flexible. This avoids global blocking caused by a single system intervention while maintaining the security control principle of "isolation on demand and minimal impact," thus improving the overall efficiency of multi-system collaborative deployment.

[0105] "Transaction system" refers to a complete software system that participates in the execution of a transaction, such as a "core accounting system" or a "corporate online banking system." "Splitting" refers to dividing the original system into multiple independent deployment units, namely "transaction subsystems," according to their functional responsibilities. Each subsystem is responsible for only a single and specific business function. For example, the "core accounting system" can be split into three parts: "account management subsystem," "funds clearing subsystem," and "interest calculation and reconciliation subsystem." The functions of these three parts do not overlap, and they respectively handle account status maintenance, fund transfer, interest calculation, and end-of-day reconciliation. This splitting is based on the system architecture design document and module boundary definition, and its purpose is to achieve more granular deployment control and avoid the high risks brought about by the overall upgrade of a single system.

[0106] After identifying the target transaction and its dependent published interfaces, it is further determined whether it calls any subsystem under a certain transaction system. For example, a "remittance" transaction may only call the "funds clearing subsystem" and "interest reconciliation subsystem" in the "core accounting system" without involving the "account management subsystem". In this case, it is only necessary to ensure that these two called subsystems are not occupied by other windows and that the target transaction and its corresponding interface are not deployed. The window that meets the conditions can be identified as the production window without waiting for the entire "core accounting system" to be idle. This mechanism allows for "partial upgrades and partial deployment" within the system, significantly improving window utilization and deployment flexibility.

[0107] In some embodiments, the published interfaces associated with the above-mentioned transactions are put online in each of the above-mentioned production windows. Specifically, this can be achieved through the following steps: when there are multiple published interfaces that need to be put online, the priority of the published interfaces is obtained; and the published interfaces are put online according to the order of priority.

[0108] This solution introduces an interface priority mechanism to achieve orderly and controllable deployment of multiple interfaces within a single window, effectively preventing dependency conflicts caused by concurrent deployment. This improves the stability of interface deployment without altering the overall deployment rhythm of the window, ensuring that critical transaction links are prioritized.

[0109] "Published Interfaces" refers to system call endpoints that have been registered on the interface management platform, tested and verified, and officially provided to the public, such as "Account Balance Inquiry Interface V3.2" and "Payment Instruction Issuance Interface V4.0". "Priority" is a pre-set order of deployment based on the criticality, scope of impact, and consequences of failure of the interface in the business process. It is determined by the business department and the technical team through joint review and is divided into three levels: high, medium, and low. For example, "Core Accounting Interface" is designated as high priority because it directly affects the accuracy of funds, while "SMS Notification Interface" is designated as low priority because it is only used for customer reminders. This step automatically identifies the relative importance of all interfaces to be deployed in the current window by reading the priority field in the interface registration ledger, providing a basis for orderly deployment.

[0110] When performing the deployment operation, interfaces are deployed in strict order of priority from high to low. That is, high-priority interfaces are deployed first, and medium and low-priority interfaces are deployed in turn after they are confirmed to be running normally. For example, if the "core accounting interface", "transfer result feedback interface" and "SMS notification interface" need to be deployed simultaneously in a certain window, the "core accounting interface" will be deployed and verified first. Only after its response is stable and the transaction flow is written normally will the "transfer result feedback interface" be started, and the "SMS notification interface" will be deployed last. This order ensures that critical business links are established first and avoids the rollback of high-priority interfaces or business interruption due to the abnormality of low-priority interfaces.

[0111] In addition, the solution in this application also includes an intelligent correction mechanism for the production window based on dynamic call chain backtracking. After the initial window planning is completed, if a system temporarily changes its interface version or adds dependencies before production, "call chain backtracking" is automatically triggered: starting from the changed interface, all upstream transactions, related systems, and allocated windows are traversed in reverse to identify whether there is a risk of "cross-window dependency breakage". If a highly coupled system is found to be split into different windows, a "window merging suggestion" is automatically generated and the original window is locked, forcibly merging the relevant systems back into the same window, while notifying the relevant teams.

[0112] Once the production window planning is completed, if any transaction system assigned to a production window undergoes an interface version change or adds new call dependencies, the call chain backtracking process will be automatically triggered. The call chain backtracking process includes: starting from the changed interface, traversing all its upstream transactions and related systems in reverse, identifying all transactions and systems that have direct or indirect call dependencies with the changed interface; determining whether there are at least two systems in the above reverse traversal results that have been assigned to different production windows, and whether their dependencies meet the preset high coupling judgment criteria; if so, the system will automatically generate a window merging suggestion, lock the production plan of the relevant systems in the original window, and re-merge the changed interface and all its related systems into the same production window, while sending a change notification to the relevant responsible team.

[0113] In addition, this application also includes a "time stitching" scheduling scheme for multi-window collaborative production. Since there are time intervals between windows (e.g., window 1 is from 23:00 to 01:00, window 2 is from 01:30 to 03:30), during scheduling, the system automatically calculates whether the "time stitching gap" between adjacent windows is sufficient to complete data synchronization (e.g., T+0 batch synchronization between the core and the data platform). If the gap is insufficient, the system automatically compresses the rollback time of the previous window, extends the start time of the next window, or inserts a "synchronization buffer window" to ensure data consistency.

[0114] When planning multiple production windows, the system identifies the time gaps between adjacent windows and obtains the key data synchronization tasks that need to be completed within those gaps. These key data synchronization tasks include the core system pushing daily transaction logs to the data processing platform, generating reconciliation files, or initializing regulatory reporting data. The system calculates whether the duration of the time gap is greater than or equal to the preset completion time of the key data synchronization tasks. If the time gap is less than the preset completion time, the system automatically adjusts the start and end times of adjacent windows by compressing the rollback buffer period of the previous window, delaying the start time of the next window, or inserting a buffer window for data synchronization only between adjacent windows, so that the key data synchronization tasks are completed before the system goes live.

[0115] Specifically, this solution solidifies organizational management elements into technical control points for the production deployment process through a structured registration and responsibility binding mechanism. Transaction types are categorized according to business semantics into standard categories such as query, payment, account management, and contract signing, serving as input for production priority determination and test coverage strategies. Different categories correspond to different verification intensities and rollback thresholds. Each transaction is associated with its respective business department and office, serving as the responsible entity for production approval and business verification, ensuring that the scope of change impact is confirmed by the corresponding business unit, and production items without the business party's signature cannot enter the execution process. The transformation task for each transaction clearly designates a leading technical team, which is solely responsible for interface changes, dependency updates, and production scripts, and its changes must be approved. Submissions can only proceed after the system's dependency graph has been verified. Cross-team collaboration dependencies are automatically mapped by the system and trigger collaborative notifications. Each production deployment window has a designated business manager whose permissions are bound to the production deployment decision system. This manager is responsible for the final confirmation of the validity of test results, business continuity compliance, and the feasibility of rollback plans. Production deployment operations without the authorization of the business manager are not allowed to be initiated. All changes to the production deployment plan must be recorded with a clear reason for the delay, such as "third-party system interface not delivered on time" or "data consistency verification failed." The system automatically archives these changes and associates them with the corresponding system and transaction link for subsequent process auditing and training of automated risk warning models.

[0116] In summary, the solution proposed in this application can achieve decoupling and production deployment of the core system and related systems, eliminating the risk of global paralysis; it can construct a full-link dependency graph, covering multi-level interfaces of ESB / EDA / database; and it can establish a hierarchical production deployment decision method through the optimal window sequence of dependency strength.

[0117] In addition to using interface change declaration files, a dedicated interface management platform can be employed for collaborative management of interface changes. This platform facilitates the sharing, querying, and version control of interface information, ensuring that related systems are promptly informed of interface changes. Regarding tools for end-to-end workflow analysis, besides manual analysis combined with registration, automated workflow analysis tools can be used to automatically identify various elements in the transaction process by scanning system code and configuration files, improving efficiency and accuracy. For workflow command, in addition to enterprise scheduling groups, professional project management collaboration tools can be used to integrate task allocation, progress tracking, and information communication, ensuring smooth cross-team collaboration.

[0118] This solution has been proven feasible through practical application. In the multi-system deployment process of a large-scale core software system in a real bank, the adoption of this technical solution significantly reduced risks and narrowed the impact of single-system failures; greatly improved end-to-end controllability; achieved a high transaction success rate during deployment; and reduced fault location time. Furthermore, it supports the coexistence of old and new systems during the transition period, enabling zero-interruption upgrades of critical business operations, fully demonstrating the feasibility and effectiveness of this solution.

[0119] This application also provides a multi-system development and production management device. It should be noted that this device can be used to execute the multi-system development and production management method provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0120] The following describes the multi-system development and production management device provided in the embodiments of this application.

[0121] Figure 3 This is a structural block diagram of a multi-system development and production management device according to an embodiment of this application. (For example...) Figure 3 As shown, the device includes:

[0122] The acquisition unit 10 is used to acquire information about the preset mapping relationship between the published interface and the transaction, and obtain the association information;

[0123] Division unit 20 is used to divide the published interfaces associated with the above transactions into the same online window according to the above association information, so as to obtain the production window;

[0124] The processing unit 30 is used to process the published interface associated with the transaction in each of the above-mentioned production windows, generate a prompt message after the online processing, and send the prompt message to the device on the development side.

[0125] In this embodiment, published interfaces associated with transactions are aggregated into the same production window. Different production windows have different launch times and triggering logics, which staggers the system upgrades of different transaction links in time, avoids concurrent changes across the entire system, and the launch process is carried out only within a single window. Other systems not participating in this window continue to run, ensuring the continuity of core business. This is equivalent to a distributed launch, which can avoid systemic service interruptions and thus improve the efficiency of system launch.

[0126] In the specific implementation process, the partitioning unit includes an extraction module and a first partitioning module. The extraction module is used to extract all the above-mentioned published interfaces and determine, according to the above-mentioned association information, whether there is a call dependency relationship between the extracted above-mentioned published interfaces and the above-mentioned transactions. The first partitioning module is used to determine the window where the above-mentioned transaction has not been executed and the above-mentioned published interface corresponding to the above-mentioned transaction has not been used as the above-mentioned production window when there is a call dependency relationship between the above-mentioned published interfaces and the above-mentioned transactions.

[0127] This solution achieves unique attribution of transaction-level interfaces by accurately identifying the dependencies between interfaces and transactions and intelligently matching them based on window occupancy status. This avoids dependency failures, verification gaps, and rollback difficulties caused by dispersed interface deployment, ensuring the integrity and consistency of changes within each production window.

[0128] In some embodiments, the partitioning unit includes a first acquisition module and a second partitioning module. The first acquisition module is used to acquire a score of the strength of a preset association dependency between the published interface and the transaction, and obtain a dependency strength score. The second partitioning module is used to determine the window that satisfies the following conditions when there is a call dependency relationship between the published interface and the transaction: the transaction is not executed, the dependency strength score between the published interface and the transaction is greater than a first preset score, and the published interface is not used when the dependency strength score of the transaction is greater than the first preset score.

[0129] This solution introduces a dependency strength score as a screening mechanism to accurately identify and isolate high-risk transaction links, allowing the production deployment window to focus on key interface combinations that truly affect system stability, effectively avoiding interference from low-value changes on the verification of high-risk transactions.

[0130] In the specific implementation process, the partitioning unit includes a second acquisition module, a first search module, and a third partitioning module. The second acquisition module is used to acquire information on the preset transaction association relationship between the above transactions and obtain business impact information. The first search module is used to find the required associated transactions associated with the above transactions based on the above business impact information, and to find the above published interfaces associated with the above associated transactions. The third partitioning module is used to determine the window that satisfies the following conditions when there is a call dependency relationship between the above published interfaces and the above transactions: the above transactions are not executed, the above associated transactions are not executed, the above published interfaces corresponding to the above transactions are not used, and the above published interfaces corresponding to the above associated transactions are not used, as the above production window.

[0131] This solution expands production deployment from a single transaction to the entire business chain by introducing business relationships between transactions. This ensures that highly dependent transactions and their interfaces are launched collaboratively in a unified window, avoiding business breakpoints and data inconsistencies caused by split deployment of transactions, and improving the completeness of collaborative production deployment across multiple transaction chains.

[0132] In some embodiments, the partitioning unit includes a second search module, a third acquisition module, and a fourth partitioning module. The second search module is used to find the transaction system that is pre-associated with the transaction. The third acquisition module is used to acquire a pre-defined score of the complexity of the interdependence between any two of the transaction systems to obtain a coupling difficulty score. The fourth partitioning module is used to determine the production window as the window that satisfies the following conditions: the transaction is not executed, the published interface corresponding to the transaction is not used, and the coupling difficulty score between the two transaction systems corresponding to the transaction is greater than the second pre-defined score.

[0133] This solution introduces a difficulty score for inter-system coupling, extending the logic for dividing the production window from "transaction association" to the level of "system-level high-risk coupling," ensuring that highly complex interactive systems must be deployed collaboratively within a unified window. This effectively avoids transaction consistency disruptions, data asynchronization, and cascading failures caused by splitting and deploying systems with strong cross-system dependencies, transforming the production behavior of high-risk business links from "passive repair" to "active isolation," significantly improving the stability of multi-system collaborative production deployment.

[0134] In the specific implementation process, the division unit includes a fifth division module and a sixth division module. The fifth division module is used to split the above-mentioned transaction system into multiple transaction subsystems, wherein any two of the above-mentioned transaction subsystems perform different functions. The sixth division module is used to determine the above-mentioned production window when there is a calling dependency relationship between the above-mentioned published interface and the above-mentioned transaction. The window that satisfies the following conditions is that the above-mentioned transaction is not executed, the above-mentioned published interface corresponding to the above-mentioned transaction is not used, and at least one of the above-mentioned transaction subsystems associated with the above-mentioned transaction is not used.

[0135] This solution achieves precise and low-interference deployment of highly complex systems by refining the transaction system into functionally independent subsystems and restricting window allocation to only the subsystems actually invoked. While ensuring the integrity of the highly coupled transaction chain, it significantly reduces window waiting time caused by overall system occupancy, making deployment scheduling more efficient and flexible. This avoids global blocking caused by a single system intervention while maintaining the security control principle of "isolation on demand and minimal impact," thus improving the overall efficiency of multi-system collaborative deployment.

[0136] In some embodiments, the processing unit includes a fourth acquisition module and an online module. The fourth acquisition module is used to acquire the priority of the published interfaces when there are multiple published interfaces that need to be online. The online module is used to perform online processing on the published interfaces according to the priority order.

[0137] This solution introduces an interface priority mechanism to achieve orderly and controllable deployment of multiple interfaces within a single window, effectively preventing dependency conflicts caused by concurrent deployment. This improves the stability of interface deployment without altering the overall deployment rhythm of the window, ensuring that critical transaction links are prioritized.

[0138] The aforementioned multi-system development and production management device includes a processor and a memory. The acquisition unit, partitioning unit, and processing unit are all stored as program units in the memory, and the processor executes these program units to achieve the corresponding functions. All of the above modules reside in the same processor; alternatively, the modules may be located in different processors in any combination.

[0139] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, the current technology addresses the problem that all system upgrades follow a "one-time simultaneous deployment" model, completing the system launch at the same time. This approach is prone to systemic service interruptions and has low efficiency in launching new systems.

[0140] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0141] This invention provides a computer-readable storage medium that includes a stored program, wherein the program, when running, controls the device containing the computer-readable storage medium to execute the multi-system development and production management method.

[0142] This invention provides a processor for running a program, wherein the program executes the multi-system development and production management method.

[0143] This invention provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements development and production management method steps for at least multiple systems. The device described herein can be a server, PC, PAD, mobile phone, etc.

[0144] This application also provides a computer program product that, when executed on a data processing device, is suitable for executing a program that initializes a multi-system development and production management method with at least the following steps.

[0145] This application also provides a transaction launch management system, including one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include methods for executing any of the above-described multi-system development and production management methods.

[0146] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0147] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

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

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

[0151] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0152] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0153] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0154] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0155] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0156] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A multi-system development and production management method, characterized in that, include: Obtain information on the pre-defined mapping relationships between published interfaces and transactions to obtain the association information; Based on the association information, the published interfaces associated with the transaction are assigned to the same online window to obtain the production window; In each production window, the published interface associated with the transaction is put into operation, and a prompt message is generated after the operation is completed and sent to the development device.

2. The method according to claim 1, characterized in that, Based on the associated information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production deployment window, including: Extract all the published interfaces, and determine, based on the association information, whether there is a call dependency relationship between the extracted published interfaces and the transaction; In cases where there is a call dependency between the published interface and the transaction, the window where the transaction has not been executed and the corresponding published interface has not been used is determined as the production window.

3. The method according to claim 2, characterized in that, Based on the associated information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production deployment window, including: Obtain the score of the pre-defined correlation strength between the published interface and the transaction to obtain the dependency strength score; In cases where there is a call dependency between the published interface and the transaction, the window that satisfies the following conditions is determined as the production window: the transaction is not executed, the dependency strength score between the published interface and the transaction is greater than a first preset score, and the published interface with a dependency strength score greater than the first preset score is not used.

4. The method according to claim 2, characterized in that, Based on the associated information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production deployment window, including: Obtain information on the preset transaction association relationships between the transactions to obtain business impact information; Based on the business impact information, find the required related transactions associated with the transaction, and find the published interfaces associated with the related transactions; In cases where there is a call dependency between the published interface and the transaction, the window that satisfies the following conditions is determined as the production window: the transaction is not executed, the related transaction is not executed, the published interface corresponding to the transaction is not used, and the published interface corresponding to the related transaction is not used.

5. The method according to claim 2, characterized in that, Based on the associated information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production deployment window, including: Locate the transaction system that is pre-associated with the transaction; Obtain a score representing the degree of complexity of the pre-defined interdependence between any two of the transaction systems, thus obtaining a coupling difficulty score; In cases where there is a call dependency between the published interface and the transaction, the window that satisfies the following conditions is determined as the production window: the transaction is not executed, the published interface corresponding to the transaction is not used, and the coupling difficulty score between the two transaction systems corresponding to the transaction is greater than the second preset score.

6. The method according to claim 5, characterized in that, Based on the associated information, the published interfaces associated with the transaction are grouped into the same online window to obtain a production deployment window, including: The trading system is broken down into multiple trading subsystems, wherein any two trading subsystems perform different functions; In cases where there is a call dependency between the published interface and the transaction, the window that satisfies the following conditions is determined as the production window: the transaction is not executed, the published interface corresponding to the transaction is not used, and at least one transaction subsystem associated with the transaction is not used.

7. The method according to any one of claims 1 to 6, characterized in that, In each of the aforementioned production deployment windows, the published interfaces associated with the transaction are put online, including: If multiple published interfaces need to be launched, obtain the priority of the published interfaces; The published interfaces are put into operation according to their priority.

8. A multi-system development and production management device, characterized in that, include: The acquisition unit is used to obtain information about the pre-defined mapping relationship between published interfaces and transactions, and to obtain the association information; A partitioning unit is used to partition the published interfaces associated with the transaction into the same online window based on the association information, thereby obtaining a production window; The processing unit is used to process the published interface associated with the transaction in each production window, generate a prompt message after the process is completed, and send the prompt message to the device on the development side.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-system development and production management method according to any one of claims 1 to 7.

10. A transaction listing management system, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a method for performing a multi-system development and production management method according to any one of claims 1 to 7.

Images