1

全て、

私は現在、Classic ASP と VXML 2.0 を使用して記述された古代の IVR を改良しています。信じられないかもしれませんが、ASP コードと VXML ロジックの間でルーティング ロジックが混在し、ASP.NET のように複数のポストバックが行われたことが主な原因で、混乱が生じました。デバッグするのは楽しくありません。

そのため、MVC 3 と Razor で新たに開始し、これまでのところ非常にうまくいっています。ほとんどすべての処理ロジックをコントローラに移動し、VXML のほとんどをプロンプトの発声と DTMF 応答の待機だけにすることに成功しました。

しかし、多くのサンプル VXML コードを見ると、ページ上の複数と VXML の組み込み DTMF 処理と . より複雑な意思決定とデータベース/サーバーへのアクセスでは、現在のようにコントローラーを呼び出します。

私は、ロジックがどこにあるかについて厳密になりたいという欲求と、実際にはより単純なコードになるかもしれないものとの間で引き裂かれています。私の VXML チョップはそれほど高度ではないので (危険であることは十分承知しています)、意見を求めています。他の人が 1 つのページで複数のフォームを使用したことがありますか? 良くも悪くも？

ありがとう

ジム・スタンリー Blackboard Connect Inc.

4

3 に答える 3

1

私たちの現在のフレームワークは現在、サーバーとクライアントを組み合わせて使用​​しています。すべてのロジックは VoiceXML にあり、サーバーは状態の保存と認識コンポーネントの生成に使用されます。残念ながら、すべてのロジックが voicexml にあるため、単体テストが難しくなります。

各質問へのサブダイアログとクライアント側で行われるすべてのルーティングを行う大きな voicexml ページを作成するのではなく、各収集後にサーバーにポストバックして、どこに行くべきかを考え出します。Jim が指摘したように、明らかにこれには長所と短所がありますが、VoiceXML から IVR/コールフローの一部を抽象化し、VoiceXML の開発者のスキルアップへの依存を減らすことが望まれます。

私は、MVC3 を使用して再開発を検討しており、基本 IVR 関数に基づいてさまざまなビューを作成します。これは、ホストしている VoiceXML プラットフォームに基づいて変更できます。

  • 認識
  • プロンプト
  • 移行
  • CTI 取得/設定
  • 切断する

私がまだ取り組んでいるのは、MVC 内で再利用可能なコンポーネントを作成する方法です。サブダイアログを作成して結果を返す (現在の方法と同様) か、汎用コントローラにリダイレクトし、コントローラが完了したら「完了」アクションにリダイレクトします。

于 2011-10-24T06:53:08.593 に答える
1

単純な VoiceXML の使用を選択し、ロジック サーバー側を移動することは、かなり一般的な方法です。以下の長所/短所。

サーバー側のロジック

  • 入力検証も実行している場合、再試行カウンターを希望どおりに実行するのが難しいことがよくあります (文法には有効ですが、ホストまたはその他の検証ロジックには有効ではありません)。
  • 論理的な記述を作成するためのより優れたプログラミング言語/ツールキット (私は JavaScript のファンではありませんが、JavaScript が好きでも、必要なフロー制御を得るために多くのフォームを作成する必要がある傾向があります)。
  • 通常はデバッグが容易です。論理的な決定を進め、ログ ツールにアクセスします。
  • 通常、パラメーターを使用してコンポーネントの動作を変更する再利用可能なコンポーネントを作成する方が簡単です。

クライアント側のロジック

  • 通常、よりスケーラブルです。VoiceXML ブラウザーは、ページのコンパイルと処理に大量のリソースを使用する傾向があります。1 つの大きなページは通常、さまざまな小さなページよりも優れています。ただし、プラットフォームは大きく異なり、サイズによっては無視できる場合があります。
  • 静的ページを使用する可能性が高くなります。多くのプラットフォームには、高度に最適化されたキャッシュがあります (データをフェッチするだけではありません)。上記のように、デバイスごとに数百のポートがある場合、またはサーバーにヒットする数千のポートがある場合にのみ問題になる場合があります。

誰かがある種のグローバルな行動の変更を要求するまで、混合と一致は悪くありません. 複数の場所で変更を行っている可能性があります。デバッグ手法もさまざまであるため、サポート パスが複雑になる可能性があります (たとえば、ブラウザのログとサーバーのログを調べて、呼び出しで何が起こったかを確認します)。

于 2011-08-17T00:44:52.060 に答える
0

Jim Rush は、サーバー側とクライアント側のロジックの長所と短所の概要をよく説明しており、このトピックに関する私のブログ記事「 VoiceXML アプリケーションのクライアント側とサーバー側の開発」での議論とかなり一致しています。ロジックをサーバーに配置することの利点は、クライアントに配置することよりもはるかに優れていると思います。VoiceXML User Group は、バージョン 3.0 の VoiceXML からこのロジックのほとんどを削除し、ステート チャート XML (SCXML) と呼ばれる新しい標準を使用して音声アプリケーションの制御を処理することを提案しています。ASP.NET MVC 3.0 を使用した VoiceXML アプリケーションの開発を容易にするオープン ソース プロジェクトを開始しました。これはCodePlex にあり、VoiceModel と呼ばれます。. このプロジェクトにはサンプル アプリケーションがあり、ロジック サーバー側を保持する方法を示します。これにより、音声オブジェクトの再利用が大幅に改善されると思います。

于 2011-12-09T19:47:04.203 に答える