CN101197722A - 一种多系统错误码管理方法、装置及系统 - Google Patents

Abstract

本发明公开了一种多系统错误码管理方法、装置及系统，解决目前通过数据转换平台直接返回的错误信息混乱，带来查错困难和使用者混淆的问题。所述方法包括：接收服务系统报文并解析，如果包含错误信息，则添加到全局错误结构中；根据平台内部的错误标识判断是否有平台内部错误，如果有，则添加到全局错误结构中；然后根据预置的平台内部错误码与外部错误码的对应关系，将所述平台内部错误转换成外部错误，并添加到全局错误结构中。将所述错误信息按照服务系统错误、平台外部错误、内部错误的顺序分层次组织返回码，从而实现了将多种服务系统错误和平台错误分层次返回给客户端，客户端用户在查错时可以很容易地查找到错误的发生地，不会引起混淆。

Description

一种多系统错误码管理方法、装置及系统

技术领域

本发明涉及数据处理技术，特别是涉及一种多系统错误码管理方法及装置。

背景技术

在大型的数据处理系统中，为提高数据共享性和数据处理效率，常常设置一个数据转换平台来连接其他各服务系统，而两个服务系统之间的数据处理需要经过该数据转换平台。参照图1所示，是所述大型数据处理系统的逻辑架构图。该数据处理系统根据业务需要设置了多种服务系统11，每种服务系统11负责不同的业务处理，服务系统11之间的数据传输和业务处理通过数据转换平台12进行。数据转换平台12作为业务处理的中间环节，连接着多个服务系统11，用于从各种业务客户端13接收业务请求，并转发给相应的服务系统11处理，同时将各服务系统11返回的响应信息返回给客户端13。

在多个服务系统参与数据处理的过程中，各服务系统与数据转换平台之间的交互频繁，整个处理过程可能由于多种原因而产生各种错误信息，其中包括服务系统产生的错误和平台自身运行产生的错误。对于服务系统产生的错误，服务系统会以返回码(包含错误信息)的方式来反映服务系统的处理结果，并通过平台返回给相应的客户端。而平台在向客户端返回各种错误信息的时候，由于平台没有很好的错误管理机制，仅简单地执行转发功能，对各种错误信息不做任何处理，所以会将服务系统的返回码与自身产生的错误信息混淆在一起发送给客户端，造成返回信息混乱而冗余，引起客户端用户混淆。或者，如果部分错误信息丢失，服务系统错误就会掩盖掉平台错误，造成具体错误发生地被掩盖，给查错带来困难。

例如，在金融系统的跨系统实时交易中，受理某种业务的客户端(是指各种前置终端，如ATM、POS机、前置柜台等)向数据转换平台上送交易请求，该请求需要服务系统A和服务系统B共同处理。平台首先将请求转发到服务系统A处理，A返回处理结果，平台再将A的处理结果转发给服务系统B继续进行处理，最后把B的处理结果返回给客户端，完成交易处理过程。在此过程中，如果服务系统A和B以及平台都产生了错误信息，平台会将所有的错误信息都混淆在一起返回给客户端，这样客户端使用者就无法分清哪些错误是平台产生的，哪些错误是服务系统A产生的，哪些又是系统B产生的。或者，平台在返回错误信息时将自身产生的错误屏蔽掉，这样客户端用户就不知道有些错误是由平台引起的。

因此，上述涉及多个系统与数据交换平台交互的情况下，平台对错误信息的管理十分混乱，通过平台返回的错误码容易屏蔽掉平台错误，引起查错困难，而且混乱的信息还容易引起使用者混淆。

发明内容

本发明所要解决的技术问题是提供一种多系统错误码管理方法、装置及系统，以解决目前通过数据转换平台直接返回的错误信息混乱，带来查错困难和使用者混淆的问题。

为解决上述技术问题，根据本发明提供的具体实施例，本发明公开了以下技术方案：

一种多系统错误码管理方法，应用于数据转换平台与多个服务系统的交互，包括：

