CN114283011A - 基于分布式架构的汇款业务的状态信息的确定方法 - Google Patents

Abstract

本申请提供了一种基于分布式架构的汇款业务的状态信息的确定方法，该方法包括：获取目标汇款业务的主数据对应的主服务，主服务为根据面向服务架构对目标汇款业务进行拆分得到的多个服务中的至少一个；根据主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与主服务相关的至少部分交易，业务状态信息为表征第一预定交易的流转情况的信息，技术状态信息为表征第一预定交易对应的各服务之间的交互结果的信息，本方案保证了得到的业务状态信息和技术状态信息较为清晰和准确，从而解决了现有技术中汇款流程的状态不够清晰、准确的问题，满足了不同的人群对汇款业务的动态了解需求。

Description

基于分布式架构的汇款业务的状态信息的确定方法

技术领域

本申请涉及汇款业务领域，具体而言，涉及一种基于分布式架构的汇款业务的状态信息的确定方法、确定装置、计算机可读存储介质、处理器与电子设备。

背景技术

传统的集中式架构，一笔交易在单个系统内即可完成所有处理；而对于分布式架构，金融系统的服务能力是由数个、数十个服务协同在一起共同提供的，每个服务聚焦于自身的核心逻辑。

现有的基于分布式架构的国际汇款交易包括跨境汇款及跨行汇款的外币部分。交易分为三个环节，银行汇款组件负责校验交易信息、控制交易流程；个人存款组件负责账户资金的处理；国际支付前置负责与西联、SWIFT(Society for Worldwide InterbankFinancial Telecommunications，环球同业银行金融电讯协会)的通信、对账等。目前国际汇款状态采用位图方式设计，共分为17位。该状态不仅体现汇票状态，也体现了交易过程，例如出境申请注销，分别体现了申请操作、接收境外应答的操作。

将业务流程产品化为系统流程，是服务分析及设计的核心工作内容之一，而汇款状态，则是银行汇款服务设计的重要组成部分。一笔汇款从开始到结束会经历一系列的事件和状态，目前的汇款状态设计，既体现汇票状态，也体现了交易过程；既包含了用户关心的状态，也包含了运行关心的状态，状态不够清晰、准确。对于部分已经不存在的汇款状态，没有清理，存在冗余的现象。

在背景技术部分中公开的以上信息只是用来加强对本文所描述技术的背景技术的理解，因此，背景技术中可能包含某些信息，这些信息对于本领域技术人员来说并未形成在本国已知的现有技术。

发明内容

本申请的主要目的在于提供一种基于分布式架构的汇款业务的状态信息的确定方法、确定装置、计算机可读存储介质、处理器与电子设备，以解决现有技术中汇款流程的状态不够清晰、准确的问题。

根据本发明实施例的一个方面，提供了一种基于分布式架构的汇款业务的状态信息的确定方法，包括：获取目标汇款业务的主数据对应的主服务，所述主服务为根据面向服务架构对所述目标汇款业务进行拆分得到的多个服务中的至少一个；根据所述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与所述主服务相关的至少部分交易，所述业务状态信息为表征所述第一预定交易的流转情况的信息，所述技术状态信息为表征所述第一预定交易对应的各所述服务之间的交互结果的信息。

可选地，获取目标汇款业务的主数据对应的主服务，包括：获取所述目标汇款业务的工作流；根据所述工作流，确定所述主数据；确定所述主数据对应的所述主服务。

可选地，根据所述主服务，确定多个业务状态信息以及多个技术状态信息，包括：根据所述主服务，确定所有的候选状态信息，所述候选状态信息包括表征第二预定交易的流转情况的信息以及表征所述第二预定交易对应的各所述服务之间的交互结果的信息，所述第二预定交易为与所述主服务相关的所有的所述交易；对多个所述候选状态信息进行预定处理，得到包括各所述业务状态信息以及各所述技术状态信息的初始状态信息，所述预定处理包括修改所述候选状态信息的描述语言、删除以及合并中的至少之一；从所述初始状态信息中识别所述业务状态信息以及所述技术状态信息。

可选地，从所述初始状态信息中识别所述业务状态信息以及所述技术状态信息，包括：从所述初始状态信息中识别所述业务状态信息，并控制第一界面显示所述业务状态信息，所述第一界面为用户具有查看权限的界面；确定剩余的所述初始状态信息为所述技术状态信息，并控制第二界面显示所述技术状态信息，所述第二界面为技术人员具有查看权限的界面。

可选地，在根据所述主服务，确定多个业务状态信息以及多个技术状态信息之后，所述方法还包括：根据各所述业务状态信息，确定对应的各所述服务的流水状态信息；核对各所述流水状态信息，确定是否存在异常，所述异常为多个所述服务的预定流水状态信息不同，所述预定流水状态信息为同一个所述第一预定交易对应的所述流水状态信息；在存在所述异常的情况下，对所述异常的所述预定流水状态信息进行调整。

可选地，对所述异常的所述预定流水状态信息进行调整，包括：对所述异常的所述预定流水状态信息进行第一标识标记；对所述异常的所述预定流水状态信息进行调整；将调整后的所述预定流水状态信息的所述第一标识变更为第二标识。

根据本发明实施例的另一方面，还提供了一种基于分布式架构的汇款业务的状态信息的确定装置，包括：获取单元，用于获取目标汇款业务的主数据对应的主服务，所述主服务为根据面向服务架构对所述目标汇款业务进行拆分得到的多个服务中的至少一个；第一确定单元，用于根据所述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与所述主服务相关的至少部分交易，所述业务状态信息为表征所述第一预定交易的流转情况的信息，所述技术状态信息为表征所述第一预定交易对应的各所述服务之间的交互结果的信息。

根据本发明实施例的又一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质包括存储的程序，其中，所述程序执行任意一种所述的方法。

根据本发明实施例的再一方面，还提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行任意一种所述的方法。

根据本发明实施例的一方面，还提供了一种电子设备，包括：一个或多个处理器，存储器以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行任意一种所述的方法。

在本发明实施例中，所述的基于分布式架构的汇款业务的状态信息的确定方法中，首先，获取目标汇款业务的主数据对应的主服务，其次，根据获取到的主服务，确定多个业务状态信息和多个技术状态信息，其中，所述主服务为根据面向服务架构对所述目标汇款业务进行拆分得到的多个服务中的至少一个，第一预定交易为与所述主服务相关的至少部分交易，所述业务状态信息为表征所述第一预定交易的流转情况的信息，所述技术状态信息为表征所述第一预定交易对应的各所述服务之间的交互结果的信息。与现有技术中，在进行汇款业务的过程中并没有将状态进行分开相比，本方案中通过获取目标汇款业务的主数据对应的主服务，再根据获取到的主服务，确定多个便于用户查看的业务状态信息和多个便于业务运营人员查看的技术状态信息，即同时满足了客户可见的诉求以及运行管理可见的诉求，本方案实现了将汇款业务中的状态进行分开，得到多个业务状态信息和多个技术状态信息，这样保证了得到的业务状态信息和技术状态信息较为清晰和准确，从而解决了现有技术中汇款流程的状态不够清晰、准确的问题，满足了不同的人群对所述汇款业务的动态了解需求。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了根据本申请的一种实施例的基于分布式架构的汇款业务的状态信息的确定方法的示意图；

图2示出了根据本申请的一种实施例的识别工作流的流程图；

图3示出了根据本申请的一种实施例的基于分布式架构的汇款业务的状态信息的确定装置的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于描述，以下对本申请实施例涉及的部分名词或术语进行说明：

