CN111563002B - 交易故障的处理方法和装置、以及电子设备和存储介质 - Google Patents

Abstract

本公开提供了一种交易故障的处理方法和装置、以及电子设备和存储介质。其中，交易通过应用程序与至少一个组件的交互来实现，交易故障的处理方法包括：监听至少一个组件响应于应用程序发送的消息反馈的反馈信息；在交易存在故障的情况下，根据反馈信息确定故障的类型及故障所针对的组件；以及根据故障的类型及故障所针对的组件，获取故障修复模型，以对故障进行修复。

Description

交易故障的处理方法和装置、以及电子设备和存储介质

技术领域

本公开涉及信息处理领域，更具体地，涉及一种交易故障的处理方法和装置、以及电子设备和存储介质。

背景技术

联机交易系统凭借其高性能和稳定性，在金融领域使用广泛。该使用该交易系统进行交易的过程中若出现故障，往往需要运维人员介入分析交易故障的类型，找到故障的应用程序名称。并由运维人员根据该故障的类型等信息对故障进行人工修复。在人工修复不成功的情况下，则需要更为专业的运维人员进一步分析故障原因，并根据故障原因通知对应的程序维护人员进行故障处理。该过程涉及的步骤繁多、操作复杂、时效低，且需要运维人员具有一定的技术水平。

发明内容

有鉴于此，本公开提供了一种能够自动分析并修复故障的交易故障的处理方法和装置、以及电子设备和存储介质，以期提高故障修复效率，降低运维人员操作流程的复杂性。

本公开的一个方面提供了一种交易故障的处理方法，该方法包括：监听至少一个组件响应于应用程序发送的消息反馈的反馈信息；在交易存在故障的情况下，根据反馈信息确定故障的类型及故障所针对的组件；以及根据故障的类型及故障所针对的组件，获取故障修复模型，以对故障进行修复。

根据本公开的实施例，上述交易故障的处理方法还包括：在反馈信息中包括目标字段的情况下，确定交易存在故障；或者在反馈信息中目标字段的取值为预定值的情况下，确定交易存在故障。

根据本公开的实施例，上述根据反馈信息确定故障的类型及故障所针对的组件包括：根据反馈信息中包括的目标字段，确定故障的类型；以及根据故障的类型及反馈信息，确定故障所针对的组件。

根据本公开的实施例，上述至少一个组件包括中间件和数据库组件；应用程序包括部署于中间件的主模块和部署于数据库组件的子模块；故障的类型包括主模块的版本信息与子模块的版本信息不一致的类型；根据故障的类型及反馈信息，确定故障所针对的组件包括：根据反馈信息，确定配置于中间件的主模块的版本信息及数据库组件中与主模块匹配的子模块的版本信息；获取实体库中应用程序的版本信息；以及根据应用程序的版本信息、主模块的版本信息及子模块的版本信息，确定故障所针对的组件。

根据本公开的实施例，上述根据反馈信息，确定配置于中间件的主模块的版本信息及数据库组件中与主模块匹配的子模块的版本信息包括：从反馈信息中提取得到主模块的版本信息及中间件的名称；根据中间件的名称，确定与中间件对应的数据库组件；以及获取与中间件对应的数据库组件中与主模块匹配的子模块的版本信息。

根据本公开的实施例，上述根据应用程序的版本信息、主模块的版本信息及子模块的版本信息，确定故障所针对的组件包括：在应用程序的版本信息与主模块的版本信息不一致的情况下，确定故障所针对的组件为配置主模块的中间件；并且/或者在应用程序的版本信息与子模块的版本信息不一致的情况下，确定故障所针对的组件为配置子模块的数据库组件。

根据本公开的实施例，在故障的类型为主模块的版本信息与子模块的版本信息不一致的类型且故障所针对的组件为配置主模块的中间件的情况下，获取的故障修复模型包括重新复制修复模型，以将实体库中的应用程序重新加载至中间件；在故障的类型为主模块的版本信息与子模块的版本信息不一致的类型且故障所针对的组件为配置子模块的数据库组件的情况下，获取的故障修复模型包括绑定修复模型，以将实体库中的应用程序重新绑定至数据库组件。

根据本公开的实施例，上述交易故障的处理方法还包括：获取对故障进行修复得到的修复结果；在修复结果表征修复失败的情况下，根据修复结果确定修复失败的因素；以及向预定服务器推送表征修复失败的因素的提示信息。

本公开的另一方面提供了一种交易故障的处理装置。交易通过应用程序与至少一个组件的交互来实现，该处理装置包括：监听模块，用于监听至少一个组件响应于应用程序发送的消息反馈的反馈信息；故障确定模块，用于在交易存在故障的情况下，根据反馈信息确定故障的类型及故障所针对的组件；以及故障修复模块，用于根据故障的类型及故障所针对的组件，获取故障修复模型，以对故障进行修复。

