CN103995906A - 一种异常处理方法和装置 - Google Patents

Abstract

本发明实施方式提出一种异常处理方法和装置。方法包括：获取包含异常类型和异常参数的异常数据；解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数；输出所述处理后的异常参数。本发明实施方式实现了自动化异常处理方式，降低了人工参与程度，提升了异常处理效率，可以提升用户体验。

Description

一种异常处理方法和装置

技术领域

本发明属于互联网数据处理技术领域，特别是一种异常处理方法和装置。

背景技术

随着计算机技术和网络技术的飞速发展，互联网(Internet)技术在人们的日常生活、学习和工作中发挥的作用也越来越大。而且，随着移动互联网的发展，互联网也在向移动化发展。在当今的信息时代中，各种信息设备应运而生：有用于话音传输的固定电话、移动终端；有用于信息资源共享、处理的服务器和个人电脑；有用于视频数据显示的各种电视机等等。这些设备都是在特定领域内为解决实际需求而产生的。随着电子消费、计算机、通信(3C)融合的到来，人们越来越多地将注意力放到了对各个不同领域的信息设备进行综合利用的研究上，以充分利用现有资源设备来为人们更好的服务。

随着互联网的不断发展以及各种业务需求的日益更新，各个互联网应用系统之间的交互时效性要求也不断增加。目前，各种互联网应用系统的交互异常都是基于人工处理的。由于系统交互数据过于复杂，现有技术中一般通过数据库查询的方式将异常数据展示到页面供人工处理。

比如，互联网电子商务就是一种典型的互联网应用。互联网电子商务是指在因特网开放的网络环境下，买卖双方在任何可联接网络的地点间进行各种交互活动。电子商务通过在交易中通过运用互联网技术，提升买卖双方交易的效率，降低买卖双方的交易成本，从而提升资源配置效率。在关于电子商务的各种前后台互联网应用系统中，经常出现交互异常。目前通过数据库查询的方式确定异常数据，并且将异常数据展示到页面供人工处理。

然而，在现有技术方案下，由于人工因素无法固定预知，一旦出现大批量异常数据则会导致处理时效降低，从而影响互联网业务的正常流转。

发明内容

本发明实施方式提出一种异常处理方法，以提高异常处理的时效性。

本发明实施方式提出一种异常处理装置，以提高异常处理的时效性。

本发明实施方式的技术方案如下：

一种异常处理方法，该方法包括：

获取包含异常类型和异常参数的异常数据；

解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数；

输出所述处理后的异常参数。

所述获取包含异常类型和异常参数的异常数据包括：

调用Web Service接口以直接从异常数据源获取所述包含异常类型和异常参数的异常数据。

所述获取包含异常类型和异常参数的异常数据包括：

异常数据源将所述包含异常类型和异常参数的异常数据发送到消息队列消息体；

调用所述消息队列消息体以获取所述包含异常类型和异常参数的异常数据。

所述加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数包括：

将所述规则类文件加载到内存中，解析出异常参数处理逻辑，并生成规则包执行上下文；

将所述异常参数传递到所述规则包执行上下文中，并针对所述异常参数执行所述异常参数处理逻辑。

所述输出所述处理后的异常参数包括：

将所述处理后的异常参数输出到指令数据队列，和/或向预定地址发送异常数据提醒消息。

一种异常处理装置，包括异常数据获取单元、异常数据处理单元和输出单元，其中：

异常数据获取单元，用于获取包含异常类型和异常参数的异常数据；

异常数据处理单元，用于解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数；

输出单元，用于输出所述处理后的异常参数。

异常数据获取单元，用于调用Web Service接口以直接从异常数据源获取所述包含异常类型和异常参数的异常数据。

异常数据获取单元，用于使能异常数据源将所述包含异常类型和异常参数的异常数据发送到消息队列消息体；并调用所述消息队列消息体以获取所述包含异常类型和异常参数的异常数据。

异常数据处理单元，用于将所述规则类文件加载到内存中，解析出异常参数处理逻辑，并生成规则包执行上下文；将所述异常参数传递到所述规则包执行上下文中，并针对所述异常参数执行所述异常参数处理逻辑。

输出单元，用于将所述处理后的异常参数输出到指令数据队列，和/或向预定地址发送异常数据提醒消息。

从上述技术方案可以看出，本发明的实施方式中，获取包含异常类型和异常参数的异常数据；解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数；输出所述处理后的异常参数。由此可见，应用本发明实施方式之后，实现了自动化异常处理方式，从而降低了人工参与程度，提高了异常处理的时效性，并且提升了异常处理效率，整合了异常信息以及完善了系统流程，还可以提升用户体验。

附图说明

图1为根据本发明异常处理方法流程图。

图2为根据本发明的异常处理装置结构图。

