SMS トラブルシューティング

異なる外部アカウント間の競合

インスタンスに複数の SMS 外部アカウントがある場合は、外部アカウント間の競合が原因で問題が発生していないことを確認する必要があります。

Adobe Campaign は、外部アカウントを無関係なエンティティとして扱います。

複数のアカウントがある場合は、次の手順に従って問題を引き起こす外部アカウントを分離します。

  1. すべての外部アカウントを無効にします。
  2. 1 つの外部アカウントを有効にします。
  3. 問題を再現してみてください。
  4. 最初の問題が必ずしも発生しない場合は、結論を出す前に適切な回数の試行をおこないます。
  5. そのアカウントで問題が発生しない場合は、そのアカウントを無効にし、次のアカウントで手順 2 に戻ります。

各アカウントを個別にチェックすると、次の 2 つのシナリオが考えられます。

  • その問題は 1 つまたは複数のアカウントで発生した

    この場合、各アカウントに別々にその他のトラブルシューティング手順を適用できます。ネットワークトラフィックとログ数を減らすために、アカウントの診断時に他のアカウントを無効にすることをお勧めします。

  • 1 つのアカウントのみアクティブの場合は、問題は発生しなかった

    アカウント間で競合が発生しています。前述したように、Adobe Campaign はアカウントを個別に扱いますが、プロバイダーはアカウントを単一のアカウントとして扱うことができます。

    • すべてのアカウント間で異なるログイン/パスワードの組み合わせを使用しています。プロバイダーに連絡して、プロバイダー側の競合の可能性を診断する必要があります。

    • 一部の外部アカウントは、同じログイン/パスワードの組み合わせを共有します。プロバイダーは、BIND PDU がどの外部アカウントから来たのかを知る手段がないので、複数のアカウントからの接続をすべて単一のものとして扱います。2 つのアカウントに対してランダムに MO と SR をルーティングし、問題を引き起こしている可能性があります。プロバイダーが同じログイン/パスワードの組み合わせで複数のショートコードをサポートしている場合は、BIND PDU のどこにショートコードを置くのかについて問い合わせる必要があります。MO を正しくルーティングできるのは BIND PDU だけなので、この情報は BIND PDU の中に入れる必要があり、SUBMIT_SM の中に入れる必要はありません。BIND PDU で使用できるフィールドは、前述の各種 PDU の情報の節を参照してください。通常は address_range にショートコードを追加しますが、プロバイダーの特別なサポートが必要です。複数のショートコードを個別にルーティングする方法については、担当者にお問い合わせください。Adobe Campaign は、同じ外部アカウントでの複数のショートコードの処理をサポートしています。

一般的な外部アカウントの問題

  • コネクタが最近変更されたかどうか、およびどのユーザーによって変更されたかを調べます(外部アカウントをグループとして確認します)。

    select saccount, (sserver ||':'||sport) as serverPort, iextaccountid, CASE WHEN N0.iactive=1 THEN 'Yes' ELSE 'No' END as "(x) Enabled",
    
    (select X1.sname from xtkoperator X1 where N0.icreatedbyid = X1.ioperatorid) as "Created By",
    
    (select X1.sname from xtkoperator X1 where N0.imodifiedbyid = X1.ioperatorid) as "Last Modified By",
    
    N0.slabel as "External Account", N0.tslastmodified as "LastModifiedDate"
    
    from nmsextaccount N0 LEFT JOIN xtkoperator X0 ON (N0.icreatedbyid=X0.ioperatorid) order by 8 DESC LIMIT 50;
    
  • システムがアップグレードされたかどうか、およびシステムがアップグレードされたタイミングを調べます(/postupgrade ディレクトリ内)。

  • SMS に影響を与えるパッケージが最近アップグレードされた可能性があるかどうかを調べます(/var/log/dpkg.log)。

ミッドソーシングに関する問題(ホスト)

  • ミッドソーシング環境で問題が発生した場合は、配信とブロードログが適切に作成され、ミッドソーシングサーバーで更新されていることを確認してください。そうでない場合は、SMS の問題ではありません。

  • ミッドサーバー上で動作し、SMS が正しく送信され、マーケティングインスタンスが正しく更新されない場合は、中間同期の問題が発生している可能性があります。