本公开的另一方面提供了一种电子设备，包括：一个或多个处理器；以及存储装置，用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器执行上述的交易故障的处理方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被处理器执行时用于执行如上所述的交易故障的处理方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的交易故障的处理方法。

根据本公开的实施例，至少可以部分地解决相关技术中交易故障需要运维人员人工定位和修复的技术问题。本公开实施例通过监听组件响应于应用程序发送的消息而反馈的反馈消息，并对该反馈消息进行分析，可以定位得到故障类型及所针对的组件，并可以根据故障修复模型对故障进行自动修复，从而有效降低修复故障的复杂性，降低运维人员的工作量，提高故障修复效率。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了本公开实施例的交易故障的处理方法和装置、以及电子设备和存储介质的应用场景；

图2示意性示出了本公开实施例的交易故障的处理方法的流程图；

图3示意性示出了本公开实施例的根据故障类型及反馈信息，确定故障所针对的组件的流程图；

图4示意性示出了本公开实施例的根据反馈信息确定主模块的版本信息和子模块的版本信息的流程图；

图5示意性示出了本公开另一实施例的交易故障的处理方法的流程图；

图6示意性示出了本公开实施例的交易故障的处理装置的结构框图；

图7示意性示出了本公开另一实施例的交易故障的处理装置的结构框图；以及

图8示意性示出了本公开实施例的适于执行交易故障的处理方法的电子设备的结构框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

本公开的实施例提供了一种交易故障的处理方法。其中，交易通过应用程序与至少一个组件的交互来实现。该处理方法可以先监听至少一个组件响应于应用程序发送的消息反馈的反馈信息。然后在交易存在故障的情况下，根据反馈信息确定故障的类型及故障所针对的组件。最后根据故障的类型及故障所针对的组件，获取故障修复模型，以对故障进行修复。

图1示意性示出了根据本公开实施例的交易故障的处理方法和装置、以及电子设备和存储介质的应用场景。需要注意的是，图1所示仅为可以应用本公开实施例的应用场景的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，该实施例的应用场景100例如可以包括大型主机(Mainframe)110，该大型主机110中可以根据实际需求集成有不同的应用程序。例如，在金融领域中，该大型主机例如可以集成有联机交易应用程序。为了实现该联机交易应用程序的功能，该联机交易应用程序例如可以包括有主模块和子模块，且大型主机中可以配置有用于协助联机交易应用程序完成联机交易的至少一个组件。

在一实施例中，该至少一个组件例如可以包括中间件(middleware)111和数据库组件112。联机交易系统中的主模块用于完成应用程序的业务逻辑，其部署于中间件上。子模块包含有应用程序访问数据库组件的语句，该子模块配置于数据库组件上。

根据本公开的实施例，在通过该大型主机中的联机交易应用程序执行交易操作时，执行过程中可能会存在故障。

在一实施例中，若部署于中间件上的主模块的版本与部署于数据库组件上的子模块的版本不一致时，该执行过程会抛出版本不一致的故障中断。该版本不一致产生的原因可能是由于研发测试环境迭代版本多，版本部署频繁，业务测试同时不间断开展，交易量大等原因导致的运行环境上应用程序版本不一致。具体地可能存在以下几种情况：新版本应用程序的主模块的部署与子模块的部署存在短暂时间差，该时间差期间有业务交易调用；应用程序在中间件上未运行完成，新版本应用程序的主模块无法及时刷新生效；应用程序访问的数据库组件的资源未释放，新版本应用程序的子模块无法及时绑定生效；新版本应用程序的子模块关联的数据库组件的资源未部署，无法绑定成功。

在一实施例中，若在执行过程中需要调用除对应的组件外的其他组件，但该其他组件与对应的组件之间的链接不活动时，则会抛出跨区调用失败的故障中断。

相关技术中，往往由运维人员对交易操作执行过程中的故障进行人为分析及处理。例如，若该故障是由于主模块的版本与子模块的版本不一致引起的，则运维人员需要首先介入分析交易故障的类型，找到故障的应用程序名称，核对该应用程序在中间件上部署的主模块和在数据库组件中部署的子模块的版本是否匹配，找出不匹配的原因。在中间件上刷新应用程序正确的主模块或者在数据库组件中重新绑定正确的子模块，使交易能继续正常执行。对于无法修复成功的情况，则需要进一步分析未修复的原因，通知对应程序维护人员处理。该人为分析及处理过程的步骤繁多、操作复杂、时效低，且需要运维人员具备一定的主机技术水平。

