一种多系统协同业务处理的方法及设备

技术领域

本申请属于信息处理技术领域，尤其涉及多系统协同业务处理的方法及设备。

背景技术

随着国内证券业务的发展，证券服务、交易的系统越来越复杂，推动了分布式计算机应用系统的普及。传统的多个系统协同对某一账户进行约定业务处理时，先在主系统上对该账户进行约定业务处理，再利用系统间功能调用的方式在每个子业务系统上对该账户进行约定业务处理，所有系统上针对该账户的约定业务均处理成功，则整个流程结束，任意一个系统针对该账户的约定业务处理不成功，所有系统全部回退至未处理前的状态。

通过这样的方式，只要有一个子业务系统上针对该账户的业务处理不成功，其他子业务系统上需要全部进行业务回退，然而每个业务都比较复杂，涉及众多数据对象，处理逻辑比较复杂，容易出现各子业务系统上账户数据不一致的情况。这种方式耗时、数据处理量大，无用功。

其次，在业务处理时通过系统间功能调用的方式，主程序复杂度较高，对业务处理流程进行跟踪、监控时不方便。

另一方面，在各个子业务系统中分别处理约定业务时，若突然出现新业务，将会中断对当前约定业务的处理流程，导致某些子业务系统上业务处理不成功的情况出现，影响系统的正常运行。

发明内容

本申请实施例提供了一种多系统协同业务处理的方法及设备，在对第一账户进行业务处理时，首先检查账户系统和多个子业务系统中该账户是否满足业务处理的条件，当不满足业务处理的条件时中断正在进行的操作，通过这样的方式，涉及数据对象少，处理逻辑简单，耗时少。其次，在账户系统完成对第一账户的业务处理后，通过消息总线向多个子业务系统发布已处理完成的消息，多个子业务系统各自完成针对第一账户的业务处理，通过这样的方式，不需要对每个子业务系统进行业务处理流程跟踪。同时，由于在检查各系统上第一账户是否满足处理某个业务的条件时，锁定了第一账户在账户系统中和多个子业务系统中的账户状态为仅处理该业务的状态，因此子业务系统根据消息总线发布的消息处理业务时，不会受到其他业务的干扰，一定会处理成功，降低了业务处理的复杂度。

第一方面，本申请实施例提供了一种多系统协同业务处理的方法，该方法包括：接收销户请求，账户系统根据所述销户请求确定待销户的第一账户；根据所述销户请求，锁定所述第一账户在所述账户系统中的账户状态为仅处理销户业务的状态；根据所述第一账户，检查所述账户系统中所述第一账户是否满足销户条件；根据所述销户请求，锁定所述第一账户在多个子业务系统中的账户状态为仅处理销户业务的状态；根据所述第一账户，检查所述多个子业务系统中所述第一账户是否满足销户条件；当所述第一账户在所述账户系统和所述多个子业务系统中的每一个系统都满足所述销户条件时，注销所述账户系统中所述第一账户且注销所述多个子业务系统中所述第一账户；当所述第一账户在所述账户系统和所述多个子业务系统中的任意一个系统不满足所述销户条件时，所述账户系统和所述多个子业务系统中所述第一账户的账户状态从仅处理销户业务的状态恢复为正常状态，从而中断所述第一账户的销户流程。

应理解，所述方法中的第一账户为待销户的任何一个账户，在本方案中检查多个子业务系统中第一账户是否满足销户条件时，采用主系统即账户系统调用业务子系统功能的方式，该方式可以用多线程同时调用，也可以采用单线程顺序调用，账户系统记录每个调用接口对应的子业务系统的检查结果，只要有一个子系统中第一账户检查未通过，则其他所有已通过的子系统中的第一账户都恢复成正常办理业务的状态。在每个系统中锁定第一账户的账户状态，除了销户业务外，其他业务均不能办理。由于先检查各系统中第一账户是否满足销户条件，再修改其账户状态为锁定，第一账户可能会存在新业务处理，导致原先的判断不准确，因此在某些可能的实现方式上，在销户检查前，先锁定第一账户的账户状态。

