Method for determining status information of remittance business based on distributed architecture

Abstract

The present application provides a method for determining status information of a remittance business based on a distributed architecture, the method comprising: obtaining a main service corresponding to master data of a target remittance business, the main service being at least one of a plurality of services obtained by splitting the target remittance business according to a service-oriented architecture; determining, based on the main service, a plurality of business status information and a plurality of technical status information, wherein a first scheduled transaction is at least a portion of a transaction related to the main service, the business status information is information characterizing a flow status of the first scheduled transaction, and the technical status information is information characterizing an interaction result between the services corresponding to the first scheduled transaction. This solution ensures that the obtained business status information and technical status information are relatively clear and accurate, thereby solving the problem in the prior art that the status of the remittance process is not clear and accurate enough, and meeting the dynamic understanding needs of different groups of people for the remittance business.

Description

Technical Field

[0001] The present application relates to the field of remittance business, and in particular, to a method, a determination device, a computer-readable storage medium, a processor, and an electronic device for determining status information of a remittance business based on a distributed architecture. Background Art

[0002] In a traditional centralized architecture, all processing of a transaction can be completed within a single system; in a distributed architecture, the service capabilities of the financial system are provided by several or even dozens of services working together, with each service focusing on its own core logic.

[0003] Existing international remittance transactions based on a distributed architecture include cross-border and interbank remittances in foreign currency. Transactions are divided into three stages: the bank remittance component verifies transaction information and controls the transaction process; the personal deposit component handles account funds; and the international payment front-end handles communication and reconciliation with Western Union and SWIFT (Society for Worldwide Interbank Financial Telecommunications). Currently, international remittance status is designed using a 17-bit bitmap format. This status not only reflects the status of the draft but also the transaction process. For example, an outbound cancellation application reflects the application process and the receipt of the overseas response.

[0004] Productizing business processes into system processes is a core component of service analysis and design, and remittance status is a crucial component of bank remittance service design. From inception to completion, a remittance progresses through a series of events and states. The current remittance status design reflects both the bill status and the transaction process; it encompasses both user- and operational-focused states, but lacks clarity and accuracy. Some no longer-existing remittance states have not been cleaned up, resulting in redundancy.

[0005] The above information disclosed in the background technology section is only used to enhance the understanding of the background technology of the technology described in this article. Therefore, the background technology may contain certain information that does not form the prior art known in this country to those skilled in the art. Summary of the Invention

[0006] The main purpose of this application is to provide a method, a determination device, a computer-readable storage medium, a processor and an electronic device for determining the status information of a remittance business based on a distributed architecture, so as to solve the problem that the status of the remittance process in the prior art is not clear and accurate enough.

[0007] According to one aspect of an embodiment of the present invention, a method for determining status information of a remittance business based on a distributed architecture is provided, comprising: obtaining a main service corresponding to master data of a target remittance business, the main service being at least one of a plurality of services obtained by splitting the target remittance business according to a service-oriented architecture; and determining, based on the main service, a plurality of business status information and a plurality of technical status information, wherein a first scheduled transaction is at least a portion of a transaction related to the main service, the business status information is information characterizing a flow status of the first scheduled transaction, and the technical status information is information characterizing an interaction result between the services corresponding to the first scheduled transaction.

[0008] Optionally, obtaining the primary service corresponding to the master data of the target remittance business includes: obtaining a workflow of the target remittance business; determining the master data according to the workflow; and determining the primary service corresponding to the master data.

[0009] Optionally, based on the main service, multiple business status information and multiple technical status information are determined, including: based on the main service, all candidate status information is determined, the candidate status information includes information characterizing the flow of a second scheduled transaction and information characterizing the interaction results between each of the services corresponding to the second scheduled transaction, the second scheduled transaction being all the transactions related to the main service; predetermined processing is performed on the multiple candidate status information to obtain initial status information including each of the business status information and each of the technical status information, the predetermined processing including at least one of modifying the description language of the candidate status information, deleting and merging; and identifying the business status information and the technical status information from the initial status information.

[0010] Optionally, identifying the business status information and the technical status information from the initial status information includes: identifying the business status information from the initial status information, and controlling a first interface to display the business status information, the first interface being an interface for which a user has viewing authority; determining that the remaining initial status information is the technical status information, and controlling a second interface to display the technical status information, the second interface being an interface for which a technician has viewing authority.

[0011] Optionally, after determining multiple business status information and multiple technical status information based on the main service, the method further includes: determining the corresponding transaction flow status information of each of the services based on each of the business status information; checking each of the transaction flow status information to determine whether there is an abnormality, the abnormality being that the predetermined transaction flow status information of multiple services is different, and the predetermined transaction flow status information is the transaction flow status information corresponding to the same first predetermined transaction; if the abnormality exists, adjusting the abnormal predetermined transaction flow status information.

[0012] Optionally, adjusting the abnormal predetermined transaction status information includes: marking the abnormal predetermined transaction status information with a first identifier; adjusting the abnormal predetermined transaction status information; and changing the first identifier of the adjusted predetermined transaction status information to a second identifier.

[0013] According to another aspect of an embodiment of the present invention, a device for determining status information of a remittance business based on a distributed architecture is also provided, including: an acquisition unit, configured to acquire a main service corresponding to master data of a target remittance business, wherein the main service is at least one of multiple services obtained by splitting the target remittance business according to a service-oriented architecture; a first determination unit, configured to determine multiple business status information and multiple technical status information based on the main service, wherein a first scheduled transaction is at least a partial transaction related to the main service, the business status information is information characterizing the flow status of the first scheduled transaction, and the technical status information is information characterizing the interaction results between the services corresponding to the first scheduled transaction.

[0014] According to yet another aspect of the embodiments of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein the program executes any one of the methods described above.

[0015] According to yet another aspect of the embodiments of the present invention, a processor is provided, wherein the processor is configured to run a program, wherein any one of the methods is executed when the program is run.

[0016] According to one aspect of an embodiment of the present invention, an electronic device is also provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include methods for executing any one of the methods described.

[0017] In an embodiment of the present invention, in the method for determining status information of a remittance business based on a distributed architecture, first, a main service corresponding to master data of a target remittance business is obtained, and second, based on the obtained main service, multiple business status information and multiple technical status information are determined, wherein the main service is at least one of multiple services obtained by splitting the target remittance business according to a service-oriented architecture, the first scheduled transaction is at least a portion of a transaction related to the main service, the business status information is information representing the flow status of the first scheduled transaction, and the technical status information is information representing the interaction results between the services corresponding to the first scheduled transaction. Compared with the prior art, in which the status is not separated during the remittance process, this solution obtains the main service corresponding to the master data of the target remittance business, and then determines multiple business status information that are convenient for users to view and multiple technical status information that are convenient for business operators to view based on the obtained main service, that is, it simultaneously meets the customer's visibility and the operation and management's visibility demands. This solution separates the status in the remittance business and obtains multiple business status information and multiple technical status information. This ensures that the obtained business status information and technical status information are relatively clear and accurate, thereby solving the problem of unclear and inaccurate status of the remittance process in the prior art and meeting the dynamic understanding needs of different groups of people for the remittance business. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings that constitute part of this application are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation on this application. In the drawings:

[0019] Figure 1 A schematic diagram of a method for determining status information of a remittance service based on a distributed architecture according to an embodiment of the present application is shown;

[0020] Figure 2 A flowchart showing an identification workflow according to an embodiment of the present application is shown;

[0021] Figure 3 A schematic diagram of a device for determining status information of a remittance service based on a distributed architecture according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0022] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0023] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0025] For ease of description, some nouns or terms involved in the embodiments of the present application are explained below:

[0026] Distributed architecture: A distributed architecture is a set of principles for building systems. Using this set of principles, a complex system can be divided into a collection of simple subsystems. These subsystems should remain independent and consistent with the overall system framework. Each subsystem can be further subdivided to form a complex enterprise-level architecture. Using a distributed, stateless SOA-based architecture to build financial services systems allows for unlimited expansion of the service's parallel processing capabilities.

[0027] Interbank remittance: a service for transferring RMB or foreign currency to corporate or individual accounts opened at other domestic banks;

[0028] Cross-border remittance: Users can make foreign exchange remittances to recipients with bank accounts outside mainland China within the prescribed limit;

