Multi-system development execution management method, computer program product, and trading system

Abstract

The application provides a multi-system development execution management method, a computer program product and a transaction system. The method comprises the following steps: obtaining information of a preset mapping association relationship between an interface and a transaction, and obtaining association information; finding the required interface associated with the transaction according to the association information, and determining whether all the required interfaces associated with the transaction have been released; in the case that all the required interfaces associated with the transaction have been released, determining that the development condition is met, generating prompt information, and sending the prompt information to a device of a development end. The method solves the problem of low development efficiency in multi-layer linkage development of a bank core system in the prior art.

Description

Technical Field

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

[0002] In the process of upgrading and transforming large-scale core software systems in banks, the system typically consists of more than ten interdependent subsystems, such as core accounting, payment clearing, channel integration, business middle platform, and enterprise service bus, forming a multi-level, tightly coupled transaction call chain. The current mainstream development management model still follows the traditional waterfall development process: each subsystem team develops independently, completing design, coding, and testing sequentially according to phased requirement documents; after the interface is released, it is delivered centrally and integrated and verified by downstream systems; project progress is tracked through manual reporting methods such as weekly and monthly reports, and testing conditions are judged manually to determine whether they are met.

[0003] The current development team is in a passive state of "waiting for upstream and downstream interfaces to be complete". Layered development requires that the previous stage is completely completed before the next stage can begin. If problems are found in the early design later, the cost of modification is huge and it is easy to cause project delays. Therefore, the development efficiency in the multi-layered linkage development of the bank's core system is low. Summary of the Invention

[0004] The main objective of this application is to provide a multi-system development execution management method, a multi-system development execution management device, a computer program product, and a transaction system, so as to at least solve the problem of low development efficiency in the multi-layer linkage development of the core banking system in the prior art.

[0005] To achieve the above objectives, according to one aspect of this application, a multi-system development execution management method is provided, comprising: obtaining information on a preset mapping relationship between interfaces and transactions to obtain association information; finding the required interfaces associated with the transaction based on the association information, and determining whether all the required interfaces associated with the transaction have been published; if all the required interfaces associated with the transaction have been published, determining that development conditions are met, generating a prompt message, and sending the prompt message to the development device.

[0006] Optionally, finding the required interface associated with the transaction based on the association information includes: extracting all the interfaces, and sequentially determining whether there is a call dependency relationship between the extracted interfaces and the transaction based on the association information; if there is a call dependency relationship between the interface and the transaction, determining the interface with the call dependency relationship with the transaction as the required interface associated with the transaction.

[0007] Optionally, determining whether all required interfaces associated with the transaction have been published includes: obtaining a list of interfaces required by the transaction to obtain a first list; comparing the published interfaces with the first list to obtain a first comparison result; if the first comparison result indicates that all interfaces in the first list have been matched, determining that all required interfaces associated with the transaction have been published; if the first comparison result indicates that at least one interface in the first list has not been matched, determining that all required interfaces associated with the transaction have not been published.

[0008] Optionally, after obtaining the information on the preset mapping relationship between the interface and the transaction and obtaining the association information, the method further includes: determining that the association information that meets the conditions is invalid information if some of the association information satisfies at least one of the following: there is a redundant mapping between the interface and the transaction; the call path between the interface and the transaction is a useless path; or there is a logical conflict between the interface and the transaction; deleting the invalid information from the association information to obtain updated association information; and finding the required interface associated with the transaction based on the updated association information.

[0009] Optionally, determining whether all required interfaces associated with the transaction have been published includes: obtaining hierarchical relationship information of a preset required transaction system associated with the transaction to obtain hierarchical information; finding the transaction associated with the interface based on the association information, and finding the transaction system associated with the transaction based on the hierarchical information; obtaining a list of interfaces required by the transaction system associated with the transaction to obtain a second list; comparing the published interfaces with the second list to obtain a second comparison result; if the second comparison result indicates that all interfaces in the second list have been matched, determining that all required interfaces associated with the transaction have been published; if the second comparison result indicates that at least one interface in the second list has not been matched, determining that all required interfaces associated with the transaction have not been published.

[0010] Optionally, determining whether all required interfaces associated with the transaction have been published includes: obtaining task relationship information of preset required development objects associated with the transaction system to obtain task information; finding the transaction system associated with the transaction based on the hierarchical information, and finding the development object associated with the transaction system based on the task information; obtaining a list of interfaces required by the development object associated with the transaction system to obtain a third list; comparing the published interfaces with the third list to obtain a third comparison result; if the third comparison result indicates that all interfaces in the third list have been matched, determining that all required interfaces associated with the transaction have been published; if the third comparison result indicates that at least one interface in the third list has not been matched, determining that all required interfaces associated with the transaction have not been published.

[0011] After generating the prompt information, the method further includes: upon receiving a request to trace the origin of the transaction, finding all the interfaces associated with the transaction based on the association information; obtaining the transaction name of the transaction and the interface name of the interface associated with the transaction; and displaying the transaction name and the interface name on a display device.

[0012] According to another aspect of this application, a multi-system development execution management device is provided, comprising: a first acquisition unit, configured to acquire information on a preset mapping relationship between interfaces and transactions, thereby obtaining association information; a first processing unit, configured to locate the required interfaces associated with the transaction based on the association information, and determine whether all the required interfaces associated with the transaction have been published; and a second processing unit, configured to determine that development conditions are met when all the required interfaces associated with the transaction have been published, generate a prompt message, and send the prompt message to a device at the development end.

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

[0014] According to another aspect of this application, a transaction 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, the one or more programs including a development execution management method for executing any of the multi-system methods described above.

[0015] By applying the technical solution of this application, a precise mapping and association information between interfaces and transactions is established in advance. This information solidifies the specific set of interfaces that each transaction depends on in the multi-system call chain. Only when all the interfaces that a transaction depends on have been published is it determined that the transaction meets the development conditions, and a prompt message is actively pushed to the relevant development end. This realizes the transformation from "waiting for all to be completed" to "starting when conditions are met", thereby shortening the development cycle and improving the development efficiency in the multi-layer linkage development of the bank's core system. Attached Figure Description

[0016] 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:

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

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

[0019] Figure 3 A structural block diagram of a multi-system development execution management apparatus provided according to an embodiment of this application is shown.

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

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

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

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

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

[0025] With the increasing diversification and complexity of financial services, large-scale core software systems in banks undertake core functions such as customer account management, fund clearing, and risk control, and are composed of numerous interconnected subsystems. Currently, the most similar existing technical solutions mainly adopt a traditional layered development architecture and centralized management model. During the development process, each subsystem development team carries out design, coding, and testing work in stages according to the established requirements specifications; communication is conducted through regular reporting such as weekly and monthly reports; tasks are assigned and progress is monitored using centralized project management software; and a unified file server is used to store development documents and code resources.

[0026] The existing solutions mainly have the following problems:

[0027] 1. Lengthy development cycle: Layered development requires the previous stage to be completely completed before the next stage can begin. If problems are found in the early design later, the cost of modification is huge and it is easy to cause project delays.

[0028] 2. Inefficient cross-team collaboration: Regular reporting cannot resolve unexpected problems in the development process in a timely manner. When the interfaces between subsystems are not clearly defined, it is easy for people to pass the buck, which reduces development efficiency.

[0029] 3. Insufficient risk warning: Centralized project management software can only present static progress data, making it difficult to predict and warn of potential technical and resource risks, and project managers cannot take countermeasures in advance.

[0030] 4. Poor resource reusability: The development of each subsystem is relatively independent, and there is a lack of a unified resource sharing mechanism, which leads to the repeated development of similar functional modules, resulting in a waste of human and time resources.

[0031] As described in the background section, the development efficiency of multi-layered collaborative development of core banking systems in the prior art is low. To solve the above problems, embodiments of this application provide a multi-system development execution management method, a multi-system development execution management device, a computer program product, and a transaction system.

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

[0033] 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 execution management method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only 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.

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

[0035] This embodiment provides a development execution 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. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

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

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

[0038] Specifically, obtaining information on the pre-defined mapping relationships between interfaces and transactions means establishing a clear data connection between the specific interfaces published between systems and the business transactions they support through existing defined correspondences. The obtained association information is a static correspondence formed based on pre-set rules, without relying on real-time operation or dynamic analysis, and only reflects the dependency relationship between interfaces and transactions that was confirmed during the design phase. This process does not involve the verification of interface functions, the simulation of transaction execution, or the automatic derivation of dependency chains; it only completes the directional identification and binding from interface to transaction, providing basic data support for subsequent development, testing, and collaboration based on this association.

[0039] An interface refers to a standardized program entry point for data interaction and function calls between the bank's core system and other related subsystems. Each interface has its own business functions (such as query, transfer, and freeze), which are published by the core system and called by upper-level systems (such as the channel integration layer and business middle platform). It is the basic unit for building the transaction chain.

[0040] A transaction refers to a complete business process in the core banking system that is triggered by the initiating party (such as counter, mobile banking, corporate online banking), passed through multiple layers of systems (channel integration layer, middle platform, enterprise service bus, etc.) and finally completed for accounting or business processing. It has a unique transaction code and business name identifier and usually relies on multiple interfaces to complete the process.

[0041] Mapping relationships refer to the logical correspondence between transactions and interfaces formed through manual definition and automated processing tools. They are used to establish a traceable link between "interface - transaction - system level", enabling the rapid derivation of the affected transaction set and call path from a single interface release, and supporting parallel development and condition verification.

[0042] Association information refers to the hierarchical dependency data formed between systems in the transaction call chain, including the order of interface calls between systems, the combined dependency of multiple interfaces of a transaction pair, and the serial path of cross-layer systems (such as channel layer → middle platform → core), which constitutes a structured dependency graph for collaborative development and testing throughout the entire transaction lifecycle.

[0043] The pre-defined mapping relationships are static association rules from transactions to their dependent interfaces, which are manually sorted out and entered into the database. For example, "account opening transaction" must depend on 18 specific interfaces such as "customer information query", "account creation" and "identity verification". This mapping relationship has been structurally defined based on business logic and interface documentation before the system goes live, forming a full transaction-interface dependency graph.