为了解决该技术问题，本公开实施例的大型主机中例如还可以集成有“无侵入式拦截-日志监听-集中分析及修复”三层技术架构的故障处理架构，以完成对交易故障的采集、分析和处理。该架构独立于交易系统，通过该架构的集成设置，可以在不改造现有交易系统的前提下，即使联机交易发生故障，也能够自动拦截交易故障信息以对故障进行分析定位。

需要说明的是，本公开实施例的交易故障的处理方法一般可以由该大型主机(例如IBM大型主机)执行。相应地，本公开实施例的交易故障的处理装置一般可以设置于该大型主机中。

应该理解，图1中的大型主机、中间件和数据库组件的数目和类型仅仅是示意性的。根据实现需要，可以具有任意数目和类型的大型主机、中间件和数据库组件。

以下将结合图2～图5对本公开实施例的交易故障的处理方法进行详细描述。

图2示意性示出了根据本公开实施例的交易故障的处理方法的流程图。

如图2所示，该交易故障的处理方法可以包括操作S210～操作S230。其中，交易可以是通过应用程序与至少一个组件的交互来实现的。

在操作S210，监听至少一个组件响应于应用程序发送的消息反馈的反馈信息。

根据本公开的实施例，该反馈信息例如可以通过配置于大型主机110中至少一个组件上的交易拦截模块拦截得到。其中，该至少一个组件例如可以为前述的中间件和/或数据库组件。中间件例如可以为CICS(Customer Information Control System)。

例如，当运行在中间件上的交易应用程序访问数据库组件得到反馈信息时，该交易拦截模块可以对该反馈信息进行拦截。

在操作S220，在交易存在故障的情况下，根据反馈信息确定故障的类型及故障所针对的组件。

根据本公开的实施例，在操作S220之前例如还应包括判断交易是否存在故障的操作。

在一实施例中，具体可以通过判断反馈信息中是否包括目标字段来判断交易是否存在故障。在所述反馈信息中包括目标字段的情况下，确定交易存在故障。例如，若该反馈信息中包括表征跨区调用失败的目标字段的情况下，则确定交易存在故障。

在一实施例中，具体可以通过判断反馈信息中的目标字段的取值是否为预定值来判断交易是否存在故障。在反馈信息中目标字段的取值为预定值的情况下，确定交易存在故障。例如，若该反馈信息中包括目标字段“SQLCA.SQLCODE”，且该目标字段的取值为负值，则可以确定该交易存在故障。

根据本公开的实施例，目标字段例如可以是预先维护的表征故障的字段表中的字段。该表征故障的字段表中的字段可以是根据专家经验及实际的应用环境设定的。该字段表中例如可以设定有目标字段与故障类型的映射关系。或者，该字段表中还可以进一步设定有目标字段的取值与故障类型的映射关系。

根据本公开的实施例，该操作S220例如可以先根据反馈信息中包括的目标字段，确定故障的类型。然后根据故障的类型及反馈信息来确定故障所针对的组件。

在一实施例中，操作S220例如可以是在确定存在故障的情况下，根据目标字段，从前述维护的字段表中查找得到故障的类型。例如，若目标字段“SQLCA.SQLCODE”的取值为-805，则可以确定故障类型主模块的版本信息与子模块的版本信息不一致的类型。该实施例中，故障所针对的组件例如可以是发送该反馈信息的组件，或者执行故障所针对的交易步骤的目标组件。或者，该故障所针对的组件可以通过根据故障的类型及具体的反馈信息来确定。即确定故障所针对的组件的具体方法与故障的类型一一对应。

在一实施例中，故障的类型例如可以包括：主模块的版本信息与子模块的版本信息不一致的故障类型、跨区调用失败的故障类型等。若交易故障的类型为跨区调用失败的故障类型，该故障例如可以是由应用程序在经由多个组件中的对私中间件调用对公中间件时，因对私中间件与对公中间件之间的链接不活动，或对私中间件与对公中间件之间的链接被删除、或对公中间件停机导致的。此种情况下，该反馈信息是通过拦截对私中间件发出的信息得到的。该反馈信息中包括有执行故障所针对的交易步骤的对公中间件的名称。此种情况下，可以确定故障所针对的组件为对公中间件。

若交易故障的类型为主模块的版本信息与子模块的版本信息不一致的故障类型时，则可以通过图3描述的流程来确定故障所针对的组件，在此不再详述。

可以理解的是，上述两种故障类型时，确定故障所针对的组件的方法仅作为示例以利于理解本公开，根据实际需求，该操作S220可以通过任意的方式来确定故障的类型及故障所针对的组件。

在操作S230，根据故障的类型及故障所针对的组件，获取故障修复模型，以对故障进行修复。

根据本公开的实施例，该故障修复模型例如可以是由专家人员根据经验预先设定的。该故障修复模型例如可以与故障的类型及故障所针对的组件相对应。

