最近在跟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:\inetpub\logs\LogFiles\W3SVC2下面的u_ex120305.txt里面發現了一條500錯誤，我們再去看C:\inetpub\logs\FailedReqLogFiles\W3SVC2下面有什么變化，這時候這個路徑下面多了一些fr0000開頭的XML文件，那么我們來打開這個最新的文件，來分析一下。
見紅色標注的地方就是問題所在，原來是一個字段的類型定義錯了，導致QAD那邊調用接口在序列化的時候報錯了，問題解決。