论文部分内容阅读
报文协议
银行与SMS之间采用基于TCP/IP的报文通讯，具体为长连接方式。银行作为CLIENT进程，SMS作为SERVER进程，由银行向SMS发送请求报文，SMS回送结果报文。(对账文件可以由FTP服务器中转)。
通讯的网络结构图如图4。
1、通用报文结构(见表1)
2、协议说明
a．包为不定长，总长度由len域指定，报文头没有分隔符，固定为51个char长，char为8位。SMS系统只接收单包请求，并且只返回单包。
b．请求包和响应包都使用此结构。
c．交易编码cmd_id，客户端必须写入遵守SMS系统提供的交易编码规则，服务端在应答报文中原样返回。
d．流水号sequence为异步通讯的标识，由客户端生成，服务端在应答报文中原样返回。如果服务端返回的报文大于一个包，则这一组包的流水号相同。
e．MorePkt字段：当对应一个请求有多个应答报文时，必须通过该字段来说明是否还有后续包，还是应答结束。如果有多个应答包，则只有最后一个应答包的morePkt为0，其他包的morePkt都为1。
f．包序号packetno由SMS生成。对于每个请求，相应的一个或多个应答包都从1开始编号，逐次连续加一。
g．mark字段为报文体的校验字段，使用MD5算法产生32位的字符串，取前4和后4个的字符，交叉后的字符串作为校验字，如果MD5串第一个字符为A0，第二个字符为A1，依次类推，那么最后产生的校验字为AOA28A1A29A2A30A3A31。
正确报交：[5399990001
101 bank625dlc2a
11]
h．MD5算法为“输入记录信息字符串＋双方约定的密钥”，对输入信息使用MD5算法产生128比特数字摘要，128比特数字摘要转换为32字节16进制字符串。(计算MARK字段的值时，将MARK字段设置为空格。)
i．reserved字段中存储SMSID信息，银行可以不填写此字段内容，使用全空。
j．报文体datatrans为实际发送或接收的数据内容，为一个变长数组，数据内容依次向后放。
k．报文体的字段采用定长方式。银行必须与本接口说明一致。
l．报文头字段定义的长度，表示字段的固定长度，实际长度不足时采用左补空格。
m．报文体字段定义的长度，表示字段的固定长度，实际长度不足，则左补空格。
n．报文体中有关交易的流水账号推荐使用“YyyyMmDd(交易当天日期)＋序列号”这种格式，比如：“20060624000000000001”，其中序列号位数可以为小于或等于12位。
实现功能的协议说明
下面重点描述与实现功能相关的报文内容。
★以下表格中的“请求参数”与“返回结果”不做特别说明，均指请求报文和响应报文中的datatrans字段。
★请求参数、返回结果参考协议说明，均为固定长度，中间没有分隔符。
★请求时，如果SMS系统设置为不校验订户密码，则消息参数涉及到密码字段可以填空格。如果SMS系统校验订户密码，则密码字段必须填写，否则密码校验不通过，返回失败。密码加密，需要双方协定。现在暂时不提供预站订户的查询。 ★业务编码见表2 ★处理结果见表3，必须说明结果码，固定4位，如果处理失败，返回结果中的结果码。 ★时间统一为yyyyMMddHHmmss，日期统一为yyyyMMdd，金额使用“分作”为基本单位。
1订户基本信息查询
实现“订户信息基本查询”的报文内容见表4～表7。
2柜面业务
编者注：由于篇幅所限，柜面业务中包含的，订户已订购业务查询、计算订购费用、订购、计算续定费用、续定、冲正、银行柜面业务对账等项业务的按文内容图表略去。
数据文件格式
为了保证数据传递的安全性，对数据文件采用进行数字签名的方法进行保护。在数字签名前不要对数据采用补空和补0。具体方法是对数据文件中的每一行数字签名前面的数据(不包括数据签名前面的竖线)进行数字签名。字段之间以“1”分隔，对每条记录信息采用MD5算法进行数字签名，银行终端需要针对每条记录进行数字签名校验，如果有校验不通过的记录，SMS系统不处理该结算文件，数字签名同报文的校验字段算法，以数据内容(最后一个字符不为“1”)作为信息字段。文件最后一行统一以‘#’表示文件的结束。
1、柜面文件对账
此文件由银行提供给SMS，其内容是SMS用户通过银行柜面业务的明细(文件内容不包括冲账记录)。
a．文件名格式 格式为CHKyyyyMMddXXX，dat，其中yyyyMMdd表示日期，XXX表示编号。
b．文件内容格式：明细文件内容＝文件头＋文件体＋文件结束符。
文件第一行为文件头，最后一行为文件结束符，文件头格式定义见表8。例如：00000120000000123400表示扣款记数为120条，总费用为1234元。
文件中的每一行格式为useridlfeelserialnolsign“1”分隔符内的每个这段都不要采用补空和补0来填充满足字段的位数长度，下同。
参数说明：
userid 用户ID，如“000000000001”
fee
银行代收金额，以分为单位
serialno银行扣款流水号
sign
数字签名
c．文件体中记录按银行扣款流水号进行升序排序。银行给出的对账文件必须包括某段流水号之间的所有记录，
因为对账时是针对某段流水账号之间的所有记录，如果本次不是给出所有指定流水号之间的记录，那么下次又把上次没有对账的流水号所对应的记录取出来对账，则会造成对账时会把正确的记录都取消掉或者作为一笔错识的帐目。
2、柜面业务对账不一致的文件
此文件由SMS提供给银行，当对银行柜面业务对账出现了银行存在而SMS不存在的记录，则记录在该文件中，某笔对账明细不一致时也放在对帐不一致文件中返回。
a．文件名格式：DISyyyyMMddXXX，dat，其中yyyyMMdd表示日期，XXX表示编号。
b．文件内容格式：明细文件内容＝文件体＋文件结束符。
文件中的每一行格式为useridlfeelserialnolsign。
3、代扣金额列表文件
此文件由SMS提供给银行，内容是用户在结算月应缴纳的费用的明细。
a．文件名格式：文件名格式为FEEyyyyMMddXXX，dat，其中yyyyMMdd表示日期，XXX表示编号。
b．文件内容格式：明细文件内容＝文件头＋文件体＋文件结束符。
文件第一行为文件头，最后一行为文件结束符，文件头格式定义见表9。例如：00000120000000123400表示扣款记数为120条，总费用为1234元。
文件体中的每一行格式如下
useridlsettlemonthlproductidluserindexlfeelmonthlsign。
(编者注：由于篇幅所限，带扣列表文件和带扣银行记录对账文件具体参数略)
银行与SMS之间采用基于TCP/IP的报文通讯，具体为长连接方式。银行作为CLIENT进程，SMS作为SERVER进程，由银行向SMS发送请求报文，SMS回送结果报文。(对账文件可以由FTP服务器中转)。
通讯的网络结构图如图4。
1、通用报文结构(见表1)
2、协议说明
a．包为不定长，总长度由len域指定，报文头没有分隔符，固定为51个char长，char为8位。SMS系统只接收单包请求，并且只返回单包。
b．请求包和响应包都使用此结构。
c．交易编码cmd_id，客户端必须写入遵守SMS系统提供的交易编码规则，服务端在应答报文中原样返回。
d．流水号sequence为异步通讯的标识，由客户端生成，服务端在应答报文中原样返回。如果服务端返回的报文大于一个包，则这一组包的流水号相同。
e．MorePkt字段：当对应一个请求有多个应答报文时，必须通过该字段来说明是否还有后续包，还是应答结束。如果有多个应答包，则只有最后一个应答包的morePkt为0，其他包的morePkt都为1。
f．包序号packetno由SMS生成。对于每个请求，相应的一个或多个应答包都从1开始编号，逐次连续加一。
g．mark字段为报文体的校验字段，使用MD5算法产生32位的字符串，取前4和后4个的字符，交叉后的字符串作为校验字，如果MD5串第一个字符为A0，第二个字符为A1，依次类推，那么最后产生的校验字为AOA28A1A29A2A30A3A31。
正确报交：[5399990001
101 bank625dlc2a
11]
h．MD5算法为“输入记录信息字符串＋双方约定的密钥”，对输入信息使用MD5算法产生128比特数字摘要，128比特数字摘要转换为32字节16进制字符串。(计算MARK字段的值时，将MARK字段设置为空格。)
i．reserved字段中存储SMSID信息，银行可以不填写此字段内容，使用全空。
j．报文体datatrans为实际发送或接收的数据内容，为一个变长数组，数据内容依次向后放。
k．报文体的字段采用定长方式。银行必须与本接口说明一致。
l．报文头字段定义的长度，表示字段的固定长度，实际长度不足时采用左补空格。
m．报文体字段定义的长度，表示字段的固定长度，实际长度不足，则左补空格。
n．报文体中有关交易的流水账号推荐使用“YyyyMmDd(交易当天日期)＋序列号”这种格式，比如：“20060624000000000001”，其中序列号位数可以为小于或等于12位。
实现功能的协议说明
下面重点描述与实现功能相关的报文内容。
★以下表格中的“请求参数”与“返回结果”不做特别说明，均指请求报文和响应报文中的datatrans字段。
★请求参数、返回结果参考协议说明，均为固定长度，中间没有分隔符。
★请求时，如果SMS系统设置为不校验订户密码，则消息参数涉及到密码字段可以填空格。如果SMS系统校验订户密码，则密码字段必须填写，否则密码校验不通过，返回失败。密码加密，需要双方协定。现在暂时不提供预站订户的查询。 ★业务编码见表2 ★处理结果见表3，必须说明结果码，固定4位，如果处理失败，返回结果中的结果码。 ★时间统一为yyyyMMddHHmmss，日期统一为yyyyMMdd，金额使用“分作”为基本单位。
1订户基本信息查询
实现“订户信息基本查询”的报文内容见表4～表7。
2柜面业务
编者注：由于篇幅所限，柜面业务中包含的，订户已订购业务查询、计算订购费用、订购、计算续定费用、续定、冲正、银行柜面业务对账等项业务的按文内容图表略去。
数据文件格式
为了保证数据传递的安全性，对数据文件采用进行数字签名的方法进行保护。在数字签名前不要对数据采用补空和补0。具体方法是对数据文件中的每一行数字签名前面的数据(不包括数据签名前面的竖线)进行数字签名。字段之间以“1”分隔，对每条记录信息采用MD5算法进行数字签名，银行终端需要针对每条记录进行数字签名校验，如果有校验不通过的记录，SMS系统不处理该结算文件，数字签名同报文的校验字段算法，以数据内容(最后一个字符不为“1”)作为信息字段。文件最后一行统一以‘#’表示文件的结束。
1、柜面文件对账
此文件由银行提供给SMS，其内容是SMS用户通过银行柜面业务的明细(文件内容不包括冲账记录)。
a．文件名格式 格式为CHKyyyyMMddXXX，dat，其中yyyyMMdd表示日期，XXX表示编号。
b．文件内容格式：明细文件内容＝文件头＋文件体＋文件结束符。
文件第一行为文件头，最后一行为文件结束符，文件头格式定义见表8。例如：00000120000000123400表示扣款记数为120条，总费用为1234元。
文件中的每一行格式为useridlfeelserialnolsign“1”分隔符内的每个这段都不要采用补空和补0来填充满足字段的位数长度，下同。
参数说明：
userid 用户ID，如“000000000001”
fee
银行代收金额，以分为单位
serialno银行扣款流水号
sign
数字签名
c．文件体中记录按银行扣款流水号进行升序排序。银行给出的对账文件必须包括某段流水号之间的所有记录，
因为对账时是针对某段流水账号之间的所有记录，如果本次不是给出所有指定流水号之间的记录，那么下次又把上次没有对账的流水号所对应的记录取出来对账，则会造成对账时会把正确的记录都取消掉或者作为一笔错识的帐目。
2、柜面业务对账不一致的文件
此文件由SMS提供给银行，当对银行柜面业务对账出现了银行存在而SMS不存在的记录，则记录在该文件中，某笔对账明细不一致时也放在对帐不一致文件中返回。
a．文件名格式：DISyyyyMMddXXX，dat，其中yyyyMMdd表示日期，XXX表示编号。
b．文件内容格式：明细文件内容＝文件体＋文件结束符。
文件中的每一行格式为useridlfeelserialnolsign。
3、代扣金额列表文件
此文件由SMS提供给银行，内容是用户在结算月应缴纳的费用的明细。
a．文件名格式：文件名格式为FEEyyyyMMddXXX，dat，其中yyyyMMdd表示日期，XXX表示编号。
b．文件内容格式：明细文件内容＝文件头＋文件体＋文件结束符。
文件第一行为文件头，最后一行为文件结束符，文件头格式定义见表9。例如：00000120000000123400表示扣款记数为120条，总费用为1234元。
文件体中的每一行格式如下
useridlsettlemonthlproductidluserindexlfeelmonthlsign。
(编者注：由于篇幅所限，带扣列表文件和带扣银行记录对账文件具体参数略)