根据本公开的实施例，该故障修复模型例如可以存储于大型主机中除数据库组件外的其他数据库中。且故障修复模型可以是以故障的类型及故障所针对的组件为索引的。该操作S230可以根据故障的类型及故障所针对的组件，自该数据库中查找匹配的故障修复模型。

在得到故障修复模型后，即可通过运行该故障修复模型对交易故障进行修复。

根据本公开的实施例，在故障的类型为跨区调用失败类型时，该故障修复模型例如可以包括发送激活命令的模型。通过运行该故障修复模型，可以将激活命令发送给目标组件或产生反馈信息的组件。使得目标组件或产生反馈信息的组件响应于该激活命令，激活目标组件与产生反馈信息的组件之间的链接。

根据本公开的实施例，在故障的类型为主模块的版本信息与子模块的版本信息不一致的类型时，该故障修复模型例如可以包括用于更新主模块和/或子模块的模型。通过运行该故障修复模型，可以使得中间件中配置的主模块与数据库组件中配置的子模块均为正确版本，从而使得主模块的版本信息与子模块的版本信息一致。

在一实施例中，操作S210例如可以通过部署于中间件CICS上的交易拦截模块和部署于SA(System Automation，系统自动化)组件上的监听模块的相互配合来实现。具体地，通过交易拦截模块和监听模块相互配合得到反馈信息的方法可以详见后续对图6的描述，在此不再详述。

在一实施例中，操作S220和操作S230例如可以通过部署于大型主机中的JES2(JobEntry System)组件上的故障分析及处理模块来实现。具体地，通过该故障分析及处理模块执行操作S220～操作S230的方法可以详见后续对图6的描述，在此不再赘述。

综上可知，本公开实施例的交易故障的处理方法，通过监听运行应用程序和所述组件交互过程所产生的反馈信息来提取故障特征信息，相较于传统技术中需要依赖于应用程序自身输出的错误信息分析故障的技术方案，可以避免对应用程序的侵入。因此该处理方法可以在不改造现有交易系统的前提下，当交易发生故障时，自动拦截包括故障信息的反馈信息进行分析定位，且可以对故障进行自动修复。能够达到节省人力、提高研发测试效率的有益效果。

以下结合图3，以交易故障是由于应用程序的主模块的版本与子模块的版本不一致引起的为例，对根据故障的类型及反馈信息，确定故障所针对的组件的流程进行详细描述。

图3示意性示出了根据本公开实施例的根据故障类型及反馈信息，确定故障所针对的组件的流程图。

如图3所示，在故障的类型为主模块的版本信息与子模块的版本信息不一致的类型的情况下，确定故障所针对的组件的流程可以包括操作S321～操作S323。

在操作S321，根据反馈信息，确定配置于中间件的主模块的版本信息及数据库组件中与主模块匹配的子模块的版本信息。

根据本公开的实施例，该操作S321例如可以先从反馈信息中获取与故障相关的SQLCA.SQLERRMC字段的字段内容。然后确定该SQLCA.SQLERRMC字段中CONTOKEN(consistency Token，固有标记)的值，该CONTOKEN值可以作为中间件中配置的主模块的版本信息。这是由于CONTOKEN值为应用程序编译时自动生成的一个固有唯一标识，存在于应用程序编译后的目标码实体，通过CONTOKEN值可以分辨不同的应用程序目标码实体版本。

根据本公开的实施例，该操作S321可以是先根据产生反馈信息的中间件的名称，确定与中间件对应的数据库组件。然后根据反馈信息中的应用程序名称，查找该对应的数据库组件中存储的SYSIBM.SYSPACKAGE系统表(应用程序名称与CONTOKEN值的对应关系表)，以从该系统表中查找得到数据库组件中存储的应用程序的CONTOKEN值，以该CONTOKEN值作为数据库组件中与主模块匹配的子模块的版本信息。

根据本公开的实施例，该操作S321例如可以通过后续图4描述的流程来实现，在此不再详述。

在操作S322，获取实体库中应用程序的版本信息。

在获取到主模块的版本信息和子模块的版本信息后，为了便于对故障进行修复，则需要先确定是主模块的版本未更新还是子模块的版本未更新。因此，还可以通过操作S322获取实体库中应用程序的版本信息。该实体库例如可以为大型主机中的硬盘中存储的应用程序库，该实体库中应用程序的版本信息为大型主机中安装的正确版本应用程序的版本信息。该操作S322例如可以是根据反馈信息中的应用程序名称，从该实体库中查找该应用名称所对应的应用程序的CONTOKEN值。

在操作S323，根据应用程序的版本信息、主模块的版本信息及子模块的版本信息，确定故障所针对的组件。