分布式架构：分布式架构是一套构建系统的准则。通过这套准则，可以把一个复杂的系统划分为一套简单子系统的集合，子系统之间应该保持相互独立，并与整个系统框架保持一致。而且每个子系统还可以继续细分，从而构成一个复杂的企业级架构；采用分布式无状态的SOA化架构构建金融服务系统，可以使服务的并行处理能力无限扩展；

跨行汇款：一种向开立在国内其他银行的单位或个人账户进行人民币或外币转账汇款的业务；

跨境汇款：用户在规定的限额之内，向大陆以外地区银行开户的收款人进行外汇汇款的业务；

支付通道：一种支持用户汇款或者支付的通道，这些通道帮助银行用户完成资金的流转，并且支持银行与通道之间进行资金流转、对账和清分，本方案中涉及的通道包括大额支付通道、小额支付通道、超级网银、银联支付通道、西联支付通道、SWIFT；

SAF机制：保存和前进(Save and Forward，简称SAF)机制，主要用于系统间超时情况的处理，保证系统间数据一致性的处理机制，采用逐级承诺的设计模式，发起系统未收到接收系统的应答或收到的应答码为超时，引发SAF机制，即：A系统发送SAF报文到B系统，B系统收到SAF报文并应答A系统后，意味着B系统向A系统承诺，一定将SAF转发给下游执行系统(交易转发类系统)，或者一定完成SAF要求的重发,恢复处理(后台处理类系统)。

正如背景技术中所说的，现有技术中的汇款流程的状态不够清晰、准确，为了解决上述问题，本申请的一种典型的实施方式中，提供了一种基于分布式架构的汇款业务的状态信息的确定方法、确定装置、计算机可读存储介质、处理器与电子设备。

根据本申请的实施例，提供了一种基于分布式架构的汇款业务的状态信息的确定方法。对于企业级分布式架构，需要各个应用组件间协同共同对用户提供服务。作为提供流程调度服务服务的应用组件，状态设计需要满足相应的特点和要求。本申请针对分布式架构及流程类业务的特点提出了有效的状态信息的确定方法。

图1是根据本申请实施例的基于分布式架构的汇款业务的状态信息的确定方法的流程图。如图1所示，该方法包括以下步骤：

步骤S101，获取目标汇款业务的主数据对应的主服务，上述主服务为根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务中的至少一个；

步骤S102，根据上述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与上述主服务相关的至少部分交易，上述业务状态信息为表征上述第一预定交易的流转情况的信息，上述技术状态信息为表征上述第一预定交易对应的各上述服务之间的交互结果的信息。

上述的基于分布式架构的汇款业务的状态信息的确定方法中，首先，获取目标汇款业务的主数据对应的主服务，其次，根据获取到的主服务，确定多个业务状态信息和多个技术状态信息，其中，上述主服务为根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务中的至少一个，第一预定交易为与上述主服务相关的至少部分交易，上述业务状态信息为表征上述第一预定交易的流转情况的信息，上述技术状态信息为表征上述第一预定交易对应的各上述服务之间的交互结果的信息。与现有技术中，在进行汇款业务的过程中并没有将状态进行分开相比，本方案中通过获取目标汇款业务的主数据对应的主服务，再根据获取到的主服务，确定多个便于用户查看的业务状态信息和多个便于业务运营人员查看的技术状态信息，即同时满足了客户可见的诉求以及运行管理可见的诉求，本方案实现了将汇款业务中的状态进行分开，得到多个业务状态信息和多个技术状态信息，这样保证了得到的业务状态信息和技术状态信息较为清晰和准确，从而解决了现有技术中汇款流程的状态不够清晰、准确的问题，满足了不同的人群对上述汇款业务的动态了解需求。

具体地，对于传统的集中式架构，一笔交易在单个系统内即可完成所有处理；而对于分布式架构，金融系统的服务能力由数个、数十个服务协同在一起共同提供，每个服务聚焦于自身的核心逻辑，对于汇款状态的设计也要充分考虑服务组件的特点。以跨行汇款及跨境汇款为例，服务组件属于银行IT架构的产品服务层，承接渠道服务层、渠道整合层的用户请求，完成汇款交易的审核、处理、调整等，同时需要调用存款组件来完成账户资金处理，因此，服务组件的核心数据、交易的主数据为汇款，强调的是汇款的流转过程能否通过状态清晰的展示出来，并且通过汇款状态实现流程的控制，汇款状态是汇款实体最重要的属性。以跨行汇款及跨境汇款业务为例，对于一笔业务来说，从发起到结束，完成“端到端”的工作流程梳理，目的是确定交易流程中各个服务所提供的能力，对于辅助性、支撑性的服务，可以不在工作流图体现，最终得到的工作流流程图如图2所示。

具体地，以跨行汇款及跨境汇款业务为例，在获取目标汇款业务的主数据对应的主服务的过程中，可以根据服务所属分层来进行协助判断，例如，[柜面]是渠道服务层，为用户提供银行服务或内部用户操作界面，不负责业务结果状态记录，数据操作主要是业务或技术流水数据；[存款]是产品服务层，管理行内所有个人账户，数据操作主要是账户属性的变更；[人行前置]也是渠道服务层，只是对接行外系统，数据操作主要是与行外系统通信、对账等；[汇款]也是产品服务层，管理所有跨行跨境汇款，数据操作主要是汇款属性的变更。由上述的分析可知，对于该工作流的主数据是汇款，分布在[汇款]服务。另外，需要说明的是[]表示根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请的一种实施例中，获取目标汇款业务的主数据对应的主服务，包括：获取上述目标汇款业务的工作流；根据上述工作流，确定上述主数据；确定上述主数据对应的上述主服务。在该实施例中，根据获取到目标汇款业务的工作流确定主数据，再确定主数据对应的主服务，方便了后续根据得到的主服务确定多个业务状态信息以及多个技术状态信息，从而进一步地保证了得到的多个业务状态信息和多个技术状态信息较为清晰。

本申请的另一种实施例中，根据上述主服务，确定多个业务状态信息以及多个技术状态信息，包括：根据上述主服务，确定所有的候选状态信息，上述候选状态信息包括表征第二预定交易的流转情况的信息以及表征上述第二预定交易对应的各上述服务之间的交互结果的信息，上述第二预定交易为与上述主服务相关的所有的上述交易；对多个上述候选状态信息进行预定处理，得到包括各上述业务状态信息以及各上述技术状态信息的初始状态信息，上述预定处理包括修改上述候选状态信息的描述语言、删除以及合并中的至少之一；从上述初始状态信息中识别上述业务状态信息以及上述技术状态信息。流程类状态如按照交易流程简单粗暴的进行一对一映射成位图方式，一方面冗杂不清楚，一方面实现逻辑较复杂，在该实施例中，根据主服务，确定所有的候选状态信息，即将所有的候选状态信息列举出来，这样保证了能够得到较为完善的候选状态信息，再对得到的多个候选状态信息进行预定处理得到初始状态信息，再从上述初始状态信息中识别上述业务状态信息以及上述技术状态信息，这样保证了得到的业务状态信息和技术状态信息较为合理，通过简单易操作的方法，实现了对业务流程抽象建模后提炼出业务状态信息以及技术状态信息，并且，通过将业务状态信息以及技术状态信息进行划分，保证了两个状态功能单一、互不影响，可以分别满足业务、运行的需求。

具体地，以上述目标汇款业务为跨行汇款及跨境汇款业务为例，根据上述主服务，确定所有的候选状态信息的具体过程为：根据汇款的工作流确定涉及汇款的操作及事件，去掉查询类操作；并逐一对操作结果进行分析，列出所有的候选状态信息，如表一所示。

表一