平台接收服务系统报文并解析，如果包含错误信息，则添加到全局错误结构中；

根据平台内部的错误标识，判断是否有平台内部错误，如果有，则添加到所述全局错误结构中；然后根据预置的平台内部错误码与外部错误码的对应关系，将所述平台内部错误转换成外部错误，并添加到所述全局错误结构中；

将所述全局错误结构中的错误信息组成报文发送给客户端。

其中，将服务系统错误和平台内部错误添加到全局错误结构之前，还包括：分别将服务系统错误和平台内部错误转换成统一的错误格式，然后再添加到全局错误结构中。

其中，将错误信息组成报文之前还包括：根据不同客户端对报文结构的定义不同，将全局错误结构中的错误信息映射到相应客户端定义的报文结构中。

优选的，所述报文按照服务系统错误、平台外部错误、内部错误的顺序组包。

所述方法还包括：采用JDK异常嵌套机制，根据不同服务系统与平台的交互顺序分层返回错误信息。

一种多系统错误码管理装置，设置于数据转换平台上，包括：

服务系统错误处理单元，用于接收服务系统报文并解析，如果包含错误信息，则添加到全局错误结构中；

平台错误处理单元，用于根据平台内部的错误标识，判断是否有平台内部错误，如果有，则添加到所述全局错误结构中；然后根据预置的平台内部错误码与外部错误码的对应关系，将所述平台内部错误转换成外部错误，并添加到所述全局错误结构中；

错误码返回单元，用于将所述全局错误结构中的所有错误信息组成报文发送给客户端。

优选的，所述装置还包括：格式转换单元，用于根据所述服务系统错误处理单元和平台错误处理单元的调用，分别将服务系统错误和平台内部错误转换成统一的错误格式，然后再添加到全局错误结构中。

其中，所述错误码返回单元先根据不同客户端对报文结构的定义不同，将全局错误结构中的错误信息映射到相应客户端定义的报文结构中，然后再组成报文发送。

其中，所述错误码返回单元按照服务系统错误、平台外部错误、内部错误的顺序返回错误信息。

其中，所述错误码返回单元采用JDK异常嵌套机制，根据不同服务系统与平台的交互顺序分层返回错误信息。

一种错误码管理系统，包括数据转换平台和多个服务系统，以及与数据转换平台交互的客户端，其中，所述数据转换平台包括：

服务系统错误处理单元，用于接收服务系统报文并解析，如果包含错误信息，则添加到全局错误结构中；

平台错误处理单元，用于根据平台内部的错误标识，判断是否有平台内部错误，如果有，则添加到所述全局错误结构中；然后根据预置的平台内部错误码与外部错误码的对应关系，将所述平台内部错误转换成外部错误，并添加到所述全局错误结构中；

错误码返回单元，用于将所述全局错误结构中的所有错误信息组成报文发送给客户端。

其中，所述数据转换平台还包括：格式转换单元，用于根据所述服务系统错误处理单元和平台错误处理单元的调用，分别将服务系统错误和平台内部错误转换成统一的错误格式，然后再添加到全局错误结构中。

其中，所述错误码返回单元按照服务系统错误、平台外部错误、内部错误的顺序返回错误信息。

根据本发明提供的具体实施例，本发明公开了以下技术效果：

本发明实施例提供了一种多系统错误码管理机制，采用分层机制组织错误返回码，通过将各种错误信息分类处理，分别将服务系统错误、平台内部错误和外部错误添加到全局错误结构中，然后将全局错误结构中的错误信息按照服务系统错误、平台外部错误、内部错误的顺序分层次组织返回码，从而实现了将多种服务系统错误和平台错误分层次返回给客户端。由于返回的错误码中明确标识了错误来源、错误原因等详细信息，客户端用户在查错时可以很容易地查找到错误的发生地，不会引起混淆。