[0044] Step S202: Based on the above association information, find the required interfaces associated with the above transaction, and determine whether all the required interfaces associated with the above transaction have been published.

[0045] Specifically, based on the relationship between transactions and interfaces, all interfaces required for the transaction to be called are identified from the defined mapping system to ensure that each interface can be accurately mapped to the business logic requirements of the transaction. Subsequently, the integrity of these identified interfaces is checked to determine whether they have all been published by the relevant systems, that is, to confirm whether each interface necessary for the normal execution of the transaction has been provided to the outside world and can be called, thereby forming a clear basis for determining the preconditions for transaction execution.

[0046] The aforementioned "finding the required interfaces associated with the above transactions" involves using automated tools to extract a list of all interfaces that the transaction depends on from the database, indexed by the transaction code. "Determining whether all the required interfaces have been published" refers to comparing the currently published set of interfaces with the list of interfaces required by the transaction to determine if there are any missing items. For example, if an account opening transaction requires 20 interfaces, but only 15 have been published so far, it is determined that "not all have been published." This step relies on a real-time synchronization mechanism of the interface publication log to ensure that the system always keeps track of the latest published interface versions and statuses, avoiding the inability to run transactions in the test environment due to missing interfaces.

[0047] Step S203: If all the required interfaces associated with the above transaction have been published, determine that the development conditions are met, generate a prompt message, and send the prompt message to the device on the development end.

[0048] Specifically, once all necessary interfaces associated with a transaction have been published, the system determines whether the technical dependencies required for transaction development are complete based on preset conditions. Once confirmed to be complete, a notification message generation mechanism is triggered. This notification message directly reflects that the transaction has met the prerequisites for starting development and testing. The information is then pushed to the terminal devices of the corresponding development team in real time through the communication channel, ensuring that developers can promptly carry out subsequent development work based on the completeness of the interfaces, thus avoiding waiting and misoperation caused by missing interfaces.

[0049] Development conditions refer to the prerequisite criteria for determining whether a transaction can start development or testing. They are determined by whether all the interfaces required by the transaction have been published and fully provided. If any required interface is missing, it is determined that "development conditions are not met". The system automatically identifies and filters transactions that do not meet the testing conditions to avoid ineffective parallel development.

[0050] The notification message refers to the feedback content automatically output during the transaction development and testing process, based on the mapping relationship and the verification results of the development conditions. It is used to notify the development team of problems such as missing interfaces, field errors, and logical conflicts (such as "account opening transaction lacks account freezing interface"), so as to achieve early exposure and accurate location of risks.

[0051] The development end refers to the upstream system or system level that initiates transaction requests in the multi-layered system architecture of a bank, including the channel integration layer system such as counter system, mobile banking, and corporate online banking. It triggers the transaction process by calling the core system interface, and is the starting point of the transaction link, as well as an important object for interface mapping and collaborative verification.

[0052] In existing technologies, multi-system collaborative development relies on manual synchronization, phased advancement, and passive waiting. Each system development team must wait for all upstream interfaces to be completed and delivered in a unified manner before they can start joint debugging and testing, which passively prolongs the development cycle.

[0053] This embodiment establishes a precise mapping relationship between interfaces and transactions in advance. This information solidifies the specific set of interfaces that each transaction depends on in the multi-system call chain. Only when all the interfaces that a transaction depends on have been published is it determined that the transaction meets the development conditions, and a prompt message is actively pushed to the relevant development end. This realizes the transformation from "waiting for all to be completed" to "starting when conditions are met", thereby shortening the development cycle and improving the development efficiency in the multi-layer linkage development of the bank's core system.

[0054] The method provided in this solution enables efficient collaboration among multiple systems and teams in the process of transaction transformation, verification, and production through standardized and structured management elements. This ensures the security, accuracy, and timeliness of transactions related to core systems, reduces cross-team communication costs, and improves the overall efficiency of project progress.

[0055] In the specific implementation process, the required interfaces associated with the above transactions can be found based on the above association information through the following steps: extract all the above interfaces, and determine whether there is a call dependency relationship between the extracted interfaces and the above transactions according to the above association information; if there is a call dependency relationship between the above interfaces and the above transactions, determine the above interfaces that have a call dependency relationship with the above transactions as the required interfaces associated with the above transactions.

[0056] This solution extracts all interfaces in the system and identifies and verifies the call dependencies of each interface based on the pre-defined mapping relationship between the interfaces and transactions. Only those interfaces that clearly participate in the transaction call process and have actual dependencies are selected as the interfaces required by the transaction. This effectively eliminates misjudgments of non-calling interfaces caused by redundant mapping relationships or static configuration, ensuring that the determined set of interfaces accurately reflects the true dependency structure of the transaction. On this basis, it further determines whether all members of these confirmed required interfaces have been published. Only when all interfaces have been published is the development condition deemed met, and a prompt message is pushed to the development end. This avoids misjudgments of development start caused by omitting real dependencies or misjudging non-essential interfaces as necessary interfaces, significantly improving the accuracy and reliability of transaction development precondition judgment. Ultimately, it achieves refined control over the collaborative status of interface publication, ensuring the efficient and orderly progress of the transaction development process.

[0057] In a large-scale banking system, call dependencies refer to the ordered call paths and logical constraints among multiple systems and interfaces required for the complete execution of a transaction. These dependencies manifest as front-to-back, parallel, or cross-layer dependencies between multi-level systems (e.g., initiator → channel integration layer → middle platform → core). This solution manually identifies basic dependencies and automates the removal of invalid paths to create a verifiable call dependency graph. This allows development teams to initiate parallel testing in advance based on some published interfaces, thus overcoming the bottlenecks of traditional sequential development models.

[0058] Specifically, "extracting all of the above interfaces" refers to the real-time aggregation of all currently published service interfaces from the bank's core system and more than 130 related subsystems through an automated interface registration center or log collection module. These interfaces cover types such as query, accounting, freezing, and transfer, totaling thousands. The "call dependency relationship" mentioned above refers to the fact that a certain transaction must call a certain interface to complete its function in terms of business logic. For example, a "corporate transfer transaction" depends on the "payee account verification interface", "deduction account balance check interface", and "funds clearing instruction sending interface". This dependency relationship cannot be replaced by any interface. Instead, it is a strong logical association that is manually defined in the business process diagram and system architecture document and solidified in the database.

[0059] Specifically, the "existence of call dependencies" is achieved through an automated matching engine. This engine takes the transaction code as input, traverses the extracted interface set, and compares each one with the pre-set transaction-interface dependency table in the database. It retains only the entries that are explicitly marked as "transaction A must call interface B" and removes redundant interfaces that are unrelated or only "possibly used". This mechanism ensures the accuracy of the "required interface" list and avoids the misinclusion of irrelevant interfaces (such as "system heartbeat detection interface" or "log reporting interface") in the test trigger conditions, thereby preventing interference or misjudgment in the test environment due to the accumulation of invalid interfaces.

[0060] In some embodiments, determining whether all the required interfaces associated with the aforementioned transaction have been published can be achieved through the following steps: obtaining a list of interfaces required for the aforementioned transaction to obtain a first list; comparing the published interfaces with the first list to obtain a first comparison result; if the first comparison result indicates that all the interfaces in the first list have been matched, then it is determined that all the required interfaces associated with the aforementioned transaction have been published; if the first comparison result indicates that at least one of the interfaces in the first list has not been matched, then it is determined that all the required interfaces associated with the aforementioned transaction have not been published.

[0061] This solution obtains a pre-defined mapping relationship between transactions and interfaces to accurately locate all required interfaces associated with the transaction. It then obtains a first list of interfaces explicitly required by the transaction. Each published interface in the system is compared with this first list to generate a first comparison result. When the comparison result shows that all interfaces in the first list have been successfully matched, the transaction development conditions are deemed fully met, and a prompt message is generated and pushed to the development end. Conversely, if any interface is not matched in the comparison result, the development conditions are deemed not yet met. This solution explicitly eliminates the possibility of misjudgment based on "partial publication meeting the conditions," thus achieving a precise and traceable judgment mechanism for pre-development conditions. It effectively solves the problems of delayed development collaboration and misjudgment caused by ambiguous interface publication status and unclear missing information, significantly improving the accuracy and efficiency of transaction development preparation.

[0062] The interface list refers to the summary list of external service interfaces actually released and registered by various subsystems (such as the core system, channel integration layer, business middle platform, etc.) during the collaborative development of the bank's large core software system. It serves as the basic data source for transaction mapping and test triggering. Each interface corresponds to a specific function (such as query, deposit, transfer, etc.) and is used to correlate and compare with the transaction chain.

[0063] The first list refers to a set of transactions that have complete interface support, generated by automated processing by tools and formed by matching and filtering the interface list with manually defined system dependencies. Its content is a list of transaction items that can be started for development and testing immediately, excluding transactions that cannot run due to missing interfaces, conflicts, or incomplete logic. It is the core input data for implementing parallel development and agile verification.

[0064] Released interfaces refer to service interfaces that are delivered in stages by the development teams of various subsystems of the bank during the development process and are formally registered in the interface list, and can be called by other systems. They are characterized by clear functional definitions, calling protocols and version identifiers, and are the smallest verifiable unit in this solution to realize the parallel collaborative mode of "developing one point, mapping one point, and testing one point".

[0065] The first comparison result refers to the preliminary matching result output by the automated tool after matching the "published interfaces" with the "human-predefined transaction-interface dependency database" item by item. This result identifies which transactions have the preliminary testing conditions because some of the interfaces they depend on have been published. It is an intermediate data product for subsequent interface integrity verification and transaction executability screening.