另外，对多个候选状态信息进行预定处理需要遵从以下三个优化原则，必要性原则：状态并非越多越好，第一，要有实际含义，第二，业务操作可能停留的才有必要保留，例如表一中的待扣款状态，实际上在交易中登记合约后就会扣款，待扣款状态只会停留不足1秒，该状态对于业务基本不可见，该状态无保留的必要性；结果向原则：状态需表示当前操作的结果，而不是过程，例如已申请退汇、已申请撤销，其实申请只是个动作，申请成功才会引发状态的变化，申请失败状态不变；单一对象原则：在实际运行过程中，状态的使用对象除了用户、行内用户之外，运维人员也需要通过状态来判断汇款的流转情况，这两类对象的诉求不同，关注点也不同，例如，已超时其实是运维人员关注的状态；对于用户来讲，该场景应视为成功。当然，在实际的服务过程中，对业务状态信息以及技术状态信息的描述不仅要采用业务语言，还要统一动宾短语结构，如下表二所示，为对多个候选状态信息进行预定处理之后，从初始状态信息中识别的业务状态信息以及技术状态信息。

表二

为了能够动态地查看业务状态信息和技术状态信息，本申请的又一种实施例中，从上述初始状态信息中识别上述业务状态信息以及上述技术状态信息，包括：从上述初始状态信息中识别上述业务状态信息，并控制第一界面显示上述业务状态信息，上述第一界面为用户具有查看权限的界面；确定剩余的上述初始状态信息为上述技术状态信息，并控制第二界面显示上述技术状态信息，上述第二界面为技术人员具有查看权限的界面。在该实施例中，将得到业务状态信息显示在第一界面上，这样保证了用户可以较为便利地查看汇款业务的流转动态，了解实时的汇款状态，将得到的技术状态信息显示在第二界面上，这样保证了技术人员可以较为及时和清楚地看到汇款业务对应的多个服务之间的交互是否正常，保证了技术人员在发现问题时可以及时地进行解决。

上述实施例中，在理解应用组件核心逻辑和服务能力的基础上，确定状态特性和设计原则，得到各上述候选状态信息，充分适应分布式架构特点。通过在对业务事件、流程进行抽象和归纳的基础上定义状态，并根据三项优化指导原则：必要性原则、结果向原则以及单一对象原则对多个候选状态信息进行预定处理，来得到多个业务状态信息以及技术状态信息。

为了确保业务状态与流水状态的对应，从而方便核对各个服务的相关流水状态信息是否一致的，本申请的再一种实施例中，在根据上述主服务，确定多个业务状态信息以及多个技术状态信息之后，上述方法还包括：根据各上述业务状态信息，确定对应的各上述服务的流水状态信息；核对各上述流水状态信息，确定是否存在异常，上述异常为多个上述服务的预定流水状态信息不同，上述预定流水状态信息为同一个上述第一预定交易对应的上述流水状态信息；在存在上述异常的情况下，对上述异常的上述预定流水状态信息进行调整，这样进一步地保证了满足事务一致性管理的诉求。

在实际的服务过程中，在分布式架构中，流水对账方式比业务对账方式是更为适宜的，对于同一笔流水，需要通过对账的方式核对并确保各个服务的流水状态是一致的，业务状态信息体现了这笔汇款的流转情况，但流水状态信息体现了单次交易的处理结果，例如，用户做发汇取消成功，就本次交易来讲是成功的，就这笔汇款来讲是失败的，状态为已取消。在通过各上述业务状态信息，确定对应的各服务的流水状态信息的过程中，需要注意的是，在多系统间状态不明确的情况下，如何设置流水状态信息取决于业务层面的考量，例如，发汇超时的情况下是当成功，还是当失败，需要从资金安全性、业务目标等方面考量。

本申请的一种实施例中，对上述异常的上述预定流水状态信息进行调整，包括：对上述异常的上述预定流水状态信息进行第一标识标记；对上述异常的上述预定流水状态信息进行调整；将调整后的上述预定流水状态信息的上述第一标识变更为第二标识。在该实施例中，在预定流水状态信息异常的情况下，对异常的预定流水状态信息标记第一标识，在对异常的预定流水状态信息调整后，将调整后的预定流水状态信息的第一标识变更为第二标识，这样保证了能够较为方便地查看预定流水状态信息，同时还能够体现出整个纠错的过程和结果。

具体地，上述第一标识可以为“待调整”，上述第二标识可以为“已调整”，这样技术人员可以一目了然地确定待调整以及已调整的流水状态信息。当然，上述第一标识以及上述第二标识并不限于上述的“待调整”以及“已调整”，其还可以为其他的标识字符。

本申请的一种具体的实施例中，状态设置不宜通过硬编码方式实现，可以采用动态配置、内存读取的方式来实现，即可以实现在线维护、准实时生效，从而可有效提升状态管理的便捷性、时效性，具体的配置方式如表三所示。

表三

交易	触发事件	技术状态信息	业务状态信息
				发汇-止付(需审核)	创建汇款实体，调用存款前	外呼中
发汇-止付(需审核)	调用存款止付成功	外呼成功	待人工审核
				发汇-止付(需审核)	调用存款止付失败	外呼失败	止付失败
发汇-止付(需审核)	调用存款止付超时	外呼超时/异常	止付失败
				发汇-合规性审核	柜员审核通过		未出境
发汇-合规性审核	柜员审核不通过		待退款

本申请的另一种具体的实施例中，可以通过SAF机制来保证系统间数据一致性的处理机制，由于采用了逐级承诺的设计模式，应答超时上游系统可以默认成功/失败(根据资金方向)，所以超时情况下交易等同于成功、失败，无需为超时设置状态表示。而在具体的交叉检查的过程中，可以具体分为三部分：一是工作流与状态的交叉检查，关注状态的设计能否满足流程控制；二是状态与数据的交叉检查，关注状态在数据库表的分布是否合理；三是状态与技术平台的交叉检查，关注能否满足事务控制、异常机制的要求。当然，对于对多系统的事务协同失败，还需支持服务层的自动化和人工纠错手段，即上述的汇款业务的状态确定过程需以满足自动化需求为目的进行。本实施例分别在实时交易环节、事后参照SAF机制以及对账机制明确提出状态设计与系统间事务协同、事务一致性管理的相关性，进一步地使得状态设计能够满足事务一致性管理的要求。

在传统集中式系统设计中，业务处理过程往往在一个系统内完成，状态更多的是对于结果的体现而不是过程的体现；状态设计按照业务事件、系统事件映射，缺少了抽象和建模的过程，未能准确体现出流程类业务的生命周期；未能对状态需求来源进行分类，状态功能定义不准确。本申请的上述方法，在理解应用组件核心逻辑和服务能力的基础上，确定状态特性和设计原则，充分适应分布式架构特点；提出在对业务事件、流程进行抽象和归纳的基础上定义状态，并提炼处必要性原则、结果向原则以及单一对象原则这三项优化指导原则；扩展状态设计考量范畴，纳入对异常处理机制的分析，能够满足事务一致性管理的诉求。

本申请实施例还提供了一种基于分布式架构的汇款业务的状态信息的确定装置，需要说明的是，本申请实施例的基于分布式架构的汇款业务的状态信息的确定装置可以用于执行本申请实施例所提供的用于基于分布式架构的汇款业务的状态信息的确定方法。以下对本申请实施例提供的基于分布式架构的汇款业务的状态信息的确定装置进行介绍。

图3是根据本申请实施例的基于分布式架构的汇款业务的状态信息的确定装置的示意图。如图3所示，该装置包括：

获取单元10，用于获取目标汇款业务的主数据对应的主服务，上述主服务为根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务中的至少一个；

