タイムアウトになった場合に重複予約を回避する

以下の場合に予約手続きがタイムアウトになる可能性があります :

  • アフィリエイト サーバーのタイムアウト設定値が低すぎる
  • 予約処理システムの処理がサプライヤ レベルで遅すぎる
  • 決済ゲートウェイの処理が決済処理レベルで遅すぎる
  • 予期せず通信量が急増したために、サーバーが過負荷状態になっている

タイムアウトはどこで発生しますか ?

  • 応答にサーバーの設定よりも長い時間がかかると、アフィリエイト サーバーでタイムアウトが発生する場合があります。すべての予約および決済処理にかかる時間を見越して、30 秒以上を設定することを推奨します。通常、処理にこれほど長い時間がかかることはありませんが、所要時間はサプライヤ ゲートウェイと決済ゲートウェイの効率によって左右されます。
  • サプライヤ ゲートウェイまたは決済ゲートウェイの実行にデフォルトのタイムアウト設定である 60 秒よりも長い時間がかかると、当社サーバーでタイムアウトが発生することがあります。予約の結果が示される前にすべてのシステムがタイムアウトになったとしても、処理が正常に実行されている可能性があります。残念ながら、この場合はシステムをチェックしないとすべての確認情報を収集できない可能性があります。

タイムアウトになっても予約が完了しているか、それともどこかのレベルでシステムがタイムアウトになっているために予約結果が空で返されるかを、どうすれば確認できますか ?

予約リクエストのアウトラインを読んで、affiliateConfirmationId (アフィリエイト確認 ID) の使い方について詳しく調べてください。このパラメーターは、タイムアウト発生時に、予約が正常に処理されたことや旅程が不明な場合、予約を検索するために使用できます。

  • タイムアウトになった予約や空の予約結果を処理する特別なロジックを予約ページに組み込むことによって、重複予約を回避できます。
  • その後、ふさわしいメッセージ情報をお客様に通知し、適切なロジックを使用して予約を回復します。

affiliateConfirmationId (文字列)

  • 独自のアフィリエイト トラッキングまたはアフィリエイト個人使用にのみ使われる、アフィリエイト固有 ID
  • 固有の値である必要があります
  • 失敗した予約の値も含め、同じ値を 2 回送信してしまうと、予約は失敗します
  • この値は、お客様が予約ボタンを複数回押したときに予約が重複しないようにするためにも使用できます
    • このパラメーターが渡された場合、同じ affiliateConfirmationId (アフィリエイト確認 ID) による予約がすでにシステム内に作成されていないかを検証しますまた、アフィリエイト様はこの ID を使用してシステムから旅程を取得できます。
  • このフィールドを使用するアフィリエイト様は、ID が確実に一意であることを確認する必要があります (GUID ID など)。
  • ID は、お客様が最終予約フォームを送信する前に作成する必要があります。同じお客様が送信ボタンを再度押すと、同じ affiliateConfirmationId (アフィリエイト確認 ID) が送信され、重複予約として検出されます。
  • {: .red} 最新のリクエストを新しい affiliateConfirmationId (アフィリエイト確認 ID) で作成する必要が生じることが多くあるため (予約に失敗した場合や予約が回復不能な場合など)、このエレメントを送信する際には細心の注意を払ってください。
  • このアイテムの用途は次のとおりです
  • パートナー様自身のトラッキング
  • お客様による重複予約/課金の送信を避ける
  • 予約がタイムアウトになった場合や、サードパーティ システムの処理がタイムアウトになったために空の結果が返された場合に、システムに旅程がないか確認する