[0066] Specifically, the "list of interfaces required for a transaction" refers to a set of all necessary call interfaces manually compiled and fixed in the database for a specific transaction (such as a "corporate transfer transaction") based on a pre-defined mapping relationship. For example, a certain transfer transaction may require 18 specific interfaces, such as "payee account status query", "payer balance verification", "deduction instruction generation", "clearing route matching", and "transaction flow record". Each interface has a unique identifier (such as interface ID: API-CT-089). This list is not dynamically generated, but is based on the transaction flowchart and interface contract document. It is jointly confirmed and entered into the system by the architect and business analyst at the beginning of the project to ensure its authority and completeness.

[0067] Specifically, "the aforementioned published interfaces" refers to the latest set of services continuously published to the interface registration center by various subsystems (such as the core system, channel integration layer, enterprise service bus, etc.) every day, and synchronized to the comparison engine in real time through automated collection tools; the aforementioned "comparison" refers to accurately matching the unique identifier of each interface in the first list with the set of published interfaces, using string hash comparison or ID index matching methods to ensure that misjudgments are not caused by naming differences or version numbers; this process is automatically executed twice a day, supports incremental comparison, and only processes newly added or changed interfaces, thereby improving execution efficiency.

[0068] Specifically, "all have been matched" means that every interface in the first list can be found in the set of published interfaces with a completely matching entity, without any omissions. When this condition is met, the transaction is determined to have the minimum technical prerequisites for starting the test. For example, if a transaction list contains 18 interfaces, and it is confirmed that all 18 exist in the publishing library, it is considered to have "meeting the test conditions". This determination result is not subject to any manual intervention and is completely driven by the rule engine automatically.

[0069] Specifically, "at least one of the above interfaces did not match" means that there are one or more interfaces in the first list that have no matching items in the published set. In this case, the system does not make a "partial completion" judgment, but directly determines that the transaction "does not meet the test conditions as a whole". This design avoids the risks of unstable test environment, high false alarm rate and difficulty in attributing problems caused by "testing as soon as some interfaces are released". It ensures that the test process is allowed only when all dependencies are complete, forming a strict "all or nothing" triggering mechanism.

[0070] In the specific implementation process, after obtaining the information on the preset mapping relationship between the interface and the transaction and obtaining the association information, the above method further includes the following steps: if some of the above association information satisfies at least one of the following conditions, namely, there is a redundant mapping between the interface and the transaction, the call path between the interface and the transaction is a useless path, or there is a logical conflict between the interface and the transaction, then the above association information that satisfies the conditions is determined to be invalid information; the invalid information in the above association information is deleted to obtain updated association information; and the required interface associated with the transaction is found based on the updated association information.

[0071] This solution obtains the pre-defined mapping relationships between interfaces and transactions to form initial association information. It then identifies any abnormal associations such as redundant mappings, useless call paths, or logical conflicts. Association information meeting any of these abnormal conditions is deemed invalid and removed, resulting in updated association information containing only valid paths. Subsequently, based on this purified association information, the solution accurately locates the required interfaces directly associated with the transaction and accurately determines whether all required interfaces have been published. This avoids misjudgments of development conditions caused by invalid associations, ensuring that a prompt indicating that development conditions are met is triggered only when all truly valid interfaces have been published. This effectively solves the problem of development resource scheduling delays or incorrect startups caused by historical or misconfigured association information, improving the accuracy, collaboration, and execution efficiency of the transaction development process.

[0072] Redundant mapping refers to duplicate, invalid, or logically conflicting interface-transaction binding relationships in the mapping relationship caused by manual definition or system changes. For example, the same function is repeatedly covered by multiple interfaces, or a transaction is incorrectly bound to an unrelated interface. These need to be identified and removed by automated tools to ensure the accuracy of test triggering.

[0073] The call path refers to the complete system-level link that a transaction goes through from the initiating end (such as counter or mobile banking), through the channel integration layer, business middle platform, enterprise service bus, and finally to the core system. It usually contains 3 to 6 layers of system nodes, and there are clear interface dependencies between each layer of system. It is a key clue for analyzing transaction integrity and locating problems.

[0074] Unused paths refer to invalid links in the call path that cannot complete transaction execution due to system architecture changes, interface obsolescence, or logical errors. For example, if an interface has been deactivated but not removed from the mapping relationship, or if a certain system layer has not been developed, causing the path to be interrupted, it needs to be identified and excluded through an automated verification mechanism to prevent the false triggering of invalid tests.

[0075] Logical conflicts refer to abnormal situations in the transaction call process where multiple interface functions contradict each other or the state definitions are inconsistent, causing the transaction to fail to execute normally. For example, the state logic of the "Query Account Balance" interface and the "Freeze Account" interface are incompatible, or the field values ​​of the "Post Account" and "Deduct Payment" interfaces conflict with each other. These conflicts need to be detected and corrected in advance through a mapping verification mechanism.

[0076] Invalid information refers to erroneous data generated during the interface release, transaction mapping, or verification process due to human input errors, system integration failures, or data pollution, such as incorrect interface numbers, duplicate transaction codes, missing fields, and mismatched call relationships. This type of information will be filtered and marked as invalid by automated tools to avoid affecting test startup and risk warnings.

[0077] The updated association information refers to the interface-transaction mapping relationship, call path, and system dependency data that are recalculated and synchronously updated by automated tools whenever a new interface is released or transaction requirements change during the development process. This ensures that the "business flow diagram" always reflects the latest development status and is the technical support for achieving incremental collaborative development and continuous verification.

[0078] Specifically, the aforementioned "redundant mapping" refers to the same transaction being incorrectly associated with two or more interfaces that have completely identical or highly overlapping functions. For example, the "query account balance" transaction is associated with both API-ACQ-023 (standard query) and API-ACQ-023-V2 (versions with identical functions but different parameter names), causing ambiguity in testing. The aforementioned "useless path" refers to a transaction being mapped to an interface that will never be called in the actual business process. For example, a "corporate transfer transaction" is incorrectly bound to the "customer SMS notification interface," which is only used in retail business and is irrelevant to the corporate scenario. The aforementioned "logical conflict" refers to a contradiction in the order of calls or preconditions between interfaces. For example, the "freeze account" interface is mapped to a pre-step of the "transfer transaction," but the transaction can only be executed in the "unfrozen" state, creating a business logic paradox. The aforementioned "invalid information" is identified and marked by an automated rule engine that scans a preset association information database, based on the transaction flowchart, interface contract document, and historical call logs. After automatic marking by the system, these relationships are placed in a queue to be cleaned, without relying on manual verification.

[0079] Specifically, the aforementioned "deletion" refers to the system removing or setting unavailable mapping relationships marked as invalid from the database, retaining only valid, unique, and conflict-free transaction-interface dependencies. This operation is not a simple deletion of records, but rather triggers a version update mechanism for the relationships, ensuring that all downstream modules (such as the interface matching engine and test triggers) run based on the latest and clean relationship graph, thus avoiding the pollution of subsequent judgment processes by historical erroneous data.

[0080] Specifically, the aforementioned "based on the updated association information" means that when the system performs interface lookup and matching, it only uses the cleaned and retained set of accurate mapping relationships. This mechanism ensures that all subsequent identification of "required interfaces", release status judgment and development condition triggering are based on real and valid dependency relationships, completely eliminating the risk of misjudgment caused by incorrect mapping. For example, it avoids the system mistakenly believing that a transaction "has met the test conditions" due to "useless path" mapping and thus incorrectly pushing test notifications.

[0081] In some embodiments, determining whether all the required interfaces associated with the aforementioned transaction have been published can be achieved through the following steps: obtaining hierarchical relationship information of the preset required transaction systems associated with the aforementioned transaction, thus obtaining hierarchical information; finding the aforementioned transaction associated with the aforementioned interface based on the aforementioned association information, and finding the aforementioned transaction system associated with the aforementioned transaction based on the aforementioned hierarchical information; obtaining a list of interfaces required by the aforementioned transaction system associated with the aforementioned transaction, thus obtaining a second list; comparing the published interfaces with the aforementioned second list, thus obtaining a second comparison result; if the aforementioned second comparison result indicates that all the aforementioned interfaces in the aforementioned second list have been matched, then it is determined that all the required interfaces associated with the aforementioned transaction have been published; if the aforementioned second comparison result indicates that at least one of the aforementioned interfaces in the aforementioned second list has not been matched, then it is determined that all the required interfaces associated with the aforementioned transaction have not been published.

[0082] This solution acquires the hierarchical relationship information of the pre-defined required trading systems associated with the transaction, constructs a hierarchical mapping relationship between the transaction and the underlying trading system, and combines this with the pre-defined mapping relationship between the interface and the transaction to accurately locate the specific trading system level on which the transaction depends. This allows for the acquisition of the interface list required by that specific trading system, ensuring that interface integrity verification is no longer based on a generalized transaction dimension but converges to the actual system level it depends on. This avoids misjudgments of interface requirements due to complex system architecture levels. By comparing the published interfaces with the interface list of that specific system level, the development conditions are only considered met when all interfaces in the list have been published. This effectively prevents false satisfaction states caused by cross-system level interface confusion or omissions, ensuring the true availability of all dependent interfaces before development begins. Ultimately, this achieves accurate and reliable judgment of transaction development conditions in a multi-system collaborative environment, improving system integration efficiency and the stability of the development process.

[0083] A transaction system refers to any subsystem that participates in a transaction chain within a bank's large-scale core software architecture. This includes the core system, channel integration layer (such as personal online banking and corporate online banking), business middle platform, enterprise service bus, etc. The systems form a multi-layered call chain according to their hierarchical relationship. Each transaction system is responsible for the development of some interfaces and the implementation of business logic. The status of its interface release directly affects the testability of upstream transactions.

[0084] Hierarchical relationship information refers to the structured dependency data formed between various transaction systems in a multi-system collaborative environment of a bank, along the transaction call path. This includes call chains of five or more layers, such as "Initiator → Channel Integration Layer → Business Middle Platform → Enterprise Service Bus → Core System." This information is generated by manually pre-defining the interface call attribution between systems and then processed layer by layer by automated tools to identify the complete transaction dependency path. Hierarchical information refers to the structured description of the hierarchical position of each system in the transaction chain and its relationships with its superiors and inferiors. It is used to classify system roles (e.g., the first layer is the core system, the second layer is the channel integration layer) and is the fundamental basis for achieving accurate "interface-transaction" mapping, identifying the complete set of transaction dependencies, and determining whether test conditions are met.