根据本公开的实施例，考虑到实体库中应用程序的CONTOKEN值表征应用程序的正确的版本信息。因此，该操作S323可以分别将主模块的版本信息和子模块的版本信息与该应用程序的版本信息进行比对。即将操作S321中获得的两个CONTOKEN值与操作S322中得到的CONTOKEN值进行比对。

在应用程序的版本信息与主模块的版本信息不一致的情况下，可以说明应用程序在中间件内没有正确刷新，因此确定故障所针对的组件为配置主模块的中间件。此种情况下，通过操作S230获取的故障修复模型包括重新复制修复模型，以将实体库中的应用程序重新加载至中间件。在一实施例中，将实体库中的应用程序重新加载至中间件例如可以包括：通过NEWCOPY操作将实体库中正确版本的应用程序的主模块加载到中间件的内存中。其中，NEWCOPY为IBM大型主机联机中间件CICS提供的维护类命令，其作用是重新加载运行环境实体库指定应用程序主模块目标码到中间件CICS的内存中。

在应用程序的版本信息与子模块的版本信息不一致的情况下，可以说明应用程序没有在数据库组件中正确绑定，则确定故障所针对的组件为配置子模块的数据库组件。此种情况下，通过操作S230获取的故障修复模型包括绑定修复模型，以将实体库中的应用程序重新绑定至数据库组件。在一实施例中，将实体库中的应用程序重新绑定至数据库组件例如可以包括：通过对数据库组件执行BIND操作，将实体库中正确版本的应用程序的子模块绑定到该数据库组件，使得应用程序的运行恢复正常。其中，BIND为IBM大型主机DB2数据库提供的维护类命令，其作用是重新绑定运行环境实体库指定应用程序数据库子模块到DB2数据库中。

图4示意性示出了本公开实施例的根据反馈信息确定主模块的版本信息和子模块的版本信息的流程图。

如图4所示，根据反馈信息确定主模块和子模块的版本信息的流程例如可以包括操作S4211～操作S4213。

在操作S4211，从反馈信息中提取得到主模块的版本信息及中间件的名称。

根据本公开的实施例，该反馈信息例如可以是运行于组件上的拦截模块在监听到故障时生成的故障日志。例如，该拦截模块可以对组件响应于应用程序的请求产生的信息进行分析，在确定产生的信息中包括目标字段时，确定交易存在故障。然后从产生的信息中提取SQLCA.SQLERRMC字段中的CONTOKEN值，并将该CONTOKEN值、组件名称、交易名称、应用程序等名称拼装为故障报文，并添加用于表征故障类型的信息头，格式化后得到故障日志。相应地，监听模块用于监听反馈信息的产生，即监听故障日志的产生。在监听到故障日志，且故障为版本不一致的类型时，通过分析该故障日志，可以提取得到主模块的版本信息及中间件(即产生故障日志的组件)的名称。

在操作S4212，根据中间件的名称，确定与中间件对应的数据库组件。

该实施例可以维护有中间件与数据库组件的对应关系，当应用程序需要通过中间件访问大型主机的操作系统时，访问过程所需的数据可以从对应的数据库组件中获取。在操作S4211得到中间件的名称后，即可根据中间件与数据库组件的对应关系来确定与中间件对应的数据库组件。

在操作S4213，获取与中间件对应的数据库组件中与主模块匹配的子模块的版本信息。

根据本公开的实施例，该操作S4213例如可以通过前述查找该对应的数据库组件中存储的SYSIBM.SYSPACKAGE系统表得到的CONTOKEN值作为子模块的版本信息。

根据本公开的实施例，考虑到采用修复模型修复时，存在修复失败的情况。此种情况下，为了便于后续运维人员对该故障进行修复，该实施例的交易故障的处理方法例如还可以分析修复失败的原因，并将该原因推送给运维人员。

图5示意性示出了本公开另一实施例的交易故障的处理方法的流程图。

如图5所示，该实施例的交易故障的处理方法除了操作S210～操作S230外，还可以包括操作S540～操作S560。该操作S540～操作S560在操作S230之后执行。

在操作S540，获取对故障进行修复得到的修复结果。

根据本公开的实施例，该操作S540例如可以是获取根据故障修复模型修复故障得到的修复报告。若该修复报告中有报错信息，则确定修复结果表征修复失败。若该修复报告中没有报错信息，则确定修复结果表征修复成功。

在操作S550，在修复结果表征修复失败的情况下，根据修复结果确定修复失败的因素。

根据本公开的实施例，对于主模块的版本信息与子模块的版本信息不一致的故障，修复失败的原因例如有以下几种：应用程序在中间件被交易长时间占用而没有释放，这会导致对应用程序执行NEWCOPY操作时反馈报错信息“IN USE”，以表征该中间件被占用；应用程序在数据库组件执行时间过长且执行未结束，这会导致对该应用程序执行BIND操作时反馈特定代码的报错信息，该特定代码用于表征申请锁超时；应用程序SQL涉及的表及表结构与数据库组件上定义的表及表结构不一致，导致执行BIND操作时报错，具体的报错信息在执行BIND操作时会详细输出。