通过这样的方案，不存在某一个子业务系统中对第一账户销户失败后，对每一个子业务系统及账户系统全部进行业务回退，从而导致各子业务系统上账户数据不一致的情况。在各个系统对第一账户进行销户处理前，不满足销户条件就中断销户的操作，数据处理量小，耗时少。另一方面，通过锁定确保账户系统和所有子业务系统在处理销户业务时，不再有其他业务发生，避免出现部分子系统销户成功，部分子系统销户不成功，导致各子系统数据不一致的情况。

在第一方面的某些可能的实现方式中，所述注销所述账户系统中所述第一账户且注销所述多个子业务系统中所述第一账户，包括：所述账户系统注销所述第一账户，并通过消息总线向所述多个子业务系统发送所述第一账户注销完成的消息；所述多个子业务系统根据所述第一账户注销完成的消息，注销所述多个子业务系统中所述第一账户。

具体地，多个子业务系统通过消息总线收取账户系统的销户结果的消息，再异步处理该消息，将第一账户在本系统进行销户，各个子系统互不干扰。通过这样的方案，实现了账户系统对各子业务系统异步调用处理，降低了主程序的复杂度，减少了主程序的处理时间，节约了主系统资源，将业务流程变为数据信息，更容易跟踪与监控。

结合第一方面和上述实现方式，在第一方面的某些实现方式中，所述多个子业务系统包括第一子业务系统和第二子业务系统，当所述第一账户在所述账户系统和所述多个子业务系统中的任意一个系统不满足所述销户条件时，所述账户系统和所述多个子业务系统中所述第一账户的账户状态从仅处理销户业务的状态恢复为正常状态，从而中断所述第一账户的销户流程，包括：当所述第一账户在所述账户系统中不满足所述销户条件时，所述账户系统中所述第一账户的账户状态从仅处理销户业务的状态恢复为正常状态，从而中断所述第一账户的全部销户流程；当所述第一账户在所述第一子业务系统中不满足所述销户条件时，所述第一子业务系统中所述第一账户的账户状态从仅处理销户业务的状态恢复为正常状态，并向所述账户系统发送中断销户指令，所述中断销户指令用于将所述账户系统和所述第二子业务系统中所述第一账户的账户状态从仅处理销户业务的状态恢复为正常状态，从而中断所述第一账户在所述账户系统和所述第二子业务系统的销户流程。

具体地，所述第一子业务系统为任意一个不满足销户条件的子业务系统，第二子业务系统为任意一个满足销户条件的子业务系统。当账户系统中第一账户不满足销户条件时，将账户系统中第一账户的状态从仅处理销户业务恢复为正常状态，其他子业务系统中不再进行销户检查，中断销户流程。当账户系统中第一账户满足销户条件时，账户系统记录每个调用接口对应的业务子系统的检查结果，只要有一个子系统中第一账户不满足销户条件，其他所有已通过的子系统中都要将第一账户的账户状态恢复为正常办理业务的状态。

通过这样的方案，使各个系统之间可以快速了解对方的状态，并及时对账户1的账户状态做出改变，节省了程序处理的时间，使销户流程变得简单。

结合第一方面和上述实现方式，在第一方面的某些实现方式中，所述根据所述第一账户，检查账户系统中所述第一账户是否满足销户条件，包括：获取所述账户系统中所述第一账户的接口返回值；根据所述第一账户的接口返回值的数值，确定所述账户系统中所述第一账户是否满足所述销户条件；以及，所述根据所述第一账户，检查多个子业务系统中所述第一账户是否满足销户条件，包括：获取所述多个子业务系统中所述第一账户的接口返回值；根据所述第一账户的接口返回值的数值，确定所述多个子业务系统中所述第一账户是否满足所述销户条件。

具体地，记录账户系统中以及每一个子业务系统中第一账户的接口返回值，通过返回值判断该账户是否满足销户条件。只要有一个子系统未通过，则其他所有已通过的子系统都要将状态恢复为原来的值。

结合第一方面和上述实现方式，在第一方面的某些实现方式中，在所述根据所述销户请求，锁定所述第一账户在所述账户系统中的账户状态和所述第一账户在所述多个子业务系统中的账户状态为仅处理销户业务的状态中，确定所述第一账户在所述账户系统中的账户状态，包括：获取所述账户系统中所述第一账户的基本信息表的字段值；根据所述第一账户的基本信息表的字段值，确定所述第一账户在所述账户系统中的账户状态；以及确定所述第一账户在所述多个子业务系统中的账户状态，包括：获取所述多个子业务系统中所述第一账户的基本信息表的字段值；根据所述第一账户的基本信息表的字段值，确定所述第一账户在所述多个子业务系统中的账户状态。