第一确定单元20，用于根据上述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与上述主服务相关的至少部分交易，上述业务状态信息为表征上述第一预定交易的流转情况的信息，上述技术状态信息为表征上述第一预定交易对应的各上述服务之间的交互结果的信息。

上述的基于分布式架构的汇款业务的状态信息的确定装置中，获取单元用于获取目标汇款业务的主数据对应的主服务，上述主服务为根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务中的至少一个；第一确定单元用于根据上述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与上述主服务相关的至少部分交易，上述业务状态信息为表征上述第一预定交易的流转情况的信息，上述技术状态信息为表征上述第一预定交易对应的各上述服务之间的交互结果的信息。与现有技术中，在进行汇款业务的过程中并没有将状态进行分开相比，本方案中通过获取目标汇款业务的主数据对应的主服务，再根据获取到的主服务，确定多个便于用户查看的业务状态信息和多个便于业务运营人员查看的技术状态信息，即同时满足了客户可见的诉求以及运行管理可见的诉求，本方案实现了将汇款业务中的状态进行分开，得到多个业务状态信息和多个技术状态信息，这样保证了得到的业务状态信息和技术状态信息较为清晰和准确，从而解决了现有技术中汇款流程的状态不够清晰、准确的问题，满足了不同的人群对上述汇款业务的动态了解需求。

具体地，对于传统的集中式架构，一笔交易在单个系统内即可完成所有处理；而对于分布式架构，金融系统的服务能力由数个、数十个服务协同在一起共同提供，每个服务聚焦于自身的核心逻辑，对于汇款状态的设计也要充分考虑服务组件的特点。以跨行汇款及跨境汇款为例，服务组件属于银行IT架构的产品服务层，承接渠道服务层、渠道整合层的用户请求，完成汇款交易的审核、处理、调整等，同时需要调用存款组件来完成账户资金处理，因此，服务组件的核心数据、交易的主数据为汇款，强调的是汇款的流转过程能否通过状态清晰的展示出来，并且通过汇款状态实现流程的控制，汇款状态是汇款实体最重要的属性。以跨行汇款及跨境汇款业务为例，对于一笔业务来说，从发起到结束，完成“端到端”的工作流程梳理，目的是确定交易流程中各个服务所提供的能力，对于辅助性、支撑性的服务，可以不在工作流图体现，最终得到的工作流流程图如图2所示。

具体地，以跨行汇款及跨境汇款业务为例，在获取目标汇款业务的主数据对应的主服务的过程中，可以根据服务所属分层来进行协助判断，例如，[柜面]是渠道服务层，为用户提供银行服务或内部用户操作界面，不负责业务结果状态记录，数据操作主要是业务或技术流水数据；[存款]是产品服务层，管理行内所有个人账户，数据操作主要是账户属性的变更；[人行前置]也是渠道服务层，只是对接行外系统，数据操作主要是与行外系统通信、对账等；[汇款]也是产品服务层，管理所有跨行跨境汇款，数据操作主要是汇款属性的变更。由上述的分析可知，对于该工作流的主数据是汇款，分布在[汇款]服务。另外，需要说明的是[]表示根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务。

本申请的一种实施例中，上述获取单元包括获取模块、第一确定模块和第二确定模块，其中，上述获取单元用于获取上述目标汇款业务的工作流；上述第一确定模块用于根据上述工作流，确定上述主数据；上述第二确定模块用于确定上述主数据对应的上述主服务。在该实施例中，根据获取到目标汇款业务的工作流确定主数据，再确定主数据对应的主服务，方便了后续根据得到的主服务确定多个业务状态信息以及多个技术状态信息，从而进一步地保证了得到的多个业务状态信息和多个技术状态信息较为清晰。

本申请的另一种实施例中，上述第一确定单元包括第三确定模块、预定处理模块和识别模块，其中，上述第三确定模块用于根据上述主服务，确定所有的候选状态信息，上述候选状态信息包括表征第二预定交易的流转情况的信息以及表征上述第二预定交易对应的各上述服务之间的交互结果的信息，上述第二预定交易为与上述主服务相关的所有的上述交易；上述预定处理模块用于对多个上述候选状态信息进行预定处理，得到包括各上述业务状态信息以及各上述技术状态信息的初始状态信息，上述预定处理包括修改上述候选状态信息的描述语言、删除以及合并中的至少之一；上述识别模块用于从上述初始状态信息中识别上述业务状态信息以及上述技术状态信息。流程类状态如按照交易流程简单粗暴的进行一对一映射成位图方式，一方面冗杂不清楚，一方面实现逻辑较复杂，在该实施例中，根据主服务，确定所有的候选状态信息，即将所有的候选状态信息列举出来，这样保证了能够得到较为完善的候选状态信息，再对得到的多个候选状态信息进行预定处理得到初始状态信息，再从上述初始状态信息中识别上述业务状态信息以及上述技术状态信息，这样保证了得到的业务状态信息和技术状态信息较为合理，通过简单易操作的方法，实现了对业务流程抽象建模后提炼出业务状态信息以及技术状态信息，并且，通过将业务状态信息以及技术状态信息进行划分，保证了两个状态功能单一、互不影响，可以分别满足业务、运行的需求。

具体地，以上述目标汇款业务为跨行汇款及跨境汇款业务为例，根据上述主服务，确定所有的候选状态信息的具体过程为：根据汇款的工作流确定涉及汇款的操作及事件，去掉查询类操作；并逐一对操作结果进行分析，列出所有的候选状态信息，如表一所示。

另外，对多个候选状态信息进行预定处理需要遵从以下三个优化原则，必要性原则：状态并非越多越好，第一，要有实际含义，第二，业务操作可能停留的才有必要保留，例如表一中的待扣款状态，实际上在交易中登记合约后就会扣款，待扣款状态只会停留不足1秒，该状态对于业务基本不可见，该状态无保留的必要性；结果向原则：状态需表示当前操作的结果，而不是过程，例如已申请退汇、已申请撤销，其实申请只是个动作，申请成功才会引发状态的变化，申请失败状态不变；单一对象原则：在实际运行过程中，状态的使用对象除了用户、行内用户之外，运维人员也需要通过状态来判断汇款的流转情况，这两类对象的诉求不同，关注点也不同，例如，已超时其实是运维人员关注的状态；对于用户来讲，该场景应视为成功。当然，在实际的服务过程中，对业务状态信息以及技术状态信息的描述不仅要采用业务语言，还要统一动宾短语结构，如下表二所示，为对多个候选状态信息进行预定处理之后，从初始状态信息中识别的业务状态信息以及技术状态信息。

为了能够动态地查看业务状态信息和技术状态信息，本申请的又一种实施例中，上述识别模块包括第一控制子模块和第二控制子模块，其中，上述第一控制子模块用于从上述初始状态信息中识别上述业务状态信息，并控制第一界面显示上述业务状态信息，上述第一界面为用户具有查看权限的界面；上述第二控制子模块用于确定剩余的上述初始状态信息为上述技术状态信息，并控制第二界面显示上述技术状态信息，上述第二界面为技术人员具有查看权限的界面。在该实施例中，将得到业务状态信息显示在第一界面上，这样保证了用户可以较为便利地查看汇款业务的流转动态，了解实时的汇款状态，将得到的技术状态信息显示在第二界面上，这样保证了技术人员可以较为及时和清楚地看到汇款业务对应的多个服务之间的交互是否正常，保证了技术人员在发现问题时可以及时地进行解决。

