[也適用於v8]{class="badge positive" title="亦適用於Campaign v8"}

簡訊連接器通訊協定及設定 sms-connector-protocol

概覽 overview

SMS可能僅限於傳送無格式的短文字訊息，但其簡易性使其成為有價值的通訊頻道。

傳送SMS有兩個主要方法：

本檔案將引導您完成Adobe Campaign與SMPP提供者之間的連線設定。

SMPP提供者有時可能會偏離官方規格，但Adobe Campaign中的SMS聯結器提供許多選項來調整其行為，使其與大多數提供者相容。

簡訊型別 sms-types

透過SMS提供者傳送大量簡訊時，您會遇到三種不同的SMS：

您需要區分確認（RESP PDU，SMPP通訊協定的一部分）和SR： SR是一種透過網路端對端傳送的SMS，而確認僅是確認一項傳送已成功。

確認和SR都可以觸發錯誤，區分兩者有助於疑難排解。

簡訊所攜帶的資訊 information-sms

簡訊包含的資訊多於文字。 以下是您可在SMS中找到的專案清單：

smpp通訊協定 smpp-protocol

Adobe Campaign Classic支援SMPP通訊協定版本3.4。這是廣泛的通訊協定，允許傳送SMS給提供者(SMSC)並接收SMS以及回條。 如需詳細資訊，請參閱SMPP檔案。

SMS服務提供者端的網路裝置通常稱為SMSC。

smpp連線 smpp-connections

Adobe Campaign透過TCP連線至SMS服務提供者的網路裝置。 SMPP通訊協定會設定從Adobe Campaign到提供者的永久TCP連線。 TCP連線一律由Adobe Campaign起始，即使是接收訊息亦然。
SMPP會根據其模式開啟1或2個TCP連線。 所有連線一律由Adobe Campaign起始。

SMPP通訊協定可以在兩種模式中運作：

SMPP PDU smpp-pdu

SMPP傳輸單位（「封包」）稱為PDU。 PDU ​包含命令、狀態、序號和資料。

每個PDU都必須由SMPP RESP PDU確認（同步回應）。 請求可以管道化：傳送者可以傳送許多命令，而不需要等候RESP，任何時候可以管道化的請求數稱為視窗。 RESP PDU可能以任何順序到達，與其對應的啟動器PDU的順序無關。

在分隔的​ 傳送器+接收器 ​模式中，使用的連線取決於傳送的訊息型別。 傳送器連線用於MT，而接收器連線用於MO和SR。 各種訊息的要求和回應會透過相同的TCP連線傳送。

例如，傳送MT時，會使用傳送器連線，而且會透過傳送器通道傳送確認MT的RESP。 當您收到MO （或SR）時，接收器連線會用來接收MO並傳送確認MO的RESP。

在Adobe Campaign Classic中，若要將SR與其對應的MT連結，SMSC會傳回包含SUBMIT_SM_RESP和DELIVER_SM步驟的ID。 識別碼儲存在nms::providerMsgId資料表的providerId欄位中，並連結至broadLogId和deliveryId。 此比對操作由SMS程式在寫入資料庫時完成。

成功的SUBMIT_SM_RESP PDU會在傳送記錄中觸發「已傳送」訊息狀態，而成功的DELIVER_SM (SR) PDU則會觸發「已接收」訊息狀態。

安全性方面 security-aspects

通訊協定本身並未加密。 大部分提供者在允許清單上實作IP的變體，因此必須向提供者宣告Adobe Campaign伺服器IP位址。

Adobe Campaign支援在繫結階段傳遞登入和密碼。 它也支援SMPP over TLS。 請注意，需要憑證才能保證適當的安全性。 雖然SMPP聯結器允許略過憑證檢查，但只應該用於測試，因為沒有憑證的TLS提供顯著較低的安全性層級。

聯結器使用系統openssl程式庫提供的預設憑證。 通常由Debian上的/etc/ssl/certs目錄提供。 此目錄預設由「ca-certificates」套件提供，但可加以自訂。

各種PDU中的資訊 information-pdu

每種PDU都有不同的欄位，這些欄位包含不同的資訊。 這些PDU在SMPP 3.4規格中有詳細說明。

以下各節說明PDU及其同步回應(*_RESP PDU)。 所有PDU都必須由對應的RESP確認，這是規格的必要部分。

PDU可以有選填欄位。 此處僅說明最常見的欄位。 如需詳細資訊，請參閱SMPP 3.4規格。

BIND_TRANSMITTER / BIND_RECEIVER / BIND_TRANSCEIVER

