バッチリクエストの仕組み

バッチ処理の目的は、すべてのアクションを一緒に成功または失敗することです。したがって、 はバッチアクションをまとめて AWS Elemental MediaLive 検証します。 は次の検証 MediaLive を実行します。

• 作成または削除される各アクションの明示的または暗黙的 開始時刻が、少なくとも 15 秒後であることを確認します。

• アクションがスケジュール内の既存のアクションを参照する場合、既存のアクションへの参照が正確であることを確認します。例えば、フォロー入力スイッチには、後続のアクションへの参照が含まれます。そのアクションが存在している必要があります。

いずれかのアクションの検証が失敗した場合、バッチにあるすべてのアクションが失敗になります。

アクションが一緒に成功または削除することを望まない場合、バッチを送信しないでください。代わりに、独自のバッチ更新スケジュールコマンドで各アクションを作成します。

検証が成功すると、 はアクションの開始時刻に関係なく、作成リクエストの前にすべての削除リクエスト MediaLive を処理します。

例 1

バッチの重要な使用方法は、一緒に成功または失敗する必要がある複数のアクションを実行することです。例えば、企業ロゴを削除し、(広告表示に移動するために) すぐに splice_insert を挿入するとします。そのためには、ロゴを削除するアクションと、splice_insert を挿入する別のアクションを作成する必要があります。ただし、splice_insert アクションが失敗した場合、またはその逆の場合は、削除アクション MediaLive を挿入したくない。両方のアクションが失敗する方が望ましいと言えます。この場合、誤った形式のアクションを修正し、両方のアクションを再度送信できます。

したがって、1 つのバッチ更新スケジュールコマンドで 2 つのアクションをまとめて送信します。

例 2

バッチのもう 1 つの重要な使用方法は、スケジュール内のアクションのエラーを修正することです。例えば、まだ開始しておらず、誤った開始時刻で作成されたイメージオーバーレイを修正するとします。これを行うには、以下を含む JSON で 1 つのバッチ更新スケジュールコマンドを送信します。

• イメージオーバーレイをアクティブ化する元のアクションを削除するペイロード。このアクションの開始時刻が誤っています。

• 同じイメージオーバーレイをアクティブ化する新しいアクションを追加するペイロード。このアクションの開始時刻は正確です。