上述实施例中，在理解应用组件核心逻辑和服务能力的基础上，确定状态特性和设计原则，得到各上述候选状态信息，充分适应分布式架构特点。通过在对业务事件、流程进行抽象和归纳的基础上定义状态，并根据三项优化指导原则：必要性原则、结果向原则以及单一对象原则对多个候选状态信息进行预定处理，来得到多个业务状态信息以及技术状态信息。

为了确保业务状态与流水状态的对应，从而方便核对各个服务的相关流水状态信息是否一致的，本申请的再一种实施例中，上述确定装置还包括第二确定单元、第三确定单元和调整单元，其中，上述第二确定单元用于在根据上述主服务，确定多个业务状态信息以及多个技术状态信息之后，根据各上述业务状态信息，确定对应的各上述服务的流水状态信息；上述第三确定单元用于核对各上述流水状态信息，确定是否存在异常，上述异常为多个上述服务的预定流水状态信息不同，上述预定流水状态信息为同一个上述第一预定交易对应的上述流水状态信息；上述调整单元用于在存在上述异常的情况下，对上述异常的上述预定流水状态信息进行调整，这样进一步地保证了满足事务一致性管理的诉求。

在实际的服务过程中，在分布式架构中，流水对账方式比业务对账方式是更为适宜的，对于同一笔流水，需要通过对账的方式核对并确保各个服务的流水状态是一致的，业务状态信息体现了这笔汇款的流转情况，但流水状态信息体现了单次交易的处理结果，例如，用户做发汇取消成功，就本次交易来讲是成功的，就这笔汇款来讲是失败的，状态为已取消。在通过各上述业务状态信息，确定对应的各服务的流水状态信息的过程中，需要注意的是，在多系统间状态不明确的情况下，如何设置流水状态信息取决于业务层面的考量，例如，发汇超时的情况下是当成功，还是当失败，需要从资金安全性、业务目标等方面考量。

本申请的一种实施例中，上述调整单元包括标记模块、调整模块和变更模块，其中，上述标记模块用于对上述异常的上述预定流水状态信息进行第一标识标记；上述调整模块用于对上述异常的上述预定流水状态信息进行调整；上述变更模块用于将调整后的上述预定流水状态信息的上述第一标识变更为第二标识。在该实施例中，在预定流水状态信息异常的情况下，对异常的预定流水状态信息标记第一标识，在对异常的预定流水状态信息调整后，将调整后的预定流水状态信息的第一标识变更为第二标识，这样保证了能够较为方便地查看预定流水状态信息，同时还能够体现出整个纠错的过程和结果。

具体地，上述第一标识可以为“待调整”，上述第二标识可以为“已调整”，这样技术人员可以一目了然地确定待调整以及已调整的流水状态信息。当然，上述第一标识以及上述第二标识并不限于上述的“待调整”以及“已调整”，其还可以为其他的标识字符。

本申请的一种具体的实施例中，状态设置不宜通过硬编码方式实现，可以采用动态配置、内存读取的方式来实现，即可以实现在线维护、准实时生效，从而可有效提升状态管理的便捷性、时效性，具体的配置方式如表三所示。

本申请的另一种具体的实施例中，可以通过SAF机制来保证系统间数据一致性的处理机制，由于采用了逐级承诺的设计模式，应答超时上游系统可以默认成功/失败(根据资金方向)，所以超时情况下交易等同于成功、失败，无需为超时设置状态表示。而在具体的交叉检查的过程中，可以具体分为三部分：一是工作流与状态的交叉检查，关注状态的设计能否满足流程控制；二是状态与数据的交叉检查，关注状态在数据库表的分布是否合理；三是状态与技术平台的交叉检查，关注能否满足事务控制、异常机制的要求。当然，对于对多系统的事务协同失败，还需支持服务层的自动化和人工纠错手段，即上述的汇款业务的状态确定过程需以满足自动化需求为目的进行。本实施例分别在实时交易环节、事后参照SAF机制以及对账机制明确提出状态设计与系统间事务协同、事务一致性管理的相关性，进一步地使得状态设计能够满足事务一致性管理的要求。

在传统集中式系统设计中，业务处理过程往往在一个系统内完成，状态更多的是对于结果的体现而不是过程的体现；状态设计按照业务事件、系统事件映射，缺少了抽象和建模的过程，未能准确体现出流程类业务的生命周期；未能对状态需求来源进行分类，状态功能定义不准确。本申请的上述装置，在理解应用组件核心逻辑和服务能力的基础上，确定状态特性和设计原则，充分适应分布式架构特点；提出在对业务事件、流程进行抽象和归纳的基础上定义状态，并提炼处必要性原则、结果向原则以及单一对象原则这三项优化指导原则；扩展状态设计考量范畴，纳入对异常处理机制的分析，能够满足事务一致性管理的诉求。

为了使得本领域的技术人员更加清楚明确地了解本申请的技术方案，下面将结合具体的实施例进行说明：

实施例1

大额支付通道和小额支付通道的汇款状态流转过程：

汇出方向：用户申请汇出汇款、汇出失败后柜员申请核销挂账处理；用不同的状态来表示业务办理结果；并且根据不同失败场景提炼出相应的失败状态；最终确定的汇款状态包括：扣款失败、已冲正、已清算/已轧差、已排队、已退回、再次汇出，具体的汇款状态的流转如下：

(1)用户通过柜面办理人民币跨行汇款时，账户扣款失败交易结束，汇款状态＝扣款失败(终态)；技术状态信息＝外呼失败或外呼超时/异常，分别对应关联系统失败应答、无应答两种情况；

(2)如果账户扣款成功，生成汇款报文发送行内支付前置系统，技术状态信息＝外呼中；收到支付前置同步响应成功或超时，业务状态信息＝已发送，技术状态信息＝外呼成功/外呼超时；收到支付前置同步相应失败，业务状态信息＝已挂账，技术状态信息＝外呼失败；收到支付前置同步相应失败，登记SAF恢复成功，业务状态信息＝已冲正，技术状态信息＝外呼失败；

(3)收到响应报文，清算或轧差成功通知，业务状态信息＝已清算/已轧差；收到清算或轧差排队通知，业务状态信息＝已排队；收到拒绝或轧差失败通知，业务状态信息＝已拒绝，需要冲正账户资金；

(4)如果冲正账户资金成功或超时，则业务状态信息＝已冲正，技术状态信息＝外呼成功/外呼超时；如果冲正账户资金失败，则业务状态信息＝已挂账，技术状态信息＝外呼失败；

(5)针对已挂账的用户账，由柜面柜员申请核销挂账，挂账后核销处理选择退回原账户方式的，业务状态信息＝已退回；挂账后核销处理选择再次汇出的，业务状态信息＝再次汇出；

汇入方向：用户在第二银行发起汇入第一银行的汇入汇款；用户在第一银行发起汇出汇款在第二银行挂账后，第二银行发起的退汇；汇入第一银行后由于用户账号状态异常等原因产生挂账，第一银行柜面柜员申请核销挂账处理；采用不同的状态表示业务办理结果，根据不同的失败场景提炼失败状态，最终确定的汇款状态包括如下：已入账、已挂账、已退回、已手工入账、已退汇。状态的流转如下：

(1)用户在第二银行发起汇入第一银行汇入汇款，如符合入账条件，则存入账户资金，若存入成功或超时，业务状态信息＝已入账，技术状态信息＝外呼成功/外呼超时；若存入失败，业务状态信息＝待挂账，技术状态信息＝外呼失败；

(2)如汇入汇款不符合入账条件，则业务状态信息＝待挂账；

(3)针对业务状态信息为“待挂账”的交易，执行挂账，业务状态信息＝已挂账；