可选地，通过账户信息表中的账户状态字段值得出该账户的状态是锁定状态还是正常办理所有业务的状态，确定是否开始进行销户业务的办理。

第二方面，本申请实施例提供了另一种多系统协同业务处理的方法，该方法包括：接收营业部变更请求，账户系统根据所述营业部变更请求确定待变更营业部的第一账户，所述营业部变更请求用于将所述第一账户所属的第一营业部变更为第二营业部；根据所述第一账户，检查所述账户系统中是否存在与所述第一账户所属的第一营业部相关联的第一存管账户；根据所述第一账户，检查多个子业务系统中是否存在与所述第一账户所属的第一营业部相关联的所述第一存管账户；当在所述账户系统和子业务系统中存在与所述第一账户所属的第一营业部相关联的所述第一存管账户时，注销所述第一存管账户；根据所述营业部变更请求，锁定所述第一账户在所述账户系统中的账户状态为仅处理营业部变更业务的状态；根据所述第一账户，检查所述账户系统中所述第一账户是否满足营业部变更条件；根据所述营业部变更请求，锁定所述第一账户在所述多个子业务系统中的账户状态为仅处理营业部变更业务的状态；根据所述第一账户，检查所述多个子业务系统中所述第一账户是否满足营业部变更条件；当所述第一账户在所述账户系统和所述多个子业务系统中的每一个系统都满足所述营业部变更条件时，所述账户系统中所述第一账户从第一营业部变更为第二营业部，且所述多个子业务系统中所述第一账户从第一营业部变更为第二营业部；当所述第一账户在所述账户系统和所述多个子业务系统中的任意一个系统不满足所述营业部变更条件时，所述账户系统和所述多个子业务系统中所述第一账户的账户状态从仅处理营业部变更业务的状态恢复为正常状态，从而中断所述第一账户的营业部变更流程。

在第二方面的某些可能的实现方式中，在所述账户系统中所述第一账户从第一营业部变更为第二营业部，且所述多个子业务系统中所述第一账户从第一营业部变更为第二营业部，包括：所述账户系统中所述第一账户从第一营业部变更为第二营业部，并通过消息总线向所述多个子业务系统发送所述第一账户营业部变更完成的消息；所述多个子业务系统根据所述第一账户营业部变更完成的消息，在所述多个子业务系统中将所述第一账户从第一营业部变更为第二营业部。

结合第二方面和上述实现方式，在第一方面的某些实现方式中，当所述第一账户在所述账户系统和所述多个子业务系统中的任意一个系统不满足所述营业部变更条件时，所述账户系统和所述多个子业务系统中所述第一账户的账户状态从仅处理营业部变更业务的状态恢复为正常状态，从而中断所述第一账户的营业部变更流程，包括：当所述第一账户在所述账户系统中不满足所述营业部变更条件时，所述账户系统中所述第一账户的账户状态从仅处理营业部变更业务的状态恢复为正常状态，从而中断所述第一账户从第一营业部变更为第二营业部的流程；当所述第一账户在所述第一子业务系统中不满足所述营业部变更条件时，所述第一子业务系统中所述第一账户的账户状态从仅处理营业部变更业务的状态恢复为正常状态，并向所述账户系统发送中断营业部变更指令，所述中断营业部变更指令用于将所述账户系统和所述第二子业务系统中所述第一账户的账户状态从仅处理营业部变更业务的状态恢复为正常状态，从而中断所述第一账户在所述账户系统和所述第二子业务系统中从第一营业部变更为第二营业部的流程。

第三方面，本申请实施例提供了一种终端设备，包括：一个存储器、一个处理器以及存储在所述存储器中并可在所述处理器上运行的多个计算机程序，所述处理器执行所述计算机程序时执行上述第一方面中任一项所述的多系统协同业务处理的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行上述第一方面中任一项所述的多系统协同业务处理的方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项所述的多系统协同业务处理的方法。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

