Zvdfasdfsadfa

Rogman

CP子系统接口设计

1.   概述
为了方便我们公司的短信业务与CP展开合作，并实现统一的系统接口规范，特提供本技术文档，供CP来设计其系统。

2.   系统结构设计
2.1      系统结构图
系统结构如下图所示——

说明：
SP一旦接收到来自移动短信网关的上行，即通过自有的MO发送接口，将该上行发送到指定CP的接收接口程序，CP收到MO数据包后进行处理，生成MT之后再发送到SP的“MT接收接口”，最终交由SP的短信网关进行下发。

2.2      程序模块拓扑图
系统中相关的程序模块结构如下图所示——

2.3      系统技术接口
2.3.1                   CP端的MO接收接口
具体的接口技术规范由SP给出，CP厂商按照该技术规范开发出一个接口程序，并部署到一个可以经互联网访问的服务器上，同时把相关接口参数提供给SP。
如果接口符合SP的规范要求，并且参数访问无误，则SP会把相应的MO数据包通过该接口传递给CP。
详细的技术规范请参阅第3章。

2.3.2                   SP端的MT接收接口
SP会提供一个统一的标准接口，提供给所有的CP调用，CP调用该接口程序，把需要发送的MT数据包传递给SP。
SP接收到来自CP的MT记录后，会核对数据信息，如果符合下发条件，则通过短信网关下发到用户手机，并返回正确处理的代码；如果不符合下发条件，或数据内容有误，则返回相应的错误代码。
详细的技术规范请参阅第3章。

3.   系统接口设计
3.1      协议规范定义
3.1.1                   MO数据包定义
每个MO记录数据包中将包含如下字段内容：
字段名称
类型
描述
recID
数值型
MO记录流水号（在对点播类MO回复处理的MT记录中，应该填上原始MO的recID，请参阅
MT数据包定义
）
srcTermID
字符串
发出MO的用户手机号
destTermID
字符串
MO记录要发送的目标号码，即SP的接入号（短号码＋长号码）
linkID
字符串
MO记录中的LinkID字段内容，在对点播MO作出回复处理时，应该在相应的MT记录中回填该字段内容
msgContent
字符串
MO消息内容，即上行指令

3.1.2                   MT数据包定义
每个MT记录数据包中将包含如下字段内容：
字段名称
类型
描述
moRecID
数值型
如果由MO引起的MT，应该将相应的MO包中的字段recID的值填入到该字段中，请参阅
MO数据包定义
；
对于Push的MT，该字段内容填0；
srcTermID
字符串
MT记录中需要显示的SP的长号码，如果是由MO引起的MT，则使用MO包中的destTermID字段内容；
对于主动Push的MT，请使用SP分配给CP的号码；
destTermID
字符串
MT下发的目标手机号
feeTermID
字符串
MT下发的记费手机号码
linkID
字符串
对于点播引起的MT，将相应的点播MO的LinkID字段内容填写到此处；
对于Push的MT，该字段内容可以为空字符串
msgContent
字符串
下行消息文本
mtType
数值型
1：点播引起的下行；2：Push下行
businessCode
字符串
业务代码；
SP根据与CP合作的内容和方式，给CP分配一个或多个businessCode，每一个businessCode对应一个业务，例如：SP给CP分配一个点播和Push下行通道，相应的businessCode是A和B，CP在点播的回复MT包中，该字段应该填A，在Push的MT中，该字段应该填B。
如果该字段填写了一个未分配的值，则会返回错误代码；

3.2      CP端的MO接收接口定义
为了能接收来自SP的MO数据包，CP需要按照SP提供的协议及规范来开发一个接口程序，并部署到一台Internet主机上，供SP的系统来调用。

3.2.1                   接口类型
CP端的MO接收接口采用HTTP的方式来实现，SP通过POST调用的方式通过该HTTP接口传递给CP。CP可以使用不同的开发工具来实现该接口，例如CGI、ASP、JSP、.NET、PHP诸如此类。
接口部署好之后， URL的形式如
http://cp_web_server_ip/mo_recv.asp?params=...

3.2.2                   接口参数
接口具有一个参数，即“modata”。
SP传递的modata的原始内容是XML格式，具体格式请参阅后续介绍，XML文本内容经过3DES加密后，再使用Base64编码。
下面给出modata的XML格式示例——
   32943
   13812345678
   501323
   09104501620300746064
   上行指令内容
SP会给每一个CP分配一个用于3DES加密解密的密钥，SP使用该密钥对上面的XML文本进行3DES加密，随后再进行Base64编码，紧接着发送给CP的指定接口。

3.2.3                   接口返回值
CP收到从SP传递过来的数据后，解析出modata的参数值，经过Base64解码，3DES解密，得出XML文本数据后再分解出MO包各字段的值。
如果CP成功地接收并解析出MO的内容，则应通过HTTP返回文本内容“SUCCESS”，否则返回“FAIL”。

3.3      SP端的MT接收接口定义
为了使CP能把要发送的下行传递给SP，SP提供统一的MT接收接口，CP使用指定的协议把相关数据通过该接口传递到SP的系统中，SP根据处理的情况返回不同的结果值。

3.3.1                   接口类型
SP提供统一的HTTP接口接收来自CP的MT数据包，CP应采用POST的方式把数据送给SP。接口URL示例——
http://sp_web_server_ip/mt_recv.asp?params=...

3.3.2                   接口参数
该接口具有如下参数——
参数名称
描述
cpguid
CP标识，由SP统一分配静态的标识字符串给CP，用于标识每一个CP的身份，其格式采用GUID类型，例如：{BC08D3B2-36E5-48a2-AF0A-4ABA679ADC90}
mtdata
MT数据包内容

CP在传递数据给SP时，应使用SP分配好的标识通过参数cpguid传递，否则将无法被正确识别。
CP传递的mtdata数据包的原始内容是XML文本，具体格式请参阅后续介绍，XML文本内容经过3DES加密后，经Base64编码后传递给SP。
下面给出mtdata的XML格式示例——
   32943
   501323
   13812345678
   13812345678
   09104501620300746064
   下行指令内容
   1
   ABC

SP会给每个CP分配一个CPGUID，和一个用于加密解密的密钥，CP使用密钥把MT包的XML文本加密后，经Base64编码，再传递给SP。

3.3.3                   接口返回值
SP的MT接收接口接收到数据包后，进行3DES解密处理，然后再使用Base64解码，最后再解析出XML包中的MT详细信息。
调用结束后，接口通过HTTP返回一个数字代码，具体意义，请参照下面表格——

返回代码
描述
0000
成功。
1001
发送服务器地址鉴权失败。
1002
身份校验失败，CPGUID不存在。
1003
Base64解码或3DES解密错误。
1004
不能正确解析MT包，无效的XML文件格式。
1005
被拒绝，无效的业务代码或接入号。
1006
被阻止，下行内容中包含不良信息。
1007
被拒绝，点播MO记录不存在,无效数据。
1008
url传入参数无效。
1009
点播回复下行数量超出限制条数。
1010
被拒绝,无效的MtType。
1011
被拒绝,Post数据包超长。
1012
失败，其他错误。


4.   加密解密的说明
  加密的说明
加密规则和SP提供的规则完全一致。
采用3DES加密, ECB模式/使用PKCS7方式填充不足位,目前给的密钥是192位(24个字节)经过BASE64编码后的可见字符串。

加密流程
1.对获得的密钥进行Base64解码(解码后的密钥是字节数组)
2.使用编码后的密钥用3DES对源字符串加密(加密后的字符串也是字节数组)
3.对加密后的字符串进行Base64编码(编码后的是经过Base64编码的字符串)

以下为一个加密的例子：

密钥的base64编码是：
MTIzNDU2Nzg5MDEyMTIzNDU2Nzg5MDEy
源字符串是：
3DES以及Base64编码后的字符串:XiUyBYi83+DRdMQJ/AcwYg==

解密就是加密的逆过程。

解密流程
1.对获得的密钥进行Base64解码(解码后的密钥是字节数组)
2.对加密后的字符串进行Base64解码(解密后的字符串也是字节数组)
3.使用解码后的密钥用3DES对Base64解码后的字符串解密。

解密的例子：
密钥的base64编码是：
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAyMjEx
解密前的字符串：
gsYZ2zCdoxBzukNbQKivZA==
Base64以及3Des解码后的字符串:





本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/14401/showart_139267.html