XIP渠道上业务系统设计的一点总结

/ 隋天谋

XIP渠道上业务系统设计的一点总结

by icesky @2018.06.14

大家入职培训xip的时候，最常做的就是一笔正常代缴费。咱们以一笔代缴费来进行交易的推演和发展过程。

xip上的系统，大家都知道分为如下三种类型的渠道：

  • 来源渠道，对方系统请求的报文都通过该系统。
  • 本地渠道，渠道本地虚拟出来的一个渠道，实际上就是本地应用。
  • 目标渠道，要调用或者发交易给对方的系统。

1. CTS-MIDL直接开发流程

一笔代缴费，从柜面发起，发给水费公司与核心。正常的流程如下。

|-- CTS-MIDL 8583来帐
|   |-- ROUTE 本地, 取日期流水登记表等
|   |-- ROUTE HTC-MIDL， 发送核心记账，后续更新表
|   |-- ROUTE WATER-T 发送水费记账，后续更新表
|   |-- 冲正和流程判断略

大概是这样一笔业务，这是抽象的流程。

随着互联网和行内业务的发展，行方后来又提出，要在诸如ATM和手机银行上，实现相同的代缴水费功能。由于ATM-F和MOBILE-F是不同的来源渠道，报文格式甚至业务要素提供的也与柜面不同。因此，我们只能拷贝原来CTS-MIDL的水费交易分别到ATM-F和MOBILE-F上的，进行一定的报文适配，类如EVAL，或者加1、2个函数获取信息等。

这样会带来如下几个问题：

  • 增加开发工作量，相似的流程，开发配置很多遍。
  • 流程不统一，水费需求调整一个流程，需要调整各系统流程，万一漏了一个来源渠道，则可能导致系统异常。
  • 人员要求高，项目人员可能主要是做网银系统的，现在还要了解水费的整体流程。如果再复杂一些的系统，则实施难度增加了很多。
  • 另外的问题，定时业务比较难以触发，细心的同事可能发现，以前有hvbe.env等配置文件，就是原来用来模拟CTS-MIDL定时自己给自己发交易。但是由于是8583报文，模拟的问题较多。

因此了，有了后来的CMSERV-F渠道。

2. CTS-MIDL调用CMSERV-F渠道

改成调用CMSERV-F渠道后，流程变成了如下：

|-- CTS-MIDL 来源渠道收到流程，8583报文
|   |-- ROUTE 本地，处理一些基本信息，如接口需要的调用方日期、流水等字段。
|   |-- ROUTE CMSERV-T公共服务渠道，调用WATER01接口，使用最简单的固定分隔符。
|       |-- CMSERV-F收到固定分隔符报文格式后，开始正常的业务处理：
|           |-- ROUTE本地、取日期、流水、登记表。
|           |-- ROUTE到HTC-MIDL渠道，调用核心记账交易，根据响应信息更新表状态。
|           |-- ROUTE到水费渠道WATER-T渠道，调用水费提供的缴费业务，根据响应信息更新表状态。
|           |-- 冲正略。

这样做，完美的解决了之前遇到的各种来源渠道报文和业务格式不统一的问题。每个来源渠道，只要按照CMSERV-F的水费接口格式调用就可以了，而不用再关心水费的具体业务流程和函数。

另外，同时提供了CMSERV_SND程序进行定时处理，固定格式清晰可见。

因此，大家可能发现基本上各地都有CMSERV-F的来源渠道，并且上面有很多代缴费的交易。这里需要特殊说明的是：

  1. 来源渠道不单做了报文转换，还做了一些处理，比如币种从01转成CNY。甚至可能要补充数据，比如缴费的时候，柜面有快查，可以直接传递户名。但是网银上就没有快查，因此可能需要NETB2-F中先调用核心户名查询交易，再调用CMSERV-F中的缴费交易。
  2. CMSERV-F使用的是消息队列（进程间通讯），同一台机器的效率比较高。

随着CMSERV-F的交易不断增多，CMSERV-F的业务量也越来越大，带来了如下几个问题：

  1. CMSERV-F作为一个单一渠道，业务压力越来越大，变相的把鸡蛋都放到一个篮子中了。
  2. 业务放在一起，看日志的时候，非常麻烦。
  3. 随着一些银行业务系统的拆分等情况，导致网银和缴费业务，分别部署在了不同的渠道服务器上。进程间通讯的模式，无法满足这种远程调用。

​

因此，在做二代支付系统的时候，使用了PMTS-A，二代支付系统内部自有的来源渠道。

3 系统内部自有的公共处理渠道PMTS-A

使用PMTS-A唯一问题，还是进程间通讯的方式，但是这个问题只要修改服务成改成socket就可以解决。

å因此到目前为止，基本上不同来源渠道的交易复用问题基本上已经解决了。这其中有一个问题没有处理好：

PMTS-A或者CMSERV-F，有些交易没有登记调用方日期、流水等信息，导致后续交易状态查询和同步的时候，无法匹配。

解决这个问题需要在接口和相关流水表中，增加调用方日期、调用方流水、调用方系统类型三项。

另外，目前还比较流行，额外登记一个字段：”统一流水“，即交易发起方生成的流水，过程中所有系统都登记。这样的好处是，原来查一笔交易，需要从A系统找A系统流水对应的B系统流水，然后去B系统查B系统流水对应的C系统流水，而如果有统一流水，则直接用该流水就能查到所有。（CMSERV-F的日志中，logid也有类似的处理）

来源渠道的问题已经进行了一定的探索，在此过程中，另外两个跟核心系统对接的问题也愈发明显：

  1. 没增加一个对接的系统和交易接口，不但渠道也进行开发，核心系统也要进行开发，这个问题在C版老核心上尤其明显。 当然，这不是系统问题，是接口没有进行统一整理和封装的问题。
  2. 渠道的系统，可能多个地方都需要进行上线，但是核心版本不同，我们需要花大量的时间来修改流程，来进行核心接口适配。 而我们又是直接调用的

因此，强烈需要一个和接入渠道一样的转换层来屏蔽核心接口差异。故在做二代网银的时候，增加了EHOST-F来源渠道。

4 使用EHOST抽象和屏蔽核心接口

在开发二代网银接口的时候，由于网银需要用到大量的核心接口。之前一代网银的时候，基本上是200个网银页面交易，就对应200个网银接口。 在这次项目中，对核心系统进行了大量的梳理和交易分类。当然这是其实应该核心的工作之一，并且在FCR之后，核心系统也进行了多次梳理。

我们梳理的角度主要是从外围系统调用的角度进行的梳理，因此在EHOST-F中，按客户查询、账户查询、单笔记账、批量记账等情况，写了大概60-70个通用接口左右。然后网银、手机银行，以及后续行内比如缴费、网银互联转账等交易，都通过调用ehost-f的标准接口实现。

因此，一笔代缴费的调用流程如下：

|-- CTS-MIDL 8583来帐
|   |-- ROUTE 本地处理处理
|   |-- ROUTE CMSERV-T 调用水费缴费交易
|       |-- CMSERV-F 缴费交易
|           |-- CMSERV-L 取日期流水登记表处理
|           |-- EHOST-T 调用核心记账VAA1
|               |-- EHOST-F VAA1交易
|                   |-- EHOST-L 各种数据处理
|                   |-- HTC-MIDL 8583发送核心系统
|           |-- WATER-T 调用水费公司缴费
|           |-- 冲正

这样，在鞍山、阜新、朝阳等地方上线的时候，主要工作是在EHOST-F·里面进行核心接口适配，减少了很多的工作量。

并且后续各系统用抽象过的核心接口后，很多时候也不需要编写核心程序来处理了。

这样使用了一段时间后，发现有另外一个问题：

以VAA1的EHOST-F中的通用记账为例，这个接口使用的XML报文，因此有很多可选节点。 目前所有节点大概有60个多个节点。

如果我做一笔代缴费，调用了VAA1, 那么我向比如不是我们自己核心系统提接口需求的时候，是将VAA1的接口需求提给了对方。加上可选项是60多个节点。

而实际上，一笔水费缴费，可能只需要渠道日期流水、账号、金额字段就可以了。

这样为了实现一个只要4-5个字段就能实现的记账功能，要求对方核心提供一个60多个节点的通用记账。实施起来尤其对非咱们自己核心的银行，难道比较大。

因此，如同CMSERV-F一样，各系统也进行了拆分。

5 使用EPCCHT-F网联核心渠道来实现

其实EHOST的误区在于，老想替核心实现通用记账的功能，而不是进一步独立和抽象渠道的适配接口。当然更根本的问题是，当时很多核心程序都是渠道人员编写的，现在这个问题已经不存在了。

因此，考虑到各种不同对接系统的差异性，在网联系统中，使用EPCCHT-F这种适配渠道来进行进一步的屏蔽和拆分。

这样，就解决了VAA1接口太多要素太多的问题。

目前网联渠道的渠道有如下(只列来源渠道，对应目标渠道不列):

|-- 网联接入系统
|   |-- 网联接入渠道
|       |-- 网联本地渠道： 本地业务处理
|       |-- 网联来帐渠道： 接收网联来帐
|       |-- 网联自动渠道： 用于处理定时，可与来帐渠道合并
|   |-- 网联外联渠道
|       |-- 核心适配渠道： 用于跟各种核心系统对接。
|       |-- 贷记卡适配渠道： 用于跟各种贷记卡系统对接。
|       |-- 短信适配渠道： 用于跟各种短信系统对接。
|   |-- 网联服务渠道
|       |-- 网联对外服务渠道： 渠道网联系统本身，可以对方开放的各种交易，如签约，查询等。
|       |-- 网联管理端渠道： 主要用于适配网联管理端的各种处理，可调用对外服务渠道。

产品版一笔交易流程如下：

|-- ECCPBB-F 网联来帐
|   |-- 本地处理，取日期流水登记，判断权限，卡类型
|   |-- IF 卡是核心 
|       |-- ROUTE EPCCHT网联核心适配渠道
|           |-- 做各种接口、适应不同的银行
|   |-- IF 卡是贷记卡
|       |-- ROUTE EPCCCD网联贷记卡适配渠道
|           |-- 做各种接口、适应不同的银行
|   |-- ROUTE EPCCSMS 网联短信渠道
|       |-- 做各种接口、适应不同银行

这样各地的实施人员，主要工作如下：

  1. 根据提供的EPCCHT/EPCCCD/EPCCSMS的接口，对接行里核心系统。业务流程无需考虑，由产品版统一开发和维护。
  2. 如果如柜面等渠道的调用服务，进行适配。比如签约交易，在CTS-MIDL中配置调用“网联对外服务渠道”的签约交易。无需完全了解签约的详细流程。

目前该种模式，基本上实现了目前多个项目的EPCCBB-F的所有交易流程和传值都保持一致。

当然，这种模式建立的各种渠道也是比较多的，具体的项目要根据情况来进行处理。

如果是全国性的项目，建议大家做的时候，更多的参考。

如果是地区特色非常明显的，则没有必要进行如此多的封装。

未做好的几件事情：

  1. 网联外联渠道之间的通讯，目前使用的是8583报文格式，目前来看问题比较大。效率特别低，后续还是应该采用效率最高的固定分隔符。

  2. 调用各系统的所有接口，都应该将渠道日期+渠道流水传递过去。 如果万一发生核心需求的要素过多，且接口没传递的情况，不用修改产品版流程。

  3. 目前产品版的保持还是继续中，但是感觉相对来说，已经遇到了一些困难。想做到更好的产品封装，不但需要好的设计，还需要好的保持，不单是做产品的人要保持，实施的人也要保持。

6 新版渠道代缴费的初步探索

在阜新银行做中间业务平台的过程中，对代缴费进行了一部分的探索。总的来说，是把所有的缴费流程都放在了一个交易或者流程中，然后通过不同的业务类型来进行区分和配置特殊处理函数。

通俗意义上来讲，相当于把之前的水费缴费，抽象成了一个公共缴费，然后传入接口增加了一个缴费类型，可以传入水费、传入电费，同时增加了一个可以自定义的附加域（所谓的datatable,可以理解为文件）。

后端连接水费或者电费的时候，把以前的WATER-T，改成AGENT-F(类似于对应DSS)，然后在AGENT-F中适配对接是水费、电费。

写在后面的话

圣经说，日光之下并无新事。

很多项目经理也跟我说，感觉一个项目接着一个项目，都是在做重复的工作。

然而，王阳明有格了7天竹子的经历，乔峰一套太祖长拳，也能打遍聚贤庄。问题的关键在于相似不等于相同，怎么从每天相似的工作中，发现不同、创造不同，才能不断的进步。不然即使换一份工作、一种技术，度过新鲜期后，依旧是无尽的重复。

保持初心才能见山是山，希望大家共勉，不断在项目实践中探索更好的模式，来促进自己促进集体进步。