本申请实施例与现有技术相比存在的有益效果是：对第一账户进行业务处理时，首先检查账户系统和多个子业务系统中该账户是否满足业务处理的条件，当不满足业务处理的条件时中断正在进行的操作，通过这样的方式，涉及数据对象少，处理逻辑简单，耗时少。其次，在账户系统完成对第一账户的业务处理后，通过消息总线向多个子业务系统发布已处理完成的消息，多个子业务系统各自完成针对第一账户的业务处理，通过账户系统对各子业务系统异步调用处理，降低了主程序的复杂度，减少了主程序的处理时间，节约了主系统资源，将业务流程变为数据信息，更容易跟踪与监控。同时，在对第一账户进行检查时，锁定了第一账户在账户系统中和多个子业务系统中的账户状态为仅处理该业务的状态，因此子业务系统根据消息总线发布的消息处理业务时，不会受到其他业务的干扰，一定会处理成功，降低了业务处理的复杂度。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例提供的一例金证证券业务综合服务平台的结构图；

图2是传统的采用系统间功能的销户流程示意图；

图3是本申请实施例提供的一种多系统协同处理销户业务的流程示意图；

图4是本申请实施例提供的一例账户的基本信息表示意图；

图5是本申请实施例提供的一例账户的接口返回值示意图；

图6是本申请实施例提供的一种多系统协同处理营业部变更业务的流程示意图；

图7是本申请实施例提供的终端设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

分布式架构是一个由多个子业务系统组成的计算机应用系统，每个子业务系统都有相对独立的硬件设备、软件模块，可以独立完成特定的功能，但有些功能需要多个系统协同才能完成。随着国内证券业务的发展，证券服务、交易的软件也越来越复杂，金证证券业务综合服务平台是一种向券商提供处理交易业务及相关功能的计算机系统，采用分布式架构，图1是本申请实施例提供的金证证券业务综合服务平台的结构图。如图1所示，该平台包括多个业务系统，例如前端服务系统、账户系统、订单系统、资金系统、后台业务系统、影像系统、统一认证系统等，不同的业务处理需要由各业务系统协同完成。

可选地，在金证证券业务综合服务平台中，多个业务系统可以在任意一个电子设备中协同处理各种业务，不同的业务系统也可以处于多个不同的电子设备中协同处理各种业务，应理解，本申请实施例对电子设备的数量和形态不做限定，可以包括平板电脑、笔记本电脑、超级移动个人计算机等。

图2是传统的采用系统间功能的销户流程示意图。示例性的，在传统的方案中对账户1进行销户时，包括如图2所示的流程：

201，接收注销账户1的销户请求。

具体地，该销户请求可以通过综合运营平台或内部管理人员申请等方式发起，这里不做具体限定。

202，确定待销户的账户1。

具体地，销户请求信息中可以包含账户的基本代码、账户的名称等，这里不做具体限定，账户系统根据请求信息确定待销户的账户为账户1。

203，检查账户1是否满足销户条件。

示例性的，账户系统调用账户1的销户接口，获取账户1的销户接口的返回值，通过返回值的数值确定账户1是否满足销户条件。

由于只在账户系统中检查了账户1是否满足销户条件，在订单系统、资金系统以及后台业务系统中注销账户1时，存在处理不成功的可能性。然而任意一个子业务系统处理不成功，其他所有系统全部需要中断注销流程，回退至初始状态，涉及众多数据对象，容易出现各个子业务系统上账户1的账户数据不一致的情况。

204，注销账户系统中的账户1。

205，注销订单系统中的账户1。

206，注销资金系统中的账户1。

207，注销后台业务系统中的账户1。

具体地，在步骤205、206以及207中，通过账户系统顺序调用订单系统、资金系统以及后台业务系统中账户1的销户接口，在各个子业务系统中完成销户流程。账户系统采用顺序调用每一个子业务系统的销户接口的方式，主程序复杂度高，对流程进行跟踪和监控不方便。

另一方面，在销户过程中，每一个业务系统中账户1的接口均未被锁定，任意一个系统中若突然出现新业务，会出现此系统中注销账户1不成功的情况，影响系统的正常运行。

图3是本申请实施例提供的一种多系统协同处理销户业务的流程示意图。本申请实施例中对账户1进行销户时，包括如图3所示的流程：

301，接收第一账户的销户请求。

具体地，综合运营平台或内部管理人员发起销户请求，请求信息中可以包含账户的基本代码、账户的名称等，这里不做具体限定，账户系统根据请求信息确定待销户的账户为账户1。

302，锁定第一账户的账户状态，并检查账户系统中第一账户是否满足销户条件。