(4)若汇入汇款是普通汇入汇款，柜员可选择退汇的方式核销挂账，触发退汇事件后，外呼人行支付前置发送退汇报文，若收到人行前置同步应答外呼成功或外呼超时，则业务状态信息＝已退汇，技术状态信息＝外呼成功/外呼超时；若收到人行前置同步应答外呼失败，则业务状态信息＝已挂账，技术状态信息＝外呼失败；若汇入汇款是第二银行退汇，则柜员不能选择退汇的方式核销；

(5)若汇入账户是非自贸区账户，柜员在柜面申请核销挂账时，可选择联系用户退回现金，若用户来网点柜面退回现金成功，则业务状态信息＝已退回。若未联系到用户，则业务状态信息＝已挂账；

(6)汇入账户是自贸区账户，根据监管要求不能退回现金，可选择通过手工入账的方式核销。触发存入账户资金事件，若存入成功或超时，业务状态信息＝已手工入账，技术状态信息＝外呼成功/外呼超时；若存入失败，业务状态信息＝已挂账，技术状态信息＝外呼失败。

实施例2

网上支付跨行清算的汇款状态流转过程：

汇出方向：以用户通过柜面办理实时跨行汇出汇款为例，用不同的状态来表示业务办理结果，包括根据成功场景提炼出的状态“已轧差”，根据不同失败场景提炼出相应的失败状态“扣款失败”、“已冲正”、“冲正失败”，汇款状态的流转如下：

(1)用户通过柜面办理跨行汇出汇款，若账户扣款失败则交易结束，汇款状态＝扣款失败(终态)；技术状态信息＝外呼失败，若账户扣款超时则交易结束，汇款状态＝已冲正(终态)，技术状态信息＝外呼超时/异常；

(2)外呼超网前置，若外呼失败，汇款状态＝已冲正(已冲正)，技术状态信息＝外呼失败；若外呼成功汇款状态＝待轧差(非终态)，技术状态信息＝外呼成功；若外呼超时汇款状态＝已超时(非终态)，技术状态信息＝外呼超时/异常(超时当成功处理)；

(3)进行贷记往账轧差：若收到人行轧差通知，汇款状态＝已轧差(终态)；若收到人行拒绝通知，外呼存款进行冲正；

(4)若账户扣款成功后，交易因某种原因失败，则外呼存款进行冲正。若外呼存款成功或超时，令汇款状态＝已冲正(终态)，技术状态信息＝外呼成功或外呼超时/异常；若外呼存款失败汇款状态＝冲正失败(终态)，技术状态信息＝外呼失败。

汇入方向：以用户电子渠道发起手工资金归集(短信认证方式)活动为例，用不同的状态来表示业务办理结果；包括根据成功场景提炼出的“已入账”；根据不同失败场景提炼出相应的失败状态“认证失败”、“验证失败”、“轧差失败”，汇款状态的流转如下：

(1)用户通过电子渠道办理手工资金归集(短信认证方式)时，当短信认证失败交易结束时，汇款状态＝认证失败(终态)，技术状态信息＝外呼失败或外呼超时/异常，分别对应关联系统失败应答、无应答两种情况；若认证成功，汇款状态＝待认证(非终态)，技术状态信息＝外呼成功；

(2)短信认证成功后，用户根据收到第二银行短信验证码进行短信验证，若短信验证失败，汇款状态＝验证失败(终态)，技术状态信息＝外呼失败；若验证成功，汇款状态＝待轧差(非终态)，技术状态信息＝外呼成功；若外呼前置超时，则视为验证成功，令汇款状态＝已超时(非终态)，技术状态信息＝外呼超时/异常(超时当成功处理)

(3)短信验证成功后进行借记往账轧差：收到人行轧差通知，汇款状态＝已入账(终态)；收到人行拒绝通知，汇款状态＝轧差失败(终态)。

实施例3

银联的汇款状态流转过程：

汇出方向：实时转出、借记转出，最终确定的状态包括已扣款、扣款失败；

汇入方向：实时转入、借记转入，最终确定的状态包括已入账、入账失败、发送失败。汇款状态的流转如下：

(1)用户使用第一银行的银行卡卡通过第一银行的ATM(自动取款机，AutomaticTeller Machine，简称ATM)办理银联汇出，调用关联系统动账时，账户支取成功，技术状态信息＝外呼成功，汇款状态＝已扣款(终态)；账户支取失败，技术状态信息＝外呼失败，汇款状态＝扣款失败(终态)；账户支取超时，技术状态信息＝外呼超时/异常，汇款状态＝扣款失败(终态)；

(2)用户使用第一银行的银行卡通过第一银的行ATM办理银联汇入，调用关联系统动账时，账户存入成功，技术状态信息＝外呼成功，汇款状态＝已入账(终态)；账户存入失败，技术状态信息＝外呼失败，汇款状态＝入账失败(终态)；账户存入超时，技术状态信息＝外呼超时/异常，交易进行SAF重发，汇款状态＝已入账(终态)；

(3)用户使用第一银行的手机银行将第二银行的账户金额汇入第一银行的账户，首先将该交易信息转发前置系统，前置系统响应成功后，接着调用关联系统存入，账户存入成功，技术状态信息＝外呼成功，汇款状态＝已入账(终态)，若调用关联系统存入失败，技术状态信息＝外呼失败，汇款状态＝入账失败，若调用关联系统存入超时，技术状态信息＝外呼超时/异常，进行SAF重发，汇款状态＝已入账。

实施例4

西联支付通道的汇款状态流转过程：

汇出方向；用户申请发汇、柜员申请发汇取消；用不同的汇款状态来表示业务办理结果；并且根据不同失败场景提炼出相应的失败状态；最终确定的汇款状态包括：扣款失败、已冲正、已出境、已取消，汇款状态的流转如下：

(1)用户通过柜面办理西联账户发汇时，账户扣款失败，交易结束，汇款状态＝扣款失败(终态)；技术状态信息＝外呼失败或外呼超时/异常，分别对应关联系统失败应答、无应答两种情况；

(2)用户通过柜面办理西联账户发汇时，账户扣款成功，国际支付前置同步响应失败，交易结束，汇款状态＝已冲正(终态)，技术状态信息＝外呼失败，登记SAF恢复成功；

(3)用户通过柜面办理西联账户发汇时，账户扣款成功，国际支付前置同步响应成功，交易结束，汇款状态＝已出境(终态)，技术状态信息＝外呼成功或外呼超时/异常；

(4)在原汇款状态是已出境时柜员可以通过柜面做差错交易-发汇取消，账户存款成功交易结束，汇款状态＝已取消(终态)，技术状态信息＝外呼成功；若账户存款超时或异常，汇款状态＝已取消(终态)，技术状态信息＝外呼超时/异常；若账户存款失败，汇款状态＝已取消(终态)，技术状态信息＝外呼失败；

汇入方向：用户申请收汇、柜员申请收汇取消，用不同的状态来表示业务办理结果，并且根据不同失败场景提炼出相应的失败状态，最终确定的状态包括：已兑付、收汇失败、兑付失败、已取消，汇款状态的流转如下：

(1)用户通过柜面办理收汇兑付时，国际支付前置同步响应成功，若账户存款成功，交易结束，汇款状态＝已兑付(终态)，技术状态信息＝外呼成功；若账户存款超时，交易结束，汇款状态＝已兑付(终态)，技术状态信息＝外呼超时/异常；若账户存款失败，交易结束，汇款状态＝兑付失败(终态)，技术状态信息＝外呼失败；

(2)用户通过柜面办理收汇兑付时，国际支付前置同步响应失败，交易结束，汇款状态＝收汇失败(终态)，技术状态信息＝外呼失败；