予約リクエストがタイムアウトになった場合や、空の結果が返された場合に、予約が存在するかどうかを判別する手順

  1. 予約リクエストが固有の affiliateConfirmationId (アフィリエイト確認 ID) とともに送信されます
  2. タイムアウトが発生するか、またはしばらく待っても結果が返されません
  3. タイムアウトになるかまたは空の予約結果セットが返されたら、affiliateConfirmationId (アフィリエイト確認 ID) のみを使用して旅程リクエストを行います。

  4. この旅程リクエストを送信すると、該当する affiliateConfirmationId (アフィリエイト確認 ID) の旅程が作成されていれば、その旅程情報が返されます。

  5. その旅程のステータスも表示されます。
  6. CF - 予約確認済み
  7. PS - 保留\:handling=3 (担当者が予約を確定しなければならない) が返されると、通常はこのステータスが返されます。EAN はこれらの予約を処理しようとし、通知をさらに行うことなく CF または UC に解決する可能性があります。
  8. UC - 未確認\:この予約はご利用になれないため、確認されません。
  9. DT - 削除済み\:リクエストはキャンセルされており、旅程は統計から削除されています。通常は、予約リクエスト時に回復不可能なエラーが起きるとこのステータスになります。 ^

  10. 旅程リクエストから返される結果のステータスが CF 以外である場合

  11. 予約に問題があったことをお客様に通知し、予約のステータスを知らせます。
  12. handling = 3 が返される場合は、担当者が 24 時間以内にお客様に連絡します。
  13. 問題のあった予約リクエストを取り消して予約リクエストをやり直すことができることを、お客様に提案することもできます。
  14. リクエストをキャンセルする場合は、取得した旅程情報を使用して、完了しなかった予約のキャンセル リクエストを送信します。
  15. このようにすることで、完了しなかったその予約のフォローアップは必要ないことが担当者に通知されます。

  16. 旅程リクエストから返される結果のステータスが CF である場合

  17. タイムアウトなく予約が正常に確認された場合と同じように、正常に予約が行われたことを、旅程の結果からお客様に示します。

  18. 結果が返されない場合

  19. 予約リクエストがタイムアウトになっている間、予約の結果は返されません。
  20. 予約の処理に問題があったことをお客様に通知し、お客様が予約をやり直せるように施設選択のフォローアップを提案します。
  21. 忘れずに新しい affiliateConfirmationId (アフィリエイト確認 ID) を発行します。この ID は予約リクエストごとに固有の値でなければなりません。

重複送信を回避

お客様が制限なしの送信ボタンを押すたびに、または同一予約の予約ページをリフレッシュするたびに、重複する予約が作成されます。

Web や電子システムの性質上、および他の制御不能な要素のために、転送された送信および応答に遅延が生じることがあります。

  • このようなとき、お客様は待ちきれずに予約送信メソッドを複数回クリックするかもしれません。
  • そうすると、予約送信が行われるたびに新しい予約が作成されます。
  • 実際の確認応答が新しい応答で上書きされる場合もあるため、予約が複数回送信されていて実際には予約がサイト上で重複しているということを、メール ボックスに確認のメールが届くまで、または施設に到着するまでお客様が気付かないというケースもあります。

重複予約によるお客様への影響は ?

  • 料金前払いの予約の場合、重複予約を受信して新規予約レコードが作成されるたびに、お客様のクレジット カードに課金されます。
  • Hotel Collect/Hotel Collect 予約の場合は、同じ施設の予約システムに同一のお客様の予約が複数作成されます。
  • 施設では、これらを複数の部屋の予約とみなし、チェックイン時に宿泊客が各部屋の料金を支払う責任を負うことになります。各部屋が宿泊客のクレジット カードを担保にして確保され、他のお客様に販売されなかったためです。

重複予約によるアフィリエイト様への影響は ?

  • アフィリエイト様は各自でそれぞれのアプリケーション作成の責任を負うことになっているため、自分の顧客に対する責任もアフィリエイト様が負うことになります。
  • 適切な対応が行われなかった場合、お客様との係争により不要な費用が発生する可能性があります。その費用は直接アフィリエイト様に請求されます。

  • 重複予約を回避するために、複数回の送信を処理し、適切な情報をお客様に通知する特別なロジックを予約ページに組み込んでください。

  • 通常、複数回クリックするとお客様のクレジット カードに二重課金されると明記するだけで、ほとんどの問題を防ぐことができます。

  • 読み込み時に何度もクリックしないよう、最初にクリックした後に送信ボタンを無効にする、簡単なコードを追加することもできます。
  • 他の Web 障害が生じた場合でも、予約が 1 件だけの予定であるなら、予約が決して 2 回送信されないようにする特別な仕組みが必要になります。

特別な仕組みでは、リクエストを再送信することで一部の予約エラーが解決する場合があることに注意する必要もあります。

  • 障害や予約時に返される例外の処理コードの種類によっては、予約を再送信したほうがよいと判断することができます。
  • そのような場合、予約は重複しておらず、予約し直すことで正常に処理されます。

予約リクエストのアウトラインを読んで、<affliateConfirmationId> の使い方について詳しく調べてください。このパラメーターは、このシステムで重複する予約が行われていないかを検出するのに役立ちます。

最後に、旅程リクエストを使用して、既存の旅程または既存の旅程のステータスを確認します。