プロバイダーに接続する際の問題

  • BIND PDU がゼロ以外の command_status コードを返す場合は、プロバイダーに詳細を問い合わせてください。

  • プロバイダーへの TCP 接続を確立できるように、ネットワークが正しく設定されていることを確認してください。

  • プロバイダーに、Adobe Campaign インスタンスの許可リストに IP が正しく追加されたかどうかを確認するように依頼します。

  • 外部アカウント​の設定を確認します。フィールドの値をプロバイダーに問い合わせます。

  • 接続が成功したものの不安定な場合は、不安定な接続の問題の節を確認してください。

  • 接続の問題を診断するのが困難な場合、ネットワークキャプチャによって情報を取得できる場合があります。問題が発生するときにネットワークのキャプチャを同時に実行すると、効率的に分析できます。また、問題が発生した正確な時刻もメモしておく必要があります。

不安定な接続に関する問題

次のいずれかが発生した場合、接続が不安定であると見なされます。

  • 接続状態が 1 時間未満の場合。Adobe Campaign Classic トランスミッター接続は、Adobe Campaign Classic MTA の動作方法が原因で例外です。

  • プロバイダーが UNBIND PDU を送信する場合。

  • enquire_link が、Adobe Campaign 側またはプロバイダー側でタイムアウトする場合。この場合、ENQUIRE_LINK_RESP にはゼロ以外のエラーコードが表示されます。

  • BIND PDU が多数ある場合。接続数によっては、1 日の間に数回を超えるべきではありません。1 時間に 1 つ以上の BIND PDU は、警告を発する必要があります。

接続の安定性の問題を解決する方法:

  • 不安定な接続が根本的な原因であることはほとんどありません。多くの場合、別の問題により接続解除がトリガーされた結果です。根本原因の特定を優先する必要があります。

  • 詳細 SMPP トレースを有効にします。接続が再開されたときに何が起きているのかを確認するために必要になります。

  • プロバイダーが BIND PDU を送信した場合は、問題が発生している可能性があります。UNBING が送信された理由をプロバイダーに問い合わせてください。

  • ネットワークのキャプチャをおこなうことが、接続が閉じられた状態を確認する唯一の方法である場合があります。

  • プロバイダーが TCP FIN または TCP RST packet を送信して接続を閉じた場合は、プロバイダーに詳細を問い合わせてください。

  • エラーコードを使用して DELIVER_SM_RESP などのクリーンエラーを送信した後にプロバイダーが接続を閉じた場合は、コネクタを修正する必要があります。そうしないと、他の種類のメッセージが送信されず、MTA スロットルがトリガーされます。これは、接続を閉じると MT と SR の両方に影響を与えるトランシーバモードで特に重要です。

MT の送信時の問題(エンドユーザーに送信される通常の SMS)

  • 接続が安定していることを確認します。SMPP 接続は、Adobe Campaign Classic 上のトランスミッタ―を除き、少なくとも 1 時間は接続状態が維持される必要があります。不安定な接続に関する問題の節を参照してください。

  • MTA を再起動することで、しばらくの間送信 MT が再び作動する場合、接続が不安定なためにスロットルが発生する可能性があります。不安定な接続に関する問題の節を参照してください。

  • 広範ログが存在し、ステータスと日付が正しいことを確認します。そうでない場合は、配信または配信の準備に関する問題である可能性があります。

  • MTA が実際にメッセージを処理していることを確認します。そうでない場合は、SMS の問題ではない可能性があります。

  • SMS コネクタがプロバイダーの機器に実際にバインドされていることを確認します。すべてのシステムが正しく通信されていることを確認するために、プロバイダーにフィードバックを求めます。バインド処理について詳しくは、BIND_TRANSMITTER および BIND_TRANSCEIVER PDU を参照してください。適切なトラブルシューティングをおこなうために、SMPP トレースを有効にする必要がある場合があります。

  • SMPP トレースを有効にして、SUBMIT_SM PDU に正しい情報が含まれていることを確認します。

  • プロバイダーが「OK」値(コード 0)で SUBMIT_SM_RESP PDU に応答していることを確認します。PDU が適切な遅延で到着することを確認します。1 秒を超える場合はプロバイダーに問い合わせる必要があります。通常は、100 ミリ秒未満で到達します。

  • これらの手順がすべて正常に動作する場合は、問題がプロバイダー側にある可能性が高いです。プロバイダー側のプラットフォームのトラブルシューティングをおこなう必要があります。

  • 動作してもスループットが異なる場合は、送信ウィンドウを調整し、MT スループットを下げてみてください。MT スループットを調整するには、プロバイダーに依頼する必要があります。Adobe Campaign は非常に速くメッセージを送信できるので、プロバイダーの機器でパフォーマンスの問題が発生する可能性があります。

MT の重複(同じ SMS が複数回連続で送信される)

重複は多くの場合、再試行が原因で発生します。メッセージを再試行する際に重複が発生するのは普通です。代わりに再試行の根本原因を取り除くようにしてください。

  • 重複が正確に 60 秒間隔で送信されている場合は、おそらくプロバイダー側の問題で、SUBMIT_SM_RESP を十分な速度で送信していません。

  • BIND/UNBIND が多い場合は、接続が不安定です。重複メッセージの問題を解決しようとする前に、不安定な接続の問題の節を参照してください。

再試行時のメッセージの重複回数を軽減するには:

  • 送信ウィンドウサイズを減らします。送信側のウィンドウは、SUBMIT_SM_RESP 待ち時間に対応できるサイズにする必要があります。この値は、ウィンドウサイズが上限に達した状態でエラーが発生した場合に複製できるメッセージの最大数を表します。

SR(配信受信)を処理する際の問題

  • SR のトラブルシューティングをおこなうには、SMPP トレースを有効にする必要があります。

  • DELIVER_SM PDU がプロバイダーから送信されたものであり、正しい形式であることを確認します。

  • Adobe Campaign が DELIVER_SM_RESP PDU に正常に応答したことを適切なタイミングで確認します。Adobe Campaign Classic では、SR が providerMsgId テーブルに挿入され、SMS プロセスによる遅延処理がおこなわれていることが保証されます。

DELIVER_SM PDU が正しく認識されない場合は、次の点を確認する必要があります。

  • 外部アカウント​の ID 抽出とエラー処理に関連する正規表現を確認します。場合によっては、DELIVER_SM PDU の内容に対してこれらを検証する必要があります。

  • broadLogMsg テーブルで、エラーが適切にプロビジョニングされていることを確認します。

DELIVER_SM PDU が Adobe Campaign Classic 拡張 SMPP コネクタで認識されたが、broadLog が正しく更新されない場合は、MT、SR および broadLog エントリの一致の節で説明されている ID 調整プロセスを確認します。

すべての問題を修正したものの、無効な SR がプロバイダーのバッファに残っている場合は、「無効な ID 確認数」オプションを使用してスキップできます。このオプションは慎重に使用する必要があり、バッファがクリーンになった後、できるだけ早く 0 にリセットする必要があります。

MO(およびブロックリスト/自動応答)を処理する際の問題

  • テスト中に SMPP トレースを有効にします。TLS を有効にしない場合は、MO のトラブルシューティング時にネットワークキャプチャを実行し、PDU に正しい情報が含まれ、正しくフォーマットされていることを確認する必要があります。

  • ネットワークトラフィックをキャプチャしたり、SMPP トレースを分析する場合、応答が設定されている場合は、MO とその応答 MT との会話全体をキャプチャするようにしてください。

  • MO(DELIVER_SM PDU)がトレースに表示されない場合は、プロバイダー側に問題があります。プロバイダーのプラットフォームでトラブルシューティングをおこなう必要があります。

  • DELIVER_SM PDU が表示された場合は、Adobe Campaign が DELIVER_SM_RESP PDU に成功したことを確認してください(コード 0)。この RESP は、すべての処理ロジックが Adobe Campaign によって適用されていることを保証します(自動応答および許可/ブロックリスト)。そうでない場合は、SMS プロセスログでエラーメッセージを検索します。

  • 自動返信が有効な場合は、SUBMIT_SM がプロバイダーに送信されたことを確認します。送信されない場合は、必ず SMS プロセスログにエラーメッセージが表示されます。

  • 応答を含む SUBMIT_SM MT PDU がトレースに見つかったものの、SMS が携帯電話に届かない場合は、プロバイダーに問い合わせてトラブルシューティングのサポートを依頼する必要があります。

配信の準備中に、強制隔離された受信者(自動応答機能によって強制隔離済み)を除外しない問題

  • 電話番号の形式が、強制隔離テーブルと配信ログで完全に同じであることを確認します。それ以外の場合で、国際電話番号形式のプラスプレフィックスに問題がある場合は、このを参照してください。

  • ショートコードを確認します。受信者のショートコードが外部アカウントで定義されているものと同じ場合、または空の場合(空の場合は任意のショートコード)に、除外が発生する可能性があります。Adobe Campaign インスタンス全体にショートコードを 1 つだけ使用する場合、すべての​ショートコード​フィールドを空にすると、処理が容易になります。

エンコードの問題

手順 1:プロバイダーに問い合わせる

プロバイダーに問い合わせて、問題を調査します。問題が Adobe Campaign 側とプロバイダー側のどちらで発生しているのかを把握します。問題が Adobe Campaign にある場合は、不適切なフィールドを特定するようプロバイダーに依頼します。

手順 2:メッセージの内容を理解する

Unicode では、類似した文字に対して多くのバリエーションを使用できますが、Adobe Campaign ではすべてを処理できません。

最も一般的な問題の原因は、ワードプロセッサーからのコピー&ペーストです。ペーストすることで、通常の文字がタイポグラフィー的に正しいバージョンに変更されます。例えば、スペースはノーブレークスペースに、二重引用符は開始引用符と終了引用符に、マイナス記号は様々なハイフンにそれぞれ変更されます。

テスト時はメッセージをコピー&ペーストせずに、必ずインターフェイスに直接入力してください。

16 進数を使用すると、類似する文字の違いを識別できます。小文字の L、大文字の I、O、0、あらゆる種類の引用符、非ラテンエンコーディング、様々なスペースは、すべて同じように見えたり、まったく表示されない場合があります。

Unicode を 16 進数に変換するには、Unicode コードコンバーターの Web サイトなどのオンラインツールを使用できます。テキストを入力し、電話番号などの PII がないことを確認して、「変換する」をクリックします。下部に 16 進値(UTF-32 ゾーン)が表示されます。

エンコードの問題に関するチケットを開く際、プロバイダーとアドビカスタマーケアのどちらを使用する場合でも、入力内容と表示内容を 16 進数形式で必ず含めます。

手順 3:送信の内容を理解する

使用するエンコーディングを決定し、その文字テーブルをオンラインで検索します。送信する文字がターゲットコードページで実際に使用できることを確認します。data_coding フィールドが正しく、ユーザーとプロバイダーの予想と一致していることを確認します。

手順 4:実際に送信した内容を理解する

プロバイダーに送信するバイトを正確に確認するには、コネクタのデバッグ出力が必要です。エンコードの問題は SUBMIT_SM PDU で発生するので、必ず取得してください。ログ内で見つけやすい明確なメッセージを送信します。

テスト時に異なる種類の特殊文字を送信します。例えば、GSM7 エンコーディングには、他のエンコーディングでは使用されない 16 進形式の特徴的な拡張文字が含まれるので、容易に見分けることができます。

SMS の問題を報告する際に含めるべき要素

SMS の問題について、Adobe Campaign、SMS プロバイダー、またはその他の手段でこの問題に関するサポートチケットを作成する場合は、次の情報を提供することで、問題が適切に認定されるようにする必要があります。適切に認定されることが、問題をより早く解決するための鍵となります。

  • 問題が発生した場合に、詳細 SMPP メッセージを有効​にします。ほとんどの SMS 問題は、これなしでは解決できません。

  • 問題が SMS トラフィックに関連している場合は、まずプロバイダーに問い合わせてください。プロバイダーのプラットフォームは、SMS トラフィックの問題をリアルタイムで効率的に診断するのに最適です。

  • 問題についての簡潔で事実に即した説明を含めます。

  • 期待される結果の説明を含めます。

  • プロバイダーからのフィードバックを含めます。

  • 関連するログやネットワークキャプチャを含めます。キャプチャを取得する場合は、キャプチャ中に問題を再現してください。

  • ログ、トレース、またはキャプチャを含める場合、問題が発生したときのファイル内の正確な場所を特定します。

  • メッセージ、PDU、ログを参照する場合は、見つけやすいようにタイムスタンプを明確に記述してください。

  • テスト環境で問題を再現してみてください。設定が不明な場合は、テスト環境で試して、SMPP トレースの結果を確認してください。通常、実稼働環境の問題を直接報告するよりも、テスト環境で問題を再現して報告する方が効果的です。

  • プラットフォームでおこなった変更や微調整を含めます。また、プロバイダー側でおこなった可能性のある変更も含めます。

ネットワークキャプチャ

ネットワークキャプチャは必ずしも必要ではありません。通常は、詳細な SMPP メッセージで十分です。次に、ネットワークキャプチャが必要かどうかを判断する際に役立つガイドラインを示します。

  • 接続に問題がありますが、詳細メッセージには BIND_RESP PDU が表示されません。

  • エラーメッセージのない不明な接続の切断。低レベルのプロトコルエラーを検出した場合のコネクタの通常の動作です。

  • プロバイダーは、バインド解除/切断プロセスに関してエラーを出しています。

  • オプションの TLV フィールドでのエンコードの問題。

  • トラフィックが異なる接続間で混在している疑いがあります。

その他の状況では、詳細な SMPP メッセージを最初に分析し、詳細ログに情報がない場合にのみネットワークキャプチャを要求してください。

場合によっては、ネットワークトラフィックをキャプチャする必要はありません。最も一般的な状況を次に示します。

  • TLS が有効:定義上、TLS トラフィックは暗号化されるため、キャプチャできません。

  • パフォーマンスの問題:ログにパフォーマンスの問題を追跡するために必要なすべての情報が含まれます。

  • タイミングの問題(retry timingenquire_link 期間、スループットの上限など)

  • SR 解析と処理:詳細ログは、より多くのコンテキストを提供し、より適切な表示を提供します。

  • MO 処理(自動応答、強制隔離)

  • 実際の SMPP トラフィックが関係しないエラー:配信の準備、Message Center API の問題、ワークフローの問題など

SMPP トレースを有効にする

新しいコネクタは、次のトレースを介した拡張ログをサポートします:SMPPトレースは、標準出力ではなく、MTA ログに出力されます。

外部アカウントごとの有効化(推奨される方法)

  1. 外部アカウント​で、「ログファイルの詳細 SMPP トレースを有効にする」をオンにします。
  2. 10 分待って、サーバーが外部アカウントを再読み込みするまで待ちます。

これで、SMPP トレースが有効化されたはずです。

設定での有効化

config-instance.xml ファイルで、次のパラメーターを設定します。

<mta>
  <child extraArgs="-tracefilter:SMPP"/>
</mta>
<sms args="-tracefilter:SMPP"/>

コンテナ上のオープン接続数の確認

コンテナ上で開いている接続の数を確認するには、次のコマンドを使用します。

(for pid in $(ss -neopts  | sed -n ‘s/^.*:3600[ \t].*users:(([0-9A-Za-z”]*,pid=\([0-9]*\),.*$/\1/p’ | sort ); do  cat /proc/$pid/cmdline; echo  ” $pid” ;done;) | uniq --count

これは、特定のポートに対して開かれた接続数をリストします。ここでは、ポート 3600 を使用しています。

結果は次のようになります。

4 nlserversms -noconsole -tracefile:sms@INSTANCE_NAME -instance:INSTANCE_NAME -detach 15180
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 1838
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 24025
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 24029
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 29088
2 nlservermtachild -tracefile:mtachild@INSTANCE_NAME -instance:INSTANCE_NAME -detach 30390

SMS プロセス用に開かれた 4 つの接続と、5 つの子を持つ MTA の子につき 2 つの接続があります。

このページ

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free