此PDU用於啟動與SMSC的連線。 傳送器、接收器 ​和​ 收發器 ​模式只會變更允許透過此連線傳送的SMS型別，特別是：

BIND_* PDU中的主要欄位：

BIND_*_RESP沒有特定欄位，它確認連線是否成功。

解除繫結 unbind

此PDU必須在中斷連線之前由系統傳送。 它必須等候相符的UNBIND_RESP PDU才能關閉連線。

符合SMSC的請勿關閉連線，TCP連線是由Adobe Campaign聯結器所控制。

SUBMIT_SM submit-sm

此PDU會將MT傳送至SMSC。 其回應PDU會提供MT的ID。

SUBMIT_SM PDU中的主要欄位：

Adobe Campaign支援下列選用欄位：

SUBMIT_SM_RESP submit-sm-resp

此PDU將包含MT的ID。 這對於將其與傳入SR匹配很有用。

有些提供者在傳送SR後會傳送SUBMIT_SM_RESP。 為了說明該行為，Adobe Campaign會等待30秒才回覆​ 無效的訊息ID ​給具有未知ID的SR。

DELIVER_SM delivery-sm

此PDU由SMSC傳送至Adobe Campaign。 它包含MO或SR。

大部分欄位與其SUBMIT_SM對應欄位具有相同的意義。 以下是實用欄位清單：

Adobe Campaign可使用某些設定讀取receipted_message_id選用欄位中的訊息ID。

DELIVER_SM_RESP deliver-sm-resp

此PDU由Adobe Campaign傳送以認可SR和MO。

SR和MO插入資料庫後，Adobe Campaign Classic會加以確認。 即使已傳送成功的DELIVER_SM_RESP PDU，仍可能發生一些處理錯誤。 此限制是由Adobe Campaign Classic的軟體架構所造成。

ENQUIRE_LINK enquire-links

此PDU僅用於檢查連線是否使用中。 應根據提供者的需求設定其頻率。

預設的60秒應與外部帳戶中設定的大多數設定相符。

INQUIRE_LINK_RESP enquire-links-resp

此PDU確認連線為作用中。

多部分SMS （長SMS） multipart

多部分SMS或長SMS是以多個部分傳送的SMS。 由於行動網路通訊協定中的技術限制，SMS不能大於140位元組，否則需要分割。 請參閱SMS文字編碼區段以進一步瞭解SMS中可容納的字元數。

長訊息的每個部分是個別的SMS。 這些零件在網路上獨立運作，並由接收的行動電話組裝。 為了處理重試和連線問題，Adobe Campaign會以相反順序傳送這些部分，並僅在訊息的第一部分（最後傳送）請求SR。 由於行動電話只會在收到其第一部分時顯示訊息，因此對其他部分的重試不會在行動電話上產生重複專案。

可使用​ 傳遞範本 ​中的​ 每則訊息的SMS數目上限 ​設定，設定每則傳遞的SMS數目上限。 超過此限制的訊息將在傳送期間因簡訊失敗原因過長而失敗。

傳送長簡訊的方式有兩種：

如需有關通訊協定和格式的詳細資訊，請參閱SUBMIT_SM PDU的esm_class、short_message和message_payload欄位描述。

輸送量上限與視窗 throughput-capping

大多數提供者需要每個SMPP連線的輸送量限制。 這可透過在外部帳戶中設定多個SMS來達成。 請注意，每個連線都會發生輸送量節流，總有效輸送量是每個連線的限制乘以連線總數。 這在同時連線區段中詳細說明。

若要達到最大可能的輸送量，您需要微調最大傳送時段。 傳送視窗是不需要等候SUBMIT_SM_RESP即可傳送的SUBMIT_SM PDU數目。 如需詳細資訊，請參閱傳送視窗設定區段。

服務請求與錯誤管理（「附錄B」） sr-error-management

SMPP通訊協定定義了RESP PDU中的標準同步錯誤，但並未定義SR的錯誤代碼。 每個提供者都使用自己的錯誤代碼及其含義。

已在SMPP通訊協定規格 （第167頁）的附錄B區段中提供建議，但這不會列出實際的錯誤碼及其含義。

為了適應錯誤管理，已運用Adobe Campaign的broadlog訊息系統來適當地布建錯誤及其嚴重性（硬式、軟式等）。

如上所述，有兩種不同型別的錯誤：