在金证证券业务综合服务平台中，每个系统中都包含了无数个业务主体，一个业务主体表现为一个数据库表的一条记录，包括了账户的基本信息。图4为本申请实施例提供的一例账户的基本信息表示意图，包含了账户代码、账户名称以及账户状态等字段。每个账户在同一时刻只能有一个状态，状态表现可以为数据库表里的账户状态字段值，这里不做限定。不同的字段值表示该账户所处的不同状态，处于正常办理业务状态或是锁定状态，锁定状态表示对于账户而言，除了办理约定业务外，其他业务均不能办理。

为了准确判断在账户系统上能否进行销户，本申请实施例在接收销户请求，根据销户请求确定待销户的第一账户之后，锁定第一账户在账户系统中的账户状态为仅处理销户业务的状态。

具体地，在检查账户系统中账户1是否满足销户条件时，将账户系统中账户1的账户状态设置为锁定状态，即只允许账户1处理销户业务。示例性的，如图4所示，当账户1的状态字段值为‘A’时，表示账户1的账户状态已锁定，当账户2的状态字段值为‘0’时，表示账户2为正常处理业务的状态。

本实施例中所述的方法，可以确保账户系统在处理销户业务时，不再有其他业务发生。

在检查账户系统中账户1是否满足销户条件时，在账户系统中调用账户1的接口，获取接口的返回值，该接口功能代码、返回值、入参等均通过系统相关设计文档约定，图5是本申请实施例提供的一例账户的接口返回值示意图。示例性的，如图5所示，当账户系统中账户1、账户2的接口返回值都为0时，代表账户1、账户2在账户系统中满足销户条件且锁定成功。

303，锁定第一账户的账户状态，并检查订单系统中第一账户是否满足销户条件。

304，锁定第一账户的账户状态，并检查资金系统中第一账户是否满足销户条件。

305，锁定第一账户的账户状态，并检查后台业务系统中第一账户是否满足销户条件。

具体地，在步骤303、304以及305中，账户系统分别调用订单系统、资金系统以及后台业务系统中账户1的接口，可以通过多线程的方式同时调用，也可以采用单线程顺序调用的方式，这里不做具体限定。在分别检查订单系统、资金系统以及后台业务系统中账户1是否满足销户条件时，同样将订单系统、资金系统以及后台业务系统中账户1的账户状态设置为锁定状态，即只允许账户1处理销户业务。获取每个系统中账户1接口的返回值，通过返回值的数值确定每个系统中账户1是否可以办理销户业务。

本实施例中所述的方法，避免了出现账户1在资金系统注销成功，在后台业务系统以及订单系统注销不成功，导致资金系统、后台业务系统以及订单系统中账户1的数据不一致的情况。各个系统对账户1注销前先进行销户条件的检查，不满足销户条件就中断销户的操作，数据处理量小，耗时少。

作为一种实现方式，如图5所示的账户3，在账户系统上账户3的接口返回值不为0，中断注销账户3的流程。

具体地，当账户系统上账户3的接口返回值不为0，将账户系统上账户3的账户状态由仅处理销户业务的状态恢复为正常处理所有业务的状态，中断账户系统上账户3的销户流程，各子业务系统上不再对账户3进行销户条件的检查。

作为另一种实现方式，如图5所示的账户2，在账户系统、后台业务系统以及资金系统上账户2的接口返回值均为0，但在订单系统上账户2的接口返回值大于0。中断销户流程如步骤306-308所述：

306，恢复账户系统上第一账户的账户状态。

307，恢复资金系统上第一账户的账户状态。

308，恢复后台业务系统上第一账户的账户状态。

具体地，当订单系统上账户2的接口返回值不为0，将订单系统上账户2的账户状态由仅处理销户业务的状态恢复为正常处理所有业务的状态，中断订单系统上账户2的销户流程，并通过返回值的数值向账户系统发送中断销户指令。账户系统收到订单系统上账户2不满足销户条件的中断销户指令后，在账户系统上将账户2的账户状态从仅处理销户业务的状态恢复为正常状态。之后在账户系统上分别调用资金系统以及后台业务系统上账户2的接口，将资金系统和后台业务系统上账户2的账户状态由仅处理销户业务的状态恢复为正常处理所有业务的状态，中断资金系统和后台业务系统上账户2的销户流程。各子系统中中断账户2的销户流程，各系统之间互不干扰，应理解，步骤307和308无先后顺序，各自将账户2的账户状态恢复至正常办理所有业务的状态。