图3为根据本发明实施方式的财务应用中异常处理方法流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

为了描述上的简洁和直观，下文通过描述若干代表性的实施方式来对本发明的方案进行阐述。实施方式中大量的细节仅用于帮助理解本发明的方案。但是很明显，本发明的技术方案实现时可以不局限于这些细节。为了避免不必要地模糊了本发明的方案，一些实施方式没有进行细致地描述，而是仅给出了框架。下文中，“包括”是指“包括但不限于”，“根据……”是指“至少根据……，但不限于仅根据……”。由于汉语的语言习惯，下文中没有特别指出一个成分的数量时，意味着该成分可以是一个也可以是多个，或可理解为至少一个。

鉴于现有技术中人工因素参与过多所导致的出现大批量异常数据时处理时效低等缺陷，本发明实施方式通过自动化异常处理方式，降低人工参与程度，提高异常处理的时效性，提升异常处理效率，整合异常信息从而完善系统流程，并提升用户体验。

图1为根据本发明异常处理方法流程图。

如图1所示，该方法包括：

步骤101：获取包含异常类型和异常参数的异常数据。

步骤102：解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数。

步骤103：输出所述处理后的异常参数。

在一个实施方式中，步骤101中的获取包含异常类型和异常参数的异常数据包括：

调用Web Service接口以直接从异常数据源获取所述包含异常类型和异常参数的异常数据。Web Service技术使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件，即可相互交换数据或集成。依据Web Service规范实施的应用之间，无论它们所使用的语言、平台或内部协议是什么，都可以相互交换数据。因此，通过调用Web Service接口，可以为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制，从而便于获取各个组织之间的异常数据。

Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web Service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。目前这些协议主要有：

XML和XSD：可扩展的标记语言(标准通用标记语言下的一个子集)是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既与平台无关，又与厂商无关。XML是由万维网协会(W3C)创建，W3C制定的XML SchemaXSD定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web Service平台用XSD作为数据类型系统。当用某种语言如VB.NET或C#来构造一个Web Service时，为了符合Web Service标准，所有使用的数据类型都必须被转换为XSD类型。

SOAP：即简单对象访问协议(Simple Object Access Protocol)，它是用于交换XML(标准通用标记语言下的一个子集)编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如，你可以使用SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。在传输层之间的头是不同的，但XML有效负载保持相同。Web Service希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。

WSDL：即Web Service描述语言，就是用机器能阅读的方式提供的一个正式描述文档而基于XML(标准通用标记语言下的一个子集)的语言，用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。

UDDI：目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。

调用RPC与消息传递：Web Service本身其实是在实现应用程序间的通信。现在有两种应用程序通信的方法：RPC远程过程调用和消息传递。使用RPC的时候，用户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而用户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，用户端也就根本不需要知道对象是在哪台机器上。

以上详细罗列了本发明的Web Service的示范性实例，本领域技术人员可以意识到，这种罗列仅是阐述性的，并不用于对本发明实施方式的保护范围进行限定。

在一个实施方式中，步骤101中的获取包含异常类型和异常参数的异常数据包括：

异常数据源将所述包含异常类型和异常参数的异常数据发送到消息队列消息体；

调用所述消息队列消息体以获取所述包含异常类型和异常参数的异常数据。

消息队列是在消息的传输过程中保存消息的容器。消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。

目前主要有两种类型的消息队列：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。考虑到程序的可移植性，新开发的应用程序应尽量使用POSIX消息队列。系统V消息队列是随内核持续的，只有在内核重起或者显式删除一个消息队列时，该消息队列才会真正被删除。因此系统中记录消息队列的数据结构(struct ipc_ids msg_ids)位于内核中，系统中的所有消息队列都可以在结构msg_ids中找到访问入口。消息队列就是一个消息的链表。每个消息队列都有一个队列头，用结构struct msg_queue来描述。队列头中包含了该消息队列的大量信息，包括消息队列键值、用户ID、组ID、消息队列中消息数目等等，甚至记录了最近对消息队列读写进程的ID。读者可以访问这些信息，也可以设置其中的某些信息。

以上详细罗列了本发明的消息队列的示范性实例，本领域技术人员可以意识到，这种罗列仅是阐述性的，并不用于对本发明实施方式的保护范围进行限定。

在本发明实施方式中，异常数据包含异常类型和异常参数。异常类型用于标示异常数据的类型，异常类型可以由异常数据源标示。异常参数是异常过程相关的具体实例。示范性地，在电子商务领域，异常参数具体可以包括异常单号、创建时间、异常处理流程编号等。

在一个实施方式中，步骤102中的加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数包括：

将所述规则类文件加载到内存中，解析出异常参数处理逻辑，并生成规则包执行上下文；将所述异常参数传递到所述规则包执行上下文中，并针对所述异常参数执行所述异常参数处理逻辑。