因此，该操作S550例如可以是先定位修复报告中的报错信息。然后根据该报错信息确定修复失败的因素。例如，若报错信息为“IN USE”时，可以确定修复失败的原因为应用程序在中间件被交易长时间占用而没有释放。

在操作S560，向预定服务器推送表征修复失败的因素的提示信息。

在确定修复失败的因素后，为了便于运维人员对故障进行人工修复，可以将该修复失败的因素形成提示信息推送至运维人员的通讯账户，例如，可以向运维人员注册的邮箱发送邮件，或者向运维人员注册的微信发送消息等。相应地，预定服务器即为该通讯账户所对应的服务器。

例如，若修复失败的因素为应用程序在中间件被交易长时间占用而没有释放，则需要通知运维人员判断交易和应用程序是否因存在应用程序执行效率差或者死循环问题而不能正常结束。相应地，提示信息可以用于提示运维人员查看应用程序的执行效率或应用程序的运行是否存在死循环问题。若修复失败的因素为应用程序在数据库组件执行时间过长且执行未结束，需要通知运维人员查看交易和应用程序是否因数据库组件访问效率问题而不能正常结束。相应地，提示信息可以用于提示运维人员查看应用程序访问数据库组件的访问效率。若修复失败的因素为应用程序SQL涉及的表及表结构与数据库组件上定义的表及表结构不一致，则需要通知运维人员确认是否需要修改应用程序或者修改数据库组件上的表及表结构定义。相应地，提示信息可以用于提示运维人员修改应用程序或者数据库组件上的表及表结构定义。

根据本公开的实施例，对于跨区调用失败的故障类型，修复失败的原因可能是目标组件停机，或者目标组件与产生反馈信息的组件之间的链接被删除。因此需要提醒运维人员启动目标组件或者建立目标组件与产生反馈信息的组件之间的链接。相应地，提示信息用于提示运维人员启动目标组件或者建立目标组件与产生反馈信息的组件之间的链接。

综上可知，本公开实施例的交易故障的处理方法，即使在无法成功修复故障的情况下，也可以对无法修复的原因进行分析定位，并向运维人员反馈提示信息。从而使得运维人员无需分析故障即可对故障进行修复，可以有效提高故障修复效率，降低对运维人员的技术要求。

根据本公开的实施例，为了提高故障处理的灵活性，执行前述交易故障的处理方法中各个步骤的模块例如可以相互独立地配置，以此使得各模块之间采用松耦合模式，最大限度地减少对联机交易系统的消耗，使得每个模块可以根据实际交易的负载量灵活地横向扩展。

以下将结合图6～图7对本公开实施例的交易故障的处理装置进行详细描述。

图6示意性示出了本公开实施例的交易故障的处理装置的结构框图。

如图6所示，在交易故障为主模块的版本信息与子模块的版本信息不一致的故障时，该交易故障的处理装置600可以包括交易拦截模块610、日志监听模块620和故障分析及修复模块630。

在该实施例中，大型主机包括的组件例如可以包括主机CICS中间件、主机DB2数据库组件、主机SA组件和主机JES2组件。联机交易系统包括的主模块具体为配置于主机CICS中间件上的应用程序逻辑主模块，联机交易系统包括的子模块具体为配置于主机DB2数据库组件上的应用程序数据库子模块。应用程序主模块与应用程序数据库子模块通过数据库出口交互连接。该数据库出口具体可以为EXIT出口，该EXIT出口为IBM大型主机中CICS中间件提供的一种应用程序控制权转移技术接口，允许用户编写EXIT程序，以此来扩展或者客户化CICS中间件以满足应用的需求，此过程无需修改现有的应用程序。该实施例的交易故障的处理装置通过编写EXIT出口程序，可以将应用程序访问主机DB2数据库组件返回时将控制权转移到本实例的交易拦截模块，从而达到拦截效果。其中，该联机交易系统例如可以通过与前述多个组件中至少一个组件的交互来实现对交易的处理。

交易拦截模块610部署于该数据库出口与应用程序数据库子模块之间，用于拦截应用程序访问主机DB2数据库组件后的反馈信息。并对该反馈信息进行分析，根据反馈信息中目标字段SQLCA.SQLCODE的取值是否为“-805”来确定是否存在版本不一致的故障。若取值为“-805”，则确定应用程序出现了应用程序逻辑主模块和应用程序数据库子模块的版本不一致的故障，该交易拦截模块610即可从反馈信息中获取故障相关的SQLCA.SQLERRMC字段内容，提取SQLCA.SQLERRMC字段内容里面的CONTOKEN值作为该应用程序在中间件内配置的主模块的版本信息。然后将CONTOKEN值、联机中间件名称、交易名称、应用程序名称等内容拼装为故障报文，并添加“#-805”信息头用于标记该类型故障，格式化后输出到中间件日志。