本实施例中的方法，使各个系统之间可以快速了解对方的状态，不同的返回值代表不同的不满足销户条件的原因。及时对账户1的账户状态做出改变，节省了程序处理的时间，使销户流程变得简单。

作为另一种实现方式，如图5所示的账户1，在账户系统、订单系统、资金系统以及后台业务系统上，账户1的接口返回值均为0，可以正常办理销户业务，注销流程如步骤309-313所述：

309，注销账户系统中第一账户。

应理解，如图5所示的账户1，在账户系统、订单系统、资金系统以及后台业务系统中账户1接口的返回值全部为0，进入销户阶段，首先在账户系统中注销账户1。

310，账户系统通过消息总线向各个子系统发布第一账户注销完成的消息。

作为一种实现方式，账户系统处理完销户业务后，通过消息总线向各个子业务系统发布处理完成的消息，具体地，账户系统注销账户1后，通过消息总线向订单系统、资金系统以及后台业务系统发送账户1已完成注销的消息。

311，注销订单系统中所述第一账户。

312，注销资金系统中所述第一账户。

313，注销后台业务系统中所述第一账户。

具体地，订单系统、资金系统以及后台业务系统通过消息总线接收到账户系统中账户1完成注销的信息后，在各自系统中对账户1完成注销流程，各系统之间互不干扰。应理解，步骤311、312以及313无先后顺序。

本实施例中所述的方法，多个子业务系统分别注销账户1，各个子业务系统互不干扰。通过这样的方案，实现了账户系统对各子业务系统异步调用处理，降低了主程序的复杂度，减少了主程序的处理时间，节约了主系统资源，将业务流程变为数据信息，更容易跟踪与监控。

以上结合图3至图5对本申请实施例提供的多系统协同处理销户业务的方法做了详细说明。以下，为本申请实施例提供的多系统协同处理营业部变更业务的方法。图6是本申请实施例提供的一种多系统协同处理营业部变更业务的流程示意图。

601，接收第一账户的营业部变更请求。

具体地，系统扫描是否存在营业部变更的事件，扫描出账户1需要进行营业部变更后，内部管理人员发起变更账户1的营业部的申请，当审批通过时，定时器触发，定时器处理接口发出变更账户1所属营业部的请求，请求信息中可以包含账户的基本代码、账户的名称等，这里不做具体限定，账户系统根据请求信息确定待变更营业部的为账户1。

602，检查账户系统中是否存在与第一账户的所属营业部关联的存管账户。

603，检查子业务系统中是否存在与第一账户的所属营业部关联的存管账户。

具体地，存管银行1中的存管账户1记载了账户1交易计算资金的变动明细，存管账户1与账户系统中账户1以及资金系统中的账户1之间存在对应关系，步骤603和步骤604用来检查存管银行1中的存管账户1是否存在。

604，存管销户。

具体地，当存管账户1存在时，进行银证销户，解除账户1在账户系统以及资金系统中的账户与存管账户1之间的关联性。

605，锁定账户系统中第一账户的账户状态，并检查第一账户是否满足营业部变更条件。

在注销了存管账户1之后，根据营业部变更请求，锁定账户1在账户系统中的账户状态，设置为仅处理营业部变更业务的状态，再检查账户系统中账户1是否满足营业部变更条件。

具体地，在检查账户系统中账户1能否进行营业部变更时，将账户系统中账户1的账户状态设置为锁定状态，只允许账户1处理营业部变更业务。示例性的，当账户系统中账户基本信息表中的账户1的状态字段值均为‘A’时，开始进行营业部变更检查。在账户系统中调用账户1的接口，获取接口的返回值，该接口功能代码、返回值、入参等均通过系统相关设计文档约定。示例性的，当账户系统中账户1的接口返回值为0时，代表账户1在账户系统中满足营业部变更条件。

606，锁定订单系统中第一账户的账户状态，并检查订单系统中第一账户是否满足营业部变更条件。

607，锁定资金系统中第一账户的账户状态，并检查资金系统中第一账户是否满足营业部变更条件。

608，锁定后台系统中第一账户的账户状态，并检查后台系统中是否满足营业部变更条件。

