限定提供（LA）
SMPP 接続の検証
- 適用対象：
- Campaign v8 Client Console
作成対象：
- 中級
- ユーザー
SMPP 接続が正常であることを確認するためのいくつかの確認事項を次に示します。
運用開始前の確認事項
運用開始前に、以下のチェックリストで SMPP 設定が正常であることを確認します。
IMPORTANT
NOTE外部アカウントの競合の確認
残っている SMS 外部アカウントがないことを確認します。潜在的な競合を排除するために、テストアカウントを削除します。
他のインスタンスが外部アカウントに接続していないことを確認します。特に、実稼動前の環境が実稼動外部アカウントに接続していないことを確認します。
同じプロバイダーに接続する、同じ Campaign インスタンス上に複数のアカウントが必要な場合は、プロバイダーに問い合わせて、これらのアカウント間の接続が実際に区別されることを確認してください。複数のアカウントに同じログインを割り当てる場合は、追加の設定が必要です。
有効になっているすべての SMS 外部アカウントで専用のプロセス設定が有効になっていることを確認します。同じインスタンス上で 2 種類のアカウント（専用プロセスありとなし）を混在させることはできません。
実際のテストの実行
異なる携帯電話でいくつかの SMS の送信を試してください。
SMS に様々な文字を送信する
GSM 以外の文字や ASCII 以外の文字で SMS を送信する必要がある場合は、できるだけ多様な文字でメッセージを送信してみてください。カスタム文字マッピングテーブルを設定する場合は、考えられるすべての data_coding 値に対して 1 つ以上の SMS を送信します。
SR が正しく処理されていることを確認する
SMS が配信ログに受信済みとマークされます。配信ログは正常に作成され、「SR yourProvider stat=DELIVRD err=000|#MESSAGE#」のようになります。
「SMSC 実装名」フィールドを正しく設定していることを確認します。実稼動環境では、配信ログに SR Generic を含めないでください。
MO が処理されていることを確認する
すべての自動返信キーワードに対して SMS を数回送信し、返信速度が迅速である（数秒以内）ことを確認します。
MO が nms:inSms データベースに挿入されていることを確認します。カスタム TLV がある場合は、これらも正しく挿入され、適切にフォーマットされていることを確認します。
Campaign が DELIVER_SM_RESP（command_status=0） に正常に応答したことをログで確認します。
負荷テストを実行する
これは、大量のメッセージを送信する場合や、リアルタイムメッセージングを使用する場合に特に重要です。
接続を 100％で負荷するテストを 5 秒以上実行します。プロバイダーがテストのために架空のアカウントに接続する方法がない場合は、実際のメッセージを送信する必要があります。これを実現する方法の 1 つは、詳細 SMPP メッセージを有効にして、最初の十分な量の配信を注意深く監視することです。
送信するメッセージの最小数は、次のように計算できます。
MT の最大スループット * トランスミッター/トランシーバ接続の合計数 * 5
配信が完了したら、次の点を確認します。
- すべてのメッセージが送信されたことを確認します（必ずしも受信されるとは限りません）
- プロバイダーが通常の操作として明示的に指定しない限り、command_status が 0x00000000 ではない PDU は絶対にゼロにする必要があります
- 配信プロセス全体を通じて、接続は絶対に安定した状態（BIND PDU なし）を維持する必要があります。
- すべてのメッセージに SR があり、正しく処理されていることを確認します（SR が正しく処理されていることを確認するを参照）。わずかな割合でエラーが発生する場合は、これらが Campaign 側での送信中または処理中のエラーではなく、実際に SR が返したエラーであることを確認します。
- パフォーマンスが不明な場合は、特に PDU とそれに対応する RESP 間の待ち時間が適切であることを確認します。待ち時間が 500 ミリ秒を超えると、高スループットに問題が発生する可能性があります。その待ち時間を使用して、送信ウィンドウの式を確認します（詳しくは、送信ウィンドウの設定を参照）
PDU の確認
PDU が正しくフォーマットされていることを確認します。
IMPORTANTBIND
BIND_* PDU が正しく送信されていることを確認します。最も重要な点は、プロバイダーが常に成功した BIND_*_RESP PDU を返すことです（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 進数コンバーターを使用してデコードしてみてください（オンラインで使用できるものがあります）。
- 長いメッセージに message_payload を使用する場合は、コンテンツが short_message フィールドではなく、オプションフィールドに存在することを確認します。
SUBMIT_SM_RESP PDU の場合：
- 成功したことを確認します（command_status = 0）。
- 本文で、適切にフォーマットされた ID の後に「0」バイトが続くことを確認します。
DELIVER_SM PDU の場合：
- 16 進数 short_message フィールドをデコードします（そのためのオンラインツールがあります）。
- SR 内の ID の抽出用正規表現に定義された正規表現が 1 つの取得グループを返し、メッセージ内の ID 全体を取り込むことを正規表現チェックツールで確認します。
- 抽出した ID が SUBMIT_SM_RESP の ID と一致することを確認します。
- SR 内のステータスの抽出用正規表現に定義されている正規表現が、stat フィールドの内容を返すことを確認します。
- SR 内のエラーの抽出用正規表現に定義されている正規表現が err フィールドの内容を返すことを確認します。
DELIVER_SM_RESP PDU の場合：
- DELIVER_SM PDU を受信した後、1 秒未満で迅速に送信されたことを確認します。
- 成功したことを確認します（command_status = 0）。
プロバイダーとのライブテスト
運用開始前のベストプラクティスは、プロバイダーとのライブテストを実行し、双方の関係者が実行中にログを確認することです。
IMPORTANT詳細 SMPP トレースの無効化
すべてのチェックが完了したら、最後に詳細 SMPP トレースを無効にして、多くのログを生成しないようにします。
SMS トラブルシューティング
一般的なトラブルシューティング手順
SMS コネクタには、SMPP プロバイダー、アドビ、ユーザーの 3 つのエンティティが関与します。
SMS の主なエキスパートは SMPP プロバイダーなので、SMS トラフィック関連のすべての問題（接続の問題、メッセージの消失、エンコーディングの問題、国別のルールなど）に SMPP プロバイダーが関与する必要があります。
専用プロセスを有効にする
IMPORTANT以前の（MTA ベースの）コネクタに問題がある（専用プロセスが無効である）場合は、専用プロセスコネクタへの移行を検討する必要があります。パフォーマンスと安定性が大幅に向上し、ログでより優れたフィードバックが提供されます。
異なる外部アカウント間の競合
インスタンスに複数の SMS 外部アカウントがある場合は、アカウント間の競合が原因で問題が発生していないことを確認します。
問題の原因となっている外部アカウントを特定するには、次の手順に従います。
- すべての外部アカウントを無効にします
- 1 つの外部アカウントを有効にします
- 問題を再現してみてください
- そのアカウントで問題が発生しない場合は、そのアカウントを無効にし、次のアカウントで手順 2 に戻ります。各アカウントを個別にチェックすると、次の 2 つのシナリオが考えられます。
その問題は 1 つまたは複数のアカウントで発生した
この場合、各アカウントに別々にその他のトラブルシューティング手順を適用できます。ネットワークトラフィックとログ数を減らすために、アカウントの診断時に他のアカウントを無効にすることをお勧めします。
1 つのアカウントのみアクティブの場合は、問題は発生しなかった
アカウント間で競合が発生しています。Adobe Campaign はアカウントを個別に扱いますが、プロバイダーはアカウントを単一のアカウントとして扱うことができます。
すべてのアカウント間で異なるログイン／パスワードの組み合わせを使用しています
プロバイダーに連絡して、プロバイダー側の競合の可能性を診断する必要があります。
一部の外部アカウントは、同じログイン／パスワードの組み合わせを共有します
プロバイダーは、BIND PDU がどの外部アカウントから来たのかを知る手段がないので、複数のアカウントからの接続をすべて単一のものとして扱います。そのため、2 つのアカウントに対してランダムに MO と SR をルーティングし、一見ランダムな問題を引き起こしている可能性があります。
プロバイダーが同じログイン／パスワードの組み合わせで複数のショートコードをサポートしている場合は、BIND PDU のどこにショートコードを置くのかについて問い合わせる必要があります。MO を正しくルーティングできるのは BIND PDU だけなので、この情報は SUBMIT_SM ではなく、BIND PDU 内に配置する必要があります。
BIND PDU で使用できるフィールドは、前述の各種 PDU の情報の節を参照してください。通常は address_range にショートコードを入れますが、プロバイダーの特別なサポートが必要です。複数のショートコードを個別にルーティングする方法については、担当者にお問い合わせください。
Adobe Campaign は、同じ外部アカウントでの複数のショートコードの処理をサポートしています。そのため、多くの場合、すべてのトラフィックに対して 1 つのアカウントを使用するだけで正常に機能します。
外部アカウントの機能が停止しました
一般に、SMPP 接続は時間の経過と共に非常に安定する傾向があり、正しく設定すると、引き続き機能します。
- コネクタが最近変更されたかどうか、およびどのユーザーによって変更されたかを調べます（外部アカウントをグループとして確認します）。
- システムがアップグレードされたかどうか、およびシステムがアップグレードされたタイミングを調べます。
- SMS に影響を与えるパッケージが最近アップグレードされた可能性があるかどうかを調べます。
これらの確認のいずれでも根本原因が見つからない場合は、プロバイダーにお問い合わせください。プロバイダーがプラットフォームをアップデートする際、コネクタの動作が若干異なる場合があります。これにより、微調整された設定が解除され、不具合が発生する可能性があります。
プロバイダーは大きな変更を事前に通知することがよくあるので、プロバイダーと連絡を取り続けることをお勧めします。
ミッドソーシングに関する問題（ホスト）
- ミッドソーシング環境で問題が発生した場合は、配信と広範ログが適切に作成され、ミッドソーシングサーバーで更新されていることを確認してください。そうでない場合は、SMS の問題ではありません。
- 中間オペレーター名が必ず小文字で指定されていることを確認してください。指定されていない場合、配信は保留中ステータスのままになります。
- ミッドサーバー上で動作し、SMS が正しく送信され、マーケティングインスタンスが正しく更新されない場合は、中間同期の問題が発生します。
プロバイダーに接続する際の問題
- BIND PDU がゼロ以外の command_status コードを返す場合（エラーがあることを意味します）、または BIND_RESP PDU がない場合は、その理由をプロバイダーにお問い合わせください。
- プロバイダーへの TCP 接続を確立できるように、ネットワークが正しく設定されていることを確認してください。
- プロバイダーに、Adobe Campaign インスタンスの IP アドレスが正しく許可されたかどうかを確認するように依頼します（ほとんどのプロバイダーはこの IP アドレスを必要とします）。
- 外部アカウントの設定を確認します。一部のフィールドの値について不明な点がある場合は、プロバイダーにお問い合わせください。
- 接続が成功したものの不安定な場合は、以下の不安定な接続の問題の節を確認してください。
- 接続の問題を診断するのが困難な場合、ネットワークキャプチャを使用すると多くの情報を取得できます。効率的に分析できるよう、ネットワークキャプチャは問題発生時に同時に実行するようにしてください。また、問題が発生した正確な時刻もメモしておく必要があります。これにより、ネットワークキャプチャで問題を見つけやすくなります。
不安定な接続の問題
不安定な接続を診断する方法：
次のいずれかが発生した場合、接続が不安定であると見なされます。
- 接続状態が 1 時間未満の場合。
- SMS プロセスを再起動すると、一時的に問題が「修正」される場合。つまり、不安定な接続によってスロットルがトリガーされ、SMS プロセスを再起動するとスロットルがクリアされ、その後、根本原因が見つかるまで同じことが繰り返される可能性があります。
- プロバイダーが UNBIND PDU を送信する場合。プロバイダーは、通常の操作では UNBIND PDU を送信しません。
- enquire_link が、Campaign 側またはプロバイダー側でタイムアウトする場合。この場合、ENQUIRE_LINK_RESP にはゼロ以外のエラーコードが表示されます。
- BIND PDU が多数ある場合。1 日の間に数回を超えるべきではありません（接続数によって異なります）。1 時間および接続に 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 スループットを下げてみてください。MT スループットを調整するには、プロバイダーに依頼する必要があります。Campaign は非常に速くメッセージを送信できるので、プロバイダーの機器でパフォーマンスの問題が発生する可能性があります。
MT の重複（同じ SMS が連続して複数回送信される）
重複は多くの場合、再試行が原因で発生します。メッセージを再試行する際に重複が発生するのは普通なので、再試行の根本原因を取り除くことに重点を置く必要があります。
- 重複が正確に 60 秒間隔（またはその他の疑わしい「定期的な」期間）で送信されている場合は、おそらくプロバイダー側の問題で、SUBMIT_SM_RESP を十分な速度で送信していません。
- BIND/UNBIND が多い場合は、接続が不安定です。重複メッセージの問題を解決しようとする前に、不安定な接続の問題の節を参照してください。
- その後すぐに、すべての SUBMIT_SM PDU に、一致する SUBMIT_SM_RESP があることを確認します。そうしない場合や、SUBMIT_SM_RESP が遅すぎる場合、問題はプロバイダー側にあります。
再試行時のメッセージの重複回数を軽減するには：
- 送信ウィンドウ のサイズを減らします。送信ウィンドウは、SUBMIT_SM_RESP 待ち時間に対応できるサイズにする必要がありますが、大きすぎてもいけません。この値は、ウィンドウサイズが上限に達した状態でエラーが発生した場合に複製できる、メッセージの最大数を表します。
SR（配信レシート）を処理する際の問題
- SR のトラブルシューティングを行うには、SMPP トレースを有効にする必要があります。
- DELIVER_SM PDU がプロバイダーから送信されたものであり、正しい形式であることを確認します。
- Campaign が DELIVER_SM_RESP PDU に正常に応答したことを適切なタイミングで確認します。これにより、SR が providerMsgStatus テーブルに挿入され、SMS プロセスによる遅延処理が行われていることが保証されます。
DELIVER_SM PDU が正しく認識されない場合は、次の点を確認する必要があります。
- 外部アカウントの ID 抽出とエラー処理に関連する正規表現を確認します。場合によっては、DELIVER_SM PDU の内容に対してこれらを検証する必要があります。
- broadLogMsg テーブルで、エラーが適切にプロビジョニングされていることを確認します（詳しくは、Campaign ドキュメントを参照）。
DELIVER_SM PDU が ACC 拡張 SMPP コネクタで認識されたが、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 インスタンス全体にショートコードを 1 つだけ使用する場合、すべての「ショートコード」フィールドを空にすると、処理が容易になります。
エンコードの問題
エンコーディングの問題は、SMS でよく発生します。以下に、基本的な手順をいくつか示します。
手順 1：プロバイダーに問い合わせる
プロバイダーは、SMS の仕組みを熟知しているエキスパートです。プロバイダーに問い合わせて、問題を調査します。問題が Campaign 側とプロバイダー側のどちらで発生しているのかを把握します。問題が Campaign にある場合は、プロバイダーは間違ったフィールドを特定できるはずでなので、非常に役立ちます。
手順 2：メッセージの内容を理解
メッセージの内容を理解する必要があります。それは簡単に聞こえるかもしれませんが、そうではありません。Unicode では、類似した文字に対して多くのバリエーションを使用できるので、Campaign ではすべてを処理できません。
最も一般的な問題の原因は、ワードプロセッサーからのコピー＆ペーストです。ペーストすることで、通常の文字がタイポグラフィー的に正しいバージョンに変更されます。例えば、スペースはノーブレークスペースに、二重引用符は開始引用符と終了引用符に、マイナス記号は様々なハイフンにそれぞれ変更されます。
テスト時はメッセージをコピー＆ペーストせずに、必ずインターフェイスに直接入力してください。
16 進数を怖がる必要はありません。16 進数は奇妙で不自然に見えますが、非常に特徴的な性質があります。16 進数は、類似する文字の違いを識別できます。小文字の L、大文字の I、O、0、あらゆる種類の引用符、ラテン文字以外のエンコーディング、様々なスペースは、すべて同じように見える場合があります（またはまったく表示されない場合もあります）。16 進数はすべてを表示し、比較に役立ちます。
Unicode を 16 進数に変換するには、オンラインツールを使用できます。
エンコーディングの問題に関する チケットを送信する際、プロバイダーまたは Campaign サポートにかかわらず、入力内容と表示内容の 16 進数バージョンを含めます。
手順 3：送信の内容を理解する
使用するエンコーディングを決定し、その文字テーブルをオンラインで検索します。送信する文字がターゲットコードページで実際に使用できることを確認します。data_coding フィールドが正しく、ユーザーとプロバイダーの予想と一致していることを確認します。
手順 4：実際に送信した内容を理解する
プロバイダーに送信するバイトを正確に確認するには、コネクタのデバッグ出力が必要です。エンコーディングの問題は SUBMIT_SM PDU で発生するので、必ず取得してください。ログ内で見つけやすい明確なメッセージを送信します。
テスト時に異なる種類の特殊文字を送信します。例えば、GSM7 エンコーディングには、他のエンコーディングでは使用されない 16 進形式の特徴的な拡張文字が含まれるので、容易に見分けることができます。
パフォーマンスの問題
NOTEMT の送信中のパフォーマンスの問題
- 外部アカウントの「スループットと遅延」セクションのすべての設定が正しく、プロバイダーによって許可されている設定と一致していることを確認します。
- 再試行がないことを確認します。
- プロバイダーのインフラストラクチャが飽和状態になっていないことを確認します。RESP PDU の RMSGFUL エラーまたは RTHROTTLED エラーを確認します。
- serverConf 設定を確認します。デフォルト値から開始して、パラメーターをゆっくりと 1 つずつ増やします。
- 負荷がかかっている間は 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 トラフィックが関係しないエラー：配信の準備、Message Center API の問題、ワークフローの問題など