(3)用户通过柜面办理收汇兑付时，国际支付前置同步响应超时，交易结束，汇款状态＝收汇失败(终态)，技术状态信息＝外呼超时/异常；

(4)用户通过柜面办理收汇补录时，若账户存款成功，交易结束，汇款状态＝已兑付(终态)，技术状态信息＝外呼成功；若账户存款失败，交易结束，汇款状态＝兑付失败(中间态)，技术状态信息＝外呼失败；若账户存款外呼超时/异常，交易结束，汇款状态＝已兑付(终态)，技术状态信息＝外呼超时/异常；

(5)柜员通过柜面办理收汇取消，可以对汇款状态为已兑付交易做取消交易，若账户存款取消响应成功，汇款状态＝已取消(终态)，技术状态信息＝外呼成功；若账户存款取消响应失败，汇款状态＝已兑付(终态)，技术状态信息＝外呼失败；若账户存款取消响应外呼超时/异常，汇款状态＝已兑付(终态)，技术状态信息＝外呼超时/异常。

实施例5

银邮支付通道的汇款状态流转过程：

汇出方向：用户申请发汇、柜员申请发汇取消、用户申请退汇、合规性审核、系统自动汇出，用不同的状态来表示业务办理结果，并且根据不同失败场景提炼出相应的失败状态，最终确定的状态包括：止付失败、待人工审核、待退款、已退款、已撤销、已取消、已出境、发汇超时、发汇失败，汇款状态的流转如下：

(1)用户通过柜面办理银邮发汇申请时，账户止付失败，交易结束，汇款状态＝止付失败(终态)，技术状态信息＝外呼失败；

(2)用户通过柜面办理银邮发汇申请时，账户止付超时/异常，交易结束，汇款状态＝止付失败(终态)，技术状态信息＝外呼超时/异常；

(3)用户通过柜面办理银邮发汇申请时，账户止付成功，需人工进行合规性审核，汇款状态＝待人工审核(中间态)，技术状态信息＝外呼成功。然后柜员进行合规性审核，若审核通过，则汇款状态＝未出镜(中间态)，技术状态信息＝外呼成功；然后需解止付扣款，若解止付扣款响应成功，汇款状态＝未出镜(中间态)，技术状态信息＝外呼成功；若解止付扣款响应失败，汇款状态＝扣款失败，技术状态信息＝外呼失败；

(4)用户通过柜面办理银邮发汇申请时，账户止付成功，需人工进行合规性审核，汇款状态＝待人工审核(中间态)，技术状态信息＝外呼成功。然后柜员进行合规性审核，若审核不通过，汇款状态＝待退款(中间态)。然后需进行解止付，若解止付响应成功，汇款状态＝已退款(终态)，技术状态信息＝外呼成功；若解止付响应失败，汇款状态不变，技术状态信息＝外呼失败；

(5)用户通过柜面办理银邮发汇申请时，账户止付成功，需人工进行合规性审核，汇款状态＝待人工审核(中间态)，技术状态信息＝外呼成功，然后柜员进行合规性审核，若超时未审核，进行账户扣款取消，若取消成功，汇款状态＝已退款(终态)，技术状态信息＝外呼成功；若取消失败，汇款状态＝待退款(中间态)，技术状态信息＝外呼失败；若取消超时，汇款状态＝已退款(终态)，技术状态信息＝外呼超时/异常；

(6)用户通过柜面办理银邮发汇申请时，若账户扣款成功，无需人工进行合规性审核，汇款状态＝未出境(中间态)，技术状态信息＝外呼成功；若账户扣款失败，无需人工进行合规性审核，汇款状态＝扣款失败(中间态)，技术状态信息＝外呼失败；若账户扣款超时/异常，无需人工进行合规性审核，汇款状态＝扣款失败(中间态)，技术状态信息＝外呼超时/异常；

(7)在汇款状态＝未出镜(中间态)，技术状态信息＝外呼成功的条件下，给国际支付前置发送汇款报文，若收到支付前置同步响应成功，交易结束，汇款状态＝已出境(终态)，技术状态信息＝外呼成功；若收到支付前置同步响应失败，汇款状态＝发汇失败(中间态)，技术状态信息＝外呼失败；若收到支付前置同步响应超时，汇款状态＝发汇超时(中间态)，技术状态信息＝外呼超时/异常；

(8)用户通过柜面办理银邮发汇退汇成功，汇款状态＝已撤销(终态)，技术状态信息＝外呼成功；若退汇失败，汇款状态＝待人工审核/未出境，即恢复更改之前的状态；若退汇超时，汇款状态不变，技术状态信息＝外呼超时/异常，登记SAF重做；

(9)柜员通过柜面办理银邮发汇取消成功，汇款状态＝已取消(终态)，技术状态信息＝外呼成功；

(10)柜员通过柜面办理银邮发汇注销成功，汇款状态＝已注销(终态)，技术状态信息＝外呼成功；

(11)系统自动发送银邮发汇报文成功，汇款状态＝已出境(终态)，技术状态信息＝外呼成功；

(12)系统自动发送银邮发汇报文失败，汇款状态＝发汇失败(中间态)，汇款状态＝发汇失败(中间态)；

(13)系统自动发送银邮发汇报文超时，汇款状态＝发汇超时(中间态)，技术状态信息＝外呼超时/异常，等待对账后的调整；

汇入方向：系统自动入账、境外来账退汇、合规性审核、收汇兑付、手工入账、柜员发起的取消、注销，用不同的状态来表示业务办理结果，并且根据不同失败场景提炼出相应的失败状态，最终确定的状态包括：已受理、审核失败、待人工审核、待申报、已退汇、待入账、兑付失败、已兑付、已取消、已注销，汇款状态的流转如下：

(1)系统收汇自动入账，若系统审核失败且判断需退汇，汇款状态＝已退汇；若审核失败且需改汇，汇款状态＝已受理；

(2)系统收汇自动入账，若系统审核通过且需收支申报，汇款状态＝待申报；若系统审核通过且需人工审核，汇款状态＝待人工审核；

(3)系统收汇自动入账，审核通过且自动入账，若账户存款响应成功，汇款状态＝已兑付，技术状态信息＝外呼成功；若账户存款响应失败，汇款状态＝兑付失败，技术状态信息＝外呼失败；若账户存款响应超时，汇款状态＝已兑付，技术状态信息＝外呼超时/异常；

(4)合规性审核失败，汇款状态＝已退汇；

(5)合规性审核通过，汇款状态＝待入账，然后进行存款存入，若存入响应成功，汇款状态＝已兑付(终态)，技术状态信息＝外呼成功；若存入响应失败，汇款状态＝兑付失败，技术状态信息＝外呼失败；若存入响应超时，汇款状态＝已兑付(终态)，技术状态信息＝外呼超时/异常，SAF重做；

(6)柜员对退汇来账进行手工入账，若存款存入响应成功，汇款状态＝已兑付(终态)，技术状态信息＝外呼成功；若存款存入响应失败，汇款状态＝兑付失败，技术状态信息＝外呼失败；若存款存入响应超时，汇款状态＝已兑付(终态)，技术状态信息＝外呼超时/异常，SAF重做；

(7)收汇取消/注销，若存入取消成功，汇款状态＝兑付失败(中间态)，技术状态信息＝外呼成功；若存入取消失败，汇款状态不变，技术状态信息＝外呼失败；若存入取消超时，汇款状态不变，技术状态信息＝外呼超时/异常；

(8)司法机关冻结，冻结成功，汇款状态＝已冻结；

(9)司法机关扣划，扣划成功，汇款状态＝已扣划。