而且，针对各服务系统返回的错误码格式不同的问题，平台还对服务系统错误按照统一格式进行转换，然后和自身的错误码分层组织在一起返回给不同的客户端。如果服务系统和平台同时发生错误，由于客户端用户更多关注的是业务层面的错误信息，所以优先将服务系统错误返回。

附图说明

图1是现有技术中大型数据处理系统的逻辑架构图；

图2是本发明实施例所述多系统错误码管理方法流程图；

图3是本发明实施例所述多系统错误码管理装置结构框图；

图4是本发明实施例所述错误码管理系统结构图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

针对多服务系统环境下，数据转换平台向客户端返回的错误码混乱的问题，本发明实施例为平台提供了一种错误码管理机制，采用分层机制组织错误返回码，通过将各种错误信息分类处理，分别将服务系统错误、平台内部错误和外部错误添加到全局错误结构中，然后将全局错误结构中的错误信息按照服务系统错误、平台外部错误、内部错误的顺序分层次组织返回码，从而实现了将多种服务系统错误和平台错误分层次返回给客户端。下面将以金融领域的交易处理为例进行说明。

本实施例中，首先将错误信息进行分类，分为服务系统错误、平台内部错误和外部错误。其中，下文将服务系统错误统称为应用错误，因为服务系统负责业务处理，反映的是业务层面的错误，例如“金额”字段虽然在技术上没有错误，但可能不满足业务上的要求而出错。而平台负责数据转换，不涉及业务处理，反映的是技术层面上的错误。平台错误又分为内部错误和外部错误，平台内部错误是用于平台自身的错误描述方式，而外部错误是返回给各种客户端的错误描述方式，便于用户理解。这两种错误的描述方式和表示格式不同，需要进行转换，它们的对照关系在错误码配置中描述。

参照图2，是所述多系统错误码管理方法流程图。

步骤201，平台接收各服务系统返回的相应报文。

在服务系统执行交易处理的过程中，如果发生错误，则将错误信息以报文形式返回给数据转换平台。其中，所述错误信息记录了错误类型、错误码、错误描述、错误现场信息等，所述错误现场信息是对错误描述的补充，用于描述错误发生的上下文，帮助通过日志排错。例如，某个的某个交易拆包出错，那么“拆包出错”属于错误描述，而“客户端”和“交易”属于错误现场信息。

步骤202，平台收到服务系统返回的报文后，进行服务系统报文拆包处理，从而进行报文解析。

步骤203，根据报文中的错误标识判断报文中是否包含应用错误。

通常，服务系统处理如果有错误，会在返回报文中进行标识，平台通过该标识可以判断是否有错误。如果有，则执行步骤204；如果没有，则服务系统在交易处理过程中没有出错，转到步骤205。

步骤204，如果有应用错误，则将应用错误添加到全局错误结构中。

从服务系统的返回报文中提取的错误信息，包括错误类型、错误码、错误描述等，将这些信息添加到全局错误结构中。所述全局错误结构用于保存各种错误信息，包括服务系统产生的应用错误、平台产生的内部错误和外部错误。

优选的，将应用错误添加到全局错误结构中之前，先将应用错误转换成统一的错误格式，然后再添加到全局错误结构中。由于与平台相连的每个服务系统都有其自身的信息处理方式和错误处理方式，所以这些系统返回的反映系统处理结果的错误码都具有不同的数据格式。平台为了便于内部数据管理，需要按照内部统一的数据格式将服务系统错误进行转换，然后再添加到全局错误结构中。

步骤205，根据服务系统报文进行相应的服务处理。

由于平台是一个中间系统，对于业务处理的实现最终是由不同的服务系统实现的。平台服务处理的主要功能是实现对不同服务系统的服务调用，并通过映射和服务组合的方式对客户端提供新的服务，同时负责对不同服务系统调用时产生的数据进行一致性处理。

例如：服务系统中的各个业务处理功能(如卡折开户、存款、取款、客户收益查询等)在平台中都会发布成一个或一组相对应的服务。服务处理就是调用这些发布的服务来实现对不同服务系统的服务调用。

同时，服务处理模块还要保证处理的数据一致性。例如：客户将一笔资金从帐户A转到帐户B，平台会先调用取款服务从帐户A扣除资金，再调用存款服务将资金存入帐户B。如果取款服务成功，而存款服务由于网络原因被中断，造成数据的不一致性，那么服务处理模块将会自动对取款服务进行冲正，也就是撤销对帐户A的服务处理，来保证数据的一致性。

步骤206，服务处理完成后，继续判断是否有平台内部错误。

在平台与服务系统的整个数据转换与处理过程中，服务系统和平台都有可能产生错误信息，因此在判断完服务系统数是否有应用错误后，还需要判断平台内部是否发生错误。判断时，根据平台自身的错误标识判断是否有错误，如果有，则继续步骤207；如果没有，则平台未发生错误，转到步骤210。

本发明对应用错误和平台内部错误的判断顺序不做限定，上述步骤仅作为实施例进行说明，根据不同的业务应用可作调整。

步骤207，如果平台产生错误，则将平台内部错误添加到全局错误结构。

从平台自身的数居处理信息中提取的错误信息，包括错误类型、错误码、错误描述等，将这些信息也添加到全局错误结构中。同样，优选的，内部错误信息也先转换成统一的数据格式，然后再向全局错误结构添加。

优选步骤208，根据平台内部错误码生成外部错误码。

本步骤是本实施例的优选步骤，由于内部错误是用于平台内部的错误描述方式，对于ATM、POS、柜面等前置终端用户是无法识别的，因此需要转换成平台外部人员能够识别理解的描述方式，即外部错误。平台内部错误和外部错误的对应关系预先在错误码配置中进行描述，因而，可根据错误码配置将内部错误码生成外部错误码。

步骤209，将外部错误也添加到全局错误结构中。

此时，如果服务系统和平台都发生了错误，则所述全局错误结构中保存了应用错误、平台内部错误和外部错误的描述。将全局错误结构中的各种错误描述通知相应客户端即可完成错误处理，而后续步骤是作为实施例的详细说明。

步骤210，将全局错误结构添加到统一数据区。

所述统一数据区是本实施例中用于存放各种数据处理结果的区域，包括数据处理过程中产生的各种错误信息、业务数据、系统控制数据等各类数据，根据用户的不同设置，这些数据都可以返回给客户端供用户查询。

步骤211，将所述统一数据区中的错误信息按照不同客户端定义的报文结构进行映射转换。

在实际业务中，不同客户端要求返回的报文结构是不同的，包括数据格式和报文字段定义的不同，例如ATM机是一种报文格式，前置柜台又是另一种报文结构。因此，针对不同的客户端，需要将返回的错误信息映射到相应的报文结构中。

步骤212，组错误包返回。

将错误信息进行报文映射转换后，组成报文包返回给相应的客户端。优选的，本实施例按照应用错误、平台外部错误、内部错误的顺序组织报文，因为当服务系统和平台同时发生错误时，由于客户端用户更多关注的是业务层面的错误，所以优先将服务系统产生的应用错误返回，而平台外部错误比内部错误对用户更易于理解，所以其次返回外部错误。这种多层次的错误码返回形式，为用户查错提供了很大地便利性。

上述平台错误码管理机制与平台不做任何处理、直接进行信息转发的处理方式相比，由于采用分层机制组织错误返回码，实现了将多种服务系统错误和平台错误分层次返回给客户端，客户端用户在查错时可以很容易地查找到错误的发生地，不会引起混淆，也不会掩盖任何一种错误。而且，对不同格式的服务系统返回码进行了统一，便于平台内部对各种错误数据的管理。

上述服务系统应用错误、平台外部错误、内部错误的分层方式是按照错误来源进行的分层处理，本实施例中，对错误码分层机制可以从多个角度进行理解。例如，当同一交易处理过程中需要调用多个服务系统进行处理时，如果有多个系统发生错误，则按照服务系统与平台的交互顺序顺次返回错误码。

举例说明，某跨两个系统的实时交易，该交易从客户端C送上交易请求，平台处理后发送给服务系统A，A做完业务处理后给平台返回响应信息，平台从响应信息中提取返回码(错误码)。然后，再把该交易发送给服务系统B做处理，同样平台也从其返回信息中提取返回码(错误码)。最后，平台根据外系统的处理情况和本系统的处理情况，按照分层机制组织返回码(错误码)返回给客户端C。

在技术实现上，本发明实施例采用的分层机制基于JDK异常嵌套机制，JDK是Java Development Kit的简称，JDK是整个Java的核心，是一切java应用程序的基础，所有的java应用程序都是构建在JDK之上的。

JDK的异常处理是Java中唯一正式的错误报告机制。Java中的异常对象包含异常类型和异常信息，在捕获一个异常之后，可以进行以下处理：

(1)处理该异常而不抛出；

(2)不处理而抛出原异常；

(3)包装成新异常后再次抛出。

包装异常是指将原始异常设置为新异常的“诱饵”，这种包装技术允许用户抛出系统中的高级异常，而不丢失原始异常的细节信息。对于抛出异常的情况，JDK采用异常链的方式处理，也就是在异常链表中逐次添加异常，这样所有抛出的异常就形成一个异常链。

针对上述错误码管理机制，本发明还提供了相应的处理装置实施例。参照图3，是所述多系统错误码管理装置结构框图。所述装置设置在数据转化平台上，用于对服务系统和平台自身产生的错误信息进行处理转换，然后再分层返回给不同的客户端。所述装置主要包括服务系统错误处理单元301、平台错误处理单元302和错误码返回单元303。

其中，所述服务系统错误处理单元301主要用于解析服务系统报文，并根据报文中的错误标识判断报文中是否包含应用错误，如果包含，则提取错误信息并添加到全局错误结构中。

所述平台错误处理单元302用于根据平台内部的错误标识，判断是否有平台内部错误，如果有，则从平台自身的数据处理信息中并添加到所述全局错误结构中；然后根据预置的平台内部错误码与外部错误码的对应关系，将所述平台内部错误转换成外部错误，并添加到所述全局错误结构中。

所述错误码返回单元303用于将所述应用错误、平台内部错误和外部错误组成报文，返回给相应的客户端。优选的，由于不同客户端定义的报文结构不同，所以错误码返回单元303需要先将各种错误信息映射到相应客户端定义的报文结构中，并按照服务系统错误、平台外部错误、内部错误的顺序组成报文返回。而且，由于采用JDK异常嵌套机制，多个服务系统的错误码返回是根据不同服务系统与平台的交互顺序分层返回。

优选的，所述装置还包括格式转换单元304，用于根据所述服务系统错误处理单元301和平台错误处理单元302的调用，分别将服务系统错误和平台内部错误转换成统一的错误格式，然后再添加到全局错误结构中。这样，平台就便于对各种错误数据进行统一管理。

基于上述错误码管理装置，本发明还提供了一种错误码管理系统。参照图4，是本发明实施例所述错误码管理系统结构图。所述系统包括数据转换平台41，与该平台41相连的多个服务系统42，以及与平台交互的不同客户端43。客户端43发起的请求经由数据转换平台41转发给相应的服务系统42处理，服务系统42产生的返回码(包括错误码)也经由数据转换平台41处理后，转发给相应客户端43。其中，多个服务系统42之间的数据交互过程也需通过数据转换平台41处理转发。

所述数据转换平台41包括服务系统错误处理单元411、平台错误处理单元412、错误码返回单元413，以及优选设置格式转换单元414，这几个单元实现的功能可参考上述图3说明，在此不再详述。

所述错误码管理系统中，由于数据转换平台41对服务系统42和平台41内部产生的各种错误信息进行了处理转换，并进行分层处理，所以返回给客户端43的错误码能够分层显示不同的错误信息，为客户端用户的查错提供了极大地方便。

图3、图4所示装置、系统中未详述的部分可以参见图2所示方法的相关部分，为了篇幅考虑，在此不再详述。

以上对本发明所提供的一种多系统错误码管理方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。

Claims (13)

1.一种多系统错误码管理方法，应用于数据转换平台与多个服务系统的交互，其特征在于，包括：

平台接收服务系统报文并解析，如果包含错误信息，则添加到全局错误结构中；

根据平台内部的错误标识，判断是否有平台内部错误，如果有，则添加到所述全局错误结构中；然后根据预置的平台内部错误码与外部错误码的对应关系，将所述平台内部错误转换成外部错误，并添加到所述全局错误结构中；

将所述全局错误结构中的错误信息组成报文发送给客户端。

2.根据权利要求1所述的方法，其特征在于，将服务系统错误和平台内部错误添加到全局错误结构之前，还包括：分别将服务系统错误和平台内部错误转换成统一的错误格式，然后再添加到全局错误结构中。

3.根据权利要求1所述的方法，其特征在于，将错误信息组成报文之前还包括：根据不同客户端对报文结构的定义不同，将全局错误结构中的错误信息映射到相应客户端定义的报文结构中。

4.根据权利要求1所述的方法，其特征在于：所述报文按照服务系统错误、平台外部错误、内部错误的顺序组包。

5.根据权利要求1所述的方法，其特征在于，还包括：采用JDK异常嵌套机制，根据不同服务系统与平台的交互顺序分层返回错误信息。

6.一种多系统错误码管理装置，设置于数据转换平台上，其特征在于，包括：

服务系统错误处理单元，用于接收服务系统报文并解析，如果包含错误信息，则添加到全局错误结构中；

平台错误处理单元，用于根据平台内部的错误标识，判断是否有平台内部错误，如果有，则添加到所述全局错误结构中；然后根据预置的平台内部错误码与外部错误码的对应关系，将所述平台内部错误转换成外部错误，并添加到所述全局错误结构中；

错误码返回单元，用于将所述全局错误结构中的所有错误信息组成报文发送给客户端。

7.根据权利要求6所述的装置，其特征在于，还包括：格式转换单元，用于根据所述服务系统错误处理单元和平台错误处理单元的调用，分别将服务系统错误和平台内部错误转换成统一的错误格式，然后再添加到全局错误结构中。

8.根据权利要求6所述的装置，其特征在于：所述错误码返回单元先根据不同客户端对报文结构的定义不同，将全局错误结构中的错误信息映射到相应客户端定义的报文结构中，然后再组成报文发送。

9.根据权利要求6所述的装置，其特征在于：所述错误码返回单元按照服务系统错误、平台外部错误、内部错误的顺序返回错误信息。

10.根据权利要求6所述的装置，其特征在于：所述错误码返回单元采用JDK异常嵌套机制，根据不同服务系统与平台的交互顺序分层返回错误信息。

11.一种错误码管理系统，包括数据转换平台和多个服务系统，以及与数据转换平台交互的客户端，其特征在于，所述数据转换平台包括：

服务系统错误处理单元，用于接收服务系统报文并解析，如果包含错误信息，则添加到全局错误结构中；

平台错误处理单元，用于根据平台内部的错误标识，判断是否有平台内部错误，如果有，则添加到所述全局错误结构中；然后根据预置的平台内部错误码与外部错误码的对应关系，将所述平台内部错误转换成外部错误，并添加到所述全局错误结构中；

错误码返回单元，用于将所述全局错误结构中的所有错误信息组成报文发送给客户端。

12.根据权利要求11所述的系统，其特征在于，所述数据转换平台还包括：格式转换单元，用于根据所述服务系统错误处理单元和平台错误处理单元的调用，分别将服务系统错误和平台内部错误转换成统一的错误格式，然后再添加到全局错误结构中。

13.根据权利要求11所述的系统，其特征在于：所述错误码返回单元按照服务系统错误、平台外部错误、内部错误的顺序返回错误信息。

Images