[0029] Payment channel: A channel that supports user remittances or payments. These channels help bank users complete the flow of funds and support the flow, reconciliation, and clearing of funds between banks and channels. The channels involved in this solution include large-value payment channels, small-value payment channels, super online banking, UnionPay payment channels, Western Union payment channels, and SWIFT;

[0030] SAF mechanism: Save and Forward (SAF) mechanism is mainly used to handle timeout situations between systems and ensure data consistency between systems. It adopts a hierarchical commitment design pattern. If the initiating system does not receive a response from the receiving system or the received response code is a timeout, the SAF mechanism is triggered, that is: System A sends a SAF message to System B. After System B receives the SAF message and responds to System A, it means that System B promises to System A that it will forward the SAF to the downstream execution system (transaction forwarding system) or complete the retransmission and recovery processing required by SAF (backend processing system).

[0031] As mentioned in the background technology, the status of the remittance process in the prior art is not clear and accurate enough. In order to solve the above problems, a typical embodiment of the present application provides a method for determining the status information of a remittance business based on a distributed architecture, a determination device, a computer-readable storage medium, a processor and an electronic device.

[0032] According to an embodiment of the present application, a method for determining status information for a remittance service based on a distributed architecture is provided. Enterprise-level distributed architectures require collaboration between various application components to provide services to users. As an application component providing process scheduling services, the state design must meet corresponding characteristics and requirements. This application proposes an effective method for determining status information based on the characteristics of distributed architectures and process-based services.

[0033] Figure 1 Flowchart of a method for determining status information of a remittance service based on a distributed architecture according to an embodiment of the present application. Figure 1 As shown, the method includes the following steps:

[0034] Step S101, obtaining a main service corresponding to the master data of a target remittance business, where the main service is at least one of a plurality of services obtained by splitting the target remittance business according to a service-oriented architecture;

[0035] Step S102: Determine multiple business status information and multiple technical status information based on the above-mentioned main service, wherein the first scheduled transaction is at least a partial transaction related to the above-mentioned main service, the above-mentioned business status information is information representing the flow status of the above-mentioned first scheduled transaction, and the above-mentioned technical status information is information representing the interaction results between the above-mentioned services corresponding to the above-mentioned first scheduled transaction.

[0036] In the above-mentioned method for determining status information of a remittance business based on a distributed architecture, first, a main service corresponding to master data of a target remittance business is obtained. Second, based on the obtained main service, multiple business status information and multiple technical status information are determined. The main service is at least one of multiple services obtained by splitting the target remittance business according to a service-oriented architecture. The first scheduled transaction is at least a portion of a transaction related to the main service. The business status information is information representing the flow status of the first scheduled transaction. The technical status information is information representing the interaction results between the services corresponding to the first scheduled transaction. Compared with the prior art, in which the status is not separated during the remittance process, this solution obtains the main service corresponding to the master data of the target remittance business, and then determines multiple business status information that are easy for users to view and multiple technical status information that are easy for business operators to view based on the obtained main service, that is, it simultaneously meets the customer's visibility and the operation and management's visibility demands. This solution separates the status in the remittance business and obtains multiple business status information and multiple technical status information. This ensures that the obtained business status information and technical status information are relatively clear and accurate, thereby solving the problem of unclear and inaccurate status of the remittance process in the prior art, and meeting the needs of different groups of people for dynamic understanding of the above-mentioned remittance business.

[0037] Specifically, for a traditional centralized architecture, all processing of a transaction can be completed within a single system; while for a distributed architecture, the service capabilities of the financial system are provided by several or even dozens of services working together. Each service focuses on its own core logic, and the design of the remittance status must also fully consider the characteristics of the service components. Taking inter-bank and cross-border remittances as an example, the service component belongs to the product service layer of the bank's IT architecture, accepting user requests from the channel service layer and the channel integration layer, completing the review, processing, and adjustment of remittance transactions, and at the same time, it needs to call the deposit component to complete account fund processing. Therefore, the core data of the service component and the master data of the transaction are remittances. The emphasis is on whether the remittance flow process can be clearly displayed through the status, and whether the process can be controlled through the remittance status. The remittance status is the most important attribute of the remittance entity. Taking inter-bank and cross-border remittance services as an example, for a business, from initiation to completion, an "end-to-end" workflow is completed. The purpose is to determine the capabilities provided by each service in the transaction process. Auxiliary and supporting services can be reflected in the workflow diagram. The final workflow flowchart is as follows: Figure 2 shown.

[0038] Specifically, taking interbank and cross-border remittances as an example, when obtaining the master data corresponding to the target remittance business, the service's layer can be used to assist in determining the corresponding primary service. For example, [Counter] is the channel service layer, providing banking services or an internal user interface for users. It is not responsible for recording transaction results and status, and its data operations primarily involve business or technical flow data. [Deposit] is the product service layer, managing all personal accounts within the bank, and its data operations primarily involve modifying account attributes. [PBOC Front Office] is also a channel service layer, simply connecting to external systems. Its data operations primarily involve communication and reconciliation with external systems. [Remittance] is also a product service layer, managing all interbank and cross-border remittances, and its data operations primarily involve modifying remittance attributes. From the above analysis, we can see that the master data for this workflow is remittances, which are distributed within the [Remittance] service. It should be noted that [] represents the multiple services derived from the decomposition of the target remittance business according to the service-oriented architecture.

[0039] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0040] In one embodiment of the present application, obtaining a primary service corresponding to master data of a target remittance business includes: obtaining a workflow for the target remittance business; determining the master data based on the workflow; and determining the primary service corresponding to the master data. In this embodiment, determining the master data based on the workflow of the target remittance business and then determining the primary service corresponding to the master data facilitates subsequent determination of multiple business status information and multiple technical status information based on the obtained master service, thereby further ensuring that the obtained multiple business status information and multiple technical status information are relatively clear.

[0041] In another embodiment of the present application, based on the above-mentioned main service, multiple business status information and multiple technical status information are determined, including: based on the above-mentioned main service, all candidate status information are determined, the above-mentioned candidate status information includes information representing the flow status of the second scheduled transaction and information representing the interaction results between the above-mentioned services corresponding to the above-mentioned second scheduled transaction, and the above-mentioned second scheduled transaction is all the above-mentioned transactions related to the above-mentioned main service; predetermined processing is performed on the multiple above-mentioned candidate status information to obtain initial status information including each of the above-mentioned business status information and each of the above-mentioned technical status information, the above-mentioned predetermined processing includes modifying at least one of the description language, deletion and merging of the above-mentioned candidate status information; and identifying the above-mentioned business status information and the above-mentioned technical status information from the above-mentioned initial status information. If the process status is simply and crudely mapped one-to-one into a bitmap according to the transaction process, it will be cumbersome and unclear on the one hand, and the implementation logic will be complex on the other hand. In this embodiment, all candidate status information is determined according to the main service, that is, all candidate status information is listed, which ensures that relatively complete candidate status information can be obtained, and then the multiple candidate status information obtained are processed in a predetermined manner to obtain initial status information, and then the business status information and the technical status information are identified from the initial status information, which ensures that the obtained business status information and technical status information are relatively reasonable. Through a simple and easy-to-operate method, the business process is abstractly modeled and the business status information and technical status information are extracted. Moreover, by dividing the business status information and the technical status information, it is ensured that the two states have single functions and do not affect each other, and can meet the business and operation needs respectively.

[0042] Specifically, taking the target remittance business of inter-bank remittance and cross-border remittance as an example, based on the above main service, the specific process of determining all candidate status information is as follows: determine the operations and events related to remittance according to the remittance workflow, and remove query operations; and analyze the operation results one by one to list all candidate status information, as shown in Table 1.

[0043] Table 1

[0044]

[0045]

[0046] In addition, the scheduled processing of multiple candidate status information must comply with the following three optimization principles: the necessity principle: the more statuses, the better. First, they must have practical significance. Second, only those that may remain for business operations need to be retained. For example, the pending deduction status in Table 1 actually causes deductions after the contract is registered in the transaction. The pending deduction status will only remain for less than 1 second and is basically invisible to the business, so there is no need to retain this status. The result-oriented principle: the status must represent the result of the current operation, not the process. For example, applications for refund and cancellation are actually just actions. A successful application will trigger a change in status, while a failed application will not change the status. The single object principle: In actual operation, the status is used not only by users and internal users, but also by operation and maintenance personnel to determine the flow of remittances. These two types of objects have different demands and focuses. For example, timed out is actually a status that operation and maintenance personnel are concerned about; for users, this scenario should be considered a success. Of course, in the actual service process, the description of business status information and technical status information should not only use business language, but also unify the subject-verb phrase structure. As shown in Table 2 below, the business status information and technical status information identified from the initial status information after predetermined processing of multiple candidate status information are performed.