与账户系统类似，在检查订单系统、资金系统以及后台系统中账户1能否进行营业部变更时，将各子业务系统中账户1的账户状态设置为锁定状态，只允许账户1处理营业部变更业务。具体地，账户系统分别调用订单系统、资金系统和后台系统中账户1的接口，可以通过多线程的方式同时调用，也可以采用单线程顺序调用的方式，这里不做具体限定。获取每个系统中账户1接口的返回值，通过返回值的数值确定每个系统中账户1是否可以处理营业部变更业务。

作为一种实现方式，当账户系统上账户1的接口返回值不为0，直接恢复账户系统上账户1的账户状态，中断变更账户1所属营业部的流程。

具体地，当账户系统上账户1的接口返回值不为0，将账户系统上账户1的账户状态由仅处理营业部变更业务的状态恢复为正常处理所有业务的状态，中断账户系统上账户1所属营业部从营业部1变更为营业部2的流程，各子业务系统不再进行营业部变更条件的检查。

作为另一种实现方式，如图6中的步骤609-611，在后台系统上，账户1的接口返回值不为0，中断后台系统上变更账户1所属营业部的流程，所有系统中账户1的账户状态也恢复至正常状态，可以正常办理所有业务。

609，恢复账户系统上第一账户的账户状态。

610，恢复订单系统上第一账户的账户状态。

611，恢复资金系统上第一账户的账户状态。

具体地，当后台系统上账户1的接口返回值不为0时，将后台系统上账户1的账户状态由仅处理营业部变更业务的状态恢复为正常处理所有业务的状态，中断后台系统上账户1的营业部从营业部1变更为营业部2的流程。账户系统收到后台系统上账户1不满足营业部变更条件的返回值后，首先在账户系统上将账户1的账户状态由仅处理营业部变更业务的状态恢复为正常处理所有业务的状态。之后在账户系统上分别调用资金系统和订单系统上账户1的接口，将资金系统和订单系统上账户1的账户状态由仅处理营业部变更业务的状态恢复为正常处理所有业务的状态，中断资金系统和订单系统上账户1的营业部从营业部1变更为营业部2的流程。各系统之间互不干扰，应理解，步骤610和611无先后顺序，各自将账户1的账户状态恢复至正常办理所有业务的状态。

作为另一种实现方式，如图6中的步骤612-616，在账户系统、订单系统、资金系统以及后台系统上，账户1的接口返回值均为0，可以正常办理营业部变更业务。

612，变更账户系统中第一账户的营业部。

当账户1在账户系统和多个子业务系统中的每一个系统都满足营业部变更条件时，变更账户系统中账户1的营业部。

示例性的，当账户系统、订单系统、资金系统以及后台系统中账户1接口的返回值全部为0时，在账户系统里分别将账户1的归属营业部从营业部1变更为营业部2。

613，账户系统通过消息总线向各子业务系统发布第一账户变更营业部完成的消息。

具体地，在各系统均满足营业部变更条件时，账户系统变更账户1的营业部，并通过消息总线向订单系统、资金系统以及后台系统发送账户1已完成营业部变更的消息。

614，变更后台系统中第一账户的营业部。

615，变更订单系统中第一账户的营业部。

616，变更资金系统中第一账户的营业部。

具体地，订单系统、资金系统以及后台系统接收到账户系统中账户1完成营业部变更的信息后，在各自系统中将账户1的归属营业部从营业部1变更为营业部2，其中，步骤614，615以及616无先后顺序。

图7是本申请实施例提供的终端设备的结构示意图。如图7所示，该终端设备包括处理器701、存储器702以及存储在所述存储器702中并可在所述处理器701上运行的计算机程序，所述处理器701执行计算机程序时实现上述任意多系统协同业务处理的实施例中的步骤。

所述多系统协同业务处理的终端设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述处理器701可以是中央处理单元(Central Processing Unit，CPU)，该处理器701还可以是其他通用处理器、数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器702在一些实施例中可以是所述终端设备的内部存储单元，硬盘或内存。所述存储器702在另一些实施例中也可以是所述终端设备的外部存储设备，例如所述多系统协同业务处理的装置上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器702还可以既包括内部存储单元也包括外部存储设备。所述存储器702用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器702还可以用于暂时地存储已经输出或者将要输出的数据。

需要说明的是，上述设备之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。