[0085] The second list refers to the list of transactions with complete interface support conditions generated by automated tools after matching, filtering, and deduplication based on hierarchical relationship information and transaction dependency rules, based on the interface list. This list is used to guide the development and testing teams to carry out verification work in parallel.

[0086] The second comparison result refers to the judgment result output by the automated tool after matching the "published interfaces" with the "list of interfaces required for the transaction" item by item. It is used to determine whether a transaction has complete interface support conditions. If not all the interfaces required for the transaction have been published, it is judged as "not meeting the test conditions" and automatically excluded from the set of testable transactions to ensure the validity of the verification.

[0087] Specifically, the aforementioned "hierarchical relationship information of the transaction system" refers to the structured topology of multiple system layers that a transaction passes through from the initiating end to the final accounting core in a large bank's core system. For example: customer channel layer (counter, mobile banking, corporate online banking) → channel integration layer (unified gateway) → business middle platform layer (payment middle platform, account middle platform) → enterprise service bus (ESB) → core accounting system, a total of five layers. This hierarchical relationship was manually sorted out and solidified into a tree structure database by the architecture team at the beginning of the project. Each layer corresponds to multiple subsystems, and calls between layers are only allowed in specific directions. For example, the "core system" is not allowed to call the "channel layer" in reverse. This information does not depend on the interface itself, but defines the complete path that a "transaction" goes through in the system architecture.

[0088] Specifically, the phrase "finding the transactions associated with the interfaces based on the aforementioned association information" refers to reversing the lookup by interface ID to determine which transactions depend on it. For example, interface API-CORE-120 is used by three transactions: "corporate transfer," "personal transfer," and "salary payment." The phrase "finding the transaction systems associated with the transactions based on the aforementioned hierarchical information" refers to locating all upstream and downstream system nodes involved in the transaction within the hierarchical topology based on the transaction ID. For example, the system hierarchy associated with the "corporate transfer transaction" is: corporate online banking → channel integration layer → payment middle platform → ESB → core system. This step expands the point-to-point relationship between interfaces and transactions into a three-dimensional association view of "interface—transaction—system hierarchy," enabling cross-system boundary accountability.

[0089] Specifically, the aforementioned "second list" refers to the set of interfaces that each system needs to provide to complete the transaction, extracted layer by layer based on each system involved in the transaction. For example, the core system needs to provide "accounting interface" and "balance update interface", the payment middle platform needs to provide "clearing instruction interface", and the ESB needs to provide "message routing interface". Unlike the first list, the second list is not based on the interfaces that the transaction directly depends on, but rather on the interfaces that each level must deliver according to "system responsibilities", ensuring that no system omits its responsibility interface in the transaction chain.

[0090] Specifically, the aforementioned "comparison" refers to precisely matching the currently published set of interfaces with each interface in the second list, which is divided into system levels. A triple verification mechanism of interface ID, version number, and protocol type is used to ensure that no misjudgment occurs due to naming differences or interface upgrades. This comparison is executed in parallel at the system level, supports incremental updates, runs automatically twice a day, and generates an independent status report based on the comparison results at the system level.

[0091] Specifically, "all have been matched" means that every interface in the second list, regardless of whether it belongs to the core system, the middle platform layer, or the channel layer, has a complete match in the release library. For example, of the 28 interfaces involved in "corporate transfer transactions," 12 are from the core system, 10 from the middle platform layer, and 6 from the ESB layer. All of them have been released and are deemed to "meet the release conditions," thus triggering the development test notification. This determination is not based on transactions but on "system-level responsibility" to ensure that each system layer completes delivery. "At least one of the above interfaces has not been matched" means that if any interface in any layer of the system has not been released, the transaction as a whole is deemed not to meet the release conditions, and no "partial completion" or "priority priority" judgment is made. This mechanism enforces the "full-link readiness" principle. For example, even if all core system interfaces have been released, if the "clearing instruction interface" of the payment middle platform is missing, the system will still refuse to trigger testing to avoid integration failures caused by the front-end system completing testing but the back-end system lagging behind.

[0092] In the specific implementation process, determining whether all the required interfaces associated with the aforementioned transaction have been published can be achieved through the following steps: Obtain task relationship information of the preset required development objects associated with the aforementioned transaction system to obtain task information; locate the aforementioned transaction system associated with the aforementioned transaction based on the aforementioned hierarchical information, and locate the aforementioned development objects associated with the aforementioned transaction system based on the aforementioned task information; obtain a list of interfaces required by the aforementioned development objects associated with the aforementioned transaction system to obtain a third list; compare the published interfaces with the aforementioned third list to obtain a third comparison result; if the aforementioned third comparison result indicates that all the interfaces in the aforementioned third list have been matched, it is determined that all the required interfaces associated with the aforementioned transaction have been published; if the aforementioned third comparison result indicates that at least one of the interfaces in the aforementioned third list has not been matched, it is determined that all the required interfaces associated with the aforementioned transaction have not been published.

[0093] This solution obtains task relationship information of pre-defined development objects associated with the transaction system, clarifies the interface responsibility boundaries of each development object within the transaction system, and accurately locates the specific development object associated with the transaction system. This leads to the creation of a third list of interfaces responsible for each development object. The published interfaces are then compared item by item with this third list. Based on the comparison results, it is determined whether all interfaces required for the transaction have been fully published. When all interfaces in the third list are successfully matched, the development conditions are confirmed to be met; otherwise, it is determined that interfaces are missing. This process overcomes the limitations of previous methods that only used the transaction system as a unit for coarse-grained judgment of interface completeness. It achieves precise identification of the responsible parties for interfaces and fine-grained verification of delivery status, effectively solving problems such as difficulty in tracing missing interfaces and misjudgment of development conditions caused by ambiguous interface responsibilities among development objects. This ensures that the interface preparation status before transaction development is traceable and verifiable, significantly improving the efficiency and accuracy of multi-team collaborative development.

[0094] The required development objects refer to the complete set of interfaces that must be relied upon to complete a specific transaction. These are preset and recorded manually according to business logic. For example, "account opening transaction" requires 20 interfaces. If only 10 are provided, it is considered that the conditions are not met. This is used to determine whether the transaction meets the conditions for testing or development to start.

[0095] Task relationship information refers to the call paths and dependency topologies between systems, interfaces, and transactions formed through manual pre-setting and automated processing in collaborative development management. This includes hierarchical relationships (such as five-layer chains), direct / indirect connections between systems, and interface ownership transactions, used to construct "business flow diagrams" and intelligent matching engines. Task information refers to structured data related to each transaction or interface development task, including transaction name, transaction code, ownership development team, initiating system, suggested verification time, and whether the customer has been migrated. This information is used for task allocation, progress tracking, responsibility attribution, and collaborative scheduling.

[0096] The development object refers to the specific system, interface or transaction unit that is identified in the collaborative development process as needing to participate in verification or testing. The identification is based on the matching result of the "preset" relationship and the "released interface". It is the basic unit for dynamic resource scheduling and parallel development.

[0097] The third list refers to a set of transactions with complete interface support conditions generated after multiple rounds of comparison between the "interface list" and the "preset required development objects" through automated tools, and the elimination of invalid, duplicate, and incomplete items. It is used to guide the actual testing and production scheduling and is a feasibility output list for collaborative development.

[0098] The third comparison result refers to the final judgment generated by the automated tool after completing the dual matching of the "interface list" and the "preset required development objects". It includes the "list of transactions that can be tested", the "list of transactions with missing interfaces", and the "abnormal interface identifiers", which are used to guide the development team to quickly fix and accurately deploy test resources.

[0099] Specifically, the aforementioned "transaction system" refers to an independent subsystem within the bank's core software architecture that undertakes specific business functions, such as the core accounting system, payment middle platform, and enterprise service bus (ESB); the aforementioned "development object" refers to the smallest responsible unit responsible for developing specific functional modules within the system, typically corresponding to a development group or team, such as the "core system - account management group" or the "payment middle platform - clearing module group"; the aforementioned "task relationship information" refers to the mapping relationship that the project management team manually sorts out and enters into the system during the project initiation phase, based on the system architecture and functional division of labor, clarifying "which interfaces a certain development object is responsible for developing." For example, the "account management group" is responsible for 12 interfaces, such as the "account opening interface," "balance freezing interface," and "account status query interface." This information is bound to the team ID, the person in charge, and the development cycle, forming a strong association between the interface and the responsible development entity.

[0100] Specifically, the phrase "finding the transaction system associated with the transaction based on the above-mentioned hierarchical information" refers to identifying all system nodes involved in the transaction based on the five-layer path of the transaction in the system architecture (e.g., channel layer → integration layer → middle platform → ESB → core). The phrase "finding the development object associated with the transaction system based on the above-mentioned task information" refers to reversing the lookup of the specific team responsible for the development of all relevant interfaces within each system node through the task relationship database. For example, a "corporate transfer transaction" involves the core system, where the "account management group" is responsible for the "accounting interface," "balance update interface," and "freeze status verification interface," while the "clearing module group" is responsible for the "clearing instruction generation interface." This step achieves a layer-by-layer penetration from "transaction → system → development team," precisely assigning interface delivery responsibility to individuals.

[0101] Specifically, the aforementioned "third list" refers to the collection of all interfaces assigned to each development object associated with the aforementioned transaction system, forming the final interface list for the transaction in the "development responsibility dimension." For example, a "corporate transfer transaction" involves two development objects: the "account management group" is responsible for 8 interfaces, and the "clearing module group" is responsible for 5 interfaces. In this case, the third list is a complete set of 13 interfaces. This list differs from the second list (system dimension) in that it focuses on "who develops" rather than "what the system needs to do," ensuring that each interface has a clearly defined development responsibility and avoiding ambiguity or overlap in responsibility.