比如，解析异常数据以获取异常类型和所述异常参数，并根据异常类型取得对应的规则类文件(class)，规则类文件包含有异常参数处理逻辑。然后，将规则类加载到内存中以生成规则包执行上下文。同时将异常参数传递到规则包执行上下文中，然后开始执行规则包中的异常参数处理逻辑。执行完毕后，再将规则包执行上下文中的数据(即处理后的异常参数)，传回给调用规则包的应用程序。整个执行过程简单高效，从而最大限度的保证了异常处理逻辑的稳定性及性能。

再比如，可以在规则引擎中预先存储包含预设的规则数据配置文件和异常处理规则数据表。规则数据配置文件用来存放对应于各种异常类型的规则类文件；异常处理规则数据表用来记录异常处理类型等基础信息以及规则类文件与异常类型的对应关系。当解析异常数据以获取异常类型和异常参数之后，根据异常类型查询异常处理规则数据表以确定对应于异常类型的规则类文件名，然后再从规则数据配置文件中获取所确定的规则类文件。

在一个实施方式中，步骤103中的输出所述处理后的异常参数包括：

将所述处理后的异常参数输出到指令数据队列，和/或向预定地址发送异常数据提醒消息。

应用本发明实施方式之后，可以在规则数据配置文件中动态灵活配置各个规则类文件，从而可以动态适配生产活动中频繁变化的异常处理规则，同时还大大降低了代码的维护成本，规则配置过程也很简单，只需在规则引擎的配置页面配置规则名称，规则条件即可完成新业务的规则配置。

另外，规则引擎可以实现对规则全方位多角度的控制，如反复开启规则，监控某一规则的应用时间，应用频率等数据。还有，当现有配置无法完成某一规则时可以进行相应新规则的建议。本发明实施方式中，针对系统使用者只需要简单的输入一些基础数据、并通过鼠标拖拽即可完成规则的建立。

基于上述详细分析，本发明实施方式还提出了一种异常处理装置。

图2为根据本发明异常处理装置结构图。

如图2所示，该装置包括异常数据获取单元201、异常数据处理单元202和输出单元203，其中：

异常数据获取单元201，用于获取包含异常类型和异常参数的异常数据；

异常数据处理单元202，用于解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数；

输出单元203，用于输出所述处理后的异常参数。

输出单元203用于将异常数据处理单元202处理的数据异常参数在UI界面中展示出来，可以用于监控某些业务出现的异常是否可以避免。

在一个实施方式中：

异常数据获取单元201，用于调用Web Service接口以直接从异常数据源获取所述包含异常类型和异常参数的异常数据。

在一个实施方式中：

异常数据获取单元201，用于使能异常数据源将所述包含异常类型和异常参数的异常数据发送到消息队列消息体；并调用所述消息队列消息体以获取所述包含异常类型和异常参数的异常数据。

在一个实施方式中：

异常数据处理单元202，用于将所述规则类文件加载到内存中，解析出异常参数处理逻辑，并生成规则包执行上下文；将所述异常参数传递到所述规则包执行上下文中，并针对所述异常参数执行所述异常参数处理逻辑。

在一个实施方式中：

输出单元203，用于将所述处理后的异常参数输出到指令数据队列，和/或向预定地址发送异常数据提醒消息。

可以将本发明实施方式应用到多种基于互联网的应用场景中。比如，可以应用到财务应用中。

图3为根据本发明实施方式的财务应用中异常处理方法流程图。

如图3所示，该方法包括：

步骤301：获取从售后子系统到财务子系统的计费异常数据。

比如，在正常情况下，售后子系统会向财务子系统定期发送计费数据。当异常情况(比如，售后子系统与财务子系统之间的接口失灵)时，售后子系统无法向财务子系统发送计费数据。此时，售后子系统生成计费异常数据，该计费异常数据包括异常参数(即为售后子系统应该向财务子系统发出的计费数据)以及异常类型(即指出当前的异常为售后子系统无法向财务子系统发送计费数据)。异常数据获取单元通过消息队列或Web Service等方式从售后子系统获取计费异常数据。

步骤302：解析计费异常数据以获取异常类型，根据异常类型获取相对应的规则类文件，该规则类文件包含有指定的处理逻辑。

在这里，异常数据处理单元首先解析计费异常数据以获取异常参数和异常类型，根据异常类型获取相对应的规则类文件，该规则类文件包含有指定的处理逻辑。此处，获取的规则类文件包含有针对售后子系统无法向财务子系统发送计费数据的处理逻辑。

步骤303：执行该处理逻辑。