收到SR時，可在其short_message欄位中找到狀態和錯誤（例如附錄B合規實作）。 PDU的short_message欄位通常稱為​ 文字欄位，因為它包含MT中的文字。 若是SR，則包含技術資訊以及名為​ Text ​的子欄位。 這2個欄位不同，short_message實際包含​ 文字 ​欄位和其他資訊。

Adobe Campaign Classic聯結器（擴充式SMPP除外）會根據選取的提供者，使用硬式編碼行為。 通用SMPP只會區分成功和錯誤，沒有詳細資料。 傳送記錄檔可能包含無法保證的一些資訊。

SR文字欄位格式 sr-text-field-format

該規格建議對SR文字欄位使用此格式。 這是子欄位的清單，以冒號分隔以區隔欄位名稱及其值。 欄位名稱不區分大小寫。

符合附錄B建議的SR文字欄位範例：

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

ID欄位是SUBMIT_SM_RESP PDU中收到的ID，MT的認可。

sub和dlvrd應該計算傳遞的部分和傳遞的訊息數量，但Adobe Campaign並未使用此專案，因為broadlog系統提供更好、更整合的資訊。

submit date和done date欄位是指示性時間戳記，表示傳送MT的時間以及行動裝置傳送SR的時間。 預期時區會出現一些問題，甚至是日期集不正確的行動裝置所給定的錯誤時間戳記。

stat欄位很重要，因為它可告知訊息的狀態。 唯一重要的狀態為DELIVRD、UNDELIV和REJECTD。 DELIVRD狀態表示成功，其他兩個狀態表示錯誤。 也可以使用其他值，但通常是中繼通知，例如MT到達行動電信業者，但不是行動電話。 Adobe Campaign會忽略這些中繼通知。

錯誤欄位包含提供者特有的錯誤代碼。 提供者必須提供一份可能的錯誤代碼表格，以及能夠解譯此值的意義。

最後，文字欄位通常包含MT文字的開頭。 Adobe Campaign會忽略此專案，而有些提供者不會傳輸此專案，以避免PII洩漏和網路頻寬消耗。 在疑難排解期間，可透過讀取此欄位，更輕鬆地找出與測試MT相符的SR。

Adobe Campaign Classic Extended generic SMPP中的SR處理範例 sr-processing

此範例顯示遵循附錄B建議的實作案例、外部帳戶中的預設值以及成功的SMS MT。

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

首先，套用id extraction規則運算式以擷取ID並將其與對應的MT調解。

接著，status extraction規則運算式和error code extraction規則運算式會套用以擷取這些欄位，並附加至字串。

broadlog訊息是以此資訊建構，並且會附加原始未變更的字串以供參考：

SR ExampleProvider DELIVRD 000|MESSAGE=id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

然後會標準化訊息，移除MESSAGE部分，以便能夠將多個訊息與相同的狀態和錯誤碼進行比對。

SR ExampleProvider DELIVRD 000|#MESSAGE#

如果訊息尚未布建在broadlog訊息表格中，則會建立新專案，將整個訊息用作​ firstText ​和規範化的訊息。 然後，聯結器使用成功和error規則運算式來判斷它是成功還是失敗：

依預設，所有錯誤都會布建為軟錯誤。 這表示必須手動布建硬錯誤。

SMS文字編碼 sms-text-encoding

您應該​ 一律與SMSC提供者連絡，以防出現編碼問題。 只有SMSC提供者知道他們支援的編碼方式，以及由於其技術平台的限制而可能適用的特殊規則。

SMS訊息使用特殊的7位元編碼，通常稱為GSM7編碼。

在SMPP通訊協定中，會將GSM7文字展開為每個字元8位元，以較容易進行疑難排解。 SMSC會將其封裝成每個字元7位元，再傳送給行動裝置。 這表示SMS的short_message欄位在SMPP框架中可能長達160位元組，而在行動網路上傳送時上限為140位元組。

如果出現編碼問題，請檢查以下重要事項：

data_coding欄位會告訴您使用哪種編碼。 主要問題是值0表示規格中的預設SMSC編碼，這通常指GSM7。 請洽詢SMSC合作夥伴，其編碼與Adobe Campaign僅支援的data_coding = 0相關聯。 其他data_coding值傾向於遵循規格，但唯一確定的方法是向SMSC提供者確認。

訊息的大小上限取決於其編碼。 下表總結了所有相關資訊：

SMPP外部帳戶引數 SMPP-parameters-external

SMPP通訊協定的每個實作都有許多變數。 為了改善相容性和適應性，可使用許多設定來變更SMPP聯結器的行為。 本節說明每個引數及其對聯結器的影響。