[0102] Specifically, the aforementioned "comparison" refers to precisely matching the set of published interfaces collected daily from the interface release platform with the unique identifier (including interface ID, version number, and the development object to which it belongs) of each interface in the third list. A multi-field hash verification mechanism is used to ensure that even if the interface names are similar or the parameters are adjusted, it can still identify whether they are the same version. This comparison is performed in groups according to the development object, and the system can generate detailed reports such as "Development Group A: 13 / 13 released" and "Development Group B: 7 / 9 released", realizing visualized monitoring of responsibility granularity.

[0103] Specifically, "all have been matched" means that every interface in the third list, regardless of which development entity it belongs to, has been successfully published and is in the "online" status. For example, if all 8 interfaces under the responsibility of the "Account Management Group" have been published, and all 5 interfaces under the responsibility of the "Clearing Module Group" have also been published, the system will determine that "all development entities of the transaction have fulfilled their obligations" and trigger the test access notification. This determination does not accept compromises such as "partial completion" or "testing higher priority interfaces first," ensuring a closed loop of development responsibility. "At least one of the above interfaces has not been matched" means that if any interface under the responsibility of any development entity has not been published, the system will determine that the transaction as a whole does not meet the conditions for publication. This mechanism enforces the principle of "responsibility binding." For example, even if the "Clearing Module Group" has published 5 interfaces, but the "Account Management Group" still has 1 interface that has not been delivered, the system will still prevent the test from starting, avoiding delays by a single team that drag down the overall progress.

[0104] In some embodiments, after generating the prompt information, the above method further includes the following steps: upon receiving a request to trace the source of the above transaction, finding all the above interfaces associated with the above transaction based on the above association information; obtaining the transaction name of the above transaction and obtaining the interface name of the above interface associated with the above transaction; and displaying the transaction name and the interface name on a display device.

[0105] In this solution, after a transaction has been published or is running, when a traceability request for that transaction is received, the system automatically locates and retrieves all interfaces directly associated with the transaction based on the preset mapping relationship between interfaces and transactions. At the same time, it extracts the name of the transaction itself and the names of each associated interface, and presents them together in a clear and corresponding form on the display device. This allows maintenance or auditing personnel to quickly and accurately grasp the complete mapping relationship between the transaction and its dependent interfaces without relying on manual document review. This effectively solves the problems of delayed problem location, difficulty in assigning responsibility, and low efficiency in audit traceability caused by opaque interface dependencies. The solution achieves the effects of improving system traceability, reducing maintenance costs, and enhancing the reliability of multi-system collaborative development and maintenance.

[0106] A traceability request refers to using tools to automatically track which transactions call a particular interface, its hierarchical path, and the capabilities of the associated development teams, based on the mapping relationship between transactions and interfaces. This enables the reverse tracing of the transaction source from the interface and the forward identification of the technical requests of the dependent systems from the transaction, ensuring the complete traceability of the transaction chain and the accurate location of problems.

[0107] The transaction name refers to the business name used to identify a specific banking operation, such as "corporate transfer transaction" or "counter account opening transaction". It is used in conjunction with a unique transaction code to ensure unified identification and accurate traceability of the same business operation in a multi-system and multi-team collaborative environment. It is the key identifier for achieving business and technology alignment in this solution.

[0108] The interface name refers to the unique identifier registered by each interface in the system. It is used to distinguish interface calls of different functions at the technical level. It is associated with the list of interfaces required for the transaction and is the basis for matching transaction dependencies, verifying interface completeness, and identifying missing or incorrect interfaces through automated tools in this solution.

[0109] Display devices refer to terminal hardware devices used to visually present collaborative management results such as the "business flow diagram" of this solution, such as PCs, large screens, and project management dashboards. They are used to display key information such as transaction dependencies between systems, interface mapping status, verification pass rate, and production window arrangements, supporting real-time collaborative decision-making and risk warning across teams.

[0110] Specifically, the aforementioned "source tracing request" refers to a query command initiated proactively by testers, operations and maintenance teams, or auditors when a transaction experiences abnormal operation, production failure, or compliance review, to query the entire chain of dependencies of a transaction. For example, "Please find all interfaces that 'corporate transfer transaction' (transaction code: CT-2024-089) depends on." The aforementioned "based on the aforementioned association information" refers to the system calling the built and continuously updated transaction-interface mapping database. This database stores the static association rules between each transaction and all dependent interfaces, and has undergone redundancy cleanup and hierarchical decomposition to ensure data accuracy. This step uses the transaction code as a unique index to quickly retrieve its complete interface dependency graph without relying on manual querying of documents or meeting minutes.

[0111] Specifically, the "transaction name" mentioned above refers to the standardized business name of the transaction, such as "corporate transfer transaction" or "counter account opening transaction," which is uniformly defined by the business department and bound to the transaction code to ensure that non-technical personnel can understand it; the "interface name" mentioned above refers to the business description name of each interface, such as "account balance query interface" or "clearing instruction generation interface," rather than the technical code (such as API-CORE-120). This name is filled in by the interface provider during registration and corresponds one-to-one with the interface ID, making it easy for non-developers to intuitively identify its function; when tracing the source, the system automatically maps the interface ID to the interface name, realizing the translation of technical information into business language.

[0112] The aforementioned "display devices" include project management dashboards, collaboration platform pages, mobile apps, or large-screen monitoring systems, used to centrally display the relationships between transactions and interfaces. The displayed content is presented in a tree structure or horizontal flowchart format, for example: "Corporate transfer transaction (CT-2024-089) → Account balance query interface, payer freeze verification interface, clearing instruction generation interface, ESB message routing interface, core accounting interface", and the system and development team to which each interface belongs are marked. This display method does not rely on code or logs, but presents the end-to-end dependency chain from a business perspective, and supports one-click export to PDF for auditing or review.

[0113] In addition to the above, the solution proposed in this application also includes: real-time monitoring of the development progress and resource requirements of each subsystem, automatically adjusting the resource configuration of cloud infrastructure (such as CPU, memory, and storage) to ensure optimal resource allocation among multiple development teams while reducing idle resource waste. It can not only dynamically adjust resources based on real-time load conditions but also learn from historical project data to predict future resource needs, thereby managing and optimizing resource utilization more efficiently.

[0114] Based on the current development progress and historical development data of each "transaction system," a dynamic demand model for cloud infrastructure resources is constructed for each "transaction system." This dynamic demand model includes: the average consumption rate of CPU computing resources, memory resources, and storage resources per unit time, the peak demand range, and the distribution of resource occupancy time. The development progress is automatically calculated based on the release status and "verification passed" status of the "interfaces" managed by the corresponding "development objects" of each "transaction system." Real-time data on resource utilization rates consumed by each "transaction system" while running "transactions" in the test environment is collected to form a resource usage sequence. Based on the above resource usage sequence and the aforementioned dynamic demand model... The demand model predicts the total resource demand of each "transaction system" within a preset future time window. Based on the total demand and the available resource capacity of the current cloud infrastructure, a resource allocation plan is generated, dynamically adjusting the virtual machine instance specifications, memory size, and storage volume capacity allocated to each "transaction system." When multiple "transaction systems" execute verification tasks in parallel, priority is given to ensuring resource supply for "transaction systems" whose "interfaces have all been published" and whose "verification passed" status is "incomplete," while resource allocation is suppressed for "transaction systems" whose "interfaces have not been fully published" or whose "verification failed." The above dynamic resource adjustment operations are executed by an automated scheduling engine without manual intervention.

[0115] Based on historical project data (such as test resource consumption logs of 120 similar projects in the past three years), we extracted the resource usage patterns of each "transaction system" at different development stages (interface development, full interface release, and verification in progress).

[0116] By deploying lightweight resource monitoring probes, the actual CPU, memory, and I / O consumption of each "trading system" during "trading" operations in the test environment is collected in real time, forming a resource usage sequence. Combined with the release status of "trading" and "interfaces," it is possible to accurately determine whether the current "trading system" has entered a "high-load verification period." Using time series forecasting algorithms (such as LSTM or exponential smoothing), based on historical patterns and current trends, the total resource requirements of each system in the next 2–4 hours are predicted, rather than relying on static configuration.

[0117] Prioritize transactions based on their development status:

[0118] Highest priority: All interfaces have been published + verification failed → This indicates that the system has a blocking defect, which needs to be reproduced and fixed as soon as possible, and resources must be guaranteed;

[0119] Medium priority: Interface partial release + verification not started → Resources are allocated proportionally based on the number of released interfaces, and only minimal testing is supported;

[0120] Lowest priority: If the interface has not been released or development has not started, only the minimum daemon resources (such as 1 core and 1G) will be retained, and the rest of the resources will be released.

[0121] This strategy ensures that limited resources are concentrated on "high-value" verification tasks, preventing "low-maturity" systems from consuming high-configuration resources. Based on the prediction results, the scheduling engine automatically calls the cloud platform API to complete virtual machine scaling, storage volume mounting and adjustment, and network bandwidth reconfiguration within 1-3 minutes, achieving dynamic matching of resource supply and demand in time and space.

[0122] In addition to the above, the proposed solution also includes: improving existing version control systems by introducing a distributed version control mechanism to achieve real-time synchronization and conflict-free collaborative editing of code and documentation. Each developer can view and modify the work of other teams in real time, while the system automatically resolves merge conflicts, maintaining the consistency and integrity of code and documentation. Distributed version control solves the efficiency bottleneck of centralized systems when the network is unstable, while also improving code accessibility and collaborative editing efficiency, and reducing errors caused by improper version control.

