SMS コネクタのプロトコルと設定
作成対象：
- 開発者
NOTE概要
SMS は、書式設定のない短いテキストメッセージの送信に限定されますが、そのシンプルさがこのコミュニケーションチャネルの利点でもあります。
SMS を送信する主な方法は 2 つあります。
- 電話から手動で送信する：人と人との間で直接通信する通常の方法。
- インターネットから送信する：Adobe Campaign がメッセージを送信する方法。インターネットをモバイルネットワークに接続する SMS サービスプロバイダーが必要です。Adobe Campaign は、SMPP プロトコルを使用して SMS をサービスプロバイダーに送信します。
このドキュメントでは、Adobe Campaign と SMPP プロバイダーの間の接続設定について説明します。
SMPP プロバイダーは公式仕様から外れる場合がありますが、Adobe Campaign の SMS コネクタは、ほとんどのプロバイダーと互換性を持つように動作を適応させるための多くのオプションを提供します。
IMPORTANTSMS の種類
SMS プロバイダー経由で大量の SMS を送信する場合、次の 3 種類の SMS が発生します。
-
SMS MT（モバイル終了）：Adobe Campaign が SMPP プロバイダーを通じて携帯電話に向けて発信する SMS。
-
SMS MO（モバイル発信）：携帯電話から SMPP プロバイダー経由で Adobe Campaign に送信される SMS。
-
SMS SR（ステータスレポート）、DR または DLR（配信受信）：SMS が正常に受信されたことを示す、SMPP プロバイダーを通じて Adobe Campaign に携帯電話から送信される返信確認メッセージ。Adobe Campaign は、メッセージが配信できなかったことを示す SR を受け取る場合もあります。多くの場合、エラーの説明が記載されています。
確認応答（RESP PDU、SMPP プロトコルの一部）と SR を区別する必要があります。SR は、ネットワークのエンドツーエンドを通じて送信される SMS の一種で、確認応答は、1 回の転送が成功したことを確認するだけのものです。
確認応答と SR は両方ともトリガーエラーを起こす可能性があります。そのため、この 2 つを区別するとトラブルシューティングに役立ちます。
SMS で送信される情報
SMS は、テキストよりも多くの情報を伝送します。SMS によって提供される情報のリストを以下に示します。
-
テキスト。140 バイトに制限されます。つまり、エンコーディングに応じて 70～160 文字の範囲です。詳細と制限については、SMS テキストエンコーディングを参照してください。
-
受信者アドレス。
ADCまたはMSISDNとも呼ばれます。SMS を受信する携帯電話の番号です。 -
送信者のアドレス。
oADCまたはsender idとも呼ばれます。日々の使用で使用される電話番号、プロバイダーや名前を通じて送信されるショートコードを指定できます。名前はオプションの機能です。この場合、SMS に返信できません。 -
メッセージが Flash メッセージであるかどうかを示すフラグ。Flash メッセージは、メモリに保存されないポップアップです。
-
SR が予想されるかどうかを示すフラグ。
-
有効日。この日を過ぎると、ネットワーク機器は再試行できません。
-
data_codingフィールド。テキストのエンコーディングを示します。
SMPP プロトコル
Adobe Campaign Classic は、SMPP プロトコルバージョン 3.4 をサポートしています。これは、SMS をプロバイダー（SMSC）に送信し、SMS および領収書も受信できる広範なプロトコルです。詳しくは、SMPP ドキュメントを参照してください。
SMS サービスプロバイダー側のネットワーク機器は、SMSC と呼ばれることが多いです。
SMPP 接続
Adobe Campaign は、TCP を介して SMS サービスプロバイダーのネットワーク機器に接続します。SMPP プロトコルは、Adobe Campaign からプロバイダーへの永続的な TCP 接続を設定します。TCP 接続は、常に Adobe Campaign が開始します。メッセージを受信する場合も同様です。SMPP は、モードに応じて 1 つまたは 2 つの TCP 接続を開きます。すべての接続は、常に Adobe Campaign によって開始されます。
SMPP プロトコルは次の 2 つのモードで動作します。
- トランスミッター + レシーバー（または TX+RX）：メッセージの送受信には、2 つの異なる TCP 接続が使用されます。
- トランシーバ（または TRX）：メッセージの送受信には、単一の TCP 接続が使用されます。
NOTESMPP 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 は「受信済み」メッセージのステータスをトリガーします。
セキュリティ面
プロトコル自体は暗号化されません。ほとんどのプロバイダーは、許可リスト上に IP のバリアントを実装しているので、Adobe Campaign サーバーの IP アドレスをプロバイダーに宣言する必要があります。
Adobe Campaign は、バインド段階でのログインとパスワードの受け渡しをサポートしています。また、SMPP over TLS もサポートします。適切なセキュリティを確保するためには、証明書が必要であることに注意してください。SMPP コネクタは証明書チェックのバイパスを許可しますが、証明書を持たない TLS はセキュリティレベルの大幅な低下につながるので、テストにのみ使用する必要があります。
コネクタは、システム openssl ライブラリが提供するデフォルトの証明書を使用します。通常は Debian の /etc/ssl/certs ディレクトリで提供されます。このディレクトリは、デフォルトで「ca-certificates」パッケージによって提供されていますが、カスタマイズ可能です。
各種 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 の主なフィールド：
-
system_id：認証に使用するログイン。外部アカウントに設定されます。
-
パスワード：認証に使用するパスワード。外部アカウントに設定されます。
-
system_type：一部のプロバイダーでは、特定の値に設定する必要があります。外部アカウントで設定され、すべてのバージョンで利用可能です。多くの場合、様々な種類の契約、チャネル、国などを区別します。
-
addr_ton および addr_npi：一部のプロバイダーで必須です。外部アカウントの
Bind TON設定とBind NPI設定で指定します。 -
address_range：一部のプロバイダーで必須です。これはほとんどの場合、この接続で使用できるショートコードのリストです。外部アカウントに設定されます。
BIND_*_RESP に特定のフィールドがない場合は、接続が成功したかどうかを確認します。
UNBIND
この PDU は、切断前にシステムから送信する必要があります。UNBIND_RESP PDU との一致を待ってから、接続を閉じる必要があります。
適合 SMSC は接続を閉じてはいけません。TCP 接続は Adobe Campaign コネクタによって制御されます。
SUBMIT_SM
この PDU は、MT を SMSC に送信します。応答 PDU は、MT の ID を提供します。
SUBMIT_SM PDU の主なフィールド：
-
service_type：一部のプロバイダーで必要です。配信のプロパティで設定します。
-
source_addr_ton および source_addr_npi：伝送される送信元アドレスの種類を示します。これらのフィールドの意味は標準化されていますが、一部のプロバイダーでは使い方が異なるので、プロバイダーに正しい値を確認する必要があります。外部アカウントに設定されます。
-
source_addr：MT のソースアドレス／oADC。携帯電話に表示されます。外部アカウントと配信で設定すると、配信内の値が外部アカウントの値よりも優先されます。
-
dest_addr_ton および dest_addr_npi：送信される宛先アドレスの種類（ローカルや国際形式など）を示します。これらのフィールドの意味は標準化されていますが、一部のプロバイダーでは使い方が異なるので、プロバイダーに正しい値を確認する必要があります。外部アカウントに設定されます。
-
destination_addr：受信者アドレス、電話番号、または MSISDN。
-
esm_class：UDH がテキストフィールドで使用されているかどうかを示すために使用します。
message_payloadモードが使用されない場合、分割 SMS のコネクタによって自動的に有効になります。 -
priority_flag：他のメッセージと比較した場合のこのメッセージの優先順位。これは、配信自体の優先度に結び付けられます。
-
validity_period：タイムスタンプ。このタイムスタンプを超えると、再試行はおこなわれません。配信自体に設定されます。
-
registered_delivery：SR が要求されているかどうかを示します。Adobe Campaign は、自動返信を除き、常にこのフラグを設定します。マルチパートメッセージの場合、フラグは最初のパーツに対してのみ設定されます。すべてのバージョンで同じ動作がおこなわれます。
-
data_coding：テキストフィールドで使用されるエンコーディングを示します。詳しくは、SMS テキストエンコーディングの節を参照してください。
-
short_message：メッセージのテキスト。UDH を使用する場合は、UHD ヘッダーも含まれます。
Adobe Campaign では、次のオプションフィールドがサポートされています。
-
dest_addr_subunit：Flash、携帯電話、または SIM カードといった SMS のターゲットを指定するために使用します。配信のプロパティで設定します。
-
message_payload：外部アカウントで有効にすると、長いメッセージは 1 つの PDU で送信され、テキストは
short_messageフィールドではなくこのフィールドで送信されます。
SUBMIT_SM_RESP
この PDU には、MT の ID が含まれます。これは、着信 SR と一致させるのに役立ちます。
IMPORTANT一部のプロバイダーは、SR を送信した後に SUBMIT_SM_RESP を送信します。この動作を考慮するには、Adobe Campaign は 30 秒待ってから、不明な ID を持つ SR に 無効なメッセージ ID を返します。
DELIVER_SM
この PDU は、SMSC から Adobe Campaign に送信されます。MO または SR が含まれます。
ほとんどのフィールドは、対応する SUBMIT_SM と同じ意味を持ちます。役立つフィールドのリストを次に示します。
-
source_addr：MO/SR のソースアドレス。通常は電話番号です。
-
destination_addr：MO または SR を受け取ったショートコード。
-
esm_class：PDU が MO か SR かを識別するために使用します。
-
short_message：メッセージのテキスト。SR の場合、SMPP プロトコル仕様の付録 B に記載されているデータが含まれます。詳しくは、SR エラー管理を参照してください。
Adobe Campaign は、receipted_message_id オプションフィールドのメッセージ ID を読み取ることができます（設定によっては可）。
DELIVER_SM_RESP
この PDU は、SR と MO を確認するために Adobe Campaign から送信されます。
Adobe Campaign Classic は、SR と MO がデータベースに挿入された後に、SR と MO に対する確認応答をおこないます。正常な DELIVER_SM_RESP PDU が送信された場合でも、処理エラーが発生する場合があります。この制限は、Adobe Campaign Classic のソフトウェアアーキテクチャが原因です。
ENQUIRE_LINK
この PDU は、接続が有効であるかどうかを確認する目的でのみ使用します。頻度は、プロバイダーのニーズに応じて設定する必要があります。
デフォルトの 60 秒は、外部アカウントで設定されているほとんどの設定と一致する必要があります。
ENQUIRE_LINK_RESP
この PDU は、接続が動作していることを確認します。
マルチパート SMS（長文 SMS）
IMPORTANTmessage_payload は、着信 SMS（MO）ではサポートされていません。つまり、MO は 160 文字に制限されています。マルチパート SMS（ロング SMS）は、複数のパーツで送信される SMS です。モバイルネットワークプロトコルの技術的な制限により、SMS は 140 バイト以下にする必要があり、超える場合は分割する必要があります。SMS に収まる文字数について詳しくは、SMS テキストエンコーディングの節を参照してください。
長いメッセージの各部分は、個々の SMS です。これらのパーツは、ネットワーク上を単独で移動し、受信側携帯電話によって組み立てられます。再試行と接続性の問題を処理するために、Adobe Campaign はこれらのパーツを逆順に送信し、メッセージの最初の部分（最後の送信）でのみ SR を要求します。携帯電話は最初の部分を受け取ったときにのみメッセージを表示するので、他の部分の再試行は携帯電話で重複を生成しません。
配信ごとの SMS の最大数は、配信テンプレート の メッセージごとの SMS の最大数 設定を使用して、メッセージごとに設定できます。この制限を超えると、メッセージが長すぎることが原因で SMS の送信に失敗します。
長い SMS を送信する方法は 2 つあります。
-
UDH：長いメッセージを送信するデフォルトおよび推奨される方法です。このモードでは、コネクタは UDH 情報を含む複数の
SUBMIT_SM PDUにメッセージを分割します。このプロトコルは、携帯電話が使用するプロトコルです。Adobe Campaign はメッセージの生成を最大限制御でき、送信されたパーツの数と分割方法を正確に計算できます。 -
message_payload：長いメッセージを単一の
SUBMIT_SM PDUで送る方法です。プロバイダーはこれを分割する必要があります。つまり、Adobe Campaign が送信されたパーツの数を正確に把握することは不可能です。一部のプロバイダーはこのモードを必要としますが、UDH をサポートしていない場合にのみ使用することをお勧めします。
プロトコルとフォーマットについて詳しくは、SUBMIT_SM PDU の esm_class、short_message、message_payload の各フィールドの説明を参照してください。
スループットのキャッピングとウィンドウイング
ほとんどのプロバイダーでは、各 SMPP 接続にスループットの制限が必要です。これは、外部アカウント内に多数の SMS を設定することで達成できます。スループットのスロットルは接続ごとに発生します。有効なスループットの合計は、接続ごとの制限値に接続の合計数を乗じた値です。これについては、同時接続の節で詳しく説明します。
最大スループットに達するには、最大送信ウィンドウを微調整する必要があります。送信ウィンドウは、SUBMIT_SM_RESP を待たずに送信できる SUBMIT_SM PDU の数です。詳しくは、送信ウィンドウの設定の節を参照してください。
SR およびエラー管理（「付録 B」）
SMPP プロトコルは、RESP PDU に標準の同期エラーを定義しますが、SR のエラーコードは定義しません。各プロバイダーは、独自のエラーコードと意味を使用します。
SMPP プロトコル仕様（167 ページ）の付録 B の節にレコメンデーションが記載されていますが、実際のエラーコードとその意味は記載されていません。
エラー管理に対応するために、Adobe Campaign の broadLog メッセージシステムを活用して、エラーとその重大度（ハード、ソフトなど）を適切にプロビジョニングできます。
上述したように、2 種類のエラーがあります。
- メッセージが SMSC に送信された直後に発生する
SUBMIT_SM_RESP内の同期応答。 - 携帯電話がメッセージを受信したとき、またはメッセージがタイムアウトしたときに、受信メッセージがずっと後に発生する場合。この場合、SR にエラーが見つかります。
SR を受け取ると、short_message フィールドにステータスとエラーが表示されます（付録 B 準拠の実装例）。PDU の short_message フィールドは、MT にテキストが含まれるので、テキストフィールド と呼ばれることがよくあります。SR の場合は、テクニカル情報に加えて テキスト という名前のサブフィールドが含まれます。これらの 2 つのフィールドは異なり、short_message には実際に テキスト フィールドと他の情報が含まれます。
Adobe Campaign Classic コネクタ（拡張 SMPP を除く）は、選択したプロバイダーに依存するハードコードされた動作を使用します。汎用 SMPP は、成功とエラーを識別するだけで、詳細情報は含まれません。配信ログには、保証されていない情報が含まれている場合があります。
SR テキストフィールドの形式
この仕様では、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 は、配信されるパーツと配信されるメッセージの量を数えると考えられますが、broadLog システムはより的確で統合された情報を提供するので、Adobe Campaign はこの値を使用しません。
submit date および done date フィールドは、MT が送信されときと、SR が携帯電話から送信されたときのタイムスタンプを示します。タイムゾーンに関する問題や、日付が正しく設定されていない携帯電話のタイムスタンプは、正しくないことが予想されます。
stat フィールドは、メッセージの状態を示すので重要です。重要なステータスは DELIVRD、UNDELIV、REJECTD のみです。DELIVRD ステータスは成功を示し、残りの 2 つはエラーを示します。その他の値も可能ですが、通常は中間通知です（例えば、MT が携帯電話会社に到達したが、携帯電話に到達しなかった場合など）。これらの中間通知は、Adobe Campaign では無視されます。
err フィールドには、プロバイダー固有のエラーコードが含まれます。プロバイダーは、この値を解釈できるように、考えられるエラーコードの表とその意味を提供する必要があります。
最後に、テキストフィールドには通常、MT のテキストの先頭が含まれます。これは Adobe Campaign では無視され、一部のプロバイダーは PII の漏洩やネットワーク帯域幅の消費を防ぐために送信しません。このフィールドを読み込むと、テスト MT に一致する SR をより容易に見つけられるため、トラブルシューティングの際に使用できます。
Adobe Campaign Classic の拡張された汎用 SMPP における SR 処理の例
次の例では、付録 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 部分を削除して同じ stat および err コードを持つ複数のメッセージが一致するようにします。
SR ExampleProvider DELIVRD 000|#MESSAGE#
メッセージが broadLog メッセージテーブルにまだプロビジョニングされていない場合は、メッセージ全体を firstText とし、正規化されたメッセージを使用して新しいエントリが作成されます。次に、コネクタは success と error 正規表現を使用して、成功か失敗かを判断します。
-
success正規表現と一致する場合は、成功と見なされます。 -
error正規表現と一致する場合は、メッセージはエラーとして認定されます。 -
この 2 つの正規表現に一致するものがない場合、SR は無視されます。それは、Adobe Campaign で処理されない中間通知の可能性があります。
デフォルトでは、すべてのエラーはソフトエラーとしてプロビジョニングされます。つまり、ハードエラーは手動でプロビジョニングする必要があります。
SMS テキストエンコーディング
エンコードの問題が発生した場合は、必ず SMSC プロバイダーに連絡する 必要があります。SMSC プロバイダーの技術プラットフォームにおける制限により、SMSC プロバイダーがサポートするエンコーディングおよび適用される可能性がある特別なルールを把握しているのは、SMSC プロバイダーのみです。
SMS メッセージは、特殊な 7 ビットエンコーディングを使用します。通常、GSM7 エンコーディングと呼ばれます。
SMPP プロトコルでは、トラブルシューティングを容易にするために、GSM7 のテキストが 1 文字あたり 8 ビットに拡張されます。SMSC は、携帯電話に送信される前に、1 文字あたり 7 ビットにパックします。つまり、SMS の short_message フィールドの長さは SMPP フレームで最大 160 バイトになりますが、モバイルネットワークで送信される場合は 140 バイトに制限されます。
エンコードの問題が発生した場合は、次の点を確認してください。
-
どの文字がどのエンコーディングに属するのかを把握しておくようにします。GSM7 は、読み分け符号やアクセント記号を完全にはサポートしていません。フランス語の場合、é と è が GSM7 に含まれますが、ê、â、ï は含まれません。スペイン語も同じです。
-
セディラが付いた C（ç）は、GSM7 アルファベットでは大文字のみで表示されますが、一部の携帯電話では小文字または「スマート」文字で表示されます。一般的なレコメンデーションは、この文字の使用を避けてセディラを削除するか、UCS-2 に切り替えることです。
-
SMSC プロバイダーから明示的に要求されない限り、SMS では ASCII を使用しないでください。このエンコーディングは、8 ビット文字で GSM7 よりも有効範囲が少ないため、領域を浪費します。このエンコーディングは、北米で使用される CDMA ネットワークで必要な場合があります。
-
Latin-1 は必ずしもサポートされているわけではありません。Latin-1 を使用する前に、SMSC プロバイダーとの互換性を確認してください。
-
各国語シフトテーブルは、Adobe Campaign コネクタではサポートされていません。代わりに、UCS-2 または他の
data_codingを使用する必要があります。 -
UCS-2 と UTF-16 は、多くの場合、携帯電話で混在します。これは、UCS-2 に存在しない絵文字やその他の文字を使用する場合に問題となります。
-
ほとんどの携帯電話では、すべての UCS-2 文字のフォントグリフはありません。スマートフォンは珍しい文字を容易に表示できる傾向にありますが、通常、フューチャーフォンは、購入した国の母語で役立つ文字に対するサポートが制限されています。絵文字やアスキーアートを使用したい場合は、送信前に複数の携帯電話でテストしてください。Adobe Campaign プレビューは、見つからないグリフをシミュレートせず、web ブラウザーで使用できる記号を表示します。
data_coding フィールドは、使用されるエンコーディングを示します。主な問題は、値 0 が仕様のデフォルトの SMSC エンコーディングを意味し、通常は GSM7 を参照する点です。エンコーディングが data_coding = 0（Adobe Campaign のみがサポート）に関連付けられている SMSC パートナーに問い合わせてください。他の data_coding 値は仕様に従う傾向にありますが、念のため SMSC プロバイダーに確認することをお勧めします。
メッセージの最大サイズは、エンコーディングによって異なります。次の表に、すべての関連情報をまとめます。
UTF-16
SMPP 外部アカウントパラメーター
SMPP プロトコルの実装は、それぞれ多くのバリエーションを持ちます。互換性と適応性を向上させるために、SMPP コネクタの動作を変更する多くの設定を使用できます。この節では、コネクタに対するすべてのパラメーターとその影響について説明します。
一般的なパラメーターとルーティング
このアカウントの MTA インスタンスの制限
SMPP プロバイダーへの接続を許可する MTA インスタンスの数に制限を設定できます。このオプションを有効にすると、最大で使用できる MTA の数を指定できます。
このオプションを使用すると、接続数をより細かく制御できます。同時接続を参照してください。
実行中の MTA の数より大きい値を設定すると、すべての MTA は通常どおりに実行されます。このオプションは制限にすぎず、追加の MTA を生成できません。
接続数（プロバイダー要件など）を正確に制御する必要がある場合は、現在のデプロイメントで適切な数の MTA が実行されていても、常にこのオプションを設定することをお勧めします。その後 MTA を追加した場合でも、接続制限は考慮されます。
接続設定
SMSC 実装名
SMSC 実装の名前を設定します。プロバイダーの名前に設定する必要があります。このフィールドに追加する内容については、管理者または配信品質チームにお問い合わせください。このフィールドの役割は、SR エラー管理の節で説明しています。
NOTEサーバー
接続先のサーバーの DNS 名または IP アドレス。
ポート
接続先の TCP ポート。
アカウント
接続のログイン。BIND PDU の system_id フィールドに渡されます。
パスワード
SMPP 接続のパスワード。BIND PDU のパスワードフィールドに渡されます。
システムタイプ
BIND PDU の system_id フィールドに渡された値。一部のプロバイダーは、ここで特定の値を必要とします。
MTA 子接続の数
Adobe Campaign Classic では、MTA の子 1 つあたりの接続数を定義します。
Adobe Campaign Classic 拡張 SMPP コネクタは、MTA の子 1 つあたりの接続数を制御できます。接続のグローバル制限を制御するには、MTA 子プロセスの数を制限する必要があります。これは、多くの場合、SMS 専用のミッドソーシングプラットフォームを持つことを意味します。
Adobe Campaign Classic の場合は、レシーバーとトランスミッターの接続数が異なる場合があります。
- トランスミッター接続 = MTA 子接続の数 * MTA 子プロセスの数 * MTA の数（自動応答が設定されている場合） MTA 子接続の数*
上記の推奨事項に従い、自動応答が有効な場合は、Adobe Campaign Classic SMS プロセスがより多くのトランスミッター接続を開きます。これらの追加の接続は、自動応答の送信に使用されます。
- レシーバー接続 = MTA 子接続の数
自動応答を設定した場合、SMS プロセスはトランスミッター／レシーバーのペアを開き、トランスミッター接続数を増やします。自動応答を設定しなかった場合は、レシーバー接続のみが開きます。
TLS over SMPP を有効にする
TLS を使用してプロバイダーに接続します。接続が暗号化されます。TLS 接続は OpenSSL ライブラリによって管理され、この接続で OpenSSL に適用されるものはすべて実行されます。
ログファイルの詳細 SMPP トレースを有効にする
この設定は、すべての SMPP トラフィックをログファイルにダンプします。多くの場合、初期設定時にパラメーターを調整する必要があります。コネクタのトラブルシューティングをおこなう場合は、この機能を有効にし、プロバイダーが確認するトラフィックと比較する必要があります。
Adobe Campaign Classic では、MT 関連のトラフィックの場合は MTA ログ、MO および SR 関連のトラフィックの場合は SMS ログにログ出力が記録されます。
受信者接続設定
このセクションは、分離された 送信者 + 受信者 モードでのみ表示されます。
受信者に別のパラメーターを使用
このチェックボックスをオフにすると、トランスミッターとレシーバーに同じ設定が適用されます。
このチェックボックスをオンにすると、接続設定 セクションの設定がトランスミッターに適用され、レシーバー接続 設定がレシーバーに適用されます。
レシーバーサーバー、ポート、アカウント、パスワード、システムタイプ
これらの設定は、トランスミッター + レシーバーモードの場合にレシーバーに適用されます。トランスミッター部分と同様に機能します。詳しくは、上記を参照してください。
SMPP チャネル設定
文字の表記変換を許可
文字の置き換えとは、見つからない文字に相当する文字を探す処理です。例えば、フランス語の「ê」（曲折アクセント記号付きの e）文字は GSM エンコーディングでは見つかりませんが、可読性を損なうことなく「e」に置き換えることができます。
このチェックボックスをオフにすると、文字列をそのままエンコードできない場合、テキストエンコードは失敗します。
このチェックボックスをオンにすると、テキストエンコーディングは、失敗する代わりに、おおよそのバージョンに変換を試みます。ターゲットエンコーディングで相当する文字がない場合、テキストエンコーディングは失敗します。
エンコーディング処理の一般的な説明については、エンコーディングの具体的なマッピングの定義設定を参照してください。
受信 MO をデータベースに格納
このオプションを有効にすると、着信 MO はデータベースの inSMS テーブルに格納されます。このテーブルは、任意のワークフローのクエリアクティビティを使用して照会できます。
Adobe Campaign Classic は、常にすべての MO を inSMS データベースに格納するので、このオプションは使用できません。
SR 処理中に KPI のリアルタイム更新を有効にする
このオプションを有効にすると、KPI はエラー SR を受け取ったときに、メイン配信ページでリアルタイムに更新されます。
欠点として、生成されるデータベースの競合が原因で、パフォーマンスが低下する場合があります。このオプションを無効にすると、統計は syncfromexec ワークフローによって更新され、20 分ごとに実行されます。
Adobe Campaign Classic の KPI には全く異なるメカニズムがあるので、このオプションは使用できません。
ソース番号
メッセージのデフォルトのソースアドレスを定義します。この設定は、ソース番号が配信内で空のままの場合にのみ適用されます。
デフォルトでは、ソース番号フィールドは渡されないので、プロバイダーはショートコードの代わりにソース番号フィールドを使用します。
これにより、送信者アドレス／oADC 上書き機能が有効になります。
ショートコード
アカウントのメインのショートコードを示します。このアカウントで複数のショートコードが使用されている場合、またはショートコードが不明な場合は、このフィールドを空欄にしてください。
ショートコードを指定すると、次の 2 つの機能において役立ちます。
-
ソース番号が指定されていない場合、プレビューにショートコードが表示されます。携帯電話での実際の動作を反映します。
-
自動応答機能のブロックリスト設定では、特定のショートコードに対してのみ、強制隔離に送信されます。
出力元 TON/NPI、出力先 TON/NPI
TON（数値のタイプ）と NPI（数値計画インジケータ）は、SMPP 3.4 仕様の 5.2.5 節（117 ページ）で説明されています。これらの値は、プロバイダーのニーズに合わせて設定する必要があります。
これらは、SUBMIT_SM PDU の source_addr_ton、source_addr_npi、dest_addr_ton、dest_addr_npi フィールドにそのまま送信されます。
サービスタイプ
このフィールドは、SUBMIT_SM PDU の service_type フィールドにそのまま送信されます。プロバイダーのニーズに合わせて設定します。
スループットとタイムアウト
これらの設定は、SMPP チャネルのすべてのタイミングを制御します。一部のプロバイダーでは、メッセージレート、ウィンドウ、再試行タイミングを非常に正確に制御する必要があります。これらの設定は、プロバイダーの処理能力と契約で示される条件に一致する値に設定する必要があります。
送信ウィンドウ
送信ウィンドウは、SUBMIT_SM_RESP との一致を待たずに送信できる SUBMIT_SM PDU の数です。
最大ウィンドウ数が 4 の送信例：
このウィンドウは、ネットワークリンクの待ち時間が長い場合のスループットを向上させるのに役立ちます。ウィンドウの値は、少なくとも SMS の数にリンクの待ち時間を秒単位で掛けた値である必要があり、そうすることで、次のメッセージを送信する前に、コネクタは SUBMIT_SM_RESP を待たない状態になります。ウィンドウが大きすぎる場合は、接続に問題が発生した場合に、より多くの重複メッセージを送信する可能性があります。また、ほとんどのプロバイダーは送信ウィンドウに対して非常に厳しい制限を適用しており、この制限を超えるメッセージを拒否します。
最適な送信ウィンドウ式の計算方法：
-
SUBMIT_SMとSUBMIT_SM_RESPの間の最大待ち時間を測定します。 -
この値に秒数を掛けて、MT の最大スループットを求めます。これにより、最適な送信ウィンドウの値が得られます。
例：最大 MT スループットに 300 個の SMS が設定されていて、SUBMIT_SM と SUBMIT_SM_RESP の間の平均待ち時間が 100 ミリ秒の場合、最適な値は 300×0.1 = 30 となります。
MT の最大スループット
1 秒あたりの最大 MT 数および 1 回の接続あたりの最大数。この設定は厳密に適用されるので、MTA はこの制限を超える速さでメッセージをプッシュすることはありません。この機能は、プロバイダーが精密なスロットルを必要とする場合に役立ちます。
総スループット制限を知るには、この数値に上の式で説明した接続の総数を掛けます。
0 は制限なしを意味し、MTA はできるだけ早く MT を送信します。
最終的なアーキテクチャで適切にベンチマークが付けられ、別段要求された SMPP プロバイダーがない限り、この制限を超えて正確なスループットを保証することは不可能なので、一般的に、この設定を 1000 未満に保つことが推奨されます。ただし、接続数を 1000 MT 以上に増やした方が良い場合もあります。
再接続までの時間
TCP 接続が失われた場合、コネクタは、この秒数の間待機してから接続を試みます。
MT の有効期間
SUBMIT_SM と SUBMIT_SM_RESP との間のタイムアウト。RESP を時間どおりに受信しない場合、メッセージは失敗と見なされ、MTA のグローバル再試行ポリシーが適用されます。
バインドのタイムアウト
TCP 接続試行と BIND_*_RESP 応答の間のタイムアウト。タイムアウトした場合、接続は Adobe Campaign コネクタによって閉じられ、再試行する前に、再接続までの時間待機します。
enquire_link 期間
enquire_link は、接続を有効に保つために送信される特別な種類の PDU です。この期間は秒単位です。キャンペーンコネクタは、帯域幅を節約するために接続がアイドル状態の場合にのみ enquire_link を送信します。この期間の 2 回後に RESP を受信しなかった場合、接続が切断されたと見なされ、再接続プロセスがトリガーされます。
SMSC 固有の設定
これらの設定は、Adobe Campaign コネクタを SMPP 実装の特殊性のほとんどに適応させるための詳細設定です。
エンコーディングの特定のマッピングの定義
テキストエンコーディングについて詳しくは、SMS テキストエンコーディングの節を参照してください。
この設定を使用すると、仕様とは異なるカスタムエンコーディングマッピングを定義できます。エンコーディングのリストと data_coding 値を宣言できます。
MTA は、リスト内の最初のエンコードを使用してエンコードを試みます。失敗した場合は、リスト上で次のエンコーディングを使用しようとします。メッセージのエンコードにエンコーディングを使用できない場合は、エラーが発生します。エンコーディングが見つかると、MTA はエンコードされたテキストと SUBMIT_SM PDU フィールドを作成し、テーブルで指定された値を使用して data_coding フィールドを設定します。
テーブル内の項目の順序は重要です。エンコーディングは上から下へ試行します。最も費用のかからないエンコーディング、または最も推奨されるエンコーディングをリストの上部に配置し、続けて高価なエンコーディングを配置する必要があります。
UCS-2 は、Adobe Campaign でサポートされるすべての文字をエンコードでき、UCS-2 SMS の最大長は非常に短い（70 文字のみ）ため、UCS-2 は失敗しません。
また、マッピングテーブルで 1 行だけ宣言することで、この設定を使用すると、特定のエンコーディングを常に使用するように強制できます。
チェックボックスがオフの場合に使用されるデフォルトのマッピングは、次の表と同じです。
つまり、MTA は GSM でメッセージのエンコードを試みます。成功した場合は、data_coding を 0 に設定して送信します。
メッセージを GSM でエンコードできない場合、UCS-2 でエンコードされ、data_coding が 8 に設定されます。
message_payload を有効にする
このオプションをオフにすると、長い SMS は MTA によって分割され、UDH と共に複数の SUBMIT_SM PDU に送信されます。メッセージは、UDH データに従って携帯電話によって再構成されます。
このオプションをオンにすると、長い SMS が 1 つの SUBMIT_SM PDU に送信され、message_payload オプションフィールドにテキストが入力されます。詳しくは、SMPP 仕様を参照してください。
この機能が有効になっている場合、Adobe Campaign は SMS パーツを個別にカウントできません。すべてのメッセージは、1 つのパーツで送信済みとしてカウントされます。
完全な電話番号を送信
このチェックボックスをオフにすると、電話番号の数字のみがプロバイダーに送信されます（SUBMIT_SM フィールドの destination_addr フィールド）。これは、国際番号インジケータ（通常は + プレフィックス）が SMPP の TON フィールドと NPI フィールドに置き換えられるので、デフォルトの動作です。
このチェックボックスをオンにすると、電話番号はそのまま送信され、前処理、潜在的なスペース、+ プレフィックスまたはシャープ／ハッシュ／スター記号は含まれません。
この機能は、自動返信ブロックリスト機能の動作にも影響します。チェックボックスがオフの場合、強制隔離テーブルに挿入される電話番号に + プレフィックスが追加され、SMPP プロトコル自体によって電話番号から + プレフィックスが削除されるのを補正します。
TLS 証明書チェックのスキップ
TLS が有効な場合は、すべての証明書の確認をスキップします。
このオプションをオンにすると、接続はセキュリティで保護されなくなるため、実稼働環境では有効化しないでください。
このオプションは、デバッグやテストの際に役立ちます。
証明書の検証には、次の 3 つの異なる値のいずれかを選択できます。
- 完全な証明書の確認（ホスト名を含む）、デフォルト。
- ホスト名の検証をスキップ。
- 証明書の検証をスキップ。
TON／NPI のバインド
SMPP 3.4 仕様の 5.2.5 節（117 ページ）で説明されている TON（番号のタイプ）と NPI（採番計画インジケータ）。これらの値は、プロバイダーのニーズに応じて設定する必要があります。
BIND PDU の addr_ton フィールドと addr_npi フィールドには、そのまま送信されます。
アドレス範囲
BIND PDU の address_range フィールドにそのまま送信されます。この値は、プロバイダーのニーズに応じて設定する必要があります。
無効な ID 確認数
1 つの SR に対して送信できる 無効なメッセージ ID DELIVER_SM_RESPの数を制限します。
これは、トラブルシューティングの目的で、ワークアラウンドとして使用し、通常の状態では 0 に設定する必要があります。
例えば、2 に設定する場合：
-
プロバイダーは、ID が「1234」の SR（
DELIVER_SM）を送信します。 -
ID「1234」はデータベースで見つかりませんでした。
-
コネクタは、その ID に対して 無効な ID エラーを 1 にカウントするので、「メッセージ ID が無効です」エラーコード（通常の動作）と共に
DELIVER_SM_RESPを送信します。 -
プロバイダーは、ID が「1234」の同じ SR を再試行します。
-
ID「1234」はやはりデータベースで見つかりませんでした。
-
コネクタは、その ID に対して 無効な ID エラーを 2 とカウントするので、正しく処理されなかった場合でも
DELIVER_SM_RESP「OK」を送信します。 -
この機能は、無効な SR ブロックが正当でない場合に、プロバイダー側の SR バッファをフラッシュするために使用されます。この場合、メッセージを処理できません。
このフィールドを 0 に設定すると、「メッセージ ID が無効です」が常に返されるメカニズムが無効になります。これは通常の動作です。
このフィールドを 1 に設定すると、ID が無効であってもコネクタは常に「OK」を返します。これは、プロバイダー側の問題からの回復など、トラブルシューティングをおこなう場合に最小限の時間で、監視下でのみ 1 に設定する必要があります。
SR に含まれている ID の抽出用正規表現
SR 形式は、SMPP プロトコル仕様に厳密には適用されません。これは、仕様書の付録 B（167 ページ）で説明されているレコメンデーションにすぎません。一部の SMPP 実装者は、このフィールドの形式を変更するので、Adobe Campaign は正しいフィールドを抽出する方法が必要です。
デフォルトでは、id: の後に最大 10 文字の英数字を取り込みます。
正規表現には、括弧内に一部を含むキャプチャグループが 1 つだけ必要です。ID 部分は括弧で囲む必要があります。正規表現の形式は PCRE です。
この設定を調整する場合は、誤ったトリガーを避けるために、できる限り多くのコンテキストを含めてください。標準に id: のような特定のプレフィックスがある場合は、正規表現に含めます。また、単語の途中でテキストが取り込まれないように、できる限り単語区切り文字（\b）を使用します。
正規表現に十分なコンテキストを含めないと、セキュリティ上の軽微な欠陥が生じる可能性があります。メッセージの実際の内容は、SR に含めることができます。UUID など、コンテキストのない特定の ID 形式のみが一致する場合、実際のテキストコンテンツ（ID の代わりにテキストフィールドに埋め込まれた UUID など）が解析される可能性があります。
成功／エラーステータスを判別するために適用された正規表現
不明な stat/err フィールドの組み合わせのメッセージが検出されると、これらの正規表現が stat フィールドに適用され、SR が成功したかエラーになったかが判別されます。これらのどの範囲とも一致しない stat 値を持つ SR は無視されます。
デフォルトでは、DELIV で始まる stat 値（例：付録 B 内の DELIVRD）は、正常に配信されたと見なされ、エラーに一致するすべての stat 値（例：REJECTED、UNDELIV）はエラーと見なされます。
MT 受信確認の ID 形式
これは、SUBMIT_SM_RESP PDU の message_id フィールドに返される ID の形式を示します。
-
変更しない：ID は、ASCII エンコードされたテキストとして、そのままデータベースに保存されます。前処理やフィルタリングはおこなわれません。
-
10 進数：ID は、ASCII 形式の 10 進数である必要があります。この設定を使用すると、先頭と末尾の空白文字と先頭の 0 が削除されます。
-
16 進数：ID は ASCII 形式の 16 進数です。先頭に 0x および末尾に h を付けません。その後、ID を 10 進数に変換してから、データベースに保存します。
-
16 進文字列：ID は、ASCII エンコードされたテキストで、16 進数でエンコードされたバイト数の文字列である必要があります。例えば、PDU には
0x34 0x31 0x34 0x32 0x34 0x33があり、これは ASCII「414243」に変換されます。次に、この文字列が 16 進数のバイト文字列としてデコードされ、「ABC」が返されます。ID「ABC」をデータベースに格納します。
SR の ID 形式
これは、SR 内の ID の Extraction 正規表現によって取り込まれる ID の形式を示します。値は同じ意味を持ち、上記の MT の形式と同じ動作をします。
オプションフィールドの SR ID またはエラーコード
NOTEこのオプションを選択すると、上記の正規表現で処理されるテキストにオプションフィールドのコンテンツが追加されます。テキストは 0xTAG:VALUE の形式です。0xTAG は大文字のタグの 4 桁の 16 進値です（0x002E など）。
例えば、receipted_message_id フィールドに 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 またはエラーコード
このオプションを選択すると、テキスト フィールドは、SR のステータステキストの処理中に保持されます。
これは、プロバイダーが ID やステータスなど、重要なデータをこのフィールドに配置する場合に役立ちます。通常、このフィールドは ASCII 以外のエンコードのテキストが含まれて正規表現の処理に支障が生じる場合があるので、安全に破棄できます。
SR フィールド内の ID の Extraction 正規表現が十分に具体的でない場合、このオプションを有効にすると、セキュリティ上の軽微な欠陥が生じる可能性があります。テキスト フィールドの内容は ID として解析され、攻撃者が偽造 ID の挿入に使用する場合があります。これにより、部分的なサービス拒否状況が発生する可能性があります。
サービス ID タグ
カスタム TLV を追加できます。このフィールドは、タグの部分を設定します。この値は、配信の詳細パラメーターにある サービスまたはプログラム ID の値の配信ごとにカスタマイズできます。
この設定では、メッセージごとに 1 つの TLV オプションのみを追加できます。
MO に送信された自動返信
IMPORTANTこの機能を使用すると、MO にすばやくテキストを返信し、ショートコードごとのブロックリスト送信処理を実行できます。
キーワード 列と ショートコード 列は、自動応答をトリガーする条件を定義します。両方のフィールドが一致する場合、MO が送信され、追加のアクションがトリガーされます。ワイルドカードを指定するには、フィールドを空のままにする必要があります。キーワードは、MO テキストの最初の英数字の単語に対して一致します。句読点や先頭のスペースは無視します。つまり、キーワード フィールドにスペースを含めることはできません。また、1 つの単語である必要があります。
キーワード 設定はプレフィックスです。例えば、「AD」を指定した場合、「AD」、「ADAPT」および「ADOBE」と一致します。共通のプレフィックスを持つ複数のキーワードがある場合は、キーワードは上から下に順に処理されるので、順序に注意する必要があります。
返信 列は返信するテキストです。このフィールドでは個人設定を使用できません。このフィールドを空のままにすると、メッセージは返信されませんが、追加のアクションはトリガーされます。
追加のアクション 列は、キーワード と ショートコード の両方が一致した場合に、追加のアクションを提供します。空のショートコードはすべてのショートコードと一致します。強制隔離に送信したり、強制隔離から削除できます。値なしはテキストに返信します。追加のアクション を指定し、返信 フィールドを空のままにした場合、アクションは実行されますが、返信は送信されません。強制隔離は、指定したショートコードに対してのみ適用されます。フィールドが空の場合は、すべてのショートコードに適用されます。
IMPORTANTテーブル内のすべてのエントリは、1 つのルールが一致するまで、指定された順序で処理されます。複数のルールが 1 つの MO に一致する場合、最上位のルールのみが適用されます。
SMS 配信テンプレートパラメーター
一部のパラメーターは、配信テンプレートごとに設定できます。
送信者フィールド
このフィールドはオプションです。送信者アドレス（oADC）を上書きできます。このフィールドの内容は、SUBMIT_SM PDU の source_addr フィールドに配置されます。
SMPP 仕様では、このフィールドの文字数が 21 文字に制限されていますが、プロバイダーによっては、これより長い値を使用できる場合があります。また、長さ、コンテンツ、許容文字など、一部の国では非常に厳密な制限が適用される場合があります。
配信パラメーター
メッセージあたりの SMS の最大数
この設定は、メッセージペイロード 設定が無効な場合にのみ機能します。メッセージにこの値より多くの SMS が必要な場合は、エラーがトリガーされます。
SMS プロトコルでは SMS は 255 のパーツに制限されていますが、携帯電話では 10 のパーツを超える長いメッセージを組み合わせるのに問題が生じる場合があります。この制限はモデルによって異なります。1 通のメッセージにつきパーツは 5 を超えないことをお勧めします。
Adobe Campaign でのパーソナライズされたメッセージの動作によって、メッセージのサイズが異なる場合があります。長いメッセージが大量に存在すると、送信コストが増加する可能性があります。
送信モード
このフィールドは、送信する SMS の種類を次のように示します。通常または Flash メッセージ、携帯電話または SIM カードに保存。
この設定は、SUBMIT_SM PDU の dest_addr_subunit オプションフィールドに送信されます。
-
「指定なし」の場合、PDU にオプションのフィールドは送信されません。
-
「Flash」の場合、値を 1 に設定します。携帯電話上でポップアップ表示され、メモリには保存されない Flash メッセージを送信します。
-
「通常」の場合、値を 0 に設定します。通常のメッセージを送信します。
-
「携帯電話に保存」の場合、値を 2 に設定します。SMS を内部メモリに保存するよう電話に指示します。
-
「ターミナルに保存」の場合、値を 3 に設定します。SIM カードに SMS を格納するよう電話に指示します。
有効期間
有効期間は、SUBMIT_SM PDU の validity_period フィールドに送信されます。日付は常に絶対 UTC 時刻形式で設定され、日付フィールドは「00+」で終わります。
拡張された汎用 SMPP コネクタ
矢印は、データフローを表します。
MTA は、配信パーツを送信する際に、MTA の子を生成します。MTA 子プロセスの数は動的で、serverConf.xml の設定によって異なります。各 MTA 子は、SMPP プロバイダーに接続するコネクタ CSmppConnectorWorker をインスタンス化します。MTA 子が存続している限り接続は維持され、serverConf.xml でも設定できます。
SMS プロセスは SR のみを処理し、プロバイダーに接続し、接続を開いたままにします。このプロセスは、10 分ごとに再接続し、新しい設定を再読み込みします。これは通常の操作です。
MT、SR、broadLog エントリの照合
中間テーブル nmsProviderMsgId は、broadLog と非同期にコミットされる前に、MT および SR データを一時的に格納するために使用されます。
nmsProviderMsgId テーブルには 3 つの列のグループがあります。
-
MT が送信され、確認応答がおこなわれた場合に更新される列：
iBroadLogId、iDeliveryId -
SR を受け取った場合に更新される列：
iMsgId、iStatus -
常に更新される列：
tsCreated、sProviderId
MT と SR の両方の処理が完了したら、broadLog 情報とステータス情報の両方を含む完全な行が必要です。
ここで iMsgId は nmsBroadLogMsg テーブルにリンクされ、完全なステータス／エラーメッセージを示します。
SMS プロセスは、完了行を毎分チェックし、非同期に処理します。
- 行全体が読み取られます。
- SMS プロセスは、配信マッピングに基づいて broadLog テーブルの名前を計算します。
- SMS プロセスは、broadLog テーブルをメッセージ ID とステータスで更新します。
スループットと並列接続
各 MTA の子は設定可能な数の接続を作成するので、MTA の子の数を制限すると接続数が制限されます。MTA 子プロセスとトラフィックに相関関係があるので、これはある程度制御できますが、それでも予測できないことがあります。
本番運用開始前
このチェックリストは、公開前に確認する必要がある事項をリストアップしています。設定が不完全な場合、多くの問題が発生する可能性があります。
外部アカウントの競合の確認
古い SMS 外部アカウントがないことを確認します。テストアカウントを無効のままにしておくと、実稼働システムで再有効化し、競合が発生する可能性があります。
1 つの Adobe Campaign インスタンス上に同じプロバイダーに接続する複数のアカウントがある場合は、プロバイダーに問い合わせて、これらのアカウント間の接続が実際に区別されることを確認してください。複数のアカウントに同じログインを割り当てる場合は、追加の設定が必要です。
チェック時の詳細 SMPP トレースの有効化
チェック中は必ず詳細 SMPP トレースを有効にしてください。
ログを自分で確認できない場合は、アドビカスタマーケアにサポートを依頼してください。
SMS のテスト
-
SMS に様々な文字を送信する
GSM 以外の文字や ASCII 以外の文字で SMS を送信する必要がある場合は、できるだけ多様な文字でメッセージを送信してみてください。カスタム文字マッピングテーブルを設定する場合は、考えられるすべてのdata_coding値に対して 1 つ以上の SMS を送信します。 -
SR が正しく処理されていることを確認する：
SMS が配信ログに受信済みとマークされます。配信ログは正常に作成され、次のようになります。SR yourProvider stat=DELIVRD err=000|#MESSAGE
配信プロバイダー名を変更したことを確認してください。実稼働環境では、配信ログに SR Generic を含めないでください。 -
MO が処理されていることを確認する
MO を処理する必要がある場合（自動応答、MO のデータベースへの格納など）、いくつかテストを試してみてください。すべての自動返信キーワードに対して SMS を送信し、返信速度が適切である（数秒以内）ことを確認します。
Adobe Campaign がDELIVER_SM_RESP（command_status=0）に正常に応答したことをログで確認します。
PDU の確認
メッセージが正常に表示された場合でも、PDU が正しくフォーマットされているかどうかを確認することが重要です。
この手順は、以前に Adobe Campaign に接続されていないプロバイダーに接続する場合に必要です。
BIND
BIND_* PDUs が正しく送信されていることを確認します。最も重要な点は、プロバイダーが常に成功した BIND_*_RESP PDUs を返すことです（command_status = 0）。
BIND_* PDU の数が多すぎないか確認します。数が多すぎる場合は、接続が不安定であることを示している可能性があります。詳しくは、不安定な接続の問題の節を参照してください。
ENQUIRE_LINK
接続がアイドル状態のときに ENQUIRE_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が正しくエンコードされていることを確認します。複数のエンコーディングをサポートする 16 進数コンバーターを使用してデコードしてみてください。
SUBMIT_SM_RESP PDU を使用：
- 成功したことを確認します（command_status = 0）。
- 本文で、適切にフォーマットされた ID の後に「0」バイトが続くことを確認します。
DELIVER_SM PDU を使用：
- 16 進数
short_messageフィールドをデコードします。 - SR 内の ID の
Extraction正規表現に定義された正規表現が 1 つの取得グループを返し、メッセージ内の ID 全体を取り込むことを正規表現チェックツールで確認します。 - 抽出した ID が
SUBMIT_SM_RESPの ID と一致することを確認します。 - SR 内のステータスの
Extraction正規表現に定義されている正規表現が、stat フィールドの内容を返すことを確認します。 - SR 内のエラーの
Extraction正規表現に定義されている正規表現が err フィールドの内容を返すことを確認します。
DELIVER_SM_RESP PDU を使用：
DELIVER_SM PDUを受信した後、通常 1 秒未満で迅速に送信されたことを確認します。- 成功したことを確認します（command_status = 0）。
プロバイダーへの問い合わせ
SMS が正常に終了した場合でも、プロバイダーに問い合わせて、すべて問題ないかどうかを確認してください。
詳細 SMPP トレースの無効化
すべてのチェックが完了したら、最後に 詳細な SMPP トレースを無効 にして、多くのログを生成しないようにします。実稼働システムでも、トラブルシューティング用にこれらを再度有効化できます。