CN106022909A - 一种账户信息维护方法及装置 - Google Patents

Abstract

本发明提供一种账户信息维护方法及装置，其中，该方法包括：核心银行系统接收外围设备发起的账户信息修改请求，账户信息修改请求包括账户号和修改数据；核心银行系统根据账户号查找数据库中相应的账户信息；核心银行系统根据修改数据对账户信息中相应的数据进行修改，生成修改结果。采用本发明方法和装置进行账户维护时，外围设备一次性将需要修改的账户信息发送给核心银行系统，无需核心银行系统将相应的账户信息多次调用给外围，这样就不会将账户信息暴露在外围，从而提高账户安全；由于只是将需要修改的账户信息发送给核心银行系统的，而不需要维护的账户信息不会上传，因此不会造成信息冗余，且控制了修改范围，降低了控制工作难度。

Description

一种账户信息维护方法及装置

技术领域

本发明涉及信息维护技术领域，特别涉及一种账户信息维护方法及装置。

背景技术

核心银行系统作为账户管理的中心，需要向众多的外围设备提供各种各样的服务，其中很重要的一项就是账户信息的维护。核心银行系统的账户信息为了支撑各种业务的需求，包含了非常繁杂众多的细节信息。现有核心银行系统提供了各类信息维护交易，这些交易将账户信息分为几组，分别维护。核心银行系统的账户信息维护，由于其重要位置，采用的方式一般为一批数据采用一个维护交易。比如基本信息维护，扩展信息维护等。每个维护交易现采用的方式是使用引导交易将所关心的数据(包含有比较多的栏位)全部读取出来，返给外围设备，然后外围设备将需要修改的数据修改后，按原有格式返回核心银行系统，核心银行系统不去判定是哪个栏位修改，直接将所有数据写入数据表。采用这种方法存在如下几个问题：

(1)需要多次调用：每次修改都需要首先查询现有账户数据，实际上很多时候都是没有必要的，因为这些修改实际上是外围设备签约和设置的一部分，客户点击设置后，是不关心以前的数据的。另外，外围设备对于多次调用的处理也非常不方便，比如需要修改的信息分属于两组，需要两次引导，两次提交，中间出错后的处理都需要外围设备考虑。对于做了自动配置的外围设备，可能无法处理这种多次提交场景。另外，多次调用对于核心银行系统增加的压力和网络传输来说也是很大的，因为引导机制相当于每支维护请求都被翻了倍，而维护类交易所占比重仅次于金融类交易和查询类交易。

(2)造成信息冗余和降低安全：维护交易现行机制相当于在外围设备和网络暴露了过多不需要展示的内容。如果外围设备控制不好，可能将不需要维护的信息修改了。另外对于外围设备来说，多余信息的分拣也是一个不小的工作量。比如一个维护展示过多的利率栏位(议价利率、透支利率等)，外围设备可能出现对照错误。信息冗余也导致交易难以监控，比如某个栏位虽然包含在一个维护交易当中，但是并不是每个调用这个交易的外围设备都使用。而核心银行系统无法通过交易记录得知哪些外围设备在修改这个栏位。

(3)修改范围和控制工作难度加大：因为每个组的每个栏位的变动，都涉及使用这个组的所有外围设备，而这个情况随着数据栏位增多和外围设备数增加会越来越差，每增加一个外围设备，修改范围及其控制难度就会增加，即使只有配合测试，也会增加项目的成本。

发明内容

本发明实施例提供了一种账户信息维护方法，无需将维护信息调给外围，也无需多次调用；不会造成信息冗余和降低账户安全；减小了账户信息修改范围，降低了控制工作难度。该方法包括：

核心银行系统接收外围设备发起的账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

核心银行系统根据所述账户号查找数据库中相应的账户信息；

核心银行系统根据修改数据对账户信息中相应的数据进行修改，生成修改结果。

在一个实施例中，还包括：

对修改数据进行分析；

当修改数据满足预定修改条件时，核心银行系统根据修改数据对账户信息中相应的数据进行修改；

当修改数据不满足预定修改条件时，核心银行系统生成失败信息。

在一个实施例中，还包括：

核心银行系统向外围设备返回修改结果和/或失败信息。

在一个实施例中，所述核心银行系统接收外围设备发起的账户信息修改请求，包括：

核心银行系统接收外围设备按照预设格式发起的账户信息修改请求；

所述预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

所述账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

在一个实施例中，还包括：

核心银行系统对按照预设格式发起的账户信息修改请求进行解析，获得账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

核心银行系统根据修改场景组编号从相应的账户信息中查找相应的账户信息栏位；

所述核心银行系统根据修改数据对账户信息中相应的数据进行修改，具体包括：

核心银行系统根据相应编号的修改场景组对应的修改数据，修改数据库中查找到的相应的账户信息栏位的数据。

在一个实施例中，还包括：

核心银行系统预设修改场景组间的关系；

当同时修改多个修改场景组对应的账户信息，且多个修改场景组间为交互关系时，所述修改场景组编号为多个修改场景组编号；

当多个场景组间为排斥关系时，所述修改场景组编号为多个修改场景组编号中的其中一个。

本发明实施例提供了一种账户信息维护方法，无需将维护信息调给外围，也无需多次调用；不会造成信息冗余和降低账户安全；减小了账户信息修改范围，降低了控制工作难度。该方法包括：

外围设备向核心银行系统发起账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

外围设备接收核心银行系统返回的修改结果。

在一个实施例中，所述外围设备向核心银行系统发起账户信息修改请求，包括：

外围设备按照预设格式向核心银行系统发起的账户信息修改请求；

所述预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

所述账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

在一个实施例中，还包括：

外围设备接收核心银行系统返回的失败信息；

所述失败信息为当修改数据不满足预定修改条件时，由核心银行系统生成的信息。

在一个实施例中，还包括：

外围设备将修改结果和/或失败信息展示给用户。

本发明实施例提供了一种账户信息维护装置，无需将维护信息调给外围，也无需多次调用；不会造成信息冗余和降低账户安全；减小了账户信息修改范围，降低了控制工作难度。该装置包括：

接收模块，用于接收外围设备发起的账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

账户信息查找模块，用于根据所述账户号查找数据库中相应的账户信息；

修改模块，用于根据修改数据对账户信息中相应的数据进行修改，生成修改结果。

在一个实施例中，还包括：

分析模块，用于对修改数据进行分析；

所述修改模块具体用于：

当修改数据满足预定修改条件时，根据修改数据对账户信息中相应的数据进行修改；

当修改数据不满足预定修改条件时，生成失败信息。

在一个实施例中，还包括：

返回模块，用于向外围设备返回修改结果和/或失败信息。

在一个实施例中，所述接收模块具体用于：

接收外围设备按照预设格式发起的账户信息修改请求；

所述预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

所述账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

在一个实施例中，还包括：

解析模块，用于对按照预设格式发起的账户信息修改请求进行解析，获得账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述账户信息查找模块还用于：

根据修改场景组编号从相应的账户信息中查找相应的账户信息栏位；

所述修改模块具体用于：

根据相应编号的修改场景组对应的修改数据，修改数据库中查找到的相应的账户信息栏位的数据。

在一个实施例中，还包括：

修改场景组关系预设模块，用于预设修改场景组间的关系；

当同时修改多个修改场景组对应的账户信息，且多个修改场景组间为交互关系时，所述修改场景组编号为多个修改场景组编号；

当多个场景组间为排斥关系时，所述修改场景组编号为多个修改场景组编号中的其中一个。

本发明实施例提供了一种账户信息维护装置，无需将维护信息调给外围，也无需多次调用；不会造成信息冗余和降低账户安全；减小了账户信息修改范围，降低了控制工作难度。该装置包括：

发起模块，用于向核心银行系统发起账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

接收模块，用于接收核心银行系统返回的修改结果。

在一个实施例中，所述发起模块具体用于：

按照预设格式向核心银行系统发起的账户信息修改请求；

所述预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

所述账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

在一个实施例中，所述接收模块还用于：

接收核心银行系统返回的失败信息；

所述失败信息为当修改数据不满足预定修改条件时，由核心银行系统生成的信息。

在一个实施例中，还包括：

展示模块，用于将修改结果和/或失败信息展示给用户。

在本发明实施例中，外围设备一次性将需要修改的账户信息发送给核心银行系统，无需核心银行系统将相应的账户信息多次调用给外围设备，这样就不会将账户信息暴露在外围，从而提高账户安全；由于只是将需要修改的账户信息发送给核心银行系统的，而不需要维护的账户信息不会上传，因此不会造成信息冗余，且控制了修改范围，降低了控制工作难度。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是本发明实施例提供的一种账户信息维护方法(核心银行系统侧)流程图；

图2是本发明实施例提供的一种外围、场景修改组、接口配置关系示意图；

图3是本发明实施例提供的修改一个场景修改组的数据填写示意图；

图4是本发明实施例提供的修改多个场景修改组的数据填写示意图；

图5是本发明实施例提供的可复用的模块结构示意图；

图6是本发明实施例提供的一种账户信息维护装置(核心银行系统侧)结构示意图；

图7是本发明实施例提供的一种账户信息维护方法(外围设备侧)流程图；

图8是本发明实施例提供的一种账户信息维护装置(外围设备侧)结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

现有对账户信息进行维护时，是核心银行系统将账户对应的所有信息调用给外围设备，这样会在外围暴露账户信息，会降低账户的安全；核心银行系统将不需要修改的账户信息也调用给了外围设备，这样会造成信息冗余，还会使修改范围和控制工作难度加大；当外围设备需要修改的数据信息分属于多组，则需要核心银行系统将账户信息多次调用给外围设备。如果采用外围设备一次性将需要修改的账户信息发送给核心银行系统，不需要修改的数据不发送给核心银行系统，这样就能解决上述现有技术中存在的问题。基于此，本发明提出一种账户信息维护方法和装置。

图1是本发明实施例提供的一种账户信息维护方法(核心银行系统侧)流程图，如图1所示，该账户信息维护方法包括：

步骤101：核心银行系统接收外围设备发起的账户信息修改请求，账户信息修改请求包括账户号和修改数据；

步骤102：核心银行系统根据账户号查找数据库中相应的账户信息；

步骤103：核心银行系统根据修改数据对账户信息中相应的数据进行修改，生成修改结果。

对于现有技术中存在的问题，本发明提出了的账户信息维护方法是一种面向渠道发起的账户信息灵活维护方法，其中，渠道是指外围向核心银行系统发起交易的方式，比如，ATM、自助银行、电话银行、网上银行、手机银行等等。与之相对应的是柜台。具体的，本发明采用将账户信息进行分组来解决。分组后对于不修改某组信息的外围设备，不会调用某组信息对应的接口。由于分组数据较小且原子化，外围设备在调用时，不必查询原有数据，即可直接修改。

下面对该方法的各个步骤进行详细说明。

具体实施时，步骤101具体包括：核心银行系统接收外围设备按照预设格式发起的账户信息修改请求。

其中，预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。而修改场景组按如下方式确定：按修改场景将相关联的账户信息栏位组成一个修改场景组；此时上传的账户信息修改请求可以包括账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

具体实施时，在实际当中，很多账户信息栏位之间是没有关联的，这些没有关联的账户信息栏位可以拆分开进行分别处理，而有些账户信息栏位是强关联的，这些账户信息栏位可以一起处理。比如利率修改场景，议价利率、利率加减点、加减百分比可以放在一起处理；对于存期修改场景，起息日、存期、到期日可以一起处理。根据这一原则，我们可以按场景将相关联的账户信息栏位组成一个修改场景组。

栏位是账户信息中的一个项目，例如账户信息中的账户号、用户名、用户所属公司、用户的电话、用户的家庭地址、公司地址等等项目，都是一个栏位。记录是由许多栏位所组成的，每一笔记录可以记载一群有关联的资枓。

具体实施时，在外围设备想要修改账户信息时，不是将账户信息全部修改，而是只修改其中的一部分。根据上述对账户信息分组来说，就是说很多外围设备对账户的维护请求其实只有维护很少的栏位数据，比如审核系统只涉及账户审核是否通过，审核级别。短信签约只涉及通知标志。对于这样的外围设备，只开放这该场景修改组中的相应栏位，即可满足他们的要求。

接口(预设格式)使用栏位场景组(修改场景组)ID的组合和这些组合对应的数据栏位进行动态配置，可实现基本场景组的复用。比如有十个外围设备涉及利率组，而其中一个还要同时修改存期组，那么这个外围设备配置两个场景修改组(利率组和修改存期组)即可，其他外围设备只配置一个场景修改组(利率组)即可。利率组的接口规范都是一致的，内部使用一套修改逻辑。比如，如图2所示，外围设备1需要维护修改场景组1，此时外围设备调用接口配置组1；外围设备2需要维护修改场景组1和2，此时外围设备调用接口配置组1和接口配置组2；外围设备3需要维护修改场景组3，此时外围设备调用接口配置组3。

下面对接口(预设格式)进行定制。

(一)整体的灵活维护接口如表1所示：

表1

(二)：接口(预设格式)的填写规则

预先定义每个场景修改组的栏位数和每个栏位长度，外围设备在调用之前，就能确定每个场景修改组的长度及解析方式。结构如表2所示：

表2

下面举例说明接口(预设格式)的填写形式。

场景1：只维护第N个场景修改组(N为01-99之间的一个数字，代表第1到第99组维护信息)，此时在场景修改组编号区的第一个组号位置填写N，其余填写00，数据区填写第N个场景修改组对应的各个栏位，每个栏位按顺序填写。填写方式如图3所示。

场景2：同时维护多个场景修改组组，比如同时维护第N个场景修改组和第M个场景修改组(N和M为01-99之间的两个不重复数字，代表第1到第99组维护信息)，此时在场景修改组编号区的前两个位置，依次填写N，M，其余填写00。数据区首先填写第N个场景修改组对应的各个栏位，每个栏位按顺序填写。接下来依次填写第M个场景修改组的各个栏位。填写方式如图4所示。

具体实施时，当同时修改多个修改场景组对应的账户信息时，为了外围理解和调用安全，需要核心银行系统预先定义场景修改组之间的互斥关系。如表3所示，下表中的X表示第01组和第02组不能同时维护。

表3

	01	02	03	04
					01		X
02
					03

在本例中，当同时修改多个修改场景组对应的账户信息，且多个修改场景组间为交互关系时，修改场景组编号为多个修改场景组编号；当多个场景组间为排斥关系时，所述修改场景组编号为多个修改场景组编号中的其中一个。

具体实施时，使用现有的技术方案对账户信息进行维护时，不利于接口的扩展和外围对接口的复用。基于此，在本例中为灵活维护接口，设计了树状可复用模块结构，主要包括以下五层。最上一层为功能层，每个功能实现一个场景修改组的修改。下面一层为栏位层，每个栏位一个原子模块，被功能层所复用。第三层设计为原子逻辑层，为栏位逻辑进行处理，比如日期的公用处理等。第四层为公用功能层，对于数据修改，可能要记录流水等其他模块使用的数据，公用功能层为账户信息修改提供公共处理方面的支持。第五层设计为数据访问层，所有读取、修改的实际访问逻辑放在这一层统一处理。不管哪个组、哪个栏位修改，如果涉及账户主表，都调用账户主表的访问逻辑。当然对于同一个表的访问，可能因为方式不同，而涉及为多个访问模块。

通过可复用模块结构设计后，整体上就具备了非常强的可扩展性。比如新加场景时，可能只是在功能层增加一个模块即可，分析和测试范围也是可控的。即使对于像COBOL这样面向过程的语言，段落标示也容易得多。

考虑到接口可扩展性，模块设计必须具备在不断扩展的情况下不会恶化。为了做到这点，进行分层设置，每一层负责每一层的功能。每个模块使用层类别加顺序来标识模块。对于功能层，A+组号就是这个层的每个模块的名称。

本发明基于的是COBOL语言，模块体现为段落，每个模块使用一个独立段落来完成。功能层(组1处理模块～组4处理模块)、栏位层(栏位1处理模块～栏位5处理模块)、原子逻辑层(逻辑1处理模块～逻辑3处理模块)、公用功能层(公用功能1模块～公用功能2模块)和数据访问层(数据表1访问模块～数据表3访问模块)分别使用A、B、C、M、T来标识。这样的布局下，段落编号可以持续进行扩展，而不至于使结构恶化。整个结构如图5所示。

具体实施时，核心银行系统还设置了一个接口配置表，每个外围设备使用了哪些场景修改组，哪些场景，在接口配置表一览无余。核心银行系统也可以通过组别列表监控外围对每个场景修改组的调用情况，使核心银行系统对于数据的被使用情况会有一个清晰的衡量。

具体实施时，核心银行系统接收了外围设备按照预设格式发起的账户信息修改请求，然后核心银行系统会对按照预设格式发起的账户信息修改请求进行解析，获得账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；然后核心银行系统在根据账户号查找到数据库中相应的账户信息的基础上，再根据修改场景组编号从相应的账户信息中查找到相应的账户信息栏位；最后核心银行系统会根据相应编号的修改场景组对应的修改数据，修改数据库中查找到的相应的账户信息栏位的数据。

具体实施时，用户要求修改的数据相对应的账户信息中的栏位数据不一定是可以修改的，因此，核心银行系统在接收到修改数据后还会对其进行分析，判断这些修改数据所对应的栏位是否能够被修改。首先预定修改条件：相对应的栏位数据可以被修改；当修改数据满足预定修改条件时，核心银行系统根据修改数据对账户信息中相应的栏位数据进行修改；当修改数据不满足预定修改条件时，核心银行系统生成失败信息。

当全部修改数据相对应的栏位数据都可以被修改时，核心银行系统会将生成的修改结果返回给外围设备，然后外围设备展示给用户查看；当只有一部分修改数据相对应的栏位数据可以被修改时，根据另一部分不能被修改的修改数据，核心银行系统会生成失败信息，此时，核心银行系统会将生成的修改结果和失败信息返回给外围设备，然后外围设备展示给用户查看；当全部修改数据相对应的栏位数据都不可以被修改时，核心银行系统会生成失败信息，此时，核心银行系统会将失败信息返回给外围设备，然后外围设备展示给用户查看。

基于同一发明构思，本发明实施例中还提供了一种账户信息维护装置(核心银行系统侧)，如下面的实施例所述。由于账户信息维护装置解决问题的原理与账户信息维护方法相似，因此账户信息维护装置的实施可以参见账户信息维护方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图6是本发明实施例提供的一种账户信息维护装置(核心银行系统侧)结构示意图，如图6所示，该装置包括：

接收模块601，用于接收外围设备发起的账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

账户信息查找模块602，用于根据所述账户号查找数据库中相应的账户信息；

修改模块603，用于根据修改数据对账户信息中相应的数据进行修改，生成修改结果。

下面对该结构进行说明。

具体实施时，接收模块601具体用于：

接收外围设备按照预设格式发起的账户信息修改请求；

其中，预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；修改场景组按如下方式确定：按修改场景将相关联的账户信息栏位组成一个修改场景组；账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

具体实施时，该装置还包括：

解析模块604，用于对按照预设格式发起的账户信息修改请求进行解析，获得账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

账户信息查找模块602还用于：

根据修改场景组编号从相应的账户信息中查找相应的账户信息栏位；

修改模块603具体用于：

根据相应编号的修改场景组对应的修改数据，修改数据库中查找到的相应的账户信息栏位的数据。

具体实施时，该装置还包括：

分析模块605，用于对修改数据进行分析；

修改模块603具体用于：

当修改数据满足预定修改条件时，根据修改数据对账户信息中相应的数据进行修改；

当修改数据不满足预定修改条件时，生成失败信息。

具体实施时，该装置还包括：

返回模块606，用于向外围设备返回修改结果和/或失败信息。

上述所说的账户信息维护方法和装置，处理流程都是从核心银行系统一侧来说明的，下面从外围设备一侧来说明处理流程。

图7是本发明实施例提供的一种账户信息维护方法(外围设备侧)流程图，如图7所示，该账户信息维护方法包括：

步骤701：外围设备向核心银行系统发起账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

步骤702：外围设备接收核心银行系统返回的修改结果。

具体实施时，步骤701具体包括：

外围设备按照预设格式向核心银行系统发起的账户信息修改请求；

预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

具体实施时，该方法还包括：

外围设备接收核心银行系统返回的失败信息；其中，失败信息为当修改数据不满足预定修改条件时，由核心银行系统生成的信息。

外围设备将修改结果和/或失败信息展示给用户。

基于同一发明构思，本发明实施例中还提供了一种账户信息维护装置(外围设备侧)，如下面的实施例所述。由于账户信息维护装置解决问题的原理与账户信息维护方法相似，因此账户信息维护装置的实施可以参见账户信息维护方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图8是本发明实施例提供的一种账户信息维护装置(外围设备侧)结构示意图，如图8所示，包括：

发起模块801，用于向核心银行系统发起账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

接收模块802，用于接收核心银行系统返回的修改结果。

下面对该结构进行说明。

具体实施时，发起模块801具体用于：

按照预设格式向核心银行系统发起的账户信息修改请求；预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

具体实施时，接收模块802还用于：

接收核心银行系统返回的失败信息；失败信息为当修改数据不满足预定修改条件时，由核心银行系统生成的信息。

具体实施时，该装置还包括：

展示模块803，用于将修改结果和/或失败信息展示给用户。

综上所述，采用本发明方法和装置对账户信息进行维护时，可以获得如下有益效果：

(1)系统的维护工作量大大减少：

外围设备影响的分析工作变少，不需要去分析以前可能涉及的那些外围设备。

核心银行系统修改的分析工作量变少，因为分组设计，不涉及的组和不涉及的层，不需要去分析。

测试工作量减少，改动了哪些场景修改组，哪些栏位，就测试这些场景修改组中的相应栏位涉及的模块、涉及的外围设备，其余的部分不需过多考虑。

(2)系统可扩展性增加：

接口总是有最大长度，未使用该设计时，接口中保留了大量不需要的字段。持续增加的需求，会使接口长度超出了系统的最大限制。分组管理后，每组的长度是非常有限的，而且不同的场景，新增组别即可，不必在相似的组上增加栏位。而增加了组别也不会使核心银行系统更加难以理解和维护。

(3)易于风险控制：

对于外围设备不需要的字段，接口中不会出现，接口不会因为外围设备错填数据栏位导致隐含的错误，核心银行系统也不会把外围设备不需要的数据返回给外围设备。对外围设备来说其它数据实现了真正的透明化。

(4)易于接口监控：

每个外围设备使用了哪些场景修改组，哪些场景，在接口配置表一览无余。核心银行系统也可以通过组别列表监控外围对每个场景修改组的调用情况，使核心银行系统对于数据的被使用情况会有一个清晰的衡量。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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

Claims (20)

1.一种账户信息维护方法，其特征在于，包括：

核心银行系统接收外围设备发起的账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

核心银行系统根据所述账户号查找数据库中相应的账户信息；

核心银行系统根据修改数据对账户信息中相应的数据进行修改，生成修改结果。

2.如权利要求1所述的账户信息维护方法，其特征在于，还包括：

对修改数据进行分析；

当修改数据满足预定修改条件时，核心银行系统根据修改数据对账户信息中相应的数据进行修改；

当修改数据不满足预定修改条件时，核心银行系统生成失败信息。

3.如权利要求2所述的账户信息维护方法，其特征在于，还包括：

核心银行系统向外围设备返回修改结果和/或失败信息。

4.如权利要求1所述的账户信息维护方法，其特征在于，所述核心银行系统接收外围设备发起的账户信息修改请求，包括：

核心银行系统接收外围设备按照预设格式发起的账户信息修改请求；

所述预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

所述账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

5.如权利要求4所述的账户信息维护方法，其特征在于，还包括：

核心银行系统对按照预设格式发起的账户信息修改请求进行解析，获得账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

核心银行系统根据修改场景组编号从相应的账户信息中查找相应的账户信息栏位；

所述核心银行系统根据修改数据对账户信息中相应的数据进行修改，具体包括：

核心银行系统根据相应编号的修改场景组对应的修改数据，修改数据库中查找到的相应的账户信息栏位的数据。

6.如权利要求4所述的账户信息维护方法，其特征在于，还包括：

核心银行系统预设修改场景组间的关系；

当同时修改多个修改场景组对应的账户信息，且多个修改场景组间为交互关系时，所述修改场景组编号为多个修改场景组编号；

当多个场景组间为排斥关系时，所述修改场景组编号为多个修改场景组编号中的其中一个。

7.一种账户信息维护方法，其特征在于，包括：

外围设备向核心银行系统发起账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

外围设备接收核心银行系统返回的修改结果。

8.如权利要求7所述的账户信息维护方法，其特征在于，所述外围设备向核心银行系统发起账户信息修改请求，包括：

外围设备按照预设格式向核心银行系统发起的账户信息修改请求；

所述预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

所述账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

9.如权利要求7所述的账户信息维护方法，其特征在于，还包括：

外围设备接收核心银行系统返回的失败信息；

所述失败信息为当修改数据不满足预定修改条件时，由核心银行系统生成的信息。

10.如权利要求9所述的账户信息维护方法，其特征在于，还包括：

外围设备将修改结果和/或失败信息展示给用户。

11.一种账户信息维护装置，其特征在于，包括：

接收模块，用于接收外围设备发起的账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

账户信息查找模块，用于根据所述账户号查找数据库中相应的账户信息；

修改模块，用于根据修改数据对账户信息中相应的数据进行修改，生成修改结果。

12.如权利要求11所述的账户信息维护装置，其特征在于，还包括：

分析模块，用于对修改数据进行分析；

所述修改模块具体用于：

当修改数据满足预定修改条件时，根据修改数据对账户信息中相应的数据进行修改；

当修改数据不满足预定修改条件时，生成失败信息。

13.如权利要求12所述的账户信息维护装置，其特征在于，还包括：

返回模块，用于向外围设备返回修改结果和/或失败信息。

14.如权利要求11所述的账户信息维护装置，其特征在于，所述接收模块具体用于：

接收外围设备按照预设格式发起的账户信息修改请求；

所述预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

所述账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

15.如权利要求14所述的账户信息维护装置，其特征在于，还包括：

解析模块，用于对按照预设格式发起的账户信息修改请求进行解析，获得账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述账户信息查找模块还用于：

根据修改场景组编号从相应的账户信息中查找相应的账户信息栏位；

所述修改模块具体用于：

根据相应编号的修改场景组对应的修改数据，修改数据库中查找到的相应的账户信息栏位的数据。

16.如权利要求14所述的账户信息维护装置，其特征在于，还包括：

修改场景组关系预设模块，用于预设修改场景组间的关系；

当同时修改多个修改场景组对应的账户信息，且多个修改场景组间为交互关系时，所述修改场景组编号为多个修改场景组编号；

当多个场景组间为排斥关系时，所述修改场景组编号为多个修改场景组编号中的其中一个。

17.一种账户信息维护装置，其特征在于，包括：

发起模块，用于向核心银行系统发起账户信息修改请求，所述账户信息修改请求包括账户号和修改数据；

接收模块，用于接收核心银行系统返回的修改结果。

18.如权利要求17所述的账户信息维护装置，其特征在于，所述发起模块具体用于：

按照预设格式向核心银行系统发起的账户信息修改请求；

所述预设格式为：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据；

所述修改场景组按如下方式确定：

按修改场景将相关联的账户信息栏位组成一个修改场景组；

所述账户信息修改请求包括：账户号、修改场景组编号和相应编号的修改场景组对应的修改数据。

19.如权利要求17所述的账户信息维护装置，其特征在于，所述接收模块还用于：

接收核心银行系统返回的失败信息；

所述失败信息为当修改数据不满足预定修改条件时，由核心银行系统生成的信息。

20.如权利要求19所述的账户信息维护装置，其特征在于，还包括：

展示模块，用于将修改结果和/或失败信息展示给用户。