在这里，基于具体需求和应用环境的不同，处理逻辑可以具有多种实施方式。比如，异常数据处理单元可以尝试将异常参数(即指出当前的异常为售后子系统无法向财务子系统发送计费数据)发送到财务子系统。如果异常数据处理单元也无法将异常参数发送到财务子系统(比如尝试发送5次)，则将异常参数发送到预先指定的数据队列，并将该数据队列呈现给相应的处理人员。

步骤304：将异常参数发送到预先指定的数据队列之后，通过电子邮件/短消息/即时通讯消息等方式通知相应的处理人员。

以上以售后子系统到财务子系统的计费异常为实例对本发明实施方式进行了详细描述，本领域技术人员可以意识到，这种描述仅是示范性的，并不用于对本发明实施方式的保护范围进行限定。

实际上，可以通过多种形式来具体实施本发明实施方式所提出的异常处理方法。

比如，可以遵循一定规范的应用程序接口，将异常处理方法编写为安装到个人电脑、移动终端等中的插件程序，也可以将其封装为应用程序以供用户自行下载使用。当编写为插件程序时，可以将其实施为ocx、dll、cab等多种插件形式。也可以通过Flash插件、RealPlayer插件、MMS插件、MIDI五线谱插件、ActiveX插件等具体技术来实施本发明实施方式所提出的异常处理方法。

可以通过指令或指令集存储的储存方式将本发明实施方式所提出的异常处理方法存储在各种存储介质上。这些存储介质包括但是不局限于：软盘、光盘、DVD、硬盘、闪存、U盘、CF卡、SD卡、MMC卡、SM卡、记忆棒(Memory Stick)、xD卡等。

另外，还可以将本发明实施方式所提出的异常处理方法应用到基于闪存(Nand flash)的存储介质中，比如U盘、CF卡、SD卡、SDHC卡、MMC卡、SM卡、记忆棒、xD卡等。

综上所述，本发明的实施方式中，获取包含异常类型和异常参数的异常数据；解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数；输出所述处理后的异常参数。由此可见，应用本发明实施方式之后，实现了自动化异常处理方式，从而降低了人工参与程度，提升了异常处理效率，整合了异常信息以及完善了系统流程，并可以提升用户体验。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种异常处理方法，其特征在于，该方法包括：

获取包含异常类型和异常参数的异常数据；

解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数；

输出所述处理后的异常参数。

2.根据权利要求1所述的异常处理方法，其特征在于，所述获取包含异常类型和异常参数的异常数据包括：

调用Web Service接口以直接从异常数据源获取所述包含异常类型和异常参数的异常数据。

3.根据权利要求1所述的异常处理方法，其特征在于，所述获取包含异常类型和异常参数的异常数据包括：

异常数据源将所述包含异常类型和异常参数的异常数据发送到消息队列消息体；

调用所述消息队列消息体以获取所述包含异常类型和异常参数的异常数据。

4.根据权利要求1所述的异常处理方法，其特征在于，所述加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数包括：

将所述规则类文件加载到内存中，解析出异常参数处理逻辑，并生成规则包执行上下文；

将所述异常参数传递到所述规则包执行上下文中，并针对所述异常参数执行所述异常参数处理逻辑。

5.根据权利要求1-4中任一项所述的异常处理方法，其特征在于，所述输出所述处理后的异常参数包括：

将所述处理后的异常参数输出到指令数据队列，和/或向预定地址发送异常数据提醒消息。

6.一种异常处理装置，其特征在于，包括异常数据获取单元、异常数据处理单元和输出单元，其中：

异常数据获取单元，用于获取包含异常类型和异常参数的异常数据；

异常数据处理单元，用于解析所述异常数据以获取所述异常类型和所述异常参数，基于所述异常类型确定相对应的预先设置的规则类文件，所述规则类文件包含异常参数处理逻辑，并加载所述规则类文件以基于所述异常参数处理逻辑处理所述异常参数；

输出单元，用于输出所述处理后的异常参数。

7.根据权利要求6所述的异常处理装置，其特征在于，

异常数据获取单元，用于调用Web Service接口以直接从异常数据源获取所述包含异常类型和异常参数的异常数据。

8.根据权利要求6所述的异常处理装置，其特征在于，

异常数据获取单元，用于使能异常数据源将所述包含异常类型和异常参数的异常数据发送到消息队列消息体；并调用所述消息队列消息体以获取所述包含异常类型和异常参数的异常数据。

9.根据权利要求6所述的异常处理装置，其特征在于，

异常数据处理单元，用于将所述规则类文件加载到内存中，解析出异常参数处理逻辑，并生成规则包执行上下文；将所述异常参数传递到所述规则包执行上下文中，并针对所述异常参数执行所述异常参数处理逻辑。

10.根据权利要求6-9中任一项所述的异常处理装置，其特征在于，

输出单元，用于将所述处理后的异常参数输出到指令数据队列，和/或向预定地址发送异常数据提醒消息。