sp接入改造问题
1、業務梳理模板中，有一項是“業務處理地址”，這個是什么意思？
答：業務處理地址就是當用戶要訂購某項業務時，MISC會往SP填寫的這個“業務處理地址”發送正向同步請求包。業務處理地址可以是域名也可以是IP地址，只要能訪問到就行。
?
2、業務梳理模板中，發送頻率如何填寫？
答：對于點播類業務，就填寫你這個業務要發送MT的條數。比如說一個MO上行，對應要下行5條MT，那么次數就填5。如果下發6條，MISC會把最后一條MT攔截掉。注意，填寫5次并不是表示你一定要下發5條才行，你可以下發4條或者3條，只要不超過5條就行。對于定制包月的業務，因為MISC目前暫時不對這個次數做判斷，所以就按照你們業務量的最大值填寫，只要不超過10000條即可。
?
3、SP接收到SyncOrderRelationReq時，如何判斷這是一個手機MO發起的訂購請求，還是網上訂購發起的請求?（比如在ActionID=1的情況下）
答：可以通過AccessMode來判斷。AccessMode為1表示web方式；為2表示WAP方式；為3表示短信。
?
4、用戶欠費停機的時候misc會調用provision“暫停服務”接口暫停在SP訂購的服務嗎？然后用戶重新交費恢復后，misc會再調用provision“激活服務”接口嗎？
答：正確。
?
5、定制和點播指令里允許有空格嗎？
答：是的。
?
6、請問最大匹配加精確匹配的原則具體內容是什么？
答：精確匹配的意思是指只有當所匹配內容和所設置的指令內容完全相同（包括長度也一樣）時，才算匹配。例如如果設置了發送號碼為“800101”，如果用戶發送一條MO到“80010123”時，是不會匹配上“800101”的那條指令；只有發往“800101”的指令才會被匹配上。最大匹配相當于模糊匹配，和精確匹配不可以同時使用，最大匹配的意思是說，長號碼或者指令，匹配位數相同的最多的字符串，如有兩個模糊匹配的指令 ‘8001 aa’、‘80011 aa’，當用戶發送‘800111 aa’的時候，會匹配到第二條指令，而不是第一條。
?
7、空指令模糊匹配是否也依照最大匹配的原則進行？比如SP有兩個業務都需要用到空指令模糊匹配，而其中第一個前五位為給定的值，第二個前六位為給定的值（前五位和第一個一樣），那么匹配的時候是否也會按照最大匹配的原則先匹配到第二個？例如申報：
?? 1、用戶發送“內容”到“8888+1＋對方ID”
?? 2、用戶發送“內容”到“8888+11＋對方ID”
那么用戶發送“內容”到“8888110000”是肯定先匹配到2嗎？
答：是的。
?
8、我們有兩個業務，屬于主、從業務，業務梳理表我們是不是按照兩個業務填寫？那主、從業務關系的業務組怎么建立？能不能給我一個完整的流程？
答：SP自服務系統里面應該可以看到每種業務組的分類方法。業務當然還是2個業務，只是在同一個組。主從業務的申請步驟：增加業務組 －》 申請第一個業務－》 申請第二個業務，業務申請完之后，默認第一個業務為主業務，但是在業務組里面你可以看到這兩個業務，你也可以通過選擇框來決定哪個業務是主業務。這里要說明一下，在業務梳理表中是不能選擇業務組類型的，SP只能通過SP自服務系統來錄入。
?
9、關于CMPP協議的修改？
答：1、刪除CMPP_SUBMIT、CMPP_DELIVER消息中的Reserve字段，添加LinkID字段；（20個字節長字符串類型）；
??? 2、CMPP_SUBMIT消息：增加Fee_terminal_type字段, 字段長度為1字節，表明Fee_terminal_Id是真實用戶號碼還是偽碼；
??? 3、CMPP_SUBMIT消息：擴展Fee_terminal_Id長度為32字節，適應偽碼的長度需求，并把其類型從Unsigned Integer修改為Octet String。
??? 4、CMPP_SUBMIT消息：增加Dest_terminal_type字段，字段長度為1字節，表明Dest_terminal_Id是真實用戶號碼還是偽碼；
??? 5、CMPP_SUBMIT消息：擴展Dest_terminal_Id長度為32字節，適應偽碼的長度需求。
??? 6、CMPP_DELIVER消息：增加Src_terminal_type字段，字段長度為1字節，表明Src_terminal_Id是真實用戶號碼還是偽碼；
7、CMPP_DELIVER消息：擴展Src_terminal_Id的長度為32字節，適應偽碼的長度需求。
?
10、同一MO上行有2種處理結果如何處理呢？比如考試成績查詢業務，mo上行代碼為KS＃準考證號，當成績已經公布時按照點播方式直接下發成績信息；而當成績尚未公布時，系統將該用戶信息保存，等成績公布時在第一時間發送給用戶，該方式為訂閱業務。只是在代碼匹配時應如何處理呢？
答：申請成點播業務，如果成績未到，就發一條信息，告訴用戶等成績一到就通知，此次可使用本業務代碼下發信息，并記錄用戶信息；然后等成績到了，用幫助信息的代碼下發成績。
?
11、對于按條定制類業務，如何獲取LinkID：如果有些業務是按條訂制類業務，用戶一次上行，訂制了業務，當時是不扣費的，每次有信息給用戶下行的時候，才收取費用（比如1元/條）。那么這種單條收費的業務，當時下行不可能有用戶上行，因為用戶早就訂制過了，就不會有LinkID，是不是也就不能用單條費用相對應的資費代碼下行給這個用戶信息，如何解決這個問題？
答：定制類的業務允許包月和按條計費，點播只能按條計費。
定制類業務不需要LinkID，對于定制類業務，只要用戶訂購了，你就可以隨時下發信息，不用管LinkID。也就是說，定制類業務只會鑒權訂購關系。
對于定制類中的包月、按條計費模式，不影響鑒權的流程，也就是說，不管是按條還是包月，都只是鑒權訂購關系，而不需要LinkID。
?
12、正向定購中怎樣取得服務長號及定購指令？
答：通過provison包中的featherstr字段，該字段的內容是長號碼和指令內容，中間用空格分割，base64編碼格式。
?
13、舉例：一個交友業務，用戶注冊成為會員以后，有5元/月的包月費，用戶可以找朋友、可以聊天、可以使用基本的功能操作而不產生額外的費用。但如果要使用某些特殊操作的話將會按條收費，而這些特殊操作是臨時推出的，是點播，不需要定制。比如社區發起的某次有獎投票活動，會員之間互贈送禮物，使用某些貼心服務等。我該如何來申報這個業務DA
答：可以申請一個主從類的業務組合，包括這兩個業務。主業務為包月，從業務為點播。
?
14、發送點播或定制指令時如果是大寫小寫都可以精確匹配，是否要改為模糊匹配，例如要滿足某項業務發送指令CZ到01888與發送cz到01888均可定制同一業務，需要精確匹配還是模糊匹配？
答：指令不分大小寫，需要精確匹配。
?
15、業務申請中的幫助類業務是怎么回事啊？是每個業務都要單獨申請幫助類業務嗎？幫助類業務和其他的業務的區別是什么？
答：沒有必要每個業務都單獨申請幫助類業務。此類業務必須免費提供，供SP向用戶下發業務使用幫助信息，要求每個SP只能申請一個幫助信息類的業務。業務申請時不需要提交點播指令，也不需要提交訂購指令和退訂指令，業務代碼前無任何符號。
?
16、MISC的業務梳理表中，業務分類－大類，小類怎么寫。我們的表中除了“信息類”可以，其他的都提示導入失敗。是不是業務分類有定義好的？
答：業務分類是由集團統一制定的，也就是昨天我給大家看的那個文件“業務大小類對照表.txt”。這個文件會由移動統一發給各位。
?
17、在MISC發起的SyncOrderRelationReq請求中，包含了一個TransactionID元素作為消息編號，我想知道：TransactionID是否會重復？若會重復，重復的時間間隔會是多少？
答：TransactionID 的產生規則是DeviceID+10 位的數字，該10 位數字從1 開始，不足10 位的前補0。每次增長的步長為1，依次循環使用。
?
18、有一個業務，是在對方號碼前加服務代碼進行點對點發送，比如A用戶向用戶B發短信：你好，發到123413912345678，，A用戶是注冊用戶，B用戶非注冊用戶。接入MISC之前是可以直接發送，請問接入MISC以后，還能不能發送了呢？對接收方也要進行訂購關系鑒權了么？
答：可以發送，對接收方不需要定購關系鑒權。
?
19、我們有個手機定制類業務，用戶發信息上來定制時，發送內容除了該業務的上行定制代碼以外，還包括用戶個人信息，我們要根據用戶個人信息不同分門別類處理。我想問的是用戶發信息定制業務時，sp是不是能夠收到用戶發送的全部內容？如果不是，我們這個業務該怎么申報？
答：可以通過provison請求包的featherstr字段得到mo的內容，里面是用戶發送的長號碼和指令內容。
?
20、填寫業務梳理表的時候，是不是每個定制類的業務都必須填寫退定指令？只用0000和00000來退定不行嗎？
答：要求定制類的業務都要有退定指令，0000和00000是系統保留字。
?
21、做provision測試時，ActionID有時會出現3（激活）或4（暫停），這值是如何產生的，我們只發定制指令和退訂指令，應該是1和2啊，為什么會出現3和4呢？
答：actionid 1 開通服務2 停止服務3 激活服務4 暫停服務
這種情況也是有的，對于某些欠費用戶，定購關系可能不會立即取消，而是暫停，當用戶重新繳費，定購關系會被激活（actionid ＝ 3），而不需要用戶再次定購。
?
22、關于填寫業務梳理表問題：
如果一個點播業務，我用空指令模糊匹配，長號碼精確匹配來點播，業務梳理表中的點播指令（空指令），我應該怎么填寫？寫0還是寫null或填寫別的？
答：什么都不填就是表示空指令。
?
23、LinkID的使用方法？
答：LinkID是臨時訂購關系的匹配碼，用來鑒權一次點播請求等事務性的業務。點播業務使用LinkID，非點播類業務的MT流程不使用該字段。當MISC生成的訂購關系為臨時訂購關系的時候，返回本字段，否則不填本字段。
LinkID的設置時間一般是5分鐘（各省設置不同），在收到請求以后在5分鐘內下發下來，
5分鐘內可任意發，但有一個最大條數限制。多條消息下發時用Pk_total和Pk_number可使
用同樣的LinkID。
LinkID的產生是和手機號碼和業務代碼相關聯的，每次點播產生不同，不能互換使用。
?
24、MO指令分為四種：訂購指令、取消指令、點播指令和普通MO。請問點播指令和普通MO的區別是什么？
答：點播指令匹配成功后，MO包中的Service_Id和linkid都會有值。收到這條MO之后，SP必須用對應的業務代碼和linkid才能下發；而普通MO包中的Service_Id和linkid是沒有值的，SP在收到這條MO包之后，只能用幫助信息類的業務代碼下發。
?
25、重復定制和重復取消的MO消息是否傳給SP？
答：重復定制的MO指令傳給SP，重復取消MO指令不傳給SP。
總結
- 上一篇： 如鹰之歌
- 下一篇： PCB多层板设计总结-层的分布设置