一般引數和路由 general-parameters-routing

限制此帳戶的MTA執行個體

您可以設定允許連線至SMPP提供者的MTA執行個體數目限制。 如果勾選，您可以指定最多可以使用多少MTA。

這個選項可讓您更精確地控制連線數目，請參閱同時連線。

如果您設定的值高於正在執行的MTA數量，則所有MTA都會正常執行：此選項只是一個限制，不會產生額外的MTA。

如果您需要精確控制連線數量（例如提供者需求），建議一律設定此選項，即使目前部署執行中的MTA數量正確。 如果之後新增其他MTA，仍會遵守連線限制。

連線設定 connection-settings

SMSC 實作名稱 smsc-implementation-name

設定SMSC實作的名稱。 應將其設定為您的提供者的名稱。 請聯絡管理員或傳遞團隊，以瞭解要在此欄位中新增什麼。 此欄位的角色在SR錯誤管理區段中說明。

伺服器 server

要連線之伺服器的DNS名稱或IP位址。

連接埠 port

要連線的TCP連線埠。

帳戶 account

連線的登入。 已在BIND PDU的system_id欄位中傳遞。

密碼 password

SMPP連線的密碼。 在BIND PDU的密碼欄位中傳遞。

系統類型 system-type

在BIND PDU的system_id欄位中傳遞的值。 有些提供者需要在此指定特定值。

MTA 子連線的數量 number-mta-child

在Adobe Campaign Classic中，這會定義每個MTA子項的連線數目。

Adobe Campaign Classic Extended SMPP聯結器可控制每個MTA子項的連線數量。 若要控制連線的全域限制，您必須限制MTA子流程的數量，這通常表示要為SMS提供專用的中間來源平台。

Adobe Campaign Classic的接收器與傳送器連線數量可能有所不同：

如上所述，如果啟用自動回覆，Adobe Campaign Classic簡訊程式會開啟更多傳送器連線。 這些額外的連線可用來傳送自動回覆。

如果您設定自動回覆，簡訊程式會開啟傳送器/接收器配對，增加傳送器連線的數量。 如果您未設定任何自動回覆，則僅會開啟接收器連線。

透過 SMPP 啟用 TLS enable-TLS

使用TLS連線到提供者。 連線將會加密。 TLS連線由OpenSSL程式庫管理，任何適用於OpenSSL的內容對於此連線都將為True。

在記錄檔中啟用詳細的 SMPP 追蹤 enable-verbose-log-file

此設定會傾印記錄檔中的所有SMPP流量。 在初始設定期間，通常需要調整引數。 疑難排解聯結器時，必須啟用此功能，並與提供者看到的流量進行比較。

在Adobe Campaign Classic中，記錄輸出位於MT相關流量的MTA記錄中，以及MO和SR相關流量的SMS記錄中。

接收方連線設定 receiver-connection

此區段僅在分隔的​ 傳送器+接收器 ​模式中可見。

為接收方使用不同的參數 receiver-parameters

取消核取此方塊時，傳送器與接收器會使用相同的設定。

核取此方塊後，連線設定 ​區段中的設定將套用至傳送器，而​ 接收器連線 ​設定中的設定將套用至接收器。

接收者伺服器、連線埠、帳戶、密碼、系統型別

這些設定適用於處於傳送器+接收器模式的接收器。 它們的運作方式與傳送器部分類似，請參閱上方以取得詳細資訊。

SMPP頻道設定 smpp-channel-settings

允許字母音譯 allow-character-transliteration

音譯是尋找與遺失字元相當的字元的程式。 例如，GSM編碼中缺少法文「e」（帶有抑揚符號）字元，但可將其取代為「e」，而不會影響可讀性。

取消核取此方塊時，如果文字編碼無法完全依照原樣編碼字串，則會失敗。

核取此方塊時，文字編碼會嘗試將字串轉換為近似版本，而非失敗。 如果部分字元在目標編碼中沒有對應的字元，文字編碼將會失敗。

請參閱定義編碼設定的特定對應，以取得編碼程式的一般說明。

在資料庫中儲存傳入MO incoming-mo-storing

啟用後，傳入的MO將儲存在資料庫的inSMS表格中。 您可以使用任何工作流程的查詢活動來查詢此表格。

Adobe Campaign Classic一律會將所有MO儲存在inSMS資料庫中，因此此選項無法使用。

在SR處理期間啟用即時KPI更新 real-time-kpi

啟用後，接收錯誤SR時，KPI將在主要傳遞頁面上即時更新。