日志监听模块620部署在主机SA组件上，由日志特征提取子模块621和信息发送子模块622组成。日志特征提取子模块621实时监听系统日志(包含中间件日志)，根据预设的信息头“#-805”抓取应用程序主模块和数据库子模块版本不一致故障信息；信息发送子模块622通过SOCKET方式将交易故障信息发送给故障分析及修复模块630进行集中处理，本实例的信息发送采用目前通用的SOCKET方式，具有高时效、高可靠、多并发、低消耗等特点。为了保证日志读取的实时性以及减少对主机SA组件的消耗，日志监听模块只负责监听日志和分发消息，不对故障作具体的分析处理。

故障分析及修复模块630作为一个程序独立的服务运行在主机JES2(Job EntrySystem)组件上，由信息接收子模块631、故障分析子模块632、NEWCOPY修复子模块633、BIND修复子模块634和修复失败处理子模块635组成。

信息接收子模块631对外开放监听端口，负责接收日志监听模块620发送过来的交易故障信息。

故障分析子模块632从故障信息中获取应用程序在中间件内存储的CONTOKEN值、联机中间件名称、交易名称、应用程序名称。然后通过前述图3中的流程来确定故障所针对的组件，从而分析定位得到故障产生的原因。

NEWCOPY修复子模块633用于负责修复应用程序在中间件内存中没有正确刷新的故障。其修复步骤为连接到发生故障的联机CICS中间件上，对该中间件上的应用程序主模块执行NEWCOPY操作以加载实体库中存储的主模块的正确版本，使应用程序恢复正常。

BIND修复子模块634负责修复应用程序没有在主机DB2数据库组件中正确绑定的故障。其修复步骤为连接到发生故障的主机DB2数据库组件，对该数据库组件上的应用程序数据库子模块执行BIND操作以绑定实体库中存储的子模块的正确版本，使应用程序恢复正常。

修复失败处理子模块635负责在修复失败的情况下，对修复失败的原因进行分析。例如可以通过前述图5描述的流程确定修复失败的因素，并向预定服务器推送提示信息。

综上可知，本公开实施例的交易故障的处理方法和装置例如可以适用于大型主机应用快速迭代的研发测试场景，在频繁不停机部署应用程序版本、业务测试不间断的前提下，对于特定类型的联机交易故障，能够在无人干预的情况下自动恢复，达到了节省运维成本、提高研发测试效率的效果。

图7示意性示出了本公开另一实施例的交易故障的处理装置的结构框图。

如图7所示，该实施例的交易故障的处理装置700包括监听模块710、故障确定模块720和故障修复模块730。交易通过大型主机中的应用程序与至少一个组件的交互来实现。

监听模块710用于监听至少一个组件响应于应用程序发送的消息反馈的反馈信息。该监听模块710例如可以用于执行前述图2描述的操作S210，在此不再赘述。

故障确定模块720用于在交易存在故障的情况下，根据反馈信息确定故障的类型及故障所针对的组件。该故障确定模块720例如可以用于执行前述图2描述的操作S210，在此不再赘述。其中，可以在反馈信息中包括目标字段的情况下，确定交易存在故障。或者可以在反馈信息中目标字段的取值为预定值的情况下，确定交易存在故障。

故障修复模块730用于根据故障的类型及故障所针对的组件，获取故障修复模型，以对故障进行修复。该故障修复模块730例如可以用于执行前述图2描述的操作S230，在此不再赘述。

在一实施例中，故障确定模块720例如可以通过图3描述的操作S321～操作S323来确定故障的类型及故障所针对的组件，在此不再赘述。

在一实施例中，故障确定模块720例如可以通过图4描述的操作S4211～操作S4213来确定配置于中间件的主模块的版本信息及数据库组件中与主模块匹配的子模块的版本信息，在此不再赘述。

根据本公开的实施例，交易故障的处理装置700例如还可以包括修复模块、失败因素确定模块和消息推送模块。该修复模块、失败因素确定模块和消息推送模块可以分别用于执行图5描述操作S540～操作S560，在此不再赘述。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图8示意性示出了根据本公开实施例的适于执行交易故障的处理方法的电子设备的结构框图。