[0047] Table 2

[0048]

[0049]

[0050] In order to dynamically view business status information and technical status information, in another embodiment of the present application, the business status information and technical status information are identified from the initial status information, including: identifying the business status information from the initial status information and controlling the first interface to display the business status information, the first interface being an interface for which the user has viewing authority; determining that the remaining initial status information is the technical status information and controlling the second interface to display the technical status information, the second interface being an interface for which the technician has viewing authority. In this embodiment, the obtained business status information is displayed on the first interface, which ensures that the user can more conveniently view the flow dynamics of the remittance business and understand the real-time remittance status. The obtained technical status information is displayed on the second interface, which ensures that the technician can more promptly and clearly see whether the interaction between the multiple services corresponding to the remittance business is normal, ensuring that the technician can promptly resolve any problems when they are discovered.

[0051] In the above embodiment, based on an understanding of the core logic and service capabilities of application components, state characteristics and design principles are determined to obtain the aforementioned candidate state information, fully adapting to the characteristics of a distributed architecture. By defining states based on the abstraction and induction of business events and processes, and pre-processing multiple candidate state information according to three optimization guiding principles: the necessity principle, the result-oriented principle, and the single object principle, multiple business state information and technical state information are obtained.

[0052] In order to ensure the correspondence between the business status and the flow status, thereby facilitating the verification of whether the relevant flow status information of each service is consistent, in another embodiment of the present application, after determining multiple business status information and multiple technical status information based on the above-mentioned main service, the above-mentioned method also includes: determining the corresponding flow status information of each of the above-mentioned services based on each of the above-mentioned business status information; verifying each of the above-mentioned flow status information to determine whether there is an abnormality, the above-mentioned abnormality is that the predetermined flow status information of multiple of the above-mentioned services is different, and the above-mentioned predetermined flow status information is the above-mentioned flow status information corresponding to the same above-mentioned first predetermined transaction; in the case of the above-mentioned abnormality, the above-mentioned predetermined flow status information of the above-mentioned abnormality is adjusted, which further ensures that the requirements of transaction consistency management are met.

[0053] In actual service operations, in a distributed architecture, a transactional reconciliation approach is more suitable than a business reconciliation approach. For the same transaction, reconciliation is required to verify and ensure the consistency of transactional status across services. Business status information reflects the flow of a remittance, while transactional status information reflects the processing results of a single transaction. For example, if a user successfully cancels a remittance, it is considered a success for the transaction, but a failure for the remittance, with the status "Cancelled." When determining the transactional status information for each service based on these business status information, it's important to note that when status is unclear across multiple systems, the appropriate transactional status setting depends on business considerations. For example, whether a remittance timeout should be considered a success or failure depends on considerations such as fund security and business objectives.

[0054] In one embodiment of the present application, adjusting the above-mentioned abnormal predetermined water flow status information includes: marking the above-mentioned abnormal predetermined water flow status information with a first identifier; adjusting the above-mentioned abnormal predetermined water flow status information; and changing the above-mentioned first identifier of the adjusted predetermined water flow status information to a second identifier. In this embodiment, when the predetermined water flow status information is abnormal, the abnormal predetermined water flow status information is marked with a first identifier, and after the abnormal predetermined water flow status information is adjusted, the first identifier of the adjusted predetermined water flow status information is changed to a second identifier. This ensures that the predetermined water flow status information can be viewed more conveniently, and can also reflect the entire error correction process and results.

[0055] Specifically, the first identifier may be "to be adjusted" and the second identifier may be "already adjusted", so that a technician can clearly identify the water flow status information to be adjusted and the water flow status information to be adjusted. Of course, the first identifier and the second identifier are not limited to the above-mentioned "to be adjusted" and "already adjusted", and may also be other identifier characters.

[0056] In a specific embodiment of the present application, the status setting should not be implemented through hard coding, but can be implemented through dynamic configuration and memory reading, that is, online maintenance and quasi-real-time effectiveness can be achieved, thereby effectively improving the convenience and timeliness of status management. The specific configuration method is shown in Table 3.

[0057] Table 3

[0058] trade Trigger Event Technical status information Business status information Remittance-Stop Payment (Subject to Review) Create a remittance entity before calling deposit Outbound call Remittance-Stop Payment (Subject to Review) Deposit stop payment call successful Outbound call successful Awaiting manual review Remittance-Stop Payment (Subject to Review) Deposit stop payment call failed Outbound call failed Stop payment failed Remittance-Stop Payment (Subject to Review) Deposit stop payment call timeout Outbound call timeout / abnormal Stop payment failed Fahui-Compliance Review Approved by the teller Not leaving the country Fahui-Compliance Review Teller review failed Pending refund

[0059] In another specific embodiment of the present application, a processing mechanism for ensuring data consistency between systems can be implemented through the SAF mechanism. Due to the adoption of a step-by-step commitment design pattern, the upstream system can default to success / failure (based on the direction of funds) when the response timeout occurs. Therefore, in the event of a timeout, the transaction is equivalent to success or failure, and there is no need to set a status representation for the timeout. In the specific cross-check process, it can be specifically divided into three parts: the first is the cross-check between workflow and status, focusing on whether the design of the status can meet process control; the second is the cross-check between status and data, focusing on whether the distribution of status in the database table is reasonable; and the third is the cross-check between status and the technical platform, focusing on whether the requirements of transaction control and exception mechanisms can be met. Of course, for the failure of multi-system transaction coordination, it is also necessary to support the automation and manual error correction methods of the service layer, that is, the state determination process of the remittance business mentioned above must be carried out with the purpose of meeting automation requirements. This embodiment clearly proposes the correlation between state design and inter-system transaction coordination and transaction consistency management in the real-time transaction link, the subsequent reference to the SAF mechanism and the reconciliation mechanism, and further enables the state design to meet the requirements of transaction consistency management.

[0060] In traditional centralized system design, business processing is often completed within a system, and the state is more of a reflection of the result rather than the process; the state design is mapped according to business events and system events, lacks the process of abstraction and modeling, and fails to accurately reflect the life cycle of process-type businesses; fails to classify the source of state requirements, and the state function definition is inaccurate. The above method of this application, based on the understanding of the core logic and service capabilities of application components, determines the state characteristics and design principles, fully adapting to the characteristics of distributed architecture; proposes to define the state based on the abstraction and induction of business events and processes, and refines the three optimization guiding principles of necessity principle, result-oriented principle and single object principle; expands the scope of state design considerations, incorporates the analysis of exception handling mechanism, and can meet the demands of transaction consistency management.

[0061] The present application also provides a device for determining status information of a remittance service based on a distributed architecture. It should be noted that the device for determining status information of a remittance service based on a distributed architecture according to the present application can be used to execute the method for determining status information of a remittance service based on a distributed architecture provided in the present application. The following describes the device for determining status information of a remittance service based on a distributed architecture provided in the present application.

[0062] Figure 3 Schematic diagram of a device for determining status information of a remittance service based on a distributed architecture according to an embodiment of the present application. Figure 3 As shown, the device includes:

[0063] An acquiring unit 10 is configured to acquire a primary service corresponding to the master data of a target remittance business, wherein the primary service is at least one of a plurality of services obtained by splitting the target remittance business according to a service-oriented architecture;

[0064] The first determination unit 20 is used to determine multiple business status information and multiple technical status information based on the above-mentioned main service, wherein the first scheduled transaction is at least a portion of the transaction related to the above-mentioned main service, the above-mentioned business status information is information representing the flow status of the above-mentioned first scheduled transaction, and the above-mentioned technical status information is information representing the interaction results between the above-mentioned services corresponding to the above-mentioned first scheduled transaction.