缺點可能是效能低，因為它會產生資料庫爭用。 如果停用，syncfromexec ​工作流程會更新統計資料，每20分鐘執行一次。

Adobe Campaign Classic的KPI機制完全不同，因此此選項無法使用。

來源編號 source-number

定義訊息的預設來源位址。 此設定僅適用於傳送中來源號碼保持空白的情況。

依預設，來源編號欄位不會傳遞，因此提供者會將其取代為短程式碼。

這會啟用寄件者地址/oADC覆寫功能。

簡短代碼 short-code

表示帳戶的主要簡短代碼。 若此帳戶使用多個短代碼，或短代碼不明，則將此欄位留空。

指定短程式碼有助於兩個功能：

Source TON/NPI、目的地TON/NPI ton-npi

TON （號碼型別）和NPI （編號計畫指示器）在SMPP 3.4規格 （第117頁）的第5.2.5節中說明。 這些值應該設定為提供者的需求。

在SUBMIT_SM PDU的source_addr_ton、source_addr_npi、dest_addr_ton及dest_addr_npi欄位中依原樣傳輸。

服務類型 service-type

此欄位在SUBMIT_SM PDU的service_type欄位中依原樣傳輸。 將此設定為提供者的需求。

輸送量和逾時 throughput-timeouts

這些設定控制SMPP頻道的所有計時方面。 有些提供者需要非常精確的訊息速率、視窗和重試計時控制。 這些設定應設定為符合提供者容量與其合約中所指示條件的值。

傳送窗口 sending-window

視窗是可傳送的SUBMIT_SM PDU數目，不需等候相符的SUBMIT_SM_RESP。

最大視窗為4的傳輸範例：

當網路連結具有高延遲時，此視窗有助於增加輸送量。 視窗的值必須至少是SMS/s數乘以連結的延遲
以秒為單位，聯結器絕不會等待SUBMIT_SM_RESP再傳送下一個訊息。
如果視窗太大，您可以在連線發生問題時傳送更多重複的訊息。 此外，大多數提供者對視窗有非常嚴格的限制，並拒絕超過限制的訊息。

如何計算最佳傳送時間公式：

範例：如果您在最大MT輸送量中設定300個SMS/s，並且平均在SUBMIT_SM和SUBMIT_SM_RESP之間有100毫秒的延遲，則最佳值將是300×0.1 = 30。

最大 MT 輸送量 max-mt-throughput

每秒和每個連線的最大MT數目。 此設定會嚴格執行，MTA絕不會以快於此限制的速度推送訊息。 對於需要精確節流功能的提供者來說，這個變數非常有用。

若要瞭解總輸送量限制，請將此數字乘以上述公式中詳述的連線總數。

0表示沒有限制，MTA會儘快傳送MT。

通常建議將此設定保持在1000以下，因為除非在最終架構上正確設定基準並特別要求SMPP提供者，否則不可能保證超過此數量的精確輸送量。 將連線數目增加到1000 MT/s以上可能會更好。

重新連線前的時間 time-reconnection

當TCP連線中斷時，聯結器會先等候這個秒數，再嘗試建立連線。

MT 的有效期限 expiration-period

介於SUBMIT_SM及其相符的SUBMIT_SM_RESP之間的逾時。 如果未及時收到RESP，則訊息會被視為失敗，並套用MTA的全域重試原則。

繫結逾時 bind-timeout

TCP連線嘗試與BIND_*_RESP回覆之間的逾時。 逾時時，連線會由Adobe Campaign聯結器關閉，而且會等待一段時間再重新連線，然後重試。

enquire_link 時段 enquire-link-period

enquire_link是一種特殊型別的PDU，會傳送以保持連線運作。 此期間以秒為單位。 行銷活動聯結器只會在連線閒置時傳送enquire_link以節省頻寬。 如果在此期間後兩次未收到任何RESP，則會將連線視為無法使用，並觸發重新連線程式。

SMSC細節 SMSC-specifics

這些設定是進階設定，可讓Adobe Campaign聯結器適應大多數SMPP實作特性。

定義編碼的特定對應

如需文字編碼的詳細資訊，請參閱SMS文字編碼區段。

此設定可讓您定義與規格不同的自訂編碼對應。 您將能夠宣告編碼清單及其data_coding值。

MTA將嘗試使用清單中的第一個編碼進行編碼。 如果失敗，則會嘗試使用清單上的下一個編碼等。 如果無法使用編碼來編碼訊息，則會發生錯誤。 找到編碼後，MTA將會以編碼文字建立SUBMIT_SM PDU，並以表格中指定的值設定data_coding欄位。

