電話は実行のエンドポイントであり、汎用の公開ウェブサーバーではありません。
SMS サーバーとしての Android 携帯
サーバーの制御された SMS エンドポイントとして Android を実行する電話を使用する
接続されたAndroid端末がセキュアなキュー方式を通じて最終的なモバイルネットワーク操作を行う間、ビジネスロジックはサーバー上に残してください。
- 互換性のあるモバイル端末
- お客様のSIMと番号
- API、ワークフローと統合
正確な問題点
お客様のバックエンドは脆弱なUSBモデムスクリプトに依存すべきではありません
電話やモデムを直接公開すると、ネットワーク、セキュリティ、リカバリの問題が発生します。SMSMobileAPIはパブリックAPI、耐久性のあるアカウントキュー、認証済みのモバイルアプリを分離します。
シンプルで見えるフロー
ビジネスイベントから有用な結果へ
一つの制御された連鎖があなたのソフトウェア、SMSMobileAPI、そしてあなたが所有するモバイルをつなぎます。
40秒のデモ
サーバーから電話へのアーキテクチャを理解する
シーケンスは自動的に繰り返されます。任意のステップで一時停止して自分のペースで確認できます。
-
1
送信
お客様のバックエンドが、ドキュメント化されたHTTPS APIを介してリクエストを作成します。
-
2
キューに入れる
アカウントが業務の保存とルーティングを行い、電話を公開することはありません。
-
3
請求する
認証された接続済みの Android が対象の作業を取得します。
-
4
レポート
ステータスとモバイルアクティビティはプラットフォームに戻り、アプリケーションが検査します。
実際のビジネス事例
例:内部アプリケーションが運用アラートを送信する
監視サーバーが重要な機械の停止を検知しSMSを作成します。当直室の Android 携帯が作業を引き受け、その SIM 経由で送信します。バックエンドは返されたリクエスト識別子を保存します。
結果: 電話へのインバウンドネットワークアクセスを開かずに実現するクリーンなHTTPS統合。正直な制約
スケールする前に運用条件を把握する
物理的な携帯アーキテクチャは、その実際の制約を設計に組み込むと強力です。
スループットは端末、OS、事業者およびアカウントの安全策によって制限されます。
本番システムは接続、キューの経過時間、失敗、デバイスの可用性を監視する必要があります。
構築方法を選択
一つのモバイルプラットフォーム、複数の実装パス
チームに合った最もシンプルな経路から始め、ワークフローが成長したら機能を組み合わせてください。
このユースケースのための質問
よくある質問
Android電話をインターネットに公開する必要がありますか?
いいえ。アプリがセキュアなサービス接続を維持し、バックエンドは公開されたSMSMobileAPIのHTTPS APIと通信します。
サーバーは特定の Android 携帯をターゲットできますか?
はい。リクエストを特定の接続済み端末経由で送る必要がある場合はモバイル識別子を使用してください。
本番環境で何を監視すべきですか?
接続デバイスの状態、キュー内の作業、失敗したリクエスト、キャリア容量、処理されていないアクションの経過時間を監視してください。
1つの管理されたテストから始める
電話を接続し、実際のメッセージでワークフローを検証してください。
アカウントを作成し、1台の対応モバイルをペアリングして、スケール前に経路全体を検証してください。