[0065] In the above-mentioned device for determining status information of a remittance business based on a distributed architecture, an acquisition unit is used to obtain a main service corresponding to master data of a target remittance business, where the main service is at least one of multiple services obtained by splitting the target remittance business according to a service-oriented architecture; a first determination unit is used to determine multiple business status information and multiple technical status information based on the main service, wherein the first scheduled transaction is at least a portion of a transaction related to the main service, the business status information is information characterizing the flow status of the first scheduled transaction, and the technical status information is information characterizing the interaction results between the above-mentioned services corresponding to the first scheduled transaction. Compared with the prior art, in which the status is not separated during the remittance process, this solution obtains the main service corresponding to the master data of the target remittance business, and then determines multiple business status information that are easy for users to view and multiple technical status information that are easy for business operators to view based on the obtained main service, that is, it simultaneously meets the customer's visibility and the operation and management's visibility demands. This solution separates the status in the remittance business and obtains multiple business status information and multiple technical status information. This ensures that the obtained business status information and technical status information are relatively clear and accurate, thereby solving the problem of unclear and inaccurate status of the remittance process in the prior art, and meeting the needs of different groups of people for dynamic understanding of the above-mentioned remittance business.

[0066] Specifically, for a traditional centralized architecture, all processing of a transaction can be completed within a single system; while for a distributed architecture, the service capabilities of the financial system are provided by several or even dozens of services working together. Each service focuses on its own core logic, and the design of the remittance status must also fully consider the characteristics of the service components. Taking inter-bank and cross-border remittances as an example, the service component belongs to the product service layer of the bank's IT architecture, accepting user requests from the channel service layer and the channel integration layer, completing the review, processing, and adjustment of remittance transactions, and at the same time, it needs to call the deposit component to complete account fund processing. Therefore, the core data of the service component and the master data of the transaction are remittances. The emphasis is on whether the remittance flow process can be clearly displayed through the status, and whether the process can be controlled through the remittance status. The remittance status is the most important attribute of the remittance entity. Taking inter-bank and cross-border remittance services as an example, for a business, from initiation to completion, an "end-to-end" workflow is completed. The purpose is to determine the capabilities provided by each service in the transaction process. Auxiliary and supporting services can be reflected in the workflow diagram. The final workflow flowchart is as follows: Figure 2 shown.

[0067] Specifically, taking interbank and cross-border remittances as an example, when obtaining the master data corresponding to the target remittance business, the service's layer can be used to assist in determining the corresponding primary service. For example, [Counter] is the channel service layer, providing banking services or an internal user interface for users. It is not responsible for recording transaction results and status, and its data operations primarily involve business or technical flow data. [Deposit] is the product service layer, managing all personal accounts within the bank, and its data operations primarily involve modifying account attributes. [PBOC Front Office] is also a channel service layer, simply connecting to external systems. Its data operations primarily involve communication and reconciliation with external systems. [Remittance] is also a product service layer, managing all interbank and cross-border remittances, and its data operations primarily involve modifying remittance attributes. From the above analysis, we can see that the master data for this workflow is remittances, which are distributed within the [Remittance] service. It should be noted that [] represents the multiple services derived from the decomposition of the target remittance business according to the service-oriented architecture.

[0068] In one embodiment of the present application, the acquisition unit includes an acquisition module, a first determination module, and a second determination module, wherein the acquisition unit is used to acquire the workflow of the target remittance business; the first determination module is used to determine the master data based on the workflow; and the second determination module is used to determine the master service corresponding to the master data. In this embodiment, the master data is determined based on the acquired workflow of the target remittance business, and then the master service corresponding to the master data is determined. This facilitates the subsequent determination of multiple business status information and multiple technical status information based on the obtained master service, thereby further ensuring that the obtained multiple business status information and multiple technical status information are relatively clear.

[0069] In another embodiment of the present application, the above-mentioned first determination unit includes a third determination module, a predetermined processing module and an identification module, wherein the above-mentioned third determination module is used to determine all candidate status information based on the above-mentioned main service, and the above-mentioned candidate status information includes information representing the flow status of the second predetermined transaction and information representing the interaction results between the above-mentioned services corresponding to the above-mentioned second predetermined transaction, and the above-mentioned second predetermined transaction is all the above-mentioned transactions related to the above-mentioned main service; the above-mentioned predetermined processing module is used to perform predetermined processing on multiple above-mentioned candidate status information to obtain initial status information including each above-mentioned business status information and each above-mentioned technical status information, and the above-mentioned predetermined processing includes at least one of modifying the description language of the above-mentioned candidate status information, deleting and merging; the above-mentioned identification module is used to identify the above-mentioned business status information and the above-mentioned technical status information from the above-mentioned initial status information. If the process status is simply and crudely mapped one-to-one into a bitmap according to the transaction process, it will be cumbersome and unclear on the one hand, and the implementation logic will be complex on the other hand. In this embodiment, all candidate status information is determined according to the main service, that is, all candidate status information is listed, which ensures that relatively complete candidate status information can be obtained, and then the multiple candidate status information obtained are processed in a predetermined manner to obtain initial status information, and then the business status information and the technical status information are identified from the initial status information, which ensures that the obtained business status information and technical status information are relatively reasonable. Through a simple and easy-to-operate method, the business process is abstractly modeled and the business status information and technical status information are extracted. Moreover, by dividing the business status information and the technical status information, it is ensured that the two states have single functions and do not affect each other, and can meet the business and operation needs respectively.

[0070] Specifically, taking the target remittance business of inter-bank remittance and cross-border remittance as an example, based on the above main service, the specific process of determining all candidate status information is as follows: determine the operations and events related to remittance according to the remittance workflow, and remove query operations; and analyze the operation results one by one to list all candidate status information, as shown in Table 1.

[0071] In addition, the scheduled processing of multiple candidate status information must comply with the following three optimization principles: the necessity principle: the more statuses, the better. First, they must have practical significance. Second, only those that may remain for business operations need to be retained. For example, the pending deduction status in Table 1 actually causes deductions after the contract is registered in the transaction. The pending deduction status will only remain for less than 1 second and is basically invisible to the business, so there is no need to retain this status. The result-oriented principle: the status must represent the result of the current operation, not the process. For example, applications for refund and cancellation are actually just actions. A successful application will trigger a change in status, while a failed application will not change the status. The single object principle: In actual operation, the status is used not only by users and internal users, but also by operation and maintenance personnel to determine the flow of remittances. These two types of objects have different demands and focuses. For example, timed out is actually a status that operation and maintenance personnel are concerned about; for users, this scenario should be considered a success. Of course, in the actual service process, the description of business status information and technical status information should not only use business language, but also unify the subject-verb phrase structure. As shown in Table 2 below, the business status information and technical status information identified from the initial status information after predetermined processing of multiple candidate status information are performed.

[0072] In order to dynamically view business status information and technical status information, in another embodiment of the present application, the above-mentioned identification module includes a first control submodule and a second control submodule, wherein the above-mentioned first control submodule is used to identify the above-mentioned business status information from the above-mentioned initial state information and control the first interface to display the above-mentioned business status information, and the above-mentioned first interface is an interface for users to view the user's permission; the above-mentioned second control submodule is used to determine that the remaining above-mentioned initial state information is the above-mentioned technical status information and control the second interface to display the above-mentioned technical status information, and the above-mentioned second interface is an interface for technicians to view the user's permission. In this embodiment, the obtained business status information is displayed on the first interface, which ensures that the user can more conveniently view the flow dynamics of the remittance business and understand the real-time remittance status. The obtained technical status information is displayed on the second interface, which ensures that the technician can more promptly and clearly see whether the interaction between the multiple services corresponding to the remittance business is normal, and ensure that the technician can solve the problem in a timely manner when it is discovered.

[0073] In the above embodiment, based on an understanding of the core logic and service capabilities of application components, state characteristics and design principles are determined to obtain the aforementioned candidate state information, fully adapting to the characteristics of a distributed architecture. By defining states based on the abstraction and induction of business events and processes, and pre-processing multiple candidate state information according to three optimization guiding principles: the necessity principle, the result-oriented principle, and the single object principle, multiple business state information and technical state information are obtained.