表格中的專案順序很重要：編碼是從上到下的嘗試。 您應該將最便宜或最建議的編碼放在清單的最前面，然後是越來越昂貴的編碼。

請注意，UCS-2絕不會失敗，因為它可編碼Adobe Campaign支援的所有字元，而UCS-2 SMS的長度上限則小得多：僅限70個字元。

您也可以使用此設定，透過在對應表中僅宣告1行來強制一律使用特定編碼。

未核取核取方塊時使用的預設對應等於下表：

這表示MTA會嘗試在GSM中編碼訊息。 如果成功，它將在data_coding設為0的情況下傳送。

如果訊息無法以GSM編碼，則會以UCS-2編碼，並將data_coding設為8。

啟用message_payload enable-message-payload

取消勾選時，MTA會分割長簡訊，並使用UDH在多個SUBMIT_SM PDU中傳送。 此訊息將由行動電話根據UDH資料重新構成。

如果勾選，長簡訊會在一個SUBMIT_SM PDU中傳送，並將文字放在message_payload選用欄位中。 如需此專案的詳細資訊，請參閱SMPP規格。

若啟用此功能，Adobe Campaign將無法個別計算SMS部分：所有訊息都會計為只傳送一個部分。

傳送完整的電話號碼 send-full-phone-number

如果未核取此核取方塊，則只會傳送電話號碼的數字給提供者（SUBMIT_SM欄位的destination_addr欄位）。 這是預設行為，因為國際數字指標（通常是+前置詞）會由SMPP中的TON和NPI欄位取代。

核取核取方塊時，電話號碼會依原樣傳送，不會預先處理及可能的空格、+前置詞或井號/雜湊/星號。

此功能也會影響自動回覆封鎖清單功能的行為：未核取核取方塊時，將向插入隔離表格的電話號碼新增+首碼，以補償SMPP通訊協定本身從電話號碼移除的+首碼。

略過TLS憑證檢查 skip-tls

啟用TLS時，略過所有憑證檢查。

一旦勾選，連線將變得不安全，生產中不應啟用此連線。

其對於除錯或測試用途相當實用。

您可以在三種不同的憑證驗證值之間進行選擇：

繫結TON/NPI bind-ton-npi

SMPP 3.4規格 （第117頁）的第5.2.5節中說明的TON （號碼型別）和NPI （號碼計畫指示器）。 這些值應該設定為提供者所需的任何值。

它們在BIND PDU的addr_ton和addr_npi欄位中依原樣傳輸。

地址範圍 address-range

在BIND PDU的address_range欄位中依原樣傳送。 此值應設定為提供者所需的任何值。

無效 ID 確認計數 invalid-id

限制可為單一SR傳送的​ 訊息ID無效 DELIVER_SM_RESP的數量。

這只能作為疑難排解之用，作為因應措施 ​並在正常情況下設為0。

Fox範例，設定為2時：

將此欄位設為0會停用一律傳回​ 訊息ID無效 ​的機制，這是正常行為。

將此欄位設為1，即使ID無效，聯結器一律會回應「確定」。 只有在監督下，才應將這個值設為1，以進行疑難排解，並設定為最短時間，例如，從提供者端的問題復原。

SR 中 ID 的擷取規則運算式 regex-extraction

SMPP通訊協定規格並未嚴格執行SR格式。 這只是規格的附錄B （第167頁）中說明的建議。 有些SMPP實作者對此欄位的格式不同，因此Adobe Campaign需要一種方法來擷取正確的欄位。

依預設，它會在id:之後擷取最多10個英數字元。

規則運算式必須正好有一個擷取群組，且部分包含在括弧中。 ID部分必須以括弧括住。 規則運算式格式為PCRE。

調整此設定時，請務必加入儘可能多的內容，以避免誤觸發。 如果有特定的字首，例如標準中的id:，請在規則運算式中加入這些字首。 請儘量使用文字分隔符號(\b)，以避免在文字中間擷取文字。

在規則運算式中加入不夠的上下文可能會引入一個小的安全性缺陷：訊息的實際內容可包含在SR中。 如果您只比對不含任何內容的特定ID格式（例如UUID），則可能是剖析實際文字內容（例如，內嵌在文字欄位中的UUID），而非ID。

用於確定成功/錯誤狀態所套用的規則運算式 regex-applied

