新しい SMS コネクタ v2 への移行

このドキュメントでは、Adobe Campaign v8 で MTA ベースの SMS コネクタから新しい 専用 SMS プロセスコネクタ に移行する際の手順と主な考慮事項について説明します。

v2 コネクタに切り替える理由

専用の SMS プロセスは、SMPP トランシーバーモードのサポートを導入し、接続数の削減とリソース効率の向上を実現し、必要に応じてトランスミッター/レシーバーの設定もサポートします。 エラーからの迅速な回復、永続的な接続、ローカルファイルやプロセス間の通信に依存することなく、安定性が大幅に向上します。 また、低遅延、高スループット、インテリジェントなマイクロバッチ処理により、速度と信頼性のバランスを取りながら、パフォーマンスも向上しています。 さらに、SMS プロセスの分離により、トラブルシューティングが簡略化され、クロスチャネルへの影響が最小限に抑えられます。 これらの機能強化により、専用コネクタが SMS 配信用のより堅牢でスケーラブルなソリューションになります。

v1 コネクタと v2 コネクタの違い

Adobe Campaign v8 の専用 SMS コネクタには、MTA ベースのコネクタと比較して、アーキテクチャがいくつか変更されています。 主な違いは、デフォルトで SMPP トランシーバーモードを使用する点です。このモードでは、送信機能と受信機能を組み合わせることで接続数を減らすことができます。 プロバイダーがこのモードをサポートしていない場合でも、送信機と受信機の接続を個別に使用することは可能です。 MTA コネクタとは異なり、自動返信を有効にしても接続数には影響せず、すべての受信者接続で、あらゆる種類の受信メッセージを処理できます。

接続数が、別の式を使用して計算されるようになりました。

Total connections = SMS sending threads * Number of MTA child connections.

serverConf で定義される sendingThreads パラメーターは、デフォルトで 1 に設定されており、高いパフォーマンスを実現するために特別に最適化しない限り、通常は変更されません。 1 つのプロセスですべての SMS トラフィックを処理するので、これらのパラメーターを通じた並列性の管理は、システムの負荷と動作を制御するために重要になります。

送信ウィンドウは MTA コネクタと同様に動作しますが、専用モードのパフォーマンスにさらに大きな影響を与えます。 送信ウィンドウを長くすると、データベースの IOPS が減少し、スループットが向上します。 Campaign は、プロバイダーがサポートし、ユースケースで接続の問題が発生した場合にメッセージの損失や重複のわずかなマージンを許可している場合に限り、1,000 を超えるメッセージのウィンドウを効率的に処理できます。 プロバイダー側では、より大きな SR 送信ウィンドウを設定すると、配信レポートのスループットも大幅に向上します。

最後に、MO (Mobile Originated)メッセージ処理は機能に変更されませんが、基になるコードが更新されました。 接続あたりのスループットも同じように制限されますが、専用コネクタを使用すると、より高速なバースト送信が可能になります。 ただし、スループットの制限がないと、高速送信がプロバイダーやシステムリソースを圧倒する可能性があるので、外部アカウント設定で MT のスループット上限を明示的に設定することをお勧めします。

切り替え手順

専用の SMS プロセスにスムーズに切り替えるように、SMS トラフィックが少ない場合または少ない場合に操作を実行することをお勧めします。 MTA バッファが完全にフラッシュされていないと、バッファに保存されたメッセージの一部が失われたり、無効な状態のままになる場合があります。 また、予期しない SR のタイミングが原因で、切り替え後の最大 1 週間は、一部の SR を見逃すことも通常あります。 これらの予防策に従わないと、組み込みの保護機能にもかかわらず、メッセージの損失や重複が発生する可能性があります。

どちらの SMS コネクタも、SR (ステータスレポート)処理に異なる形式を使用します。 どちらも NmsProviderMsgId テーブルに依存していますが、操作の方法は異なります。 したがって、コネクタを切り替えるには、テーブル全体をクリアして、競合や孤立したデータを防ぐ必要があります。 このクリーンアップを実行する方法はいくつかあります。 使用可能な SQL クエリを次に示します。

TRUNCATE TABLE NmsProviderMsgId;
TRUNCATE TABLE NmsProviderMsgStatus;

手順

  1. 設定(serverConfsms > mta2 確認します。

  2. リアルタイムメッセージ準備ワークフローを一時停止します(該当する場合)。

  3. すべての SMS 配信を一時停止します。

  4. SMS 外部アカウントを無効にします。

  5. MTA および SMS プロセスを停止して再開します。

  6. アクティブな SMPP 接続がないことを確認します。 存在する場合は、すべての配信が一時停止していることを確認します。

  7. データベース内の NmsProviderMsgId テーブルと NmsProviderMsgStatus テーブルの内容をクリアします。

  8. 外部アカウントで:

    • 「専用プロセス」チェックボックスを有効にします
    • その他の設定の調整:MTA 子接続、MT スループット、送信ウィンドウ
  9. 外部アカウントを再度有効にして保存します。

  10. SMS 配信を再開します。

  11. SMS サービスが正常に機能していることを確認します。

NOTE
SMS、MTA、MTA の子ログを監視して、エラーや問題がないか確認します。
ロールバック目的で、以前の外部アカウント設定を保存します。

ロールバック手順

MTA コネクタへのロールバックは、最初のスイッチで使用したのと同じ手順に同じ順序で従うことで可能です。 これには、すべての SMS 配信の停止または一時停止や、元の外部アカウント設定の復元が含まれます。

  1. インスタンスがリアルタイム配信を使用する場合は、メッセージの準備を担当するテクニカルワークフローを一時停止します。

  2. すべての SMS 配信を一時停止します。

  3. SMS 外部アカウントを無効にします。

  4. MTA と SMS の両方のプロセスを停止して再起動します。

  5. アクティブな SMPP 接続が残っていないことを確認し、残っている場合は、すべての配信が正しく一時停止されていることを確認します。

  6. データベース内の NmsProviderMsgId テーブルと NmsProviderMsgStatus テーブルをクリアします。

  7. 外部アカウントで:

    • 外部アカウントの「専用プロセス」オプションをオフにします。
    • 以前の外部アカウント設定をすべて復元:MTA 子接続、MT スループット、送信ウィンドウ
  8. 外部アカウントを再度有効にして保存します。

  9. すべての SMS 配信を再開します。

  10. 最後に、SMS サービスが正常に機能していることを確認します。

recommendation-more-help
c14bd44c-7b5f-474a-888d-1c2baee5a247