[0074] In order to ensure the correspondence between the business status and the flow status, thereby facilitating the verification of whether the relevant flow status information of each service is consistent, in another embodiment of the present application, the above-mentioned determination device also includes a second determination unit, a third determination unit and an adjustment unit, wherein the above-mentioned second determination unit is used to determine the corresponding flow status information of each of the above-mentioned services according to each of the above-mentioned business status information after determining multiple business status information and multiple technical status information according to the above-mentioned main service; the above-mentioned third determination unit is used to verify each of the above-mentioned flow status information to determine whether there is an abnormality, and the above-mentioned abnormality is that the predetermined flow status information of multiple of the above-mentioned services is different, and the above-mentioned predetermined flow status information is the above-mentioned flow status information corresponding to the same above-mentioned first predetermined transaction; the above-mentioned adjustment unit is used to adjust the above-mentioned predetermined flow status information of the above-mentioned abnormality when the above-mentioned abnormality exists, thereby further ensuring that the requirements of transaction consistency management are met.

[0075] In actual service operations, in a distributed architecture, a transactional reconciliation approach is more suitable than a business reconciliation approach. For the same transaction, reconciliation is required to verify and ensure the consistency of transactional status across services. Business status information reflects the flow of a remittance, while transactional status information reflects the processing results of a single transaction. For example, if a user successfully cancels a remittance, it is considered a success for the transaction, but a failure for the remittance, with the status "Cancelled." When determining the transactional status information for each service based on these business status information, it's important to note that when status is unclear across multiple systems, the appropriate transactional status setting depends on business considerations. For example, whether a remittance timeout should be considered a success or failure depends on considerations such as fund security and business objectives.

[0076] In one embodiment of the present application, the adjustment unit includes a marking module, an adjustment module, and a change module, wherein the marking module is used to mark the abnormal predetermined water flow status information with a first identifier; the adjustment module is used to adjust the abnormal predetermined water flow status information; and the change module is used to change the adjusted first identifier of the predetermined water flow status information to a second identifier. In this embodiment, in the case where the predetermined water flow status information is abnormal, the abnormal predetermined water flow status information is marked with a first identifier, and after the abnormal predetermined water flow status information is adjusted, the first identifier of the adjusted predetermined water flow status information is changed to a second identifier, thereby ensuring that the predetermined water flow status information can be viewed more conveniently and can also reflect the entire error correction process and results.

[0077] Specifically, the first identifier may be "to be adjusted" and the second identifier may be "already adjusted", so that a technician can clearly identify the water flow status information to be adjusted and the water flow status information to be adjusted. Of course, the first identifier and the second identifier are not limited to the above-mentioned "to be adjusted" and "already adjusted", and may also be other identifier characters.

[0078] In a specific embodiment of the present application, the status setting should not be implemented through hard coding, but can be implemented through dynamic configuration and memory reading, that is, online maintenance and quasi-real-time effectiveness can be achieved, thereby effectively improving the convenience and timeliness of status management. The specific configuration method is shown in Table 3.

[0079] In another specific embodiment of the present application, a processing mechanism for ensuring data consistency between systems can be implemented through the SAF mechanism. Due to the adoption of a step-by-step commitment design pattern, the upstream system can default to success / failure (based on the direction of funds) when the response timeout occurs. Therefore, in the event of a timeout, the transaction is equivalent to success or failure, and there is no need to set a status representation for the timeout. In the specific cross-check process, it can be specifically divided into three parts: the first is the cross-check between workflow and status, focusing on whether the design of the status can meet process control; the second is the cross-check between status and data, focusing on whether the distribution of status in the database table is reasonable; and the third is the cross-check between status and the technical platform, focusing on whether the requirements of transaction control and exception mechanisms can be met. Of course, for the failure of multi-system transaction coordination, it is also necessary to support the automation and manual error correction methods of the service layer, that is, the state determination process of the remittance business mentioned above must be carried out with the purpose of meeting automation requirements. This embodiment clearly proposes the correlation between state design and inter-system transaction coordination and transaction consistency management in the real-time transaction link, the subsequent reference to the SAF mechanism and the reconciliation mechanism, and further enables the state design to meet the requirements of transaction consistency management.

[0080] In traditional centralized system design, business processing is often completed within a system, and the state is more of a reflection of the result rather than the process; the state design is mapped according to business events and system events, lacks the process of abstraction and modeling, and fails to accurately reflect the life cycle of process-type businesses; fails to classify the source of state requirements, and the state function definition is inaccurate. The above-mentioned device of this application, based on the understanding of the core logic and service capabilities of the application components, determines the state characteristics and design principles, fully adapting to the characteristics of distributed architecture; proposes to define the state based on the abstraction and induction of business events and processes, and extracts the three optimization guiding principles of necessity principle, result-oriented principle and single object principle; expands the scope of state design considerations, incorporates the analysis of exception handling mechanism, and can meet the demands of transaction consistency management.

[0081] In order to make those skilled in the art more clearly understand the technical solution of this application, the following will be described with reference to specific embodiments:

[0082] Example 1

[0083] The remittance status flow process of large-value payment channels and small-value payment channels:

[0084] Outgoing remittance: The user applies for an outgoing remittance. If the remittance fails, the teller applies for a write-off. Different statuses are used to indicate the outcome of the transaction. The corresponding failure statuses are extracted based on different failure scenarios. The final remittance status includes: deduction failed, reversed, cleared / netted, queued, returned, and re-remitted. The specific remittance status flow is as follows:

[0085] (1) When a user conducts an inter-bank RMB remittance at the counter, if the account deduction fails, the transaction ends and the remittance status = deduction failure (final status); technical status information = outbound call failure or outbound call timeout / abnormal, corresponding to the two situations of failed response and no response of the associated system respectively;

[0086] (2) If the account deduction is successful, a remittance message is generated and sent to the bank's payment front-end system, with the technical status information = outbound call in progress; if the payment front-end synchronization response is successful or timed out, the business status information = sent, and the technical status information = outbound call success / outbound call timed out; if the payment front-end synchronization response fails, the business status information = pending, and the technical status information = outbound call failure; if the payment front-end synchronization response fails and the SAF recovery registration is successful, the business status information = reversed, and the technical status information = outbound call failure;

[0087] (3) Receive a response message, a clearing or netting success notification, the business status information = cleared / netted; receive a clearing or netting queue notification, the business status information = queued; receive a rejection or netting failure notification, the business status information = rejected, and the account funds need to be reversed;

[0088] (4) If the account funds are successfully reconciled or timed out, the business status information = Reconciled, and the technical status information = Outbound call successful / Outbound call timed out; if the account funds are unsuccessful, the business status information = Pending, and the technical status information = Outbound call failed;

[0089] (5) For user accounts that have been put on hold, the teller shall apply for the cancellation of the pending account. If the cancellation process after the pending account is selected to be returned to the original account, the business status information = returned; if the cancellation process after the pending account is selected to be remitted again, the business status information = remitted again;

[0090] Inbound remittance: A user initiates an inbound remittance from the Second Bank to the First Bank; a user initiates an outbound remittance from the First Bank and the remittance is placed on hold at the Second Bank, and the Second Bank then initiates a remittance refund; after the remittance is placed on hold at the First Bank due to abnormal user account status, the First Bank teller applies for a write-off of the account; different statuses are used to represent the results of the business, and failure statuses are refined according to different failure scenarios. The final remittance status includes the following: credited, on hold, returned, manually credited, and refunded. The status flow is as follows:

[0091] (1) The user initiates an inward remittance from the second bank to the first bank. If the deposit conditions are met, the funds are deposited into the account. If the deposit is successful or times out, the business status information = deposited, and the technical status information = outbound call successful / outbound call timed out; if the deposit fails, the business status information = pending, and the technical status information = outbound call failed;

[0092] (2) If the inward remittance does not meet the conditions for entry, the business status information = pending account;

[0093] (3) For transactions whose business status information is "pending", the transaction is suspended, and the business status information = suspended;

[0094] (4) If the incoming remittance is a normal inward remittance, the teller can choose to cancel the pending account by refunding the remittance. After the refund event is triggered, the PBOC payment front-end sends a refund message. If the PBOC front-end receives a synchronous response indicating that the outbound call is successful or the outbound call has timed out, the business status information = refunded, and the technical status information = outbound call success / outbound call timed out; if the PBOC front-end receives a synchronous response indicating that the outbound call has failed, the business status information = pending account, and the technical status information = outbound call failure; if the incoming remittance is a second bank refund, the teller cannot choose to cancel the remittance by refunding the remittance;

[0095] (5) If the remittance account is a non-free trade zone account, the teller can choose to contact the user to return the cash when applying for cancellation of the pending account at the counter. If the user successfully returns the cash at the branch counter, the business status information = returned. If the user is not contacted, the business status information = pending account;