遇到具有未知統計/錯誤欄位組合的訊息時，這些規則運算式會套用至統計欄位，以判斷SR是成功還是錯誤。 統計值不符合任何這些規則運算式的SR會遭到忽略。

依預設，以DELIV （例如附錄B中的DELIVRD）開頭的stat值會被視為已成功傳遞，而所有符合錯誤的stat值（例如REJECTED、UNDELIV）則會被視為錯誤。

MT確認中的ID格式 id-format-mt

這表示SUBMIT_SM_RESP PDU的message_id欄位中傳回的ID格式。

SR中的ID格式 id-format-sr

這表示SR中ID的Extraction規則運算式擷取的ID格式。 值與上述MT格式具有相同的含義和相同的行為。

選擇性欄位​ 中的 SR ID或錯誤代碼

如果勾選，選用欄位的內容將會附加至上述規則運算式處理的文字中。 文字的格式為0xTAG:VALUE，0xTAG是標籤的4位十六進位值，以大寫表示，例如0x002E。

例如，您可能想要擷取receipted_message_id欄位中的識別碼。 為此，啟用此核取方塊，並將以下文字新增到狀態：

0x001E:05e3299e-8d37-49d0-97c6-8e4fe60c7739

在此範例中，0x001E是選用欄位的標籤，而UUID是欄位的值。

為了擷取此值，您現在可以在SR欄位中ID的擷取規則運算式中設定下列規則運算式：

\b0x001E:([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})\b

文字欄位​ 中的 SR ID或錯誤代碼

如果勾選，Text ​欄位將在處理SR的狀態文字期間保留。

如果提供者將重要資料（例如ID或狀態）放置在此欄位中，這個功能會很有用。 此欄位通常可以安全地捨棄，因為它可能包含具有非ASCII編碼的文字，並中斷規則運算式處理。

如果SR欄位中ID的Extraction規則運算式不夠具體，啟用此選項可能會引入非常小的安全性漏洞。 Text ​欄位的內容可能會剖析為ID，而攻擊者可能會使用它來插入偽造的ID，這可能會導致部分拒絕服務的情況。

服務ID標籤

允許新增自訂TLV。 此欄位會設定標籤部分。 可以在​ 服務或傳遞的進階引數中的方案ID ​值中，為每個傳遞自訂值。

此設定僅允許每則訊息新增一個TLV選項。

傳送至 MO 的自動回覆 automatic-reply

此功能可讓您快速回覆文字至MO，並處理傳送到封鎖清單的每短程式碼。

關鍵字 ​和​ 短代碼 ​欄定義條件以觸發自動回覆。 如果兩個欄位相符，會傳送MO並觸發其他動作。 若要指定萬用字元，應將此欄位留空。 關鍵字會與MO文字中的第一個英數字元單字相符，忽略標點符號和前置空格。 這表示​ Keyword ​欄位不能包含空格，而且必須是單一字詞。

關鍵字 ​設定是前置詞。 例如，如果您指定「AD」，則會比對「AD」、「ADAPT」和「ADOBE」。 如果您有多個具有相同首碼的關鍵字，請務必留意順序，因為關鍵字是從上到下處理。

回覆 ​資料行是要回覆的文字。 此欄位中沒有可用的個人化。 如果您將此欄位留空，將不會回覆任何訊息，但反正也會觸發其他動作。

當​ 關鍵字 ​和​ 簡短代碼 ​都相符時，其他動作 ​欄可提供額外的動作，空白簡短代碼符合所有簡短代碼。 您可以傳送到隔離區或從隔離區中移除，對文字使用「無」回覆。 如果您指定​ 其他動作，但將​ 回覆 ​欄位保留空白，將會執行動作，但不會傳送任何回覆。 隔離僅適用於指定的短程式碼，或如果欄位留空則所有短程式碼。

表格中的所有專案會依指定順序處理，直到符合一個規則為止。 如果有多個規則符合一個MO，則只會套用最上層的規則。

簡訊傳遞範本引數 sms-delivery-template-parameters

某些引數可依傳遞範本設定。

來自欄位 from-field

此欄位為選用。 它允許覆寫寄件者地址(oADC)。 此欄位的內容置於SUBMIT_SM PDU的source_addr欄位中。

根據SMPP規格，欄位限製為21個字元，但某些提供者可能允許較長的值。 另請注意，某些國家/地區可能會套用非常嚴格的限制，例如長度、內容、允許的字元。

傳遞參數 delivery-parameters

每則訊息的簡訊數上限 maximum-sms