[0123] For each "interface" related to a "transaction," a document, interface protocol file, and test case script are defined, and a distributed version control unit is established, uniquely identified by the "initiator's transaction code." This distributed version control unit is built on a distributed version control system (such as Git), and each "development object" of a "transaction system" has an independent local code repository, maintaining asynchronous updates with the central shared repository through a two-way synchronization mechanism. When any "development object" modifies its associated "interface" document or test script, the system automatically extracts the semantic features of the modified content, including: interface name, calling method, input / output field definitions, transaction boundary description, and a list of dependent "transaction systems." Based on these semantic features, the system automatically compares the currently modified content with the associated files already committed by other "transaction systems" in the central shared repository to identify whether existing files exist. In terms of semantic conflicts, the aforementioned semantic conflicts include: the same field being defined as different data types by different teams, inconsistent order of interface parameters in the same transaction call, and the same "transaction" being assigned to different "transaction ownership development teams" in different systems. For identified semantic conflicts, the system automatically generates a conflict report, marking the conflicting items, the involved "transaction systems", the conflicting file paths and the person who made the changes, and pushes it to the relevant "development objects" for manual confirmation. For modifications without semantic conflicts, the system automatically submits them to the central shared repository through an automated merging engine, updates the shared document view of all related "transactions", and triggers local repository synchronization notifications for other "transaction systems" that depend on the "interface". All version change records are bound to the "initiator transaction code", forming a traceable full-link log of "interface - document - version - person making the change - change time".

[0124] In addition to the above, the solution proposed in this application also includes: employing a tool for automatically generating test cases, which automatically generates test scripts based on the requirements specification and code, and uses intelligent algorithms to review the generated test cases to ensure their coverage and rationality. The automation tool reduces the workload of testers, improves the quality and coverage of test cases, while intelligent review further guarantees the effectiveness of the testing.

[0125] Based on the "Requirements Specification" and the implemented "Interface" code in the "Transaction System" for a "transaction," the system automatically generates a set of test cases corresponding to that "transaction" through natural language processing and program semantic analysis. The natural language processing is used to parse the business rules in the "Requirements Specification," extracting transaction process nodes, preconditions, input parameter constraints, expected output results, and exception handling paths. The program semantic analysis is used to parse the control flow, data flow, transaction boundaries, and exception throwing points in the "Interface" code, identifying the actual implemented logical branches and state transitions. The system semantically aligns the two to generate structured test case templates. Each template includes: a test scenario description, input parameter combinations, expected output values, expected system state changes, verification assertion rules, and a list of dependent "Transaction Systems." The generated test cases undergo compliance verification by an intelligent review module. This intelligent review module, based on a machine learning model trained on a historical test case library and a defect pattern library, performs the following review operations:

[0126] (1) Verify whether the test cases cover all business rule paths extracted from the requirements;

[0127] (2) Verify that the test cases cover all executable branches in the code and that there are no redundant or invalid branches;

[0128] (3) Verify whether the combination of input parameters conforms to the data type, length, value range and business constraints defined in the "interface";

[0129] (4) Verify whether the expected output and system status changes are consistent with the data transfer rules between the "trading systems" defined in the "related information";

[0130] For test cases that fail the review, the system marks the specific discrepancies and outputs correction suggestions, which are then pushed to the corresponding "development object" for manual confirmation or modification. For test cases that pass the review, the system automatically generates an executable script and binds it to the "initiator transaction code" of the "transaction" and includes it in the test execution queue. All generation and review records are associated with "transaction", "interface", "development object" and version number, forming a traceable "requirement-code-test case" three-element consistency chain.

[0131] In summary, the proposed solution significantly shortens the development cycle. The parallel development and continuous delivery model reduces time wasted due to waiting and rework, thus shortening the overall project development cycle. It greatly improves collaboration efficiency; the use of instant collaboration tools enables rapid and accurate information transmission, preventing decision-making errors caused by information asymmetry at the source and improving cross-team collaboration efficiency. It effectively reduces development risks; the intelligent risk warning system can identify potential risks in advance, giving project managers sufficient time to take countermeasures, reducing the probability of project risks occurring. It reduces deployment risks and improves project controllability; the phased deployment sequence avoids conflicts when multiple systems are deployed in parallel (such as deployment failures due to chaotic dependencies), reducing uncertainty during the deployment phase. It improves resource utilization efficiency; the establishment of a shared resource library avoids redundant development, increases development resource utilization, and reduces development costs.

[0132] This invention constructs a collaborative management framework of "transaction-related information-hierarchical information-development objects," enabling early identification and proactive intervention of development and testing risks in a multi-level system dependency environment, significantly reducing systemic defects caused by interface errors, missing dependencies, and logical inconsistencies.

[0133] In the traditional development model, each system is developed sequentially, and integration testing is only started after all interfaces are completed. If an error is found in the definition of an interface field at a certain level (such as the channel integration layer) (e.g., the query interface is mistakenly written as the delete interface), the account status update logic is abnormal (e.g., the account should be frozen but is not), or the batch transaction interest calculation rules are missing, it is necessary to go back to the upstream system for rework, which has a long repair cycle and a wide impact.

[0134] This invention uses automated tools to establish a complete call path for transactions between system nodes based on predefined "hierarchical information" (e.g., customer channel layer → channel integration layer → business middle platform → enterprise service bus → core accounting system, a total of five layers). It also combines all the "interfaces" and their corresponding "development objects" that each transaction depends on in the "related information" to perform dynamic verification at the initial stage of interface release.

[0135] When a "transaction system" (such as a "payment platform") releases a new interface, the system automatically retrieves all "transactions" to which the interface belongs based on "related information" and determines whether there are any unreleased necessary interfaces in other levels of the transaction based on "hierarchical information". If there are any missing interfaces, the system immediately generates a "transaction-level interface incomplete warning", pushes it to the relevant "transaction-owned development team", and simultaneously notifies the upstream or downstream system leaders. If the interface itself has semantic anomalies (such as field type mismatch or operation code error), the transaction call chain is triggered through a pre-set automated test script during the simulated transaction execution in the test environment. The system manually verifies whether the returned result meets expectations (such as account balance not updated, status not changed, or interest not calculated). The verification personnel mark the anomaly type and bind it to the specific "transaction" and "interface".

[0136] The key to this mechanism lies in its approach: instead of waiting for all systems to complete development before centralized testing, it operates on the principle of "interface release triggers associated transaction verification." After each interface is released, all transactions that depend on it undergo minimal verification. For example, when the "core accounting system" releases an "account freeze interface," the system automatically identifies that this interface is depended on by 23 transactions, such as "counter account opening transactions" and "corporate transfer transactions." It then simulates the minimal call paths of these 23 transactions in the test environment, using only the released interface combination to verify whether the freeze operation is correctly triggered and whether the account status changes synchronously. If "freeze status not returned" or "interface return code incorrect," the system immediately identifies the problem as a defect in the "core accounting system" interface implementation. The relevant "development object" (such as the "core system - account management group") then fixes this defect immediately to prevent the error from propagating to downstream systems.

[0137] This process does not rely on AI models to automatically identify errors. Instead, it uses a human-machine collaborative mechanism of "manually defined rules + automated triggering + manual result verification" to ensure the accuracy and interpretability of the tests. Because verification is carried out at the "interface granularity" rather than the "system granularity" and the problem location is accurately pinpointed based on "hierarchical information," more than 90% of cross-system integration defects can be discovered early in development. These defects include, but are not limited to, missing interface parameters, mismatched field types, state machine logic errors, omissions in batch processing rules, and transaction rollback anomalies.

[0138] This method, through a mechanism of "early exposure, precise positioning, responsibility binding, and immediate feedback," decomposes high-risk defects that were originally concentrated before production into localized problems with high frequency and low impact during the development process, thereby achieving a shift from "post-event repair" to "pre-event prevention."

[0139] Furthermore, since a "transaction" serves as the smallest unit of collaboration, its associated "hierarchical information" and "development object" information are structured. All abnormal events can be traced back to specific transactions, systems, teams, and interfaces, forming a complete "problem-responsibility-repair-verification" closed loop. This mechanism not only improves the efficiency of development and testing collaboration but also constructs a new engineering management paradigm for the collaborative development of multiple systems in the core systems of large banks, characterized by "controllable risks, traceable responsibilities, and manageable processes."

[0140] In summary, the proposed solution leverages the elastic computing and automated deployment capabilities offered by cloud-native technologies to enable collaborative development across multiple systems. However, cloud-native technologies rely on specific cloud service environments, posing vendor lock-in risks and demanding high levels of cloud technology expertise from the team. Building a business platform and a technology platform allows for the accumulation and reuse of common business and technical capabilities, supporting collaborative development across multiple systems. However, the construction of such a platform architecture is time-consuming, requires significant investment, and demands extremely high levels of business analysis and technology integration capabilities.

[0141] The technical solution of this invention has been practically applied in the core system upgrade project of a joint-stock bank. The project development cycle was shortened from the original 24 months to 20 months; cross-team communication costs were reduced by approximately 50%; rework caused by interface issues and design flaws was reduced by 55%; and development manpower costs were saved by approximately 6% through resource reuse. This fully verifies the feasibility and effectiveness of the technical solution of this invention in the collaborative development management of multiple systems in large-scale core software development projects of banks.

[0142] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the multi-system development execution management method of this application will be described in detail below with reference to specific embodiments.

[0143] This embodiment relates to a specific multi-system development execution management method. Based on a comprehensive review of over 130 subsystems and over 2,000 core transactions in a large bank's core system, a structured collaborative management framework was constructed. Its core lies in the standardized collection and associated management of "basic transaction information," specifically including:

[0144] Transaction Initiating System Name: This identifies the source system that triggered a transaction, such as "counter system," "corporate online banking system," or "mobile banking app." Its purpose is to clearly define the starting point of the transaction chain and provide an anchor point for establishing dependencies between systems. This name is uniformly named and entered into the system by the system architecture team to ensure uniqueness and consistency.

[0145] Transaction Ownership Development Team: This is used to link the specific technical team responsible for the development or modification of the transaction, such as the "Core System - Account Management Group" or the "Payment Platform - Clearing Module Group." This information is manually entered and fixed according to the division of development responsibilities, serving as the basis for determining responsibility for interface releases and assigning tasks, ensuring "whoever develops, is responsible, and delivers."

[0146] Initiator Transaction Code / Transaction Name: A dual identification mechanism is adopted, using a unique code (e.g., "CT-2024-089") and a standardized business name (e.g., "Corporate Transfer Transaction"), to achieve accurate identification and traceability of transactions across multiple systems and teams. The initiator transaction code for each transaction remains unchanged throughout its entire lifecycle, serving as a unified index for related information, hierarchical information, and development object information, supporting all subsequent automated comparison and traceability operations.

