最近在跟QAD用Webservice搞接口做数据维护,搞的哥那个叫头大,遇到很多问题,系统的log4net根本就无法记录。话说QAD调我某一个接口,可能包含几百个字段,而且QAD是个产品,所以我这边提供的维护接口,必须符合QAD的接口标准。
没办法谁让咱是搞程序的呢,再苦再累也得上。这时候我突然相倒了,webservice是基于IIS的,那么基于IIS必须有IIS日志,那么我就从IIS日志入手解决这些问题。
问题示例:QAD调用我方接口,返回消息“<QdocProcessingException>HTTP/1.1 500 Internal Server Error</QdocProcessingException>”,该接口传入参数为对象,对像中包含加密口令,Maintain对象,其中Maintain对象中包含上百个字段,接口方法中有详细的日志日录,方法返回的是一个已定义对象。在QAD调用我方接口的过程中,并未产生相关日志记录。
分析:首先从返回消息格式上看,该返回消息并非是预定义的返回对象,从返回消息内容上看,该消息属于明显的500错误,也就说肯定是我方接口存在一些问题,但是具体是哪里出问题,现在不清楚。其次从问题中可以清晰的了解QAD并未调用到接口中方法,否则方法中的日志记录可以捕获到异常信息,从其他情况来看,QAD已经调用到我方接口,但是在调用进入方法之前出了一点小差错,预计可能是传入对象出错了,但是对象包含上百个字段,如何排查是哪个出错了,即便这次排查成功,那么下次呢。想到此我的汗毛都竖起来了,不过没关系,谁让咱是程序员呢。
解决方法:不是有IIS日志的吗,注意:iis日志只会记录这次请求是500错误,但是具体错误内容还得配置一番,请看详解。
在IIS配置里面有个Failed Request Tarcing Rules,我们New一个Rules。
我们来新建一个500错误,OK,这次我们再用QAD来调用一次我们的接口。
这次我们发现在C:inetpublogsLogFilesW3SVC2下面的u_ex120305.txt里面发现了一条500错误,我们再去看C:inetpublogsFailedReqLogFilesW3SVC2下面有什么变化,这时候这个路径下面多了一些fr0000开头的XML文件,那么我们来打开这个最新的文件,来分析一下。
见红色标注的地方就是问题所在,原来是一个字段的类型定义错了,导致QAD那边调用接口在序列化的时候报错了,问题解决。