此設定僅適用於​ 訊息承載 ​設定已停用的情況。 如果訊息需要的SMS數量超過此值，則會觸發錯誤。

SMS通訊協定將SMS限製為255個部分，但有些行動電話無法拼合長度超過10個部分左右的訊息，此限制取決於確切模型。 我們建議您不要每則訊息超過5個部分。

由於個人化訊息在Adobe Campaign中的運作方式，訊息的大小可能會有所不同。 大量的長訊息可能會增加傳送成本。

傳輸模式 transmission-mode

此欄位會指出您要傳輸的SMS型別：一般或快閃訊息，儲存在行動裝置或SIM卡上。

此設定會在SUBMIT_SM PDU的dest_addr_subunit選用欄位中傳輸。

有效期限 validity-period

有效期間在SUBMIT_SM PDU的validity_period欄位中傳輸。 日期始終格式化為絕對UTC時間格式，日期欄位將以「00+」結尾。

延伸的通用SMPP聯結器 acc-extended-connector

箭頭代表資料流程。

傳送傳遞部分時，MTA會產生MTA子項。 MTA子處理程式的數量是動態的，取決於serverConf.xml中的設定。 每個MTA子項都會例項化連線至SMPP提供者的聯結器CSmppConnectorWorker。 只要MTA子項保持連線（也可以在serverConf.xml中設定），連線就會保持連線。

SMS程式只會處理SR，它會連線到提供者並保持連線開啟。 程式每10分鐘會重新連線以重新載入新設定，這是正常操作。

符合MT、SR和broadlog專案 matching-mt

中繼資料表nmsProviderMsgId是用來暫時儲存MT和SR資料，然後以非同步方式提交至broadlog。

nmsProviderMsgId資料表有3個資料行群組：

當MT和SR都完成處理時，您應該有完整的行，其中包含broadlog資訊和狀態資訊。

在這裡，iMsgId連結到nmsBroadLogMsg資料表，表示完整的狀態/錯誤訊息。

SMS程式每分鐘會檢查一次完整行，然後非同步處理它們：

輸送量和平行連線

每個MTA子系會建立可設定的連線數量，因此限制MTA子系的數量將限制連線數量。 由於MTA子處理程式與流量之間的關聯是相關的，這可以控制，但仍有些無法預測。

上線之前 checklist

此檢查清單提供您上線前應檢查的事項清單。 不完整的設定可能會導致許多問題。

檢查外部帳戶衝突 external-account-conflict

確認您沒有舊的SMS外部帳戶。 如果您停用測試帳戶，則會在生產系統上重新啟用該帳戶並產生潛在衝突的風險。

如果您在同一Adobe Campaign執行個體上擁有多個連線到相同提供者的帳戶，請聯絡提供者，以確保他們實際區分這些帳戶之間的連線。 若有多個帳戶具有相同登入，則需要額外設定。

在檢查期間啟用詳細的SMPP追蹤 enable-verbose

檢查期間應一律啟用詳細的SMPP追蹤。
即使您無法自行檢查記錄檔，Adobe客戶服務也可以更輕鬆協助您。

測試您的簡訊 test

檢查PDU check-pdus

即使訊息看起來成功，也務必檢查PDU的格式是否正確。

在連線到之前未連線到Adobe Campaign的提供者時，此步驟是必要的。

繫結 bind

檢查BIND_* PDUs是否正確傳送。 要檢查的最重要事項是提供者一律會傳回成功的BIND_*_RESP PDUs (command_status = 0)。

檢查BIND_* PDU是否不多。如果有太多這類連線，可能表示連線不穩定。 如需詳細資訊，請參閱不穩定的連線問題一節。

ENQUIRE_LINK enquire-link-pdus

檢查連線閒置時是否定期交換ENQUIRE_LINK PDU。

SUBMIT_SM / DELIVER_SM

傳送訊息，然後在記錄中搜尋其對應的SUBMIT_SM、SUBMIT_SM_RESP、DELIVER_SM和DELIVER_SM_RESP PDU。

使用SUBMIT_SM PDU：

使用SUBMIT_SM_RESP PDU：

使用DELIVER_SM PDU：

使用DELIVER_SM_RESP PDU：

請洽詢您的提供者 provider

即使您的SMS成功，請聯絡提供者以檢視是否一切正常。

停用詳細的SMPP追蹤 disable-verbose

完成所有檢查後，最後一項是​ 停用詳細的SMPP追蹤 ​以不產生太多記錄。 您可以重新啟用這些功能，以進行疑難排解，即使在生產系統上也是如此。