[有限可用性]{class="badge informative"}
驗證SMPP連線 validate-smpp-connection
以下提供一些檢查，以確定您的SMPP連線是否正常。
上線前須檢查的事項 check-go-live
上線之前，請確定您的SMPP設定正常，並列出以下檢查清單。
檢查外部帳戶衝突 sms-external-accounts-check
檢查您沒有剩餘的SMS外部帳戶。 刪除測試帳戶以消除潛在衝突。
檢查是否有其他執行個體連線到外部帳戶。 尤其要確保preprod環境未連線到prod外部帳戶。
如果您需要在同一個Campaign執行個體上有多個帳戶可連線至相同的提供者，請聯絡提供者，以確保他們實際區分這些帳戶的連線。 若有多個帳戶具有相同登入，則需要額外設定。
檢查是否所有已啟用的簡訊外部帳戶都已啟用專用流程設定。 您無法在相同執行個體上混用2種帳戶（使用和不使用專用程式）。
進行真實世界測試 real-test
請嘗試在不同行動裝置上傳送一些簡訊。
傳送包含各種字元的簡訊
如果您需要傳送包含非GSM或非ASCII字元的SMS，請嘗試儘可能傳送包含最多元化字元的訊息。 如果您設定自訂字元對應表，請針對所有可能的data_coding值傳送至少一個SMS。
檢查SR是否已正確處理
SMS應在傳送記錄檔中標示為已接收。 傳遞記錄應該成功，並且看起來像這樣： "SR yourProvider stat=DELIVRD err=000|#MESSAGE#"。
檢查您是否已正確設定「SMSC實作名稱」欄位：在生產環境中，傳遞記錄不得包含「SR Generic」。
檢查MO是否已處理
為所有自動回覆關鍵字傳送一些簡訊，並檢查回覆是否快速（不超過幾秒）。
檢查MO是否已插入 nms：inSms 資料庫。 如果您有自訂TLV，請確定它們也插入正確且格式正確。
在記錄中檢查Campaign是否回覆成功的 DELIVER_SM_RESP (command_status=0)。
執行負載測試
如果您傳送大量訊息或使用即時傳送訊息，這一點尤其重要。
執行至少會在5秒內以100%載入連線的測試。 如果提供者無法連線至假帳戶以進行測試，您必須傳送即時訊息。 達到此目的的一種方法是密切監視第一個足夠大的傳送，並啟用詳細的SMPP訊息。
可以像這樣計算要傳送的最小郵件數：
最大MT輸送量 傳送器/收發器連線總數* 5*
傳送完成後，請檢查下列專案：
- 檢查是否已傳送（不一定是接收）所有訊息
- 必須絕對零個PDU，且command_status不是0x00000000，除非提供者明確指出這是正常操作
- 連線在整個傳遞過程中必須保持絕對穩定（無BIND PDU）。
- 檢查所有訊息是否都有SR且已正確處理（請參閱檢查SR是否已正確處理）。 如果一小部分出現錯誤，請檢查這些是實際SR傳回錯誤，而不是在Campaign端傳送或處理期間出現錯誤。
- 如果您不確定效能，請檢查延遲是否合理，尤其是在PDU與其對應的RESP之間，若延遲超過500毫秒，對於高輸送量而言可能會是個問題。 使用該延遲來檢查傳送時段公式（如需詳細資訊，請參閱「傳送時段」設定）
檢查PDU pdu
檢查PDU的格式是否正確。
繫結
檢查BIND_* PDU是否正確傳送。 要檢查的最重要事項是提供者一律會傳回成功的BIND_*_RESP PDU (command_status = 0)。
檢查沒有太多BIND_* PDU。 如果有太多這類連線，可能表示連線不穩定。 如需詳細資訊，請參閱以下的連線不穩定問題疑難排解一節。
INQUIRE_LINK
檢查當連線閒置時，是否定期交換INQUIRE_LINK PDU。
SUBMIT_SM / DELIVER_SM
傳送訊息，然後在記錄中搜尋其對應的SUBMIT_SM、SUBMIT_SM_RESP、DELIVER_SM和DELIVER_SM_RESP PDU。
使用 SUBMIT_SM PDU：
- 檢查data_coding是否正確（預設為0）。
- 檢查short_message是否正確編碼：嘗試使用支援多種編碼的十六進位轉換器來解碼（線上有部分可用）。
- 如果您針對長訊息使用message_payload，請檢查內容是否出現在選用欄位中，而不是在short_message欄位中。
使用 SUBMIT_SM_RESP PDU：
- 檢查是否成功(command_status = 0)。
- 檢查其內文是否包含正確格式化的ID，及其後面的「0」位元組。
使用 DELIVER_SM PDU：
- 將十六進位short_message欄位解碼（有線上工具可執行）。
- 使用規則運算式檢查工具，檢查SR中ID的擷取規則運算式中定義的規則運算式是否只傳回一個擷取群組，並擷取訊息中的整個ID。
- 檢查擷取的識別碼是否與SUBMIT_SM_RESP中的識別碼相符。
- 檢查SR中狀態的擷取規則運算式中定義的規則運算式是否傳回狀態列位的內容。
- 檢查SR中錯誤之擷取規則運算式中定義的規則運算式是否傳回錯誤欄位的內容。
使用 DELIVER_SM_RESP PDU：
- 檢查在收到DELIVER_SM PDU （通常少於1秒）後是否快速傳送。
- 檢查是否成功(command_status = 0)。
與提供者進行即時測試 sms-live-test
上線前的最佳實務是與提供者進行即時測試，讓雙方在執行期間檢視記錄。
停用詳細的SMPP追蹤 sms-disable-smpp
完成所有檢查後，最後要執行的動作是停用詳細的SMPP追蹤，因此不會產生太多記錄。
簡訊疑難排解 sms-troubleshooting
一般疑難排解程式 sms-general-troubleshooting
SMS聯結器涉及3個實體：SMPP提供者、Adobe和您。
主要SMS專家是SMPP提供者，因此他們應該參與所有SMS流量相關問題（連線問題、遺失訊息、編碼問題、特定國家/地區規則……）。
啟用專用處理序 sms-dedicated-process
如果您對舊版（MTA型）聯結器有任何問題（專用流程已停用），您應考慮移轉至專用流程聯結器。 它表現更好、更穩定，並在其記錄中提供更好的意見回饋。
不同外部帳戶之間發生衝突 sms-conflict-external-accounts
如果執行個體有多個SMS外部帳戶，請檢查問題是否不是由帳戶之間的衝突所造成。
隔離造成問題的外部帳戶：
- 停用所有外部帳戶
- 啟用一個外部帳戶
- 嘗試重現問題
- 如果該單一帳戶未出現問題，請停用該帳戶，然後重新啟動至下一個帳戶的步驟2。 當您分別檢查每個帳戶後，可能會出現以下兩種情況：
問題出現在一或多個帳戶上
在這種情況下，您可以對每個帳戶個別套用其他疑難排解程式。 在診斷帳戶時，最好停用其他帳戶，以減少網路流量和記錄數量。
在任何時候只有一個帳戶作用中時，問題未出現
帳戶之間發生衝突。 Adobe Campaign會個別處理帳戶，但提供者可能會將其視為單一帳戶。
您在所有帳戶間使用不同的登入/密碼組合
您必須連絡提供者，以診斷其一方的潛在衝突。
部分外部帳戶共用相同的登入/密碼組合
提供者無法辨別BIND PDU來自哪個外部帳戶，因此他們將來自多個帳戶的所有連線視為單一連線，因此他們可能會在2個帳戶上隨機路由MO和SR，導致看似隨機的問題。
如果提供者支援同一個登入/密碼組合的多個短程式碼，您必須詢問他們將哪個短程式碼放在BIND PDU中。 請注意，這段資訊必須放在BIND PDU中，而不是SUBMIT_SM中，因為BIND PDU是唯一允許正確路由MO的位置。
請參閱上面各種PDU🔗區段中的資訊，以瞭解BIND PDU中有哪些欄位可用，通常您會將短程式碼放在 address_range 中，但這需要提供者的特殊支援。 請聯絡他們，以瞭解他們如何獨立路由多個短程式碼。
Adobe Campaign支援在相同的外部帳戶上處理多個短程式碼，因此通常只要針對所有流量使用單一帳戶即可正常運作。
外部帳戶已停止運作 sms-external-account-not-working
一般而言，SMPP連線在一段時間內會非常穩定，且設定正確後，應會繼續運作。
- 調查聯結器最近是否變更 — 以及變更者（以群組方式檢查外部帳戶）。
- 調查系統是否已升級以及何時升級。
- 調查是否有任何影響SMS的套件最近可能已升級。
如果這些檢查都沒有導致根本原因，請聯絡提供者。 有時，當提供者更新其平台時，其聯結器的行為會略有不同。 這可能會破壞微調設定並引入回歸。
我們建議您與提供者保持聯絡，他們通常會事先溝通重大變更。
中間來源的問題（託管） sms-issue-hosted
- 如果問題發生在中間來源環境中，請確保在中間來源伺服器上正確建立和更新傳遞和broadlog。 如果不是這種情況，問題就不是SMS問題。
- 請確定mid運運算元名稱為嚴格的小寫，否則傳送將維持擱置狀態。
- 如果一切在中間伺服器上正常運作，且簡訊已正確傳送，但行銷執行個體未正確更新，則表示您發生中間同步問題。
連線到提供者時的問題 sms-issue-connection
- 如果BIND PDU傳回非零的 command_status 程式碼（表示發生錯誤），或者如果沒有BIND_RESP PDU，請詢問提供者為何發生此情況。
- 檢查網路是否已正確設定，以便與提供者建立TCP連線。
- 要求提供者確認其是否正確允許Adobe Campaign執行個體的IP位址（大部分提供者都需要此專案）。
- 檢查外部帳戶設定。 如果對某些欄位的值存疑，請詢問提供者。
- 如果連線成功但不穩定，請檢查不穩定連線的問題。 一節。
- 如果連線問題難以診斷，網路擷取會為您帶來許多資訊。 請確定網路擷取在問題出現時同時執行，以便有效地進行分析。 您也應該注意問題出現的確切時間，以便在網路擷取中更容易找到問題。
連線不穩定的問題 unstable-connections
如何診斷不穩定的連線：
如果發生下列任一情況，就會將連線視為不穩定：
- 連線持續少於1小時。
- 重新啟動簡訊程式將暫時能「修正」問題。 這可能表示不穩定的連線會觸發節流，重新啟動SMS程式會清除節流，然後會再次發生，直到找到根本原因為止。
- 提供者會傳送UNBIND PDU。 在正常操作中，提供者絕不應該傳送UNBIND PDU。
- inquire_link 逾時，無論是在Campaign端或提供者端。 在此情況下，您可能會看到或看不到INQUIRE_LINK_RESP具有非零的錯誤碼。
- 有許多BIND PDU。 一天內不應超過幾次（視連線數量而定）。 每小時和每個連線應該有超過1個BIND PDU警報。
如何修正連線穩定性問題：
- 不穩定的連線很少是根本原因，這通常是另一個問題以某種方式觸發中斷的結果。 優先尋找根本原因。
- 啟用詳細的SMPP追蹤。 您需要他們檢視連線重新啟動時發生的情況。
- 如果提供者傳送UNBIND PDU，則它們可能會執行錯誤。 詢問他們傳送UNBIND的原因，這可能會導致根本原因。
- 進行網路擷取有時是檢視連線如何關閉的唯一方法。
- 如果提供者關閉連線（透過傳送TCP FIN或TCP RST封包），請詢問他們這樣做的原因。 這應該會說明問題的根本原因。
- 如果提供者在傳送未修正的錯誤（例如含有錯誤代碼的DELIVER_SM_RESP）後關閉連線，就必須修正其聯結器，因為這樣可以防止傳輸其他型別的訊息，並觸發MTA節流。 在收發器模式中，這尤其重要，因為關閉連線會同時影響MT和SR。
- 如果發生逾時（BIND逾時、SUBMIT_SM逾時），Campaign可能會為該提供者傳送過快訊息。 請嘗試降低 最大MT輸送量 設定，看看它是否能解決問題。
傳送MT （傳送給一般使用者的一般SMS）時的問題
- 檢查連線是否穩定： SMPP連線應持續保持至少1小時。 請參閱上方的「不穩定的連線問題」一節。
- 如果重新啟動SMS程式使得傳送MT在短時間內再次工作，則可能由於連線不穩定而發生節流。 請參閱上方的「不穩定的連線問題」一節。
- 檢查廣泛記錄檔是否存在且狀態正確，且日期正確。 如果不是，則不是SMS問題，而是傳送問題或傳送準備問題（超出本檔案範圍）。
- 檢查SMS聯結器是否實際與提供者的裝置繫結。 請向提供者要求回饋意見，以確保所有系統皆能正常通訊。 請參閱BIND_TRANSMITTER和BIND_TRANSCEIVER PDU以取得有關係結程式的資訊。 您可能需要啟用SMPP追蹤才能正確進行疑難排解。
- 啟用SMPP追蹤後，請檢查SUBMIT_SM PDU是否包含正確的資訊（請參閱上述檔案）。
- 檢查提供者是否以「OK」值（代碼0）回應SUBMIT_SM_RESP PDU。 請確定PDU在到達時會有合理的延遲：超過1秒的任何時間都是可疑的，必須與提供者討論，通常在100毫秒內到達。
- 如果所有這些步驟都有效，您可以確信問題出在提供者方面。 他們必須在平台上執行疑難排解。
- 如果它可以運作，但輸送量不一致，請嘗試調整傳送視窗並降低MT輸送量。 您需要與提供者合作以調整此專案。 Campaign可以快速傳送訊息，因此提供者的裝置可能會出現效能問題。
MT重複（同一個SMS會連續多次傳送）
重複專案通常是由重試所造成。 重試訊息時一般會有重複專案，因此您應集中精力消除重試的根本原因。
- 如果您看到重複專案剛好相隔60秒（或任何其他可疑的「一般」期間），可能是提供者端的問題，他們傳送SUBMIT_SM_RESP的速度不夠快。
- 如果您看到許多BIND/UNBIND，表示您的連線不穩定：在嘗試解決重複的訊息問題之前，請先參閱不穩定的連線問題一節以取得解決方案。
- 檢查所有的SUBMIT_SM PDU之後是否具有相符的SUBMIT_SM_RESP。 如果它們沒有或SUBMIT_SM_RESP太慢，則問題出在提供者端。
在重試時減少重複專案數量：
- 降低 傳送視窗。 傳送視窗應該足夠大，以涵蓋SUBMIT_SM_RESP延遲，但不要太大。 其值代表當視窗已滿時發生錯誤時可複製的最大訊息數量。
處理SR （交貨收貨）時發放
- 您需要啟用SMPP追蹤才能進行任何型別的SR疑難排解。
- 檢查DELIVER_SM PDU是否來自提供者，以及它的格式是否正確。
- 檢查Campaign是否及時回覆成功的DELIVER_SM_RESP PDU。 這可保證SR已插入providerMsgStatus表格中，以便SMS程式延遲處理。
如果DELIVER_SM PDU未成功確認，則您需要檢查一些事項：
- 檢查與外部帳戶中ID擷取和錯誤處理相關的Regex。 您可能需要根據DELIVER_SM PDU的內容來驗證它們。
- 檢查broadLogMsg表格中是否已正確布建錯誤（Campaign檔案會詳細說明此內容）。
如果ACC延伸SMPP聯結器已確認DELIVER_SM PDU，但broadLog未正確更新，請檢查上文「比對MT、SR和broadlog專案」一節中所述的ID調解流程。
如果您已修正所有問題，但部分無效SR仍在提供者的緩衝區中，您可以使用「無效ID認可計數」選項來略過這些專案。 這應謹慎使用，並在清除緩衝區後儘快重設為0。
如果SR處理緩慢，請嘗試確認BroadLogMsg表格中最常見的狀態訊息。
如果只收到部分SR，但不是全部，請檢查是否有其他系統連線到您提供者的帳戶，例如測試系統。 SR可以在任何連線上繞線，因此其中有些可能會繞線到這個其他系統。 提供者可能會協助您找出這個連線到帳戶的其他系統的位置。
處理MO （和隔離/自動回覆）時的問題
- 在測試期間啟用SMPP追蹤。 若未啟用TLS，在MO疑難排解時最好進行網路擷取，以檢查PDU是否包含正確資訊及格式是否正確。
- 擷取網路流量或分析SMPP追蹤時，請務必擷取與MO及其回覆MT （如果已設定回覆）的整個交談。
- 如果MO (DELIVER_SM PDU)未出現在追蹤中，您可以確信問題出在提供者方面。 他們必須在平台上執行疑難排解。
- 如果DELIVER_SM PDU出現，請檢查Campaign是否確認成功DELIVER_SM_RESP PDU （代碼0）。 此RESP可保證所有處理邏輯已由Campaign套用（自動回覆和隔離）。 如果不是這種情況，請在SMS流程日誌中搜尋錯誤訊息。
- 如果已啟用自動回覆，請檢查SUBMIT_SM是否已傳送給提供者。 如果沒有，在SMS程式記錄中一定會找到錯誤訊息。
- 如果在追蹤中找到包含回覆的SUBMIT_SM MT PDU，但SMS未送達行動電話，則您必須聯絡提供者以尋求疑難排解方面的協助，因為問題可能在其側。
未排除被隔離的收件者（被自動回覆功能隔離）的傳送準備期間的問題
- 檢查隔離表格和傳送記錄中的電話號碼格式是否完全相同。 如果沒有，如果您遇到國際電話號碼格式的加號首碼問題，請參閱上方的「傳送完整電話號碼」設定。
- 檢查短代碼：如果收件者的短代碼與外部帳戶中定義的代碼相同，或是空白（空白=任何短代碼），則會發生排除。 如果整個Campaign執行個體只使用一個短程式碼，則會更輕鬆地將所有「短程式碼」欄位留空。
編碼問題 sms-encoding-issues
SMS中經常出現編碼問題。 以下是幾個基本步驟。
步驟1：與提供者連絡
提供者為知道SMS運作方式的專家。 請聯絡他們，並一起檢視問題內容。 他們應該可以告訴您問題是在他們這邊還是在Campaign。 如果問題出在Campaign，他們應該能夠告訴您哪個欄位不正確，這非常實用。
步驟2：瞭解您訊息的內容
您必須知道訊息內容。 這個句子聽起來可能很容易，但事實並非如此。 Unicode允許許多類似字元的變體，Campaign無法全部處理。
最常見的問題來源是從文書處理器複製貼上，這會將一般字元變更為印刷體正確的版本：空格變更為不可破斷的空格，雙引號變更為開頭和結尾引號，減號變更為各種連字型大小……
測試時請勿複製並貼上訊息，請一律直接在介面中輸入。
不要受到十六進位 的恐嚇。 十六進位看起來奇怪且不自然，但它的品質卻非常獨特：您可以分辨類似字元之間的差異。 小寫L、大寫I、O、0、所有不同型別的引號、非拉丁文字編碼或甚至是不同型別的空格看起來都可能相同（或甚至完全不顯示）。 十六進位會顯示所有專案，並有助於比較不同專案。
若要將unicode轉換為十六進位，您可以使用線上工具。
開啟編碼問題的票證時，無論是在提供者或Campaign支援上，都會包含您所輸入內容與所見內容的十六進位 版本。
步驟3：瞭解您應該傳送哪些內容
決定您要使用的編碼，並線上上搜尋其字元表。 檢查您要傳送的字元是否確實可在目的碼頁面中使用。 檢查data_coding欄位是否正確，它是否符合您和提供者所預期的結果。
步驟4：瞭解您實際傳送的內容
您將需要聯結器的偵錯輸出，才能檢視您傳送給提供者的確切位元組。 SUBMIT_SM PDU中出現編碼問題，請務必加以擷取。 傳送在記錄中容易找到的非常不同的訊息。
測試時，請隨時傳送不同型別的特別字元。 例如，GSM7編碼具有延伸字元，這些字元以十六進位形式非常不同，因此很容易辨識，因為它們未出現在任何其他編碼中。
效能問題 sms-performance-issues
傳送MT 時發生 效能問題
- 檢查外部帳戶「輸送量和延遲」區段中的所有設定是否正確，以及它們是否符合提供者允許的設定。
- 檢查是否沒有重試。
- 檢查提供者的基礎結構是否未飽和。 檢查RESP PDU中是否存在RMSGQFUL或RTHROTTLED錯誤。
- 檢查serverConf設定。 從預設值開始，緩慢地逐一增加引數。
- 檢查SMS程式是否在載入時未隨時重新啟動。 如果超過限制，您可能需要在serverConf檔案中增加 maxSMSMemoryMb、maxProcessMemoryAlertMb 和 maxProcessMemoryWarningMb。
接收SR時 效能問題
如果提供者抱怨他們這邊緩衝區超載，這可能是因為Campaign收到SR的速度不夠快。
- 檢查執行個體資料庫是否未超載。 SR處理非常依賴資料庫效能。
- 要求提供者增加其端的DELIVER_SM傳送視窗。 最好是serverConf中的 batchUpdateSize 設定。
通訊SMS問題時要包含的元素
每當您尋求SMS問題的協助(無論是開啟Adobe Campaign的支援票證、SMS提供者，或任何有關問題的通訊)時，都需要至少包含下列資訊以確保其符合資格。 適當合格的問題是快速解決問題的關鍵，因此花一點時間瞭解情況並提供有意義的資訊將可大幅提升效率。
- 在問題出現期間啟用詳細的SMPP訊息。 大部分的SMS問題如果沒有這個選項幾乎無法解決。
- 如果問題與SMS流量有關，請先聯絡提供者。 他們知識淵博，其平台通常適合即時診斷SMS流量問題的有效率。
- 包括問題的簡短但實事求是的描述。
- 包括預期結果的說明。
- 包含提供者的所有意見回饋。
- 包含相關記錄檔和/或網路擷取。 進行擷取時，請務必在擷取期間重現問題，否則問題將毫無用處。
- 如果您包含記錄、追蹤或擷取，請在問題出現時精準指出檔案中的確切位置，以及工作範例的確切位置（如果有的話）。 擷取或追蹤的內容可能龐雜而繁瑣，所以有助於在其中尋找資訊的任何內容都很有幫助。
- 如果您參考訊息、PDU或記錄，請清楚說明其時間戳記，好讓其他人容易找到。
- 嘗試在測試環境中重現問題。 如果您不確定設定，請在測試環境中嘗試，並使用SMPP追蹤檢查結果。 報告測試環境中復寫的問題通常比直接報告生產環境中問題要好。
- 包含平台上的任何變更或調整：即使是細微的變更都會產生巨大影響。 此外，也請包含提供者可能已在其一側完成的任何變更。
網路擷取何時有用？
網路擷取並不一定需要。 通常情況下，冗長的SMPP訊息就足夠了。 以下是一些准則，可協助您判斷網路擷取是否值得：
- 連線有問題，但詳細訊息未顯示任何BIND_RESP PDU。
- 無法解釋的連線沒有錯誤訊息（這是聯結器偵測到低層通訊協定錯誤時的行為）。
- 提供者抱怨解除繫結/中斷連線程式。
- 選擇性TLV欄位中出現編碼問題。
- 在不同的連線之間懷疑是混合的流量。
在所有其他情況下，請先嘗試分析詳細的SMPP訊息，並僅在詳細記錄中明確缺少資訊時請求網路擷取。
網路擷取何時沒有用處？
在某些情況下，擷取網路流量是無用的，或只是浪費時間。 最常見的情況如下：
- TLS已啟用：根據定義，TLS流量會加密，因此無法擷取。
- 效能問題：記錄檔包含追蹤效能問題所需的所有資訊。
- 計時問題（重試計時、enquire_link時段、輸送量上限……）
- SR剖析和處理：詳細記錄檔可提供更多內容和更好的簡報。
- mo處理（自動回覆、隔離）。
- 不涉及實際SMPP流量的錯誤：傳遞準備、訊息中心API問題、工作流程問題……