上述基于分布式架构的汇款业务的状态信息的确定装置包括处理器和存储器，上述获取单元和第一确定单元等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来解决现有技术中汇款流程的状态不够清晰、准确的问题。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本发明实施例提供了一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现上述基于分布式架构的汇款业务的状态信息的确定方法。

本发明实施例提供了一种处理器，上述处理器用于运行程序，其中，上述程序运行时执行上述基于分布式架构的汇款业务的状态信息的确定方法。

本申请的一种典型的实施例中，还提供了一种电子设备，包括：一个或多个处理器，存储器以及一个或多个程序，其中，上述一个或多个程序被存储在上述存储器中，并且被配置为由上述一个或多个处理器执行，上述一个或多个程序包括用于执行任意一种上述的方法。

本发明实施例提供了一种设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现至少以下步骤：

步骤S101，获取目标汇款业务的主数据对应的主服务，上述主服务为根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务中的至少一个；

步骤S102，根据上述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与上述主服务相关的至少部分交易，上述业务状态信息为表征上述第一预定交易的流转情况的信息，上述技术状态信息为表征上述第一预定交易对应的各上述服务之间的交互结果的信息。

本文中的设备可以是服务器、PC、PAD、手机等。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有至少如下方法步骤的程序：

步骤S101，获取目标汇款业务的主数据对应的主服务，上述主服务为根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务中的至少一个；

步骤S102，根据上述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与上述主服务相关的至少部分交易，上述业务状态信息为表征上述第一预定交易的流转情况的信息，上述技术状态信息为表征上述第一预定交易对应的各上述服务之间的交互结果的信息。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如上述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例上述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

从以上的描述中，可以看出，本申请上述的实施例实现了如下技术效果：

1)、本申请的基于分布式架构的汇款业务的状态信息的确定方法中，首先，获取目标汇款业务的主数据对应的主服务，其次，根据获取到的主服务，确定多个业务状态信息和多个技术状态信息，其中，上述主服务为根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务中的至少一个，第一预定交易为与上述主服务相关的至少部分交易，上述业务状态信息为表征上述第一预定交易的流转情况的信息，上述技术状态信息为表征上述第一预定交易对应的各上述服务之间的交互结果的信息。与现有技术中，在进行汇款业务的过程中并没有将状态进行分开相比，本方案中通过获取目标汇款业务的主数据对应的主服务，再根据获取到的主服务，确定多个便于用户查看的业务状态信息和多个便于业务运营人员查看的技术状态信息，即同时满足了客户可见的诉求以及运行管理可见的诉求，本方案实现了将汇款业务中的状态进行分开，得到多个业务状态信息和多个技术状态信息，这样保证了得到的业务状态信息和技术状态信息较为清晰和准确，从而解决了现有技术中汇款流程的状态不够清晰、准确的问题，满足了不同的人群对上述汇款业务的动态了解需求。

2)、本申请的基于分布式架构的汇款业务的状态信息的确定装置中，获取单元用于获取目标汇款业务的主数据对应的主服务，上述主服务为根据面向服务架构对上述目标汇款业务进行拆分得到的多个服务中的至少一个；第一确定单元用于根据上述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与上述主服务相关的至少部分交易，上述业务状态信息为表征上述第一预定交易的流转情况的信息，上述技术状态信息为表征上述第一预定交易对应的各上述服务之间的交互结果的信息。与现有技术中，在进行汇款业务的过程中并没有将状态进行分开相比，本方案中通过获取目标汇款业务的主数据对应的主服务，再根据获取到的主服务，确定多个便于用户查看的业务状态信息和多个便于业务运营人员查看的技术状态信息，即同时满足了客户可见的诉求以及运行管理可见的诉求，本方案实现了将汇款业务中的状态进行分开，得到多个业务状态信息和多个技术状态信息，这样保证了得到的业务状态信息和技术状态信息较为清晰和准确，从而解决了现有技术中汇款流程的状态不够清晰、准确的问题，满足了不同的人群对上述汇款业务的动态了解需求。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种基于分布式架构的汇款业务的状态信息的确定方法，其特征在于，包括：

获取目标汇款业务的主数据对应的主服务，所述主服务为根据面向服务架构对所述目标汇款业务进行拆分得到的多个服务中的至少一个；

根据所述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与所述主服务相关的至少部分交易，所述业务状态信息为表征所述第一预定交易的流转情况的信息，所述技术状态信息为表征所述第一预定交易对应的各所述服务之间的交互结果的信息。

2.根据权利要求1所述的方法，其特征在于，获取目标汇款业务的主数据对应的主服务，包括：

获取所述目标汇款业务的工作流；

根据所述工作流，确定所述主数据；

确定所述主数据对应的所述主服务。

3.根据权利要求1所述的方法，其特征在于，根据所述主服务，确定多个业务状态信息以及多个技术状态信息，包括：

根据所述主服务，确定所有的候选状态信息，所述候选状态信息包括表征第二预定交易的流转情况的信息以及表征所述第二预定交易对应的各所述服务之间的交互结果的信息，所述第二预定交易为与所述主服务相关的所有的所述交易；

对多个所述候选状态信息进行预定处理，得到包括各所述业务状态信息以及各所述技术状态信息的初始状态信息，所述预定处理包括修改所述候选状态信息的描述语言、删除以及合并中的至少之一；

从所述初始状态信息中识别所述业务状态信息以及所述技术状态信息。

4.根据权利要求3所述的方法，其特征在于，从所述初始状态信息中识别所述业务状态信息以及所述技术状态信息，包括：

从所述初始状态信息中识别所述业务状态信息，并控制第一界面显示所述业务状态信息，所述第一界面为用户具有查看权限的界面；

确定剩余的所述初始状态信息为所述技术状态信息，并控制第二界面显示所述技术状态信息，所述第二界面为技术人员具有查看权限的界面。

5.根据权利要求1所述的方法，其特征在于，在根据所述主服务，确定多个业务状态信息以及多个技术状态信息之后，所述方法还包括：

根据各所述业务状态信息，确定对应的各所述服务的流水状态信息；

核对各所述流水状态信息，确定是否存在异常，所述异常为多个所述服务的预定流水状态信息不同，所述预定流水状态信息为同一个所述第一预定交易对应的所述流水状态信息；

在存在所述异常的情况下，对所述异常的所述预定流水状态信息进行调整。

6.根据权利要求5所述的方法，其特征在于，对所述异常的所述预定流水状态信息进行调整，包括：

对所述异常的所述预定流水状态信息进行第一标识标记；

对所述异常的所述预定流水状态信息进行调整；

将调整后的所述预定流水状态信息的所述第一标识变更为第二标识。

7.一种基于分布式架构的汇款业务的状态信息的确定装置，其特征在于，包括：

获取单元，用于获取目标汇款业务的主数据对应的主服务，所述主服务为根据面向服务架构对所述目标汇款业务进行拆分得到的多个服务中的至少一个；

第一确定单元，用于根据所述主服务，确定多个业务状态信息以及多个技术状态信息，其中，第一预定交易为与所述主服务相关的至少部分交易，所述业务状态信息为表征所述第一预定交易的流转情况的信息，所述技术状态信息为表征所述第一预定交易对应的各所述服务之间的交互结果的信息。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括存储的程序，其中，所述程序执行权利要求1至6中任意一项所述的方法。

9.一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序运行时执行权利要求1至6中任意一项所述的方法。

10.一种电子设备，其特征在于，包括：一个或多个处理器，存储器以及一个或多个程序，其中，所述一个或多个程序被存储在所述存储器中，并且被配置为由所述一个或多个处理器执行，所述一个或多个程序包括用于执行权利要求1至6中任意一项所述的方法。

Images