【文章內(nèi)容簡介】 ID的消息，或者VASP收到有關(guān)無法識別以前所提交消息和消息ID的報告，將返回此代碼。2006Linked ID not found找不到鏈接ID如果已提供LinkedID，但MMSRelay/ServerRelay/Server找不到相關(guān)消息，將返回此代碼。2007Message format corrupt消息格式破壞信息單元值格式不合適或不正確。3000Server error服務(wù)器錯誤服務(wù)器未能實施明顯有效的請求。3001Not possible消息不可接受由于不可接受，而無法執(zhí)行請求。此狀態(tài)碼通常在以下情況中使用：當對不能再被取消或狀態(tài)查詢的消息進行取消或狀態(tài)查詢操作時。MMSRelay/ServerRelay/Server已識別所述消息，但由于該消息已完成或其狀態(tài)不再可用而無法實施。3002Message rejected消息被拒絕服務(wù)器無法完成請求的服務(wù)。3003Multiple addresses not supported不支持多個地址MMSRelay/ServerRelay/Server不支持對多個接收方執(zhí)行此操作。該操作可以作為多個單一的接收方操作重新提交。3501Too many recipient addresses超出系統(tǒng)容許的最大接收方數(shù)目超出MMSRelay/ServerRelay/Server支持的最大接收方數(shù)目。該操作可以作為多個單一的接收方操作重新提交。4000General service error一般服務(wù)錯誤無法實施請求的服務(wù)。4001Improper identification標識不正確（是否在頭部包含相關(guān)字段，例如vaspid等）請求的標識標題不能唯一標識客戶機（VASP或MMSRelay/ServerRelay/Server）。4002Unsupported version版本不支持不支持MM7版本單元所指示的版本。4003Unsupported operation操作不支持服務(wù)器不支持消息標題中“消息類型”單元所指示的請求。4004Validation error驗證錯誤無法解析SOAP和XML結(jié)構(gòu)、缺少必備字段或消息格式與指定格式不兼容。“詳細信息”字段可能會給出導致此狀態(tài)的解析錯誤。Validation error : Decoder failedSOAP解碼失敗Validation error : Error request type錯誤的請求類型Validation error : Soap message is null從HTTP請求中獲取不到SOAP消息Validation error : Field 39。 xxxxx 39。 must be filled缺少必要的字段xxxxxValidation error : Field 39。 xxxxx 39。 incorrect字段xxxxx填寫不正確4005Service error服務(wù)錯誤操作導致服務(wù)器（MMSRelay/ServerRelay/Server或VASP）失敗，不應(yīng)重新發(fā)送。Service error : Server timeout從SERVER獲取響應(yīng)超時4006Service unavailable無法提供服務(wù)當服務(wù)器暫時不可用（例如，服務(wù)器忙、系統(tǒng)過負荷）時，服務(wù)器可能會發(fā)送此指示。Service unavailable : System is busyMMSC系統(tǒng)處于忙狀態(tài)4007Service denied服務(wù)被拒絕客戶機無權(quán)執(zhí)行所請求的操作。Service denied : Authority failed對CP/SP簽權(quán)失敗　 對CP/SP的計費方式目前對CP/SP的計費要求在發(fā)送MM的時，在MM7SubmitReq消息的ChargedParty字段中填寫付費方，指明CP/SP所提交MM的付費方，例如，發(fā)送方、接收方、發(fā)送方和接收方、兩方均不付費、第三方付費，在付費方既不是發(fā)送方，也不是接收方的情況下，需要使用Charged party ，這樣在MMSC系統(tǒng)中對這條MM的計費就是對付費方號碼計費。ChargedParty字段填寫值的含義：0：發(fā)送方和接收方都不付費；1：發(fā)送方付費；2：接收方付費；3：發(fā)送方和接收方都付費；4：第三方付費；在群發(fā)時因為一次可以填寫多個接收方地址但是只有一個ChargedParty，這時會對這個付費方號碼計費多次?！?如何實現(xiàn)群發(fā)對于一條消息，目前支持一次發(fā)送給多個接收方地址?？梢哉{(diào)用MM7SubmitReq的addTo()、addCc()、addBcc()方法分別添加接收方地址、抄送方地址和密送方地址，但是一次發(fā)送的地址的總數(shù)不能超過系統(tǒng)配置。另外對于一次發(fā)送多個地址的情況，在MMSC系統(tǒng)中會對業(yè)務(wù)定制方計費多次?！?消息內(nèi)容體中的ID在組裝消息內(nèi)容(MMSContent)的時候，一定要設(shè)置該消息內(nèi)容的ID，可調(diào)用的方法有setContentId()和setContentLocation()兩個方法。在消息的格式是MULTIPART_MIXED格式時，只要調(diào)用setContentId()方法即可，如果消息格式是MULTIPART_RELATED時，setContentId()和setContentLocation()兩個方法都要調(diào)用，并且建議這兩個方法設(shè)置的值一致。對各個消息內(nèi)容體設(shè)置的消息ID一定要是唯一的，否則會發(fā)生消息內(nèi)容混亂?！?標題的編碼方式標題的編碼目前在程序內(nèi)部使用的是UTF8方式，所以在使用MM7SubmitReq的setSubject()方法時要保證傳入的標題字符是unicode格式的?？梢酝ㄟ^使用new String()方法對標題作一次強制轉(zhuǎn)換?！?文本內(nèi)容的編碼方式文本內(nèi)容的編碼要求是UTF8方式，所以在把文本內(nèi)容轉(zhuǎn)換為byte[]數(shù)組的時候，要保證轉(zhuǎn)換前是unicode格式的。可以通過使用new String()方法對文本內(nèi)容作一次強制轉(zhuǎn)換。　 目前主要使用的消息內(nèi)容體格式可以參見WAP203WSP (WAP Forum)文檔相關(guān)部分。下面是目前MMS手機支持的主要格式：audio/midaudio/midiaudio/xmidaudio/xmidiaudio/spmidiimage/image/jpegimage/gifimage/bmpimage/image/pngimage/vndnokcamerasnspimage/text/text/text/xcodesctext/xvCalendartext/xvCardtext/plaintext/xeMelodytext/xiMelody在MMSConstants中以CT_TEXT和CT_IMAGE開頭的變量都是這些格式，可以直接引用，但是該類中列舉的格式不多?！?填充消息內(nèi)容體時的注意事項具體的注意事項在下面的例子中進行說明MMSContent mmc = new MMSContent ()。byte[] content = null。try{//填寫消息內(nèi)容的時候要注意編碼方式，這兒填寫的消息內(nèi)容是文本字符串，要使用UTF8編碼方式content = new String( 歡迎使用彩信 ).getBytes( UTF8 )。}catch( Exception e ){content = new byte[0]。()。}(content, 0, )。 //添加內(nèi)容體 (. TEXT)。 //設(shè)置內(nèi)容體格式。填寫的格式一定要和內(nèi)容的實際格式相同。( 內(nèi)容ID)。 //設(shè)置該內(nèi)容在該消息中的ID,必須設(shè)置,而且一定要保持它的唯一性,否則會丟失消息內(nèi)容。(mmc)。 //將創(chuàng)建好的內(nèi)容添加到消息　 使用SMIL格式傳輸消息時的注意事項具體的注意事項在下面的例子中進行說明。組裝消息內(nèi)容的代碼片斷：MM7SubmitReq req = new MM7SubmitReq()。構(gòu)造一個媒體容器MMSContent mainContent = new MMSContent()。//設(shè)置消息類型，使用SMIL方式一定要設(shè)置為”multipart/related”類型()。//設(shè)置當前對應(yīng)內(nèi)容ID，必須設(shè)置這個屬性，使用SMIL方式時建議設(shè)置為smil文件名mainContent. setContentID( )。創(chuàng)建多個消息內(nèi)容體并添加到多媒體消息對象中//構(gòu)造第一個消息內(nèi)容，這是一個smil文件，一定要設(shè)置該消息內(nèi)容的類型為application/smil，其中smil文件中描述了要添加的發(fā)送的消息內(nèi)容體MMSContent mmc = new MMSContent ()。byte[] content = null。try{content = readFromFile( E:\\ )。 //讀取smil文件的內(nèi)容}catch( IOException e ){content = new byte[0]。()。}(content)。 //把讀取的SMIL文件內(nèi)容添加進消息容器中()。 //設(shè)置內(nèi)容體格式，對于內(nèi)容是smil文本內(nèi)容，必須設(shè)置為application/smil( )。 //設(shè)置該內(nèi)容的ID，必須設(shè)置，該ID要和主媒體容器中ID一致mainContent. addSubContent (mmc)。 //將創(chuàng)建好的內(nèi)容添加到消息//下面添加的消息內(nèi)容體都對應(yīng)于上面添加的smil文件中描述的各個文件mmc = new MMSContent ()。try{content = readFromFile( E:\\ )。}catch( IOException e ){content = new byte[0]。()。}(content)。 (. GIF)。 ( )。 //設(shè)置消息內(nèi)容的ID，必須設(shè)置，該ID在smil文件中體現(xiàn)。()mainContent. addSubContent (mmc)。 文件：smil xmlns=headlayoutrootlayout height=208 width=176 /region id=Image top=0 left=0 height=50 width=100 fit=hidden/region id=Text top=50 left=0 height=50 width=100 fit=hidden//layout/headbodypar dur=5s!該文件中描述的消息內(nèi)容的src要對應(yīng)于程序中設(shè)置的各個消息內(nèi)容的IDimg src= region=Image //par/body/smil對于smil文件格式的說明請參見SMIL相關(guān)文檔?！?上行業(yè)務(wù)處理方式的比較上行業(yè)務(wù)的實現(xiàn)分為方式1（普通應(yīng)用方式）和方式2（WEB應(yīng)用方式）。方式1是一個普通的java應(yīng)用程序的實現(xiàn)，不必要搭建復(fù)雜的WEB服務(wù)環(huán)境，實現(xiàn)基類中的接口，比較簡單。方式2是在一個WEB服務(wù)的基礎(chǔ)上運行的，所以不必要手工配置偵聽的IP地址和端口，只要實現(xiàn)MM7ReceiveServlet中的doDeliver、doDeliveryReport、doReadReply方法即可，使用簡單。而且本方式可以重用WEB服務(wù)器的線程資源，一般情況下該種實現(xiàn)方式效率應(yīng)該比較高。所以建議使用這種方式?！?日志為了便于調(diào)試系統(tǒng)及界定責任，MM7 API層應(yīng)有日志記錄功能，此日志有別于應(yīng)用層的日志，主要表現(xiàn)API層產(chǎn)生的數(shù)據(jù)信息。日志記錄依據(jù)用戶配置文件中的日志級別（LogLevel）產(chǎn)生，存儲在用戶配置文件中的日志路徑（LogPath）下，其中MMSCID為彩信中心的編號，N為日志記錄的序號。例如2004年1月3日15時49分產(chǎn)生的第三條日志，則日志文件名為：。日志文件的最大數(shù)量依據(jù)配置文件的LogNum產(chǎn)生，API程序應(yīng)能夠自動清除過期日志。日志文件的存盤操作由日志產(chǎn)生的絕對時間間隔（配置文件中LogInterval）或日志文件大?。ㄅ渲梦募蠰ogSize）觸發(fā)，以先滿足的觸發(fā)條件為準。日志文件中日志記錄每一行為一條記錄，每條記錄由記錄內(nèi)容和CRLF構(gòu)成，每兩條日志記錄間至少有一個空行。日志每條記錄的每部分記錄內(nèi)容以[]標識，日志記錄內(nèi)容和格式為：[時間][LogLevel][Transaction_ID][Message_type][Sender_address][Recipient_address][Comments] CRLF其中時間的格式為：YYYYMMDD HH:MM:SS。Comments域在發(fā)送成功時記錄成功信息，發(fā)送失敗時記錄錯誤信息。根據(jù)日志的配置級別，在日志記錄的CRLF后記錄API函數(shù)產(chǎn)生的soap信息。日志內(nèi)容根據(jù)配置文件中的日志級別（LogLevel）產(chǎn)生：（0）No log 不產(chǎn)生日志（1）Severe 產(chǎn)生錯誤日志，在API發(fā)現(xiàn)錯誤時產(chǎn)生日志記錄。（2）Warning暫不使用。（3）Info 產(chǎn)生信息日志，所有交互操作全部產(chǎn)生日志記錄，并記錄SOAP頭信息。（4）Config 暫不使用。（5）Fine 暫不使用。（6）Finer 產(chǎn)生完整信息日志，產(chǎn)生日志記錄并記錄全部SOAP碼流。（7）Fin