如图8所示，根据本公开实施例的电子设备800包括处理器801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。处理器801例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器801还可以包括用于缓存用途的板载存储器。处理器801可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 803中，存储有电子设备800操作所需的各种程序和数据。处理器801、ROM802以及RAM 803通过总线804彼此相连。处理器801通过执行ROM 802和/或RAM 803中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 802和RAM 803以外的一个或多个存储器中。处理器801也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备800还可以包括输入/输出(I/O)接口805，输入/输出(I/O)接口805也连接至总线804。电子设备800还可以包括连接至I/O接口805的以下部件中的一项或多项：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被处理器801执行时，执行本公开实施例的电子设备中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 802和/或RAM 803和/或ROM 802和RAM 803以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (11)

1.一种交易故障的处理方法，其中，所述交易通过应用程序与至少一个组件的交互来实现，所述方法包括：

监听所述至少一个组件响应于所述应用程序发送的消息反馈的反馈信息；

在所述交易存在故障的情况下，根据所述反馈信息确定所述故障的类型及所述故障所针对的组件；以及

根据所述故障的类型及所述故障所针对的组件，获取故障修复模型，以对所述故障进行修复，所述故障修复模型包括发送激活命令的模型、更新主模块和/或子模块的模型、重新复制修复模型、绑定修复模型。

2.根据权利要求1所述的方法，还包括：

在所述反馈信息中包括目标字段的情况下，确定所述交易存在故障；或者

在所述反馈信息中目标字段的取值为预定值的情况下，确定所述交易存在故障。

3.根据权利要求1所述的方法，其中，所述根据所述反馈信息确定所述故障的类型及所述故障所针对的组件包括：

根据所述反馈信息中包括的目标字段，确定所述故障的类型；以及

根据所述故障的类型及所述反馈信息，确定所述故障所针对的组件。

4.根据权利要求3所述的方法，其中，所述至少一个组件包括中间件和数据库组件；所述应用程序包括部署于所述中间件的主模块和部署于所述数据库组件的子模块；所述故障的类型包括所述主模块的版本信息与所述子模块的版本信息不一致的类型；所述根据所述故障的类型及所述反馈信息，确定所述故障所针对的组件包括：

根据所述反馈信息，确定配置于所述中间件的主模块的版本信息及所述数据库组件中与所述主模块匹配的子模块的版本信息；

获取实体库中所述应用程序的版本信息；以及

根据所述应用程序的版本信息、所述主模块的版本信息及所述子模块的版本信息，确定所述故障所针对的组件。

5.根据权利要求4所述的方法，其中，所述根据所述反馈信息，确定配置于所述中间件的主模块的版本信息及所述数据库组件中与所述主模块匹配的子模块的版本信息包括：

从所述反馈信息中提取得到所述主模块的版本信息及所述中间件的名称；

根据所述中间件的名称，确定与所述中间件对应的数据库组件；以及

获取与所述中间件对应的数据库组件中与所述主模块匹配的子模块的版本信息。

6.根据权利要求4所述的方法，其中，所述根据所述应用程序的版本信息、所述主模块的版本信息及所述子模块的版本信息，确定所述故障所针对的组件包括：

在所述应用程序的版本信息与所述主模块的版本信息不一致的情况下，确定所述故障所针对的组件为配置所述主模块的中间件；并且/或者

在所述应用程序的版本信息与所述子模块的版本信息不一致的情况下，确定所述故障所针对的组件为配置所述子模块的数据库组件。

7.根据权利要求6所述的方法，其中：

在所述故障的类型为所述主模块的版本信息与所述子模块的版本信息不一致的类型且所述故障所针对的组件为配置所述主模块的中间件的情况下，获取的故障修复模型包括重新复制修复模型，以将所述实体库中的应用程序重新加载至所述中间件；

在所述故障的类型为所述主模块的版本信息与所述子模块的版本信息不一致的类型且所述故障所针对的组件为配置所述子模块的数据库组件的情况下，获取的故障修复模型包括绑定修复模型，以将所述实体库中的应用程序重新绑定至所述数据库组件。

8.根据权利要求1所述的方法，还包括：

获取对所述故障进行修复得到的修复结果；

在所述修复结果表征修复失败的情况下，根据所述修复结果确定修复失败的因素；以及

向预定服务器推送表征所述修复失败的因素的提示信息。

9.一种交易故障的处理装置，其中，所述交易通过应用程序与至少一个组件的交互来实现，所述装置包括：

监听模块，用于监听所述至少一个组件响应于所述应用程序发送的消息反馈的反馈信息；

故障确定模块，用于在所述交易存在故障的情况下，根据所述反馈信息确定所述故障的类型及所述故障所针对的组件；以及

故障修复模块，用于根据所述故障的类型及所述故障所针对的组件，获取故障修复模型，以对所述故障进行修复，所述故障修复模型包括发送激活命令的模型、更新主模块和/或子模块的模型、重新复制修复模型、绑定修复模型。

10.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据权利要求1～8中任一项所述的交易故障的处理方法。

11.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行根据权利要求1～8中任一项所述的交易故障的处理方法。