[0147] The above three items of "basic transaction information" are entered into a structured form using automated tools, creating a transaction master data table. The system then uses manually defined initial dependency relationships (such as "counter system calls channel integration layer interface" and "channel integration layer calls payment middle platform interface") to construct a four-dimensional relationship model of "transaction—interface—transaction system—development object" through automated processing, forming a "relationship information" database. This database supports reverse lookup of all dependent interfaces by transaction code, reverse lookup of all used transactions by interface, and statistics of interfaces to be delivered by development team.

[0148] The model supports automatic identification of transaction call paths at five or more layers (e.g., customer channel layer → channel integration layer → business middle platform → enterprise service bus → core accounting system), and automatically eliminates redundant mappings, useless paths and logical conflicts through database processing logic to ensure the accuracy and validity of "related information" data.

[0149] Through this structured information system, this solution achieves automated judgment between "interface release - transaction readiness": when a transaction initiator's system releases a new interface, it automatically matches the transaction to which it belongs and judges whether the transaction has all the required interfaces based on the "related information"; if not, it automatically sends an "interface missing warning" to the relevant "transaction-owned development team"; if all conditions are met, it triggers a "transaction development and testing conditions ready" prompt, realizing an agile development model of "interface release triggers collaborative response".

[0150] The project team recommends the following production verification time: Each transaction's "transaction-assigned development team" should submit a suggested initial production verification time for the transaction based on the release status and development progress of the interfaces they are responsible for. The system will automatically integrate the verification time plans of all "transaction systems" involved in the transaction and combine them with the resource usage of the test environment (such as the number of test accounts, concurrent capacity, and network bandwidth) to generate a standardized "transaction verification timeline". This timeline uses the "initiator's transaction code" as a unique identifier to ensure that there are no resource conflicts in the verification windows of each transaction, and to avoid verification failures or data pollution caused by multiple transactions occupying the same test environment at the same time.

[0151] Verification of Non-Migrated Customers: For customers still running in the old system environment, the business verification team executes the complete transaction process corresponding to the above transactions in the old system to verify the functional integrity and data consistency of the transaction in the old system environment. The focus is on verifying cross-system compatibility issues such as data format conversion, field mapping rules, and business logic adaptation. The verification result is entered as "verification passed" or "verification failed" in the system by the verification personnel, and the "initiator transaction code" of the transaction is associated. The system automatically records the verification time, the personnel who performed the verification, the environment version, and any abnormal phenomena, which serve as a traceable basis for the "non-migrated customer compatibility verification" of the transaction.

[0152] Verification of Migrated Customers: For customers who have completed system migration, the business verification team executes the complete process of the above transactions in the new system environment to verify their functional correctness, response latency, concurrency processing capabilities, and security control effectiveness under real business loads. During the verification process, the system automatically collects performance indicators such as transaction execution logs, response times, and error codes, and compares them with preset thresholds. Verification personnel mark "verification passed" or "verification failed" in the system based on the results and associate them with the "initiator transaction code" of the transaction. The verification conclusions and performance data are archived synchronously as the core basis for determining whether the transaction is ready for production.

[0153] Verification Instructions: For any abnormal issues encountered during the two types of verification processes mentioned above (such as "transaction timeout", "account balance inconsistency", "interface error code 403", etc.), the verification team shall fill in a detailed description of the problem, reproduction steps, temporary solutions, and final root cause analysis in the system. The system will automatically bind the problem to the corresponding "transaction", "transaction system", and "development object" and generate a structured "verification report". This report includes the transaction name, verification time, verification status, problem summary, handling measures, and responsible person. It supports retrieval and export by transaction code, system level, development team, and other dimensions, providing a complete chain of evidence for subsequent production decisions, version rollback, or accountability.

[0154] I. Example of Dependency Analysis: Run a "funds transfer" transaction in the test environment. The complete transaction path is: Core System → Account System (check balance) → Interest Rate Engine (calculate internal interest) → Accounting Module (posting) → General Ledger System (update). This constitutes the dependency graph.

[0155] II. Production Verification: During production verification, check each point in the transaction chain outlined in the development and testing process: 1. After the core upgrade, is the account balance query accurate? 2. Is the internal funding rate calculated correctly? 3. Do the accounting entries comply with the new regulations? 4. Can the data be accurately synchronized to the general ledger?

[0156] III. Core Function: By reviewing transactions in advance, errors caused by differences in interest rate parameters and accounting rules between the production environment and the testing environment can be identified in advance, ensuring that the entire fund allocation chain is fully connected in production, rather than just looking at the core system's own functions.

[0157] The aforementioned verification process management mechanism, relying on a structured data system of "basic transaction information" and "related information," achieves a strong binding between verification activities and transactions. The determination of whether a verification passes or fails no longer depends on verbal reports or paper records, but is instead standardized by business verification personnel using the "initiator's transaction code" as an index in the system. This ensures that the verification status of each transaction can be automatically statistically analyzed, presented in real-time, and traced historically. This mechanism effectively transforms traditional "passive response" verification into "proactive triggering" closed-loop management: only when the transaction's "interfaces have all been released," the "development team has confirmed readiness," and "all verification statuses have passed" is the system allowed to enter the production window, thereby significantly improving development and testing collaboration efficiency and shortening the overall project cycle.

[0158] This application also provides a multi-system development execution management device. It should be noted that this device can be used to execute the multi-system development execution 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.

[0159] The following describes the multi-system development execution management device provided in the embodiments of this application.

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

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

[0162] The first processing unit 20 is used to find the required interfaces associated with the transaction based on the above-mentioned association information, and to determine whether all the required interfaces associated with the transaction have been published.

[0163] The second processing unit 30 is configured to determine that the development conditions are met, generate a prompt message, and send the prompt message to the device at the development end, provided that all the required interfaces associated with the transaction have been published.

[0164] This embodiment establishes a precise mapping relationship between interfaces and transactions in advance. This information solidifies the specific set of interfaces that each transaction depends on in the multi-system call chain. Only when all the interfaces that a transaction depends on have been published is it determined that the transaction meets the development conditions, and a prompt message is actively pushed to the relevant development end. This realizes the transformation from "waiting for all to be completed" to "starting when conditions are met", thereby shortening the development cycle and improving the development efficiency in the multi-layer linkage development of the bank's core system.

[0165] In the specific implementation process, the first processing unit includes a first processing module and a second processing module. The first processing module is used to extract all of the above-mentioned interfaces and determine, according to the above-mentioned association information, whether there is a call dependency relationship between the extracted interfaces and the above-mentioned transactions. The second processing module is used to determine the interfaces that have a call dependency relationship with the above-mentioned transactions as the required interfaces associated with the above-mentioned transactions when there is a call dependency relationship between the above-mentioned interfaces and the above-mentioned transactions.

[0166] This solution extracts all interfaces in the system and identifies and verifies the call dependencies of each interface based on the pre-defined mapping relationship between the interfaces and transactions. Only those interfaces that clearly participate in the transaction call process and have actual dependencies are selected as the interfaces required by the transaction. This effectively eliminates misjudgments of non-calling interfaces caused by redundant mapping relationships or static configuration, ensuring that the determined set of interfaces accurately reflects the true dependency structure of the transaction. On this basis, it further determines whether all members of these confirmed required interfaces have been published. Only when all interfaces have been published is the development condition deemed met, and a prompt message is pushed to the development end. This avoids misjudgments of development start caused by omitting real dependencies or misjudging non-essential interfaces as necessary interfaces, significantly improving the accuracy and reliability of transaction development precondition judgment. Ultimately, it achieves refined control over the collaborative status of interface publication, ensuring the efficient and orderly progress of the transaction development process.

[0167] In some embodiments, the first processing unit includes a first acquisition module, a first comparison module, a first determination module, and a second determination module. The first acquisition module is used to acquire a list of interfaces required for the transaction to obtain a first list. The first comparison module is used to compare the published interfaces with the first list to obtain a first comparison result. The first determination module is used to determine that all the required interfaces associated with the transaction have been published if the first comparison result indicates that all the interfaces in the first list have been matched. The second determination module is used to determine that all the required interfaces associated with the transaction have not been published if the first comparison result indicates that at least one interface in the first list has not been matched.

[0168] This solution obtains a pre-defined mapping relationship between transactions and interfaces to accurately locate all required interfaces associated with the transaction. It then obtains a first list of interfaces explicitly required by the transaction. Each published interface in the system is compared with this first list to generate a first comparison result. When the comparison result shows that all interfaces in the first list have been successfully matched, the transaction development conditions are deemed fully met, and a prompt message is generated and pushed to the development end. Conversely, if any interface is not matched in the comparison result, the development conditions are deemed not yet met. This solution explicitly eliminates the possibility of misjudgment based on "partial publication meeting the conditions," thus achieving a precise and traceable judgment mechanism for pre-development conditions. It effectively solves the problems of delayed development collaboration and misjudgment caused by ambiguous interface publication status and unclear missing information, significantly improving the accuracy and efficiency of transaction development preparation.

[0169] In the specific implementation process, the above-mentioned device further includes a determining unit, an updating unit, and a first searching unit. The determining unit is used to obtain information on the preset mapping relationship between the interface and the transaction. After obtaining the association information, if some of the association information satisfies at least one of the following conditions, the association information that meets the conditions is invalid information: there is a redundant mapping between the interface and the transaction; the call path between the interface and the transaction is a useless path; or there is a logical conflict between the interface and the transaction. The updating unit is used to delete the invalid information in the association information to obtain the updated association information. The first searching unit is used to find the required interface associated with the transaction based on the updated association information.

[0170] This solution obtains the pre-defined mapping relationships between interfaces and transactions to form initial association information. It then identifies any abnormal associations such as redundant mappings, useless call paths, or logical conflicts. Association information meeting any of these abnormal conditions is deemed invalid and removed, resulting in updated association information containing only valid paths. Subsequently, based on this purified association information, the solution accurately locates the required interfaces directly associated with the transaction and accurately determines whether all required interfaces have been published. This avoids misjudgments of development conditions caused by invalid associations, ensuring that a prompt indicating that development conditions are met is triggered only when all truly valid interfaces have been published. This effectively solves the problem of development resource scheduling delays or incorrect startups caused by historical or misconfigured association information, improving the accuracy, collaboration, and execution efficiency of the transaction development process.

[0171] In some embodiments, the first processing unit includes a second acquisition module, a first search module, a second acquisition module, a second comparison module, a third determination module, and a fourth determination module. The second acquisition module is used to acquire hierarchical relationship information of a preset required transaction system associated with the transaction, thereby obtaining hierarchical information. The first search module is used to find the transaction associated with the interface based on the association information and to find the transaction system associated with the transaction based on the hierarchical information. The second acquisition module is used to acquire a list of interfaces required by the transaction system associated with the transaction, thereby obtaining a second list. The second comparison module is used to compare the published interfaces with the second list, thereby obtaining a second comparison result. The third determination module is used to determine that all required interfaces associated with the transaction have been published if the second comparison result indicates that all interfaces in the second list have been matched. The fourth determination module is used to determine that all required interfaces associated with the transaction have not been published if the second comparison result indicates that at least one interface in the second list has not been matched.

[0172] This solution acquires the hierarchical relationship information of the pre-defined required trading systems associated with the transaction, constructs a hierarchical mapping relationship between the transaction and the underlying trading system, and combines this with the pre-defined mapping relationship between the interface and the transaction to accurately locate the specific trading system level on which the transaction depends. This allows for the acquisition of the interface list required by that specific trading system, ensuring that interface integrity verification is no longer based on a generalized transaction dimension but converges to the actual system level it depends on. This avoids misjudgments of interface requirements due to complex system architecture levels. By comparing the published interfaces with the interface list of that specific system level, the development conditions are only considered met when all interfaces in the list have been published. This effectively prevents false satisfaction states caused by cross-system level interface confusion or omissions, ensuring the true availability of all dependent interfaces before development begins. Ultimately, this achieves accurate and reliable judgment of transaction development conditions in a multi-system collaborative environment, improving system integration efficiency and the stability of the development process.

[0173] In the specific implementation process, the first processing unit includes a third acquisition module, a second search module, a fourth acquisition module, a third comparison module, a fifth determination module, and a sixth determination module. The third acquisition module is used to acquire task relationship information of the preset required development objects associated with the above-mentioned transaction system, and obtain task information. The second search module is used to find the above-mentioned transaction system associated with the above-mentioned transaction based on the above-mentioned hierarchical information, and find the above-mentioned development objects associated with the above-mentioned transaction system based on the above-mentioned task information. The fourth acquisition module is used to acquire the interface list required by the above-mentioned development objects associated with the above-mentioned transaction system, and obtain a third list. The third comparison module is used to compare the published interfaces with the above-mentioned third list, and obtain a third comparison result. The fifth determination module is used to determine that all the required interfaces associated with the above-mentioned transaction have been published if the above-mentioned third comparison result indicates that all the interfaces in the above-mentioned third list have been compared. The sixth determination module is used to determine that all the required interfaces associated with the above-mentioned transaction have not been published if the above-mentioned third comparison result indicates that at least one of the above-mentioned interfaces in the above-mentioned third list has not been compared.

[0174] This solution obtains task relationship information of pre-defined development objects associated with the transaction system, clarifies the interface responsibility boundaries of each development object within the transaction system, and accurately locates the specific development object associated with the transaction system. This leads to the creation of a third list of interfaces responsible for each development object. The published interfaces are then compared item by item with this third list. Based on the comparison results, it is determined whether all interfaces required for the transaction have been fully published. When all interfaces in the third list are successfully matched, the development conditions are confirmed to be met; otherwise, it is determined that interfaces are missing. This process overcomes the limitations of previous methods that only used the transaction system as a unit for coarse-grained judgment of interface completeness. It achieves precise identification of the responsible parties for interfaces and fine-grained verification of delivery status, effectively solving problems such as difficulty in tracing missing interfaces and misjudgment of development conditions caused by ambiguous interface responsibilities among development objects. This ensures that the interface preparation status before transaction development is traceable and verifiable, significantly improving the efficiency and accuracy of multi-team collaborative development.

[0175] In some embodiments, the above-described apparatus further includes a second search unit, a second acquisition unit, and a display unit. The second search unit is used to find all the interfaces associated with the transaction based on the association information after generating the prompt information and receiving a request to trace the transaction. The second acquisition unit is used to acquire the transaction name of the transaction and the interface name of the interface associated with the transaction. The display unit is used to display the transaction name and the interface name on a display device.

[0176] In this solution, after a transaction has been published or is running, when a traceability request for that transaction is received, the system automatically locates and retrieves all interfaces directly associated with the transaction based on the preset mapping relationship between interfaces and transactions. At the same time, it extracts the name of the transaction itself and the names of each associated interface, and presents them together in a clear and corresponding form on the display device. This allows maintenance or auditing personnel to quickly and accurately grasp the complete mapping relationship between the transaction and its dependent interfaces without relying on manual document review. This effectively solves the problems of delayed problem location, difficulty in assigning responsibility, and low efficiency in audit traceability caused by opaque interface dependencies. The solution achieves the effects of improving system traceability, reducing maintenance costs, and enhancing the reliability of multi-system collaborative development and maintenance.

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

[0178] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can address the low development efficiency in multi-layered, interconnected development of core banking systems in existing technologies.

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

[0180] 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 execution management method.

[0181] This invention provides a processor for running a program, wherein the program executes the multi-system development execution management method during runtime.

[0182] 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 at least several system development, execution, and management method steps. The device described herein can be a server, PC, tablet, mobile phone, etc.

[0183] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing initialization steps of a development execution management method for at least multiple systems.

[0184] This invention provides a transaction 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 a development execution management method for executing any of the above-described multi-system methods.

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

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

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

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

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

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

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

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

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

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

[0195] 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 execution management method, characterized in that, include: Obtain information about the pre-defined mapping relationship between the interface and the transaction to obtain the association information; Based on the association information, locate the required interfaces associated with the transaction, and determine whether all the required interfaces associated with the transaction have been published. If all required interfaces associated with the transaction have been published, the development conditions are determined to be met, a prompt message is generated, and the prompt message is sent to the device on the development side.

2. The method according to claim 1, characterized in that, Finding the required interface associated with the transaction based on the association information includes: Extract all of the interfaces, and determine, based on the association information, whether there is a call dependency relationship between the extracted interfaces and the transaction; In cases where there is a call dependency between the interface and the transaction, the interface that has a call dependency with the transaction is identified as the required interface associated with the transaction.

3. The method according to claim 1, characterized in that, Determine whether all the required interfaces associated with the transaction have been published, including: Obtain the list of interfaces required for the transaction to obtain the first list; The published interfaces are compared with the first list to obtain the first comparison result; If the first comparison result indicates that all the interfaces in the first list have been matched, it is determined that all the required interfaces associated with the transaction have been published. If the first comparison result indicates that at least one of the interfaces in the first list has not been matched, it is determined that all of the required interfaces associated with the transaction have not been published.

4. The method according to claim 3, characterized in that, After obtaining the pre-defined mapping relationship between the interface and the transaction, the method further includes: If any of the following conditions are met: there is a redundant mapping between the interface and the transaction; the call path between the interface and the transaction is a useless path; or there is a logical conflict between the interface and the transaction, then the associated information that meets these conditions is determined to be invalid information. The invalid information in the associated information is deleted to obtain the updated associated information; The required interface associated with the transaction is found based on the updated association information.

5. The method according to claim 3, characterized in that, Determine whether all the required interfaces associated with the transaction have been published, including: Obtain the hierarchical relationship information of the preset required transaction system associated with the transaction, and obtain the hierarchical information; The transaction associated with the interface is found based on the association information, and the transaction system associated with the transaction is found based on the hierarchy information; Obtain the list of interfaces required by the transaction system associated with the transaction, thus obtaining a second list; The published interfaces are compared with the second list to obtain the second comparison result; If the second comparison result indicates that all the interfaces in the second list have been matched, it is determined that all the required interfaces associated with the transaction have been published. If the second comparison result indicates that at least one of the interfaces in the second list has not been matched, it is determined that all of the required interfaces associated with the transaction have not been published.

6. The method according to claim 5, characterized in that, Determine whether all the required interfaces associated with the transaction have been published, including: Obtain task relationship information of the preset required development objects associated with the transaction system to obtain task information; The transaction system associated with the transaction is located based on the hierarchical information, and the development object associated with the transaction system is located based on the task information. Obtain the list of interfaces required by the development object associated with the transaction system to obtain a third list; The published interfaces are compared with the third list to obtain the third comparison result; If the third comparison result indicates that all the interfaces in the third list have been matched, it is determined that all the required interfaces associated with the transaction have been published. If the third comparison result indicates that at least one of the interfaces in the third list has not been matched, it is determined that all of the required interfaces associated with the transaction have not been published.

7. The method according to any one of claims 1 to 6, characterized in that, After generating the prompt message, the method further includes: Upon receiving a request to trace the origin of the transaction, all interfaces associated with the transaction are located based on the association information; Obtain the transaction name of the transaction, and obtain the interface name of the interface associated with the transaction; The transaction name and the interface name are displayed on the display device.

8. A multi-system development execution management device, characterized in that, include: The first acquisition unit is used to acquire information about the preset mapping relationship between the interface and the transaction, and obtain the association information; The first processing unit is configured to find the required interface associated with the transaction based on the association information, and determine whether all the required interfaces associated with the transaction have been published. The second processing unit is used to determine that the development conditions are met when all the required interfaces associated with the transaction have been published, generate a prompt message, and send the prompt message to the device on the development end.

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 development, execution and management method for the multi-system described in any one of claims 1 to 7.

10. A trading 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 development execution management method for performing a multi-system as described in any one of claims 1 to 7.

Images