核心业务系统业务开发规范

核心业务系统业务开发规范

文档修订记录

修订方法：新增/修改/删除

目录

1 前言 ................................................................................................................ 错误！未定义书签。

2 名词解释 (1)

2.1 基础版版本............................................................................................... 错误！未定义书签。

2.2 项目版版本............................................................................................... 错误！未定义书签。

3 环境清单 ........................................................................................................ 错误！未定义书签。

3.1 前台硬件要求........................................................................................... 错误！未定义书签。

3.2 前台软件要求........................................................................................... 错误！未定义书签。

3.3 后台硬件要求........................................................................................... 错误！未定义书签。

3.4 后台软件要求........................................................................................... 错误！未定义书签。

4 提交工具说明 ................................................................................................ 错误！未定义书签。

5 版本管理方案 ................................................................................................ 错误！未定义书签。

5.1 基础版版本............................................................................................... 错误！未定义书签。

5.1.1 提交流程 .......................................................................................... 错误！未定义书签。

5.1.2 基础版版本管理制度....................................................................... 错误！未定义书签。

5.2 项目版版本............................................................................................... 错误！未定义书签。

5.2.1 接收和提交流程 .............................................................................. 错误！未定义书签。

5.2.2 项目版版本管理制度....................................................................... 错误！未定义书签。

6 项目版本交互方案 ........................................................................................ 错误！未定义书签。

6.1 中心与项目版本交互方案....................................................................... 错误！未定义书签。

6.2 中心与项目Bug交互方案 ...................................................................... 错误！未定义书签。

6.3 中心与项目优化交互方案....................................................................... 错误！未定义书签。

6.4 中心与项目需求交互方案....................................................................... 错误！未定义书签。

6.5 中心与项目上线后交互方案................................................................... 错误！未定义书签。

7 多项目支持方案 ............................................................................................ 错误！未定义书签。

8 缺陷管理方案 ................................................................................................ 错误！未定义书签。

1历史数据清理

采用外挂任务，逐笔完成历史数据清理。原分区切换方式，在分区被使用、表被锁时，会造成切换失败。

设计模块时，应注意明细表和历史表的设置。

2多法人

2.1独立法人模式

独立法人模式下，各法人间相互独立，均可作为独立系统运行，法人间业务交互采用系统间往来方式完成，法人间数据隔离。

存在系统开关量及参数表，可为多个法人指定使用何种参数与产品体系。

2.2准分行模式

准分行模式下，各法人作为主体法人的分支机构存在，由系统参数决定各法人间、法人与主体法人间的数据是否隔离或共享。法人间业务交互采用系统内往来方式完成。

但同样存在系统开关量及参数表，为多个法人指定使用何种参数与产品体系。

2.3技术层面

多法人的法人代码应对开发人员透明，平台应能根据参数配置，自行选择对账户表、对参数表、对登记簿、对系统表使用何种法人代码。

3多层机构管理

3.1机构分类

机构应支持多层级关系和网状关系。

机构应可分为管理机构、账务机构、营业机构几种大类。

3.2机构关系

系统应支持多种类机构关系定义，各机构间不存在明确上下级关系，均由参数表配置决定机构系统。各业务处理应遵守参数决定的机构关系。

机构关系应可灵活扩展，可随意调整。

机构关系应支持但不限于如下关系种类。

账务关系

管理关系

报表关系

凭证关系

制卡关系

4交易设计

4.1交易分类

系统应对系统内使用的交易有严格的划分，从业务来源上至少分为如下几大类。

账务交易

查询交易

维护交易

联机批量

日终批量

不同交易应使用不同的流程号，以便于日结时流水勾对。所以交易处理应优先考虑效率问题。

4.2交易流程

所有交易中，应只通过不同条件，处理调用不同业务构件完成业务处理。即交易中不存在业务处理，交易是业务处理流程的体现。

4.3事务控制

所有事务控制均由平台统一完成，对于有特殊要求的，应使用平台统一提供的事务控制方法，完成局部事务控制。

4.4对账机制

所有外围、渠道业务处理，应有统一的流水表或业务日志表登记，以便于各渠道日终对账要求。

5账户管理体系

系统内应有统一的账户登记表，用于记录各客户账户和系统账户。对于负债分户账，应形成客户账户到系统账户的对照表，以便于检索。

5.1客户账户

卡

活期一本通

定期一本通

存折

5.2系统账户

现金分户账

凭证分户账

资金账户

负债分户账

贷款分户账

会计内部账

集团账户

6业务风险控管

6.1录入复核制

在交易定义中，交易应支持录入+复核、直通+授权多种处理模式。此模式应可以通过系统参数动态调整。

录入复核制的交易统一登记，统一商定，统一模式处理。

6.2权限控制

系统应从多个角度完成业务操作的权限控制，如：

柜员角色及权限，用于在柜员层定义柜员可以操作哪些交易 ---长亮已有

交易使用权限，定义哪些交易哪些级别的柜员可做。

产品使用权限，定义哪些交易、哪些机构可以使用哪类产品。

币种及限额使用权限，定义哪些机构、哪些柜员可以使用哪些币种及使用的额度。

分行使用权限，定义哪些产品、哪些交易可以在哪些机构使用。

科目使用权限，定义哪些科目可以在哪些机构、哪些交易中使用。

6.3授权机制

系统支持以下3种授权驱动模式：

1、前台交易流程驱动。

前台交易流程驱动，由交易开发人员在前台程序中编写代码触发，授权后交易发往后台，平台检查授权合法性。

交易开发人员根据业务个性逻辑，可以在域后事件、或者通信前处理中编写代码，实现授权。

交易开发人员调用公共处理模块提供的构件，传入参数：授权柜员级别、授权提示信息。

前台授权只支持本终端授权。

2、参数驱动。

参数驱动，由交易开发人员针对本交易配置授权参数，平台触发，授权后，平台检查授权合法性。

如果触发条件配置为无条件授权，则不管交易发生的金额大小，均提示授权。

如果触发条件配置为有条件授权，需要继续配置触发条件符号、条件字段值，如金额档次等，满足条件则提示授权。

如果授权终端配置为跨机构授权，需要继续配置授权机构级别、授权机构等。

参数驱动授权支持本终端授权、跨终端授权、跨机构授权。

3、后台交易流程驱动

后台交易流程驱动，由交易开发人员在后台程序中编写代码触发，授权后，平台检查授权合法性。

交易开发人员调用公共处理模块提供的构件，传入参数：授权柜员级别、授权提示信息、授权终端标志等参数。

后台交易流程驱动授权支持本终端授权、跨终端授权、跨机构授权。

多种授权驱动同时存在时：

触发的先后顺序为：前台交易流程驱动、参数驱动、后台交易流程驱动。依次检查授权合法性。

授权方式由最后一种驱动模式决定。

授权合法性，按模式中最高的级别进行检查。如授权柜员级别，该授权柜员的级别需满足所有模式的要求。

6.4警告机制

在交易过程中，系统提供警告机制，当柜员操作时遇到警告信息，程序不会继续执行，

当取消这次操作时，程序会以回滚的方式执行，抹掉前面执行的痕迹。

6.5提示机制

在交易过程中，系统提供提示信息的机制，但提示并不会影响交易的进行，仅仅起到提示的作用。

6.6业务查证

所有业务应在前台留有原始业务界面，以便于后续监督要求时，能够打开原业务界面检查。

6.7事中监督

系统应有参数可控制交易是否需要进行事中监督，且系统应有统一处理过程完成事中监督。事中监督应有明细记录可查。

6.8事后监督

事后监督应与事中监督类似。

6.9身份证核查

核查结果登记在客户层，核查明细信息登记在账户层。

1、系统以前台按钮方式提供统一的身份证核查入口。

2、交易开发人员在后台程序中调用公共处理模块提供的构件，完成客户层的核查结

果、账户层的核查明细信息登记。

3、平台在系统流水表中登记该笔流水是否有身份核查。

6.10黑名单

黑名单包含客户层、账户层两种不同维度。

1、黑名单登记。系统提供黑名单录入交易。

2、黑名单检查。交易流程中进行客户信息和账户信息检查时，对于存在黑名单中的客

户或账户返回对应的提示、警告，或拒绝交易。

6.11客户不良信息

1、不良信息登记：

手工登记。系统提供不良信息录入交易。

自动登记。交易开发人员在客户发生欠息、欠费用、账户司法冻结等不良记录的业务场景中，调用系统提供的不良信息登记构件，登记不良信息。

2、不良信息检查：交易流程中进行客户信息检查时，对于存在不良信息的客户返回对

应的提示、警告，或拒绝交易。

7日历管理

系统应提供日历管理，用于登记本年度的工作日与节假日，系统应提供生成函数，统一生成标准日历，再交由管理人员自行调整特殊节假日。

系统应提供统一的日历处理方法，用于处理到期日遇节假日的顺延问题。

8编码规则管理

8.1编码规则

系统内的编码应统一管理，由系统提供方法统一生成。编码中可定义总长度、组成元素、各元素长度、及元素特定值。

8.1.1简要说明

编码规则生成支持参数界面化配置，开发人员可以通过前台参数维护交易配置。

编码规则支持核心公用字段处理、如交易日期、机构号、柜员号、币种等。

编码规则支持公用参数定义必须传入，不传入的情况下报错。

编码规则支持非公用字段参数传入处理、模块自定义特殊处理。

编码规则支持非公用字段参数固定值处理，如存款证明-CKZM。

编码规则支持序号种类、校验位标志处理等。

8.1.2表结构说明

8.1.2.1编码规则表

kapp_bmguiz：

8.1.2.2编码规则组成表

kapp_bmgzzc：

8.1.3开发人员需要完成

开发人员可通过前台编码规则参数维护交易定义所需编码。

录入成功后，可以通过0003交易查询出编码组成，如图：

8.1.4实例说明

界面配置编码规则如下：

如自定义卡号生成编码规则：

卡号编码配置说明:

卡号编码：KAHAO99001 ，长度：18 ，所属模块：CD ，重置周期：0

卡号编码组成：卡BIN号 + 卡号种类 + 分行代码 + 序号 + 校验位

（1）卡BIN号组成代码：CANSZH01，组成长度：6，组成类型：2，特殊处理标志：1 （2）卡号种类组成代码：CANSZH02，组成长度：2，组成类型：2，特殊处理标志：1 （3）分行代码组成代码：CANSZH03，组成长度：2，组成类型：2，特殊处理标志：0 （4）序号组成代码：XUHAOOOO，组成长度：7，补位值：0，组成类型：0，特殊处理标志：0

（5）校验位组成代码：CANSZH04，组成长度：1，组成类型为：1，特殊处理标志：1

1、手工准备数据插入编码规则表(kapp_bmguiz)

2、手工准备数据插入编码规则组成表(kapp_bmgzzc)

3、编码生成使用事例代码：

IoApGenCodeRule ApGenCodeRuleAPI =

SysUtil.getInstance(IoApGenCodeRule.class);

IoApCodeRuleStru

cplIoApCodeRule=SysUtil.getInstance(IoApCodeRuleStru.class);

cplIoApCodeRule.setZhscdaim(sZhscdaim);

cplIoApCodeRule.setCanszh03(sFenhdaim);

cplIoApCodeRule.setCanszh10(sChanphao); //卡模块特殊处理字段，其他模块不需要。

String sBmguiz = ApGenCodeRuleAPI.genCodeRule(cplIoApCodeRule);;

bizlog.debug("GenCodeRule: %s", sBmguiz);

8.1.5注意事项

1、请严格按照表结构说明配置代码规则。

2、如果组成代码配置为公用字段“JIOYRIQI”，将会与重置周期进行强制匹配，如果按天重置，拼日期字段；如果按月重置，截取前6位，右补零；如果按年重置，截取前4位，右补零。

3、如有他模块特殊处理，在iobus上注册、本模块服务实现后，及时通知管理员。8.2序号管理

系统中序号应由统一参数表统一生成，以规范序号使用。不同序号提供自身序号种类及生成规则，系统由统一方法生成。

8.2.1序号参数表

序号参数表（kapp_xuhocs）：

8.2.2事例说明

如生成存款证明序号：

IoApSeqGenStru cplIoSeqGenStru = SysUtil.getInstance(IoApSeqGenStru.class);

IoApGenSeqNo ApGenSeqNoAPI = SysUtil.getInstance(IoApGenSeqNo.class);

cplIoSeqGenStru.setRiqiiiii(DateTools.getCurrentDate()); //非必传

cplIoSeqGenStru.setXuhozlei(sXuhozlei); //必传

cplIoSeqGenStru.setXuhaoomc(sXuhominc); //必传

cplIoSeqGenStru.setCzzhouqi(E_QIXIANDW.Day); //必传

cplIoSeqGenStru.setSuoshumk(E_SUOSHUMK.DEPT); //必传

long seq = ApGenSeqNoAPI.genSeqNo(cplIoSeqGenStru);

System.out.println("GenSeqNO: "+seq);

8.3柜员流水号管理

系统内柜员流水号应分类管理，不同类型交易使用不同的流水号规则以便于日终流水勾对。

流水号的生成应注意其连续性，同时应注意获取流水号时数据库锁的问题。

8.4业务编号管理

系统内对于不同业务，应统一生成对应的业务编号，以便于查询和统计。

8.5中间业务代码管理

系统内对于中间业务的处理，应统一生成对应的中间业务代码，以便于查询和统计。9摘要及备注管理

系统交易应提供统一的摘要代码及摘要信息，以便于统计分析需要，同时系统应允许柜员在交易时对交易内容进行备注。

强制要求。

10账单管理

10.1电子回单

系统针对对公账户应提供电子回单功能，应可针对母账户、子账户提供不同的回单内容。

系统应支持电子回单的自动打印，如条件许可，应支持电子回单的自动分发。

应支持打印次数记录，及费用收取。

10.2对账单

系统针对对私账户应提供如下两类对账单：

余额对账单

明细对账单

系统应支持对账单的周期自动打印，如条件许可，应支持对账单的自动分发。

应支持打印次数记录，及费用收取。

11综合签约管理

系统应提供统一的签约信息登记，各模块完成本模块的签约后，应同时登记综合签约登记簿，以便于在客户账号变更、销户时准确检查。

12通知机制

12.1短信通知

对于账户余额变动、关键信息变更、密码变更应提供可参数定制的短信通知机制。

1、模块开发人员在程序中调用短信通知构件，作为短信通知的入口。

2、模块开发人员配置短信发送条件参数表，满足条件的才进行短信登记和发送。

3、模块开发人员配置短信内容参数表。

12.2客户/账户备注

备注主体可以为: 账户、客户、借据。

平台统一检查备注信息，根据备注类型返回强制备注、提示备注。

12.3信息发布

系统应支持机构内、机构间、柜员间的信息发布，信息发布应能够做到自动提示，信息发布应支持广播机制和点对点机制。

此类信息发布应考虑远程授权的使用。

13参数管理

13.1参数管理机制

对于参数表的维护，系统应提供统一工具，生成统一风格的参数维护交易。

13.2参数变更明细

对于参数数据变更，系统应能够准确登记参数变更明细备查，应能够登记时间、操作人员、授权人员、变更内容。

14加密管理

14.1敏感数据分类

系统应对数据库中敏感数据在查询后进行脱敏处理，如特殊客户的姓名、特殊账户的户名，行内员工的工资信息等。

系统也应支持从生产库数据导出后的脱敏处理。

14.2密钥管理

系统应提供统一的密钥管理机制，所有密钥统一存放，统一分发，确保密钥的安全。

14.3文件加解密

系统应提供软加密功能，对于系统提供的带有敏感数据的文件，应提供统一方法进行加密处理，对于外系统进入的加密文件，应由统一方法进行解密，以减少维护成本。

系统应提供开关量，指定是否加密、是否验密、是否加密验密。

14.4密码管理

密码是进过加密处理后存放在系统数据库表中的客户的交易口令。

1、密码设置：调用公共处理模块提供的密码设置构件，传入参数：密码载体、密码类

型、密码、密码所属渠道。系统检查是否满足设定的密码风险化管理规则。

2、密码改密：调用公共处理模块提供的密码改密构件，传入参数：密码载体、密码类

型、新密码、密码所属渠道、原密码。系统校验原密码，检查新密码是否满足系统设定的密码风险化管理规则。

3、密码校验：调用公共处理模块提供的密码校验构件，传入参数：密码载体、密码类

型、密码、密码所属渠道。系统对密码进行校验，密码错误时，进行最大错误次数的控制。

15日志管理

15.1总体说明

V7系统在应用层以Log4j作为日志输出机制，采用分类分级方法，完成不同类型日志的输出与控制。

15.2日志分类

V7系统中将日志分为：

Debug-调试日志

Info-关键信息日志

Error-错误日志

Method-方法标记日志

Parm-参数日志

SQL-数据库日志

Profile-性能日志

15.3日志分级

V7系统中，日志的分级由客户自定义，日志级别不限制，可由不同的日志分类组合而成。