バッチ処理アクション

多くのコネクターはバッチベースのアクションをサポートしています。バッチ処理アクションを使用すると、システムはコネクターリクエストをバッチに蓄積し、その後ベンダーに対して一括して呼び出します。バッチ処理アクションを使用することで、ベンダーシステムへの負荷が軽減され、ベンダーAPIのレート制限内に収まるのに役立ちます。

Traceを使用する場合、バッチ処理は無視されます。

バッチ処理をサポートするコネクターには、バッチベースのパラメータロジックが含まれています。リクエストは、以下のいずれかの閾値が満たされるまでキューに入れられます：

• リクエストの数
• 最も古いリクエストからの経過時間
• リクエストのサイズ

最大閾値に達すると、コネクターはバッチを送信します。これらの閾値はORベースで動作し、いずれか一つがバッチ送信をトリガーします。

プロファイルを公開すると、バッチ制限に達していなくてもコネクターバッチキューが処理されます。

バッチコンポーネント

上記の閾値は、ベンダーへのリクエストがどのようにバッチ処理されるかに影響を与える唯一の要因ではありません。Tealiumのコンポーネントは並列で動作し、複数のコンポーネントが同時に独自のバッチを形成します。

この例では、以下の閾値でバッチ処理されるコネクターアクションを考えます（値は例示目的のみ）：

• 最大リクエスト数 = 100
• 最大時間 = 1分
• 最大サイズ = 10 MB

単一コンポーネント

この例では、Tealiumコネクターには単一のバッチングコンポーネントがあります。このコンポーネントは、1分間に150リクエストの一定のデータ流入を受け、150リクエストのサイズは10MB未満です。

この場合、最大リクエスト数のパラメータが定期的にバッチデータの送信をトリガーします。なぜなら、他の2つのパラメータがトリガーされる前に閾値に達するからです。

複数コンポーネント

実際には、Tealiumコネクターには複数のバッチングコンポーネントがあります。この例では、2つのバッチングコンポーネントが同じデータ流入（1分間に150リクエスト）を持っています。リクエストは2つのコンポーネント間で均等に分配されます。各コンポーネントが独立してバッチを監視するため、各コンポーネントへのデータ流入は1分間に75リクエストになります。このデータ流入は最大リクエスト数の閾値をトリガーするには十分ではありません。この場合、最初に最大時間の閾値がトリガーされるでしょう。それでも定期的にベンダーAPIへの呼び出しが行われますが、各呼び出しには75レコードのみが含まれます。

実際のシナリオでは、Tealiumコネクターには1つや2つ以上のコンポーネントがあります。需要に応じてバッチングコンポーネントの数を増減します。

イベントの順序

並列データフローのため、イベントは受信された順序と同じ順序で下流のコネクターにトリガーされない場合があります。たとえば、訪問がイベントAを受け取り、その後イベントBを受け取った場合、イベントBが最初のデータバッチでベンダーに送信され、イベントAが別のバッチで後に送信される可能性があります。イベントの順序が使用ケースにとって重要な場合は、コネクターペイロードにシーケンス番号またはイベントタイムスタンプを渡し、ベンダーシステムで元の順序を再構築してください。