[0096] (6) If the remittance account is a free trade zone account, cash cannot be returned according to regulatory requirements. Manual entry can be used to cancel the account. When the deposit event is triggered, if the deposit is successful or timed out, the business status information = manual entry, and the technical status information = outbound call success / outbound call timed out; if the deposit fails, the business status information = pending, and the technical status information = outbound call failure.

[0097] Example 2

[0098] The remittance status flow process of online payment inter-bank clearing:

[0099] Outward remittance: Taking a user's real-time interbank remittance at the counter as an example, different statuses are used to indicate the results of the transaction. These include the "netted" status based on the success scenario, and the corresponding failure statuses "deduction failed," "reversed," and "reversal failed" based on different failure scenarios. The flow of remittance status is as follows:

[0100] (1) When a user makes an inter-bank remittance at the counter, if the account deduction fails, the transaction ends, and the remittance status = deduction failure (final status); technical status information = outbound call failure. If the account deduction times out, the transaction ends, and the remittance status = reversed (final status); technical status information = outbound call timeout / abnormal;

[0101] (2) Outbound call over-network pre-position: if the outbound call fails, the remittance status = Reversed (Reversed), and the technical status information = Outbound call failed; if the outbound call succeeds, the remittance status = Waiting for reconciliation (non-final status), and the technical status information = Outbound call successful; if the outbound call times out, the remittance status = Timed out (non-final status), and the technical status information = Outbound call timeout / abnormal (timeout is treated as successful);

[0102] (3) Perform credit reconciliation: If a reconciliation notice is received from the People's Bank of China, the remittance status = reconciled (final status); if a rejection notice is received from the People's Bank of China, the outbound deposit is reversed;

[0103] (4) If the account deduction is successful but the transaction fails for some reason, the outbound deposit will be reversed. If the outbound deposit is successful or times out, the remittance status is set to "Reversed (final state)" and the technical status information is set to "Outbound call successful" or "Outbound call timed out / abnormal." If the outbound deposit fails, the remittance status is set to "Reversal failed (final state)" and the technical status information is set to "Outbound call failed."

[0104] Inbound remittance: Taking the manual fund collection activity initiated by a user through an electronic channel (using SMS authentication) as an example, different statuses are used to indicate the results of the transaction. This includes "Deposited" based on the success scenario, and "Authentication Failed," "Verification Failed," and "Netting Failed" based on different failure scenarios. The flow of remittance status is as follows:

[0105] (1) When a user conducts manual fund collection through electronic channels (SMS authentication method), if the SMS authentication fails and the transaction ends, the remittance status = authentication failure (final state), and the technical status information = outbound call failure or outbound call timeout / abnormal, corresponding to the two situations of failed response and no response of the associated system respectively; if the authentication is successful, the remittance status = pending authentication (non-final state), and the technical status information = outbound call success;

[0106] (2) After SMS authentication is successful, the user performs SMS verification according to the SMS verification code received from the second bank. If SMS verification fails, the remittance status = verification failure (final state), and the technical status information = outbound call failure; if verification is successful, the remittance status = pending reconciliation (non-final state), and the technical status information = outbound call success; if the outbound call pre-processing times out, it is considered that the verification is successful, and the remittance status = timed out (non-final state), and the technical status information = outbound call timeout / abnormal (timeout is treated as successful)

[0107] (3) After successful SMS verification, debit reconciliation is performed: upon receipt of the PBOC reconciliation notice, remittance status = credited (final status); upon receipt of the PBOC rejection notice, remittance status = reconciliation failure (final status).

[0108] Example 3

[0109] UnionPay remittance status flow process:

[0110] Outgoing transfer direction: real-time transfer and debit transfer, with the final status including debited and debit failed;

[0111] Remittance direction: real-time transfer in, debit transfer in, and the final status includes credited, credit failed, and send failed. The flow of remittance status is as follows:

[0112] (1) When a user uses a First Bank bank card to make a UnionPay remittance through a First Bank ATM (Automatic Teller Machine, ATM), and calls the associated system to activate the account, if the account withdrawal is successful, the technical status information = outbound call successful, and the remittance status = debited (final status); if the account withdrawal fails, the technical status information = outbound call failed, and the remittance status = debit failed (final status); if the account withdrawal times out, the technical status information = outbound call timeout / abnormal, and the remittance status = debit failed (final status);

[0113] (2) When a user uses a First Bank bank card to make a UnionPay remittance through a First Bank ATM and calls the associated system to activate the account, if the account deposit is successful, the technical status information = outbound call successful, and the remittance status = credited (final status); if the account deposit fails, the technical status information = outbound call failed, and the remittance status = credited (final status); if the account deposit times out, the technical status information = outbound call timeout / abnormal, the transaction is resent through SAF, and the remittance status = credited (final status);

[0114] (3) The user uses the mobile banking of the first bank to transfer the amount from the account of the second bank to the account of the first bank. First, the transaction information is forwarded to the front-end system. After the front-end system responds successfully, it then calls the associated system to deposit. If the account deposit is successful, the technical status information = outbound call success, and the remittance status = credited (final state). If the call to the associated system fails to deposit, the technical status information = outbound call failure, and the remittance status = credited failure. If the call to the associated system times out, the technical status information = outbound call timeout / abnormal, and SAF resends, and the remittance status = credited.

[0115] Example 4

[0116] The remittance status flow process of the Western Union payment channel:

[0117] Remittance direction; user application for remittance sending, teller application for remittance sending cancellation; different remittance statuses are used to indicate the transaction results; and corresponding failure statuses are extracted based on different failure scenarios. The final remittance status includes: deduction failed, reversed, outbound, and canceled. The remittance status flow is as follows:

[0118] (1) When a user makes a remittance from a Western Union account through the counter, the account deduction fails and the transaction ends. The remittance status = deduction failure (final status); the technical status information = outbound call failure or outbound call timeout / abnormal, corresponding to the two situations of failed response and no response of the associated system respectively;

[0119] (2) When a user makes a remittance from a Western Union account at the counter, the account deduction is successful, but the international payment pre-synchronization response fails, the transaction is completed, the remittance status = Reversed (final status), the technical status information = Outbound call failed, and the SAF registration is successfully restored;

[0120] (3) When a user makes a remittance from a Western Union account at the counter, the account deduction is successful, the international payment pre-synchronization response is successful, the transaction is completed, the remittance status = outbound (final status), and the technical status information = outbound call success or outbound call timeout / abnormal;

[0121] (4) If the original remittance status is "Outbound", the teller can make an error transaction at the counter - cancel the remittance. If the account deposit is successful, the transaction ends with the remittance status = Cancelled (final status) and the technical status information = Outbound call successful. If the account deposit is timed out or abnormal, the remittance status = Cancelled (final status) and the technical status information = Outbound call timeout / abnormal. If the account deposit fails, the remittance status = Cancelled (final status) and the technical status information = Outbound call failed.

[0122] Inbound remittance: Users apply for receiving remittances, and tellers apply for canceling receiving remittances. Different statuses are used to represent the results of the business processing, and corresponding failure statuses are extracted based on different failure scenarios. The final status includes: paid, receiving remittance failed, paying failed, and canceled. The flow of remittance status is as follows:

[0123] (1) When a user handles foreign exchange collection and payment at the counter, the international payment pre-synchronization response is successful. If the account deposit is successful, the transaction is completed, the remittance status = paid (final status), and the technical status information = outbound call success; if the account deposit times out, the transaction is completed, the remittance status = paid (final status), and the technical status information = outbound call timeout / abnormal; if the account deposit fails, the transaction is completed, the remittance status = paid (final status), and the technical status information = outbound call failure;

[0124] (2) When a user handles foreign exchange collection and payment at the counter, the international payment pre-synchronization response fails, the transaction ends, the remittance status = foreign exchange collection failure (final status), and the technical status information = outbound call failure;

[0125] (3) When a user conducts a foreign exchange collection and payment at the counter, the international payment pre-synchronization response times out, the transaction ends, the remittance status = foreign exchange collection failure (final status), and the technical status information = outbound call timeout / abnormal;

[0126] (4) When a user completes the remittance re-recording at the counter, if the account deposit is successful, the transaction is completed, the remittance status = paid (final status), and the technical status information = outbound call successful; if the account deposit fails, the transaction is completed, the remittance status = paid (intermediate status), and the technical status information = outbound call failed; if the account deposit outbound call timeout / abnormal, the transaction is completed, the remittance status = paid (final status), and the technical status information = outbound call timeout / abnormal;

[0127] (5) When a teller cancels a remittance at the counter, he or she can cancel a remittance transaction whose status is paid. If the account deposit cancellation response is successful, the remittance status = Cancelled (final status) and the technical status information = Outbound call successful; if the account deposit cancellation response fails, the remittance status = Paid (final status) and the technical status information = Outbound call failed; if the account deposit cancellation response is due to an outbound call timeout / abnormal, the remittance status = Paid (final status) and the technical status information = Outbound call timeout / abnormal.

[0128] Example 5

[0129] The remittance status flow process of the bank-post payment channel:

[0130] Outward remittance: User application for outward remittance, teller application for cancellation of outward remittance, user application for refund, compliance review, and automatic remittance by the system. Different statuses are used to represent the business processing results, and corresponding failure statuses are extracted based on different failure scenarios. The final status includes: stop payment failure, pending manual review, pending refund, refunded, revoked, canceled, outbound, outward remittance timeout, and outward remittance failure. The flow of remittance status is as follows:

[0131] (1) When a user applies for bank-post remittance at the counter, the account stop payment fails, the transaction ends, the remittance status = stop payment failure (final status), and the technical status information = outbound call failure;

[0132] (2) When a user applies for bank-post remittance at the counter, the account stop payment times out / is abnormal, the transaction ends, the remittance status = stop payment failure (final status), and the technical status information = outbound call timeout / abnormal;

[0133] (3) When a user applies for bank-post remittance through the teller, if the account is successfully stopped, a manual compliance review is required. The remittance status = pending manual review (intermediate state) and the technical status information = successful outbound call. The teller then conducts a compliance review. If the review is passed, the remittance status = not shown (intermediate state) and the technical status information = successful outbound call. The stop payment deduction must then be released. If the release response is successful, the remittance status = not shown (intermediate state) and the technical status information = successful outbound call. If the release response fails, the remittance status = deduction failure and the technical status information = failed outbound call.

[0134] (4) When a user applies for bank-post remittance through the counter, if the account is successfully stopped, a manual compliance review is required. The remittance status = pending manual review (intermediate state), and the technical status information = outbound call successful. The teller then conducts a compliance review. If the review fails, the remittance status = pending refund (intermediate state). The stop payment must then be released. If the stop payment release response is successful, the remittance status = refunded (final state), and the technical status information = outbound call successful. If the stop payment release response fails, the remittance status remains unchanged, and the technical status information = outbound call failed.

[0135] (5) When a user applies for bank-post remittance at the counter, if the account is successfully stopped, a manual compliance review is required. The remittance status = pending manual review (intermediate state), and the technical status information = outbound call successful. The teller then conducts a compliance review. If the review is not completed within the time limit, the account deduction is canceled. If the cancellation is successful, the remittance status = refunded (final state), and the technical status information = outbound call successful. If the cancellation fails, the remittance status = pending refund (intermediate state), and the technical status information = outbound call failed. If the cancellation times out, the remittance status = refunded (final state), and the technical status information = outbound call timeout / abnormal.

[0136] (6) When a user applies for bank-post remittance at the counter, if the account deduction is successful, no manual compliance review is required, and the remittance status = Not Outbound (Intermediate State), and the technical status information = Outbound call successful; if the account deduction fails, no manual compliance review is required, and the remittance status = Deduction Failed (Intermediate State), and the technical status information = Outbound call failed; if the account deduction times out / is abnormal, no manual compliance review is required, and the remittance status = Deduction Failed (Intermediate State), and the technical status information = Outbound call timeout / abnormal;

[0137] (7) Under the conditions that the remittance status = not shown (intermediate state) and the technical status information = outbound call success, a remittance message is sent to the international payment front-end. If the payment front-end synchronization response is successful, the transaction is completed, the remittance status = outbound (final state), and the technical status information = outbound call success; if the payment front-end synchronization response fails, the remittance status = remittance failure (intermediate state), and the technical status information = outbound call failure; if the payment front-end synchronization response times out, the remittance status = remittance timeout (intermediate state), and the technical status information = outbound call timeout / abnormal;

[0138] (8) If the user successfully handles a bank-post remittance refund at the counter, the remittance status will be Cancelled (Final Status) and the technical status information will be Outbound Call Successful. If the refund fails, the remittance status will be Pending Manual Review / Not Outbound, i.e., the status before the change will be restored. If the refund times out, the remittance status will remain unchanged and the technical status information will be Outbound Call Timeout / Abnormal, and the SAF registration will be redone.

[0139] (9) The teller successfully cancels the bank-post remittance at the counter, and the remittance status = Cancelled (final status), and the technical status information = Outbound call successful;

[0140] (10) The teller successfully cancels the bank-post remittance at the counter, and the remittance status = cancelled (final status), and the technical status information = outbound call successful;

[0141] (11) The system automatically sends a bank-post remittance report successfully, remittance status = outbound (final status), technical status information = outbound call successful;

[0142] (12) The system automatically sends the bank-post remittance report but fails. Remittance status = Remittance failure (intermediate state). Remittance status = Remittance failure (intermediate state).

[0143] (13) The system automatically sends the bank-post remittance report timeout, remittance status = remittance timeout (intermediate state), technical status information = outbound call timeout / abnormal, waiting for adjustment after reconciliation;

[0144] Inward remittance direction: automatic system entry, refund of foreign exchange, compliance review, payment of incoming remittance, manual entry, cancellation and deregistration initiated by the teller. Different statuses are used to represent the business processing results, and corresponding failure statuses are extracted according to different failure scenarios. The final status includes: accepted, review failed, pending manual review, pending declaration, refunded, pending entry, payment failed, paid, canceled, and deregistered. The flow of remittance status is as follows:

[0145] (1) The system automatically records the received remittance. If the system fails to review and determines that the remittance needs to be refunded, the remittance status = Remittance Refunded; if the system fails to review and the remittance needs to be changed, the remittance status = Accepted;

[0146] (2) The system automatically records the received remittance. If the system passes the review and the income and expenditure declaration is required, the remittance status = pending declaration; if the system passes the review and manual review is required, the remittance status = pending manual review;

[0147] (3) The system automatically records the incoming remittances. If the system passes the review and automatically records the incoming remittances, if the account deposit response is successful, the remittance status = paid, and the technical status information = outbound call successful; if the account deposit response fails, the remittance status = paid, and the technical status information = outbound call failed; if the account deposit response times out, the remittance status = paid, and the technical status information = outbound call timeout / abnormal;

[0148] (4) Compliance review failed, remittance status = refunded;

[0149] (5) If the compliance review is passed, the remittance status = pending, and then the deposit is made. If the deposit response is successful, the remittance status = paid (final state), and the technical status information = outbound call successful; if the deposit response fails, the remittance status = paid failure, and the technical status information = outbound call failed; if the deposit response times out, the remittance status = paid (final state), and the technical status information = outbound call timeout / abnormal, and the SAF is redone;

[0150] (6) The teller manually records the returned remittance. If the deposit response is successful, the remittance status = paid (final status) and the technical status information = outbound call successful; if the deposit response fails, the remittance status = paid (failed) and the technical status information = outbound call failed; if the deposit response times out, the remittance status = paid (final status) and the technical status information = outbound call timeout / abnormal, and the SAF is redone;

[0151] (7) Remittance cancellation / cancellation: if the deposit is successfully cancelled, the remittance status = payment failure (intermediate state), and the technical status information = outbound call success; if the deposit is failed to be cancelled, the remittance status remains unchanged, and the technical status information = outbound call failure; if the deposit is cancelled for a timeout, the remittance status remains unchanged, and the technical status information = outbound call timeout / abnormal;

[0152] (8) Judicial authorities freeze, the freezing is successful, and the remittance status = frozen;

[0153] (9) The judicial authority deducts the money. If the deduction is successful, the remittance status = deducted.

[0154] The above-mentioned device for determining status information of a remittance business based on a distributed architecture includes a processor and a memory. The above-mentioned acquisition unit and the first determination unit, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to implement corresponding functions.

[0155] The processor includes a kernel, which retrieves the corresponding program unit from the memory. One or more kernels can be set, and the problem of unclear and inaccurate status of the remittance process in the prior art can be solved by adjusting the kernel parameters.

[0156] The memory may include non-permanent memory in a computer-readable medium, 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.

[0157] An embodiment of the present invention provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the method for determining status information of a remittance service based on a distributed architecture.

[0158] An embodiment of the present invention provides a processor, which is used to run a program, wherein the program, when running, executes the method for determining status information of a remittance business based on a distributed architecture.

[0159] In a typical embodiment of the present application, an electronic device is also provided, comprising: one or more processors, a memory and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include a method for executing any one of the above methods.

[0160] An embodiment of the present invention provides a device, comprising a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, at least the following steps are performed:

[0161] Step S101, obtaining a main service corresponding to the master data of a target remittance business, where the main service is at least one of a plurality of services obtained by splitting the target remittance business according to a service-oriented architecture;

[0162] Step S102: Determine multiple business status information and multiple technical status information based on the above-mentioned main service, wherein the first scheduled transaction is at least a partial transaction related to the above-mentioned main service, the above-mentioned business status information is information representing the flow status of the above-mentioned first scheduled transaction, and the above-mentioned technical status information is information representing the interaction results between the above-mentioned services corresponding to the above-mentioned first scheduled transaction.

[0163] The devices in this article can be servers, PCs, PADs, mobile phones, etc.

[0164] The present application also provides a computer program product, which, when executed on a data processing device, is adapted to execute a program for initializing at least the following method steps:

[0165] Step S101, obtaining a main service corresponding to the master data of a target remittance business, where the main service is at least one of a plurality of services obtained by splitting the target remittance business according to a service-oriented architecture;

[0166] Step S102: Determine multiple business status information and multiple technical status information based on the above-mentioned main service, wherein the first scheduled transaction is at least a partial transaction related to the above-mentioned main service, the above-mentioned business status information is information representing the flow status of the above-mentioned first scheduled transaction, and the above-mentioned technical status information is information representing the interaction results between the above-mentioned services corresponding to the above-mentioned first scheduled transaction.

[0167] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0168] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the above-mentioned units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, units or modules.

[0169] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0170] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0171] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the above-mentioned methods of each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0172] From the above description, it can be seen that the above embodiments of the present application achieve the following technical effects:

[0173] 1) In the method for determining status information of a remittance business based on a distributed architecture of the present application, first, a main service corresponding to the master data of the target remittance business is obtained. Secondly, based on the obtained main service, multiple business status information and multiple technical status information are determined, wherein the above-mentioned main service is at least one of the multiple services obtained by splitting the above-mentioned target remittance business according to the service-oriented architecture, the first scheduled transaction is at least a portion of the transaction related to the above-mentioned main service, the above-mentioned business status information is information representing the flow status of the above-mentioned first scheduled transaction, and the above-mentioned technical status information is information representing the interaction results between the above-mentioned services corresponding to the above-mentioned first scheduled transaction. Compared with the prior art, in which the status is not separated during the remittance process, this solution obtains the main service corresponding to the master data of the target remittance business, and then determines multiple business status information that are easy for users to view and multiple technical status information that are easy for business operators to view based on the obtained main service, that is, it simultaneously meets the customer's visibility and the operation and management's visibility demands. This solution separates the status in the remittance business and obtains multiple business status information and multiple technical status information. This ensures that the obtained business status information and technical status information are relatively clear and accurate, thereby solving the problem of unclear and inaccurate status of the remittance process in the prior art, and meeting the needs of different groups of people for dynamic understanding of the above-mentioned remittance business.

[0174] 2) In the device for determining the status information of a remittance business based on a distributed architecture of the present application, an acquisition unit is used to obtain a main service corresponding to the master data of the target remittance business, where the main service is at least one of multiple services obtained by splitting the target remittance business according to the service-oriented architecture; the first determination unit is used to determine multiple business status information and multiple technical status information based on the main service, wherein the first scheduled transaction is at least a partial transaction related to the main service, the business status information is information characterizing the flow status of the first scheduled transaction, and the technical status information is information characterizing the interaction results between the above services corresponding to the first scheduled transaction. Compared with the prior art, in which the status is not separated during the remittance process, this solution obtains the main service corresponding to the master data of the target remittance business, and then determines multiple business status information that are easy for users to view and multiple technical status information that are easy for business operators to view based on the obtained main service, that is, it simultaneously meets the customer's visibility and the operation and management's visibility demands. This solution separates the status in the remittance business and obtains multiple business status information and multiple technical status information. This ensures that the obtained business status information and technical status information are relatively clear and accurate, thereby solving the problem of unclear and inaccurate status of the remittance process in the prior art, and meeting the needs of different groups of people for dynamic understanding of the above-mentioned remittance business.

[0175] The above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A method for determining status information of a remittance service based on a distributed architecture, characterized in that: include: Obtaining a primary service corresponding to master data of a target remittance business, where the primary service is at least one of a plurality of services obtained by splitting the target remittance business according to a service-oriented architecture; Determining all candidate status information based on the primary service, the candidate status information including information representing a flow of a second predetermined transaction and information representing interaction results between the services corresponding to the second predetermined transaction, the second predetermined transaction being all transactions related to the primary service; performing predetermined processing on the plurality of candidate status information to obtain initial status information including business status information and technical status information, the predetermined processing including at least one of modifying a description language of the candidate status information, deleting the candidate status information, and merging the candidate status information; Identifying the business status information from the initial status information, and controlling a first interface to display the business status information, the first interface being an interface that a user has viewing authority; Determine that the remaining initial status information is the technical status information, and control the second interface to display the technical status information, the second interface being an interface for which technical personnel have viewing authority, wherein the first scheduled transaction is at least a partial transaction related to the main service, the business status information is information characterizing the flow status of the first scheduled transaction, and the technical status information is information characterizing the interaction results between the services corresponding to the first scheduled transaction.

2. The method according to claim 1, characterized in that Obtain the master service corresponding to the master data of the target remittance business, including: Obtaining the workflow of the target remittance business; Determining the master data according to the workflow; The primary service corresponding to the primary data is determined.

3. The method according to claim 1, characterized in that After determining a plurality of business status information and a plurality of technical status information according to the primary service, the method further includes: Determine the corresponding flow status information of each of the services according to the business status information; checking each of the transaction status information to determine whether there is an anomaly, wherein the anomaly is that the predetermined transaction status information of the plurality of services is different, and the predetermined transaction status information is the transaction status information corresponding to the same first predetermined transaction; In the event that the abnormality exists, the predetermined flow state information of the abnormality is adjusted.

4. The method according to claim 3, characterized in that Adjusting the abnormal predetermined flow state information includes: Performing a first identification mark on the abnormal predetermined water flow status information; Adjusting the abnormal predetermined flow state information; The adjusted first identifier of the predetermined transaction status information is changed to a second identifier.

5. A device for determining status information of a remittance service based on a distributed architecture, characterized in that: include: an acquiring unit, configured to acquire a primary service corresponding to the master data of a target remittance business, wherein the primary service is at least one of a plurality of services obtained by splitting the target remittance business according to a service-oriented architecture; a first determining unit configured to determine, based on the primary service, all candidate status information, the candidate status information including information representing a flow of a second predetermined transaction and information representing interaction results between the services corresponding to the second predetermined transaction, the second predetermined transaction being all transactions related to the primary service; performing predetermined processing on the plurality of candidate status information to obtain initial status information including business status information and technical status information, the predetermined processing including at least one of modifying a description language of the candidate status information, deleting the candidate status information, and merging the candidate status information; Identifying the business status information from the initial status information, and controlling a first interface to display the business status information, the first interface being an interface that a user has viewing authority; Determine that the remaining initial status information is the technical status information, and control the second interface to display the technical status information, the second interface being an interface for which technical personnel have viewing authority, wherein the first scheduled transaction is at least a partial transaction related to the main service, the business status information is information characterizing the flow status of the first scheduled transaction, and the technical status information is information characterizing the interaction results between the services corresponding to the first scheduled transaction.

6. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored program, wherein the program executes the method according to any one of claims 1 to 4.

7. A processor, characterized in that: The processor is configured to run a program, wherein the program executes the method according to any one of claims 1 to 4 when running.

8. An electronic device, 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, and the one or more programs include instructions for executing the method according to any one of claims 1 to 4.

Images