サプライヤのエラー メッセージは予告なく変更され、サプライヤのシステムによって公開されることもないため、すべてのメッセージが網羅された一覧は存在しません。

  • エラーが発生したときにエラー メッセージを記録し、収集することで、エラーのデータベースを独自に構築できます。
  • システムで handling エレメント、category エレメント、および message エレメントを収集することで、最終的に、新しいメッセージを含め、サプライヤのリソースから返されるすべてのエラーを発生時に処理できるようになります。

一般的なエラー タイプ

検索エラー 既知の検索、場所に関する例外、およびその他の一般的なエラー
クレジットカード エラー 既知のクレジットカード エラー
予約エラー 一般的な予約エラー
キャンセル エラー 一般的なキャンセル エラー

特殊なケースおよび規定の処理

重複予約を回避 重複予約を避けるための特別な仕組み
スタック トレース保留中 保留中の予約ステータスを示すサプライヤ メッセージ
処理保留中 保留中の予約ステータスを示すサプライヤ メッセージ
料金変更エラー 料金不一致または料金変更のエラーを処理する方法
PHP、Axis、.NET、JSON に関する問題 PHP、Axis、.NET、または JSON の処理に関する既知の問題

エラーは次のことを示します :

  • リクエスト構造の問題。構造、スペリング、終了タグなどをチェックして、リクエスト文字列を訂正します。
  • 送信するデータの問題。選択したホテル データが正確に解析されているかどうかをチェックします。
  • ユーザーの入力の問題。入力を訂正するようユーザーに通知します。
  • サプライヤおよびサードパーティのシステムとの接続またはインタラクションの問題。サプライヤの問題は断続的または長期的に続く場合があります。

サンプル ロジック

handling、category、および message の詳細をチェックすることにより、ほとんどのエラーは非常に簡単に訂正できます。

返されたメッセージを読んでエラーの性質を知ることができますが、メッセージだけに基づいて、エラーをコードの中でどのように処理するかを判断しないでください。ほとんどの場合、次のテキストにエラーの handling と category の詳細に関連した明確な説明が提供されます。

メッセージの例 :"The selected room rate is no longer available.Price check failed on availability." (「選択した部屋料金はご利用になれません。空室状況のために料金確認が失敗しました。」)

<handling>RECOVERABLE</handling> 
<category>PRICE_MISMATCH</category>

エラー処理の例 :

  • handling=RECOVERABLE は、エラーを訂正して予約を再送信すれば、予約が正常に処理されることを意味します。
  • category=PRICE_MISMATCH は、料金が変更されたことを示し、メッセージに示されている特定のテキストが返された理由を確認します。
  • 送信した料金が「失敗した」(変更されている) ため、ユーザーは別の部屋を選択する必要があります。
  • 部屋の検索結果をリフレッシュして新しい料金を取得し、更新された予約クエリを再送信する必要があります。
  • 予約の料金が新しいまたは変更されている場合は (特に料金が高くなっている場合)、必ずユーザーが新しい料金に同意してから予約が再送信されるようにします。
  • 新しい料金に関してユーザーの同意を得る際に、料金がより妥当と思われる同施設の別の部屋を選択できるようにしたり、新しい施設を検索または選択して予約できるようにしたり、あるいはその両方を行えるようにできます。

接続および通信の問題

  • “サプライヤの通信の問題”
  • “通信の失敗”
  • “サプライヤ応答が null”
  • “予約は処理されていません。null 応答が返されました”

上記のメッセージすべては、サプライヤに関係なく、以下の状態であることを示します :

  1. 予約リクエストを受信した
  2. サプライ ソースを使用してリクエストを試行した
  3. サプライヤから応答がないか、またはサプライヤからエラー応答を受信した

上記の場合は、サプライヤ側の接続に問題があるため接続が完全に回復しない限り通信を受け付けることができないか、またはサプライヤのネットワーク内で生じたに他の問題のため予約を完了できません。場合によっては、通信の問題が断続的であるなら、リクエストを再送信することでエラーを回復できるかもしれません。接続エラーが長引いているなら、別のサプライヤを選択する必要があります。

ベスト プラクティス

例外メッセージのテキスト照合に基づいて、アクションの行程を判断しないでください。

  1. エラー固有の handling、category、および message を識別します。
  2. リクエストの構造を確認します。
    • 正しい形式のサンプル リクエストを確認し、すべてのパラメータと値を正しく送信していることを確認します。
    • API デモ ツールを使用して、有効なリクエストを生成し、使用中のリクエストと比較します。使用中のリクエストを正しい形式のリクエストと比較するには、デバッグ ワークシートが便利です。
  3. ユーザーの側で変更を行うことでエラーが解決するかどうかを判断します。
    • ユーザーは別の施設を選択する必要があるか
    • ユーザーは入力データを訂正する必要があるか
    • handling=AGENT_ATTENTION が返された場合、予約リクエストのフォローアップのために担当者様が連絡することをユーザーに通知します。

サプライヤのエラー メッセージは予告なく変更され、サプライヤのシステムによって公開されることもないため、すべてのメッセージが網羅された一覧は存在しません。

  • エラーが発生したときにエラー メッセージを記録し、収集することで、エラーのデータベースを独自に構築できます。
  • システムで handling エレメント、category エレメント、および message エレメントを収集することで、最終的に、新しいメッセージを含め、サプライヤのリソースから返されるすべてのエラーを発生時に処理できるようになります。

コンテンツ タイプおよび特殊文字のエンコーディング

コンテンツ タイプ、エンコード、および施設データの送信処理に関する情報を確認してください。