存储转发 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

2.发送方将报文发出后收不到接收方的应答
当以上两种情况之一发生时，发送方可将报文存放在存储转发队列中，在发送方系统日切
开始以前、接收方处于正常状态时，在一定次数内每隔一段时间重复发送，如果还是收不到
应答，则停止发送。发送方与接收方两者之间若出现账务不平通过差错处理解决。
该处理方法称为存储转发机制。
存储转发机制通常是在发送某些通知类报文时使用。
请大家谈谈 设置存储的时机点，转发的控制条件。
存储的时机点只要考虑受理方，转发的控制条件则需要考虑到受理方、发卡方
受理方接收通知交易，假设有三个步骤: IPO (Input / Process / Output)
1). Input 受理方接收到通知交易(比如来自终端)
2). Process受理方组织CUPS通知报文(假设终端报文与CUPS报文存在差异，需要重组报文)
3). Output受理方发送通知报文至CUPS
存储的时机点要设置在哪个阶段呢？问什么这样考虑？
转发的控制条件，分为两部分来考虑：
受理方 -- 受理方可能进行存储，并转发通知交易
考虑转发通知报文的 限制/控制 条件
* 如转发次数限制
* 有效期(换日交易之前)
* 转发的时间间隔
* SAF的处理结果
* SAF优先级?
* 其他?
发卡方 -- 发卡方可能接收来自CUPS的转发通知交易
发卡方在接收到转发通知交易有几种可能：
*1 之前未接收到原始通知交易
*2 之前接收到了原始通知交易，但在发送通知回应时，发现与CUPS线路故障
*3 之前接收到了原始通知交易，并且发送通知回应交易给CUPS，但其间CUPS线路故障
那么发卡方在这些情况下接收到转发的通知交易，应该如何处理呢?
*1 似乎没有特别的问题，直接处理就好
*2 是不是在处理一遍通知交易呢？再发送通知回应
*3 是不是不再处理通知交易，而是察看原始通知交易的交易日志，返回上次处理时的RspCode就OK呢？
请大家特别考虑一种情况，金融类交易的通知交易的存储转发，例如存款确认什么的，这些通知交易
发卡行需要作账目记录的，遇到 *1 *2 *3的问题要怎么解决呢?
我们从存储的时机点来分析一下：
如果将存储时机点设定在Input与Process之间，那么转发的处理就是需要对
接收的来自终端的通知报文进行重新处理，那么受理方产生的CUPS报文在每次
转发都会不同，比如报文的“系统跟踪号SystemTrace AuditNumber”,
“传输日期”可能都会不同，这种情况的存储转发处理比较符合假设原则(1)。
如果将存储时机点设定在Process与Output之间，那么转发的处理只需要对
发送的报文做稍微调整(比如重新设定MAC，因为断线重连后，可能受理方会
与CUPS做更新密钥的动作)，基本遵照原始CUPS报文，发送转发通知报文，
而这种情况下，报文的重要字段(域)，如系统跟踪号SystemTrace AuditNumber”,
“传输日期”将不会改变，这种处理方法就比较符合假设原则(2)。
从猜测来看，我想原则(2)的可能性高一些，不知道实际情况如何?