接口调测经验集文档.docx
- 文档编号:6065007
- 上传时间:2023-05-09
- 格式:DOCX
- 页数:14
- 大小:23.47KB
接口调测经验集文档.docx
《接口调测经验集文档.docx》由会员分享,可在线阅读,更多相关《接口调测经验集文档.docx(14页珍藏版)》请在冰点文库上搜索。
接口调测经验集文档
DTPROXY部分2
动态库与应用程序相关的函数2
业务发送包体都是ERRORMESSAGE2
只有发送报文没有返回报文2
座席部分3
AppDebug调用接口正常返回,坐席调用对应接口无反应3
坐席调用接口马上超时3
IVR部分4
IVR日期报音错误4
接口收不到流程发的数据包5
TUXEDO部分6
服务端程序异常退出6
PRO*C中宿主变量的申明6
DTPROXY部分
动态库与应用程序相关的函数
作者
严进才
日期
2004-07-28
问题产生背景
DllGetMsgLenDllGetReplyMsgTypeDllGetApplyIndex的用途
问题定位过程
我们一般在开发接口程序时往往只注重:
DllTransIVRMsg、DllTransAppSvrMsg、DllTransAppSvrMsg、TransToAppSvrMsg四个函数,因为常常也只需要修改他们即可,其实,DllGetMsgLenDllGetReplyMsgTypeDllGetApplyIndex与drproxy的联系更为紧密,如果我们与boss之间的包结构发生了改变,他们是必须被重写的,
在定位异常时他们也更为有用。
结论及处理方式
业务发送包体都是ERRORMESSAGE
作者
顾琛
日期
2004-7-28
问题产生背景
重庆联通反映很多业务发送包体都是ERRORMESSAGE
问题定位过程
根据对方发过来的日志和配置文件,发现配置和调用的命令字都是正确,单步调试DllTransIVRMsg时发现找不到对应的配置项,而配置项看起来却没有什么问题啊,继续跟踪GetParamFromICDName,发现这里在查找命令项的时候多了一条判断,除了报文的调用存储过程和配置项一致外,还加上了数据库的配置也必须一致这一条,因为没有为每一个业务对应的配置项配置相应的数据源,所以判断总是错误的.
结论及处理方式
每个局的具体要求都不一样,有的局就没有对数据源配置的要求,而有局就有,根据实际情况来配置,不要想当然
作者
王玉伟
日期
2004-7-29
问题产生背景
业务发送包体都是ERRORMESSAGE
问题定位过程
根据对方发过来的日志和配置文件,发现在DtProxy.ini文件或DtProxyDll.ini文件中没有对应的命令字的配置项,一定要保证两个配置文件都有该命令字的配置.现场多次反馈这种问题。
结论及处理方式
配置文件没有配置正确。
只有发送报文没有返回报文
作者
顾琛
日期
2004-7-28
问题产生背景
发送包体无应答包,即BOSS没有对应请求的返回
问题定位过程
其实问题很简单,根据现场的配置文件,很快就看出是MiddleWareInterface没有和现场配置一致,路由选择错误.改的和现场一致即可
结论及处理方式
这个问题很简单,很容易就能找出来,但为什么还是出了这个问题呢,这反映了我在工作中的不细心,在写现场升级说明的时候很多都是从别的地方copy过来的,然后稍加修改,也没有对一些各个现场可能不同的地方进行详细说明,要做好一件事是由做好每件小事为基础的
接口如何定位问题
作者
徐文富
日期
2005-05-30
问题产生背景
20027命令字返回值出错,比应有字段少
问题定位过程
20027人工业务返回值出错。
1,分析现场发来的日志,刚开始定位在Boss返回值的奖品字段。
2,配置testivr,dtproxy,myboss,搭建测试环境。
3,用现场发来的数据做模拟,对现场发来的dll用testivr进行单步请求,记录日志。
4,查看message.log重新分析,发现dtproxy对命令字20027的返回值
做了不必要的处理,数据被截断。
5,定位到程序中的代码段进行处理。
6,重新配置测试环境,用现场的数据测试改过的接口。
7,分析日志,问题解决。
结论及处理方式
原因:
现场的dll在20027命令字的处理上存在问题
解决方法:
逐步跟踪定位错误,找到问题所在,修改接口
座席部分
AppDebug调用接口正常返回,座席调用对应接口无反应
作者
姚雷斌
日期
2004-06-29
问题产生背景
AppDebug调用接口正常返回,坐席调用对应接口无反应。
问题定位过程
汕头移动开局时碰到该问题,仔细分析以后找到原因及解决方法。
结论及处理方式
原因:
service.cfg文件配置不正确造成。
例如:
某service.cfg文件中StartFieldName=Z,StartFieldIndex=1。
则Iuas服务器返回给AppDebug和坐席的XML文件中字段的标题依次是Z1、Z2、Z3…。
AppDebug能够接受该标题并正常显示;但是坐席默认的标题格式为C0、C1、C2…,所以无法正常显示。
解决方法:
修改service.cfg文件如下。
StartFieldName=C,StartFieldIndex=0。
座席调用接口马上超时
作者
姚雷斌
日期
2004-07-29
问题产生背景
坐席调用接口马上超时
问题定位过程
8,在坐席上查询用户资料时,刚按下查询按钮,接口就返回”Timeout”.
9,查看坐席的超时设置,30秒,正常。
10,查看Iuas上的超时设置,20秒,正常。
11,查看DtProxy上该命今字的超时设置,10秒,正常。
12,用AppDebug查询同样命令字,返回”Time(20s)isouttosendrequesttoDtProxy”。
13,查看DtProxy日志,并没有收到该请求,怀疑该命令字发送没有成功。
14,检查Iuas服务器,发现原因是icdcomm服务已经down掉了。
15,
结论及处理方式
原因:
Iuas服务器上icdcomm服务down掉,导致调用接口马上返回超时。
解决方法:
重新启动Iuas服务器上的icdcomm服务。
如何规避座席自动升级时发生死循环
作者
蓝善议
日期
2005-05-31
问题产生背景
坐席自动升级时发生死循环
问题定位过程
坐席自动升级时发生死循环。
1、将要升级的文件COPY到升级FTP服务器;
2、更改升级文件夹update下的配置文件ICDUpdateConfig.ini;
3、修改数据库表t_pub_systemparam的坐席最近升级时间值;
4、直接使用换班方式进行升级测试;
5、坐席自动重启,并提示有新版本,要进行升级;
6、升级后坐席又重新启动,并还是提示有新版本,要准备升级;
7、如此一直循环;
8、打开任务管理器,将坐席进程强行停止;
9、重新启动坐席,提示有新版本,要进行升级;
10、升级后坐席启动进入正常界面,没有出现死循环的现象;
结论及处理方式
原因:
目前全国采用自动升级版本的坐席ICDSC均存在BUG:
采用换班方式进行升级将会出现升级死循环;
解决方法:
一边提示各话务人员采用重新启动坐席的方法进行规范升级;一边联系公司ICD3.0的研发部门修改此BUG;
座席转流程时流程返回密码给坐席的取得
作者
顾琛
日期
2005-03-26
问题产生背景
坐席转流程时流程返回密码给坐席的取得
问题定位过程
因为河南移动的自动业务办理需要转自动流程密码验证,然后获得密码给返回给坐席。
以下是取得自动流程返回密码的函数
结论及处理方式
FunctionGetIVRPassword
SetDmApp=CreateObject(“ICDSC.DMCtrl”)
GetIVRPassword=DMCtrl.GetReceptInfo
(1)
EndFunction
座席定制页面提示无效的xmldata对象
作者
顾琛
日期
2005-03-28
问题产生背景
一些坐席页面查某些号码时会弹出错误对话框,提示无效的xmldata对象
问题定位过程
单步跟踪发现执行以下语句后:
SetXMLData=CreateObject("Microsoft.XMLDOM")XMLData.loadxml(Output(3))
后xmldata对象不存在,在调用一些dom接口时就失败了
结论及处理方式
用appdebug能查的出来,但将查询结果保存为xml文件时出错,判断是dtproxy某个字段的width长度不够,修改width后问题解决
座席获取不到DTProxy返回的数据
作者
方明星
日期
2005-05-31
问题产生背景
福建移动座席获取不到DTProxy返回的数据
问题定位过程
通过对座席程序的各配置进行检查没有发现配置问题,检查了IUAS服务器关于接口机配置方面的选项(iuas.cfg,app.ini,service.cfg)也没有发现问题,各配置都正确。
利用testIVR做发包测试,能够正确获取到返回数据。
座席发送请求后,在Dtproxy能够收到请求包,而且DTProxy返回数据,检查日志仔细核对应答消息包内容都正确。
那么问题出现在哪呢,好象都没有问题。
最后检查DtProxy的Message.log日志发现,各ICD包消息上的IP值不正确,为:
[2004/01/0913:
53:
14]ICD=loginIP=0.0.0.0ID=50,为0.0.0.0,
正常情况下应为发包的iuas服务器的地址。
问题终于露出水面,为iuas端icdcomm发送请求时送的服务地址IP不正确。
经检查,原来那台iuas服务器装了两个网卡,两网卡之间可能发生地址冲突造成以上情况。
结论及处理方式
将两网卡中的其中一块禁用后问题解决。
IVR部分
IVR日期报音错误
作者
杜小猛
日期
2004-06-27
问题产生背景
佛山IVR报音错误,将“200402”六位日期格式报为“20年4月2日”
问题定位过程
1.根据现象可以判断数据处理有误。
要求现场发送现场日志,对日志进行分析。
2.发现返回数据没有问题,为“200402”,转换后的数据也符合6位日期格式,经过远程拨测,发现播音存在问题,查看数据“200402”,如果按日两位数据,月两位数据,年四位数据,从右取数据,刚好符合报音:
“20年4月2日”。
3.为了验证此想法,测试东莞返回的数据(东莞现场无此问题),发现东莞返回为8位日期格式。
4.初步定位问题是返回日期格式错误,修正代码,补齐8位日期格式,现场测试,问题解决。
结论及处理方式
此问题,在协议中没有明确规定BOSS返回数据是8位还是6位日期数据,而SPT播音需要的是8位日期格式(年月日)。
修正程序,使它可以识别BOSS返回的日期格式,并做相应处理,代码如下:
strMonth.TrimLeft('');
strMonth.TrimRight('');
for(inti=0;i<8;i++)
{
if(strMonth.GetLength()>i)
{
if(strMonth.GetAt(i)<'0'||strMonth.GetAt(i)>'9')
{
strMonth.SetAt(i,'0');
}
}
else
{
strMonth.Insert(i,"0");
}
}
strMonth=strMonth.Left(8);
接口收不到流程发的数据包
作者
姚雷斌
日期
2004-07-28
问题产生背景
接口收不到流程发的数据包。
问题定位过程
接口收不到流程发的数据包。
16,用Ping检查IVR和DtProxy之间的网络连通知性,发现正常。
17,检查DtProxy.ini文件,DataSource配置为icdboss,正常。
18,检查配置台上接口数据源的配置,发现已经加了icdboss,并且指向的ip地址也正确。
19,请流程人员检查流程中配置的数据源,确认为icdboss,正常。
20,怀疑icdcomm有问题,重装icdcomm,用testivr发包确认icdcomm正常。
21,此时,实在是想不出其他原因了。
用网络工具抓包,确认DtProxy所在机器没有收到IVR发来的TCP包,重新怀疑流程方面数据源配置有问题。
22,在DtProxy机器上配置数据库的数据源icdboss(明知不需要,还是试了一下),还是收不到流程发过来的数据包。
23,数小时后,终于找到了问题原因:
在配置台上有一个资源管理,其中列出了所有数据源,在icdboss的复选框上打勾,启用该数据源即可。
结论及处理方式
原因:
配置台上icdboss数据源虽已增加,但是没有启用。
解决方法:
配置台上有一个资源管理,其中列出了所有数据源,在icdboss的复选框上打勾即可。
TUXEDO部分
服务端程序异常退出
作者
严进才
日期
2004-06-28
问题产生背景
浙江移动电子化维护服务端程序异常退出
问题定位过程
1、仔细走读源代码未发现异常。
2、在公司搭好测试环境,反复测试,错误没有重现
3、根据现场发过来的日志及真实数据进行测试,错误重现
4、单步调试发现在调用userlog时异常出现,将userlog注释掉,程序正常运行。
5、查看tuxedo的联机帮助,发现如下下面一句话:
userlog()hangsifthemessagesenttoitislargerthanBUFSIZasdefinedinstdio.h
6、改用其他方式记录日志,问题解决。
结论及处理方式
Tuxedo的日志记录函数userlog可以打印的缓冲区的长度有限,不超过在stdio.h文件中定义的BUFSIZ的长度
在调用第三方厂商提供的API函数时,一定要注意他的限制条件。
。
调用TUXEDO服务成功,取数据失败
作者
王玉伟
日期
2004-07-30
问题产生背景
调用TUXEDO服务成功,取数据失败
问题定位过程
1、调用TUXEDO服务成功,但取数据失败,查询协议字段长度一致,使用TUXEDO自带的函数Fprint32,打印缓存区数据,能够成功打印出所取的数据。
2、根据打印出的数据,怀疑还是字段长度不够,加大取数据的长度,确实取到数据。
结论及处理方式
Tuxedo的数据长度比正常C的字符长度大一,但是有的时候确实不对,加大取数据的缓冲区就可以解决问题。
BOSS厂家开发人员也对之感到莫名。
PRO*C中宿主变量的申明
作者
顾琛
日期
2004-6-29
问题产生背景
PRO*C中宿主变量的申明
问题定位过程
我的Tuxedo客户端在tpcall调用服务端的服务,返回数据总是TPFAIL超时,后来定位到是FETCH光标时抛出错误,执行到sqlerror错误处理中去了.估计可能是宿主变量长度不够,修改后果然是这样子的
结论及处理方式
当数据库表中定义为VARCHAR2,VARCHAR和char的字段,在PROC中可申明为CHAR,但长度应该比他们在表中定义的长度加1,因为PROC中的char型变量用\0做结尾
如:
ENAME在表中定义为enamevarchar2(10),在proc中可申明为
EXECSQLBEGINDECLARESECTION;
Charename[11];
EXECSQLENDDECLARESECTION;
如果插入的字符串长度大于10,会出现以下错误:
error:
ORA–01480;
C++部分
strncmp和memcmp的区别
作者
唐维理
日期
2005-5-31
问题产生背景
strncmp和memcmp的区别
问题定位过程
intmemcmp(constvoid*cs,constvoid*ct,size_tcount)
{
constunsignedchar*su1,*su2;
intres=0;
for(su1=cs,su2=ct;0 if((res=*su1-*su2)! =0) break; returnres; } intstrncmp(constchar*cs,constchar*ct,size_tcount) { registersignedchar__res=0; while(count){ if((__res=*cs-*ct++)! =0||! *cs++) break; count--; } return__res; } 对于memcmp(),如果两个字符串相同而且count大于字符串长度的话,memcmp不会在\0处停下来,会继续比较\0后面的内存单元,直到_res不为零或者达到count次数。 对于strncmp(),由于((__res=*cs-*ct++)! =0||! *cs++)的存在,比较必定会在最短的字符串的末尾停下来,即使count还未为零。 具体的例子: chara1[]="ABCD"; chara2[]="ABCD"; 对于memcmp(a1,a2,10),memcmp在两个字符串的\0之后继续比较 对于strncmp(a1,a2,10),strncmp在两个字符串的末尾停下,不再继续比较。 结论及处理方式 如果想使用memcmp比较字符串,要保证count不能超过最短字符串的长度,否则结果有可能是错误的。 EOMS接口 工单派发死锁 作者 顾琛 日期 2005-04-28 问题产生背景 河南eoms工单派出反复失败,一条工单堵死了所有其他的工单 问题定位过程 3.0工作流的Eoms的soapclient程序会定期扫描存储过程,获得派单数据,派发成功后再调用相应的存储过程取走该工单,这里有个bug,因为工单成功后才会被取走(与2。 0不同,2。 0先取走,失败再置标志位回来),所有的工单都因为这条工单卡死了。 结论及处理方式 增加了工单流水号的判断,同一条流水号的工单连续超过指定次数就调用相应的处理存储过程 SoapServer飞掉问题 作者 顾琛 日期 2005-03-28 问题产生背景 河南eoms的soapserver有时候飞掉的问题 问题定位过程 河南eoms程序有几次飞掉,单步跟踪消息发现在soapc。 C的serialize里出了问题,原来是在错误字段在调用soap_malloc时分配的内存不够大,这里分配内存的大小用的默认的一个值。 而错误的数据调用存储过程返回 结论及处理方式 将默认的错误字段大小更改后就ok了 发送附件名称是“? ? ? ”的问题 作者 顾琛 日期 2005-05-30 问题产生背景 河南eoms反映有些工单附件名称是“? ? ? ”点击后也没有反应 问题定位过程 河南eoms传送附件是发送附件名和附件的url,很可能是因为附件是中文,而发送过去时用的不是unicode字符 结论及处理方式 用wchar_t数组保存附件名和附件url即可
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 接口 经验 文档