増分クエリでは、新しいレコードだけでなく、すべてのレコードが選択されます
増分クエリが期待どおりに動作しないAdobe Campaign Classicの問題を修正する方法を説明します。
説明 description
環境
Campaign Classic
問題／症状
増分クエリが期待どおりに動作しない。 前回の実行以降に新しいレコードのみを取得するのではなく、通常のクエリ アクティビティと同様に、毎回すべてのレコードを取得しています。
解決策 resolution
この問題は、Adobe Campaign Classic 20.1.1 リリース（ビルド 9122 以降）で修正されました。
ユーザーが使用できる回避策：
回避策 1：クリーンアップワークフローを停止して断続的に実行し、修正が反映されて使用可能になるまでデータベースと HDD をクリーンアップします。 アップグレードを計画していない場合は、この方法はお勧めしません。
回避策 2：増分クエリアクティビティが影響を受けると仮定します。 この問題を回避するには、増分処理クエリと同じ操作を実行して、履歴テーブルのコンテンツを保持する永続的なスキーマを作成します。 クエリと更新のデータアクティビティを組み合わせて、動作を模倣します。 これは、増分処理クエリを必要とするすべてのワークフローについて行う必要があります。
回避策 3: 増分クエリアクティビティが影響を受けるとします。 問題のスキーマに監査フィールド tsCreated/tsLastModified を追加して、この問題を回避します。 増分処理クエリは、tscreated< GetDate() のような where 句を持つ通常のクエリアクティビティに変換されます。
回避策 4:
- 新しいシーケンス
xtknewworkflowidを作成し、現在の workflowId の範囲から遠いものに初期化します。 - この
pkSequenceを使用するようにxtkworkflowスキーマを変更します。 - 影響を受けるすべてのワークフローのクローンを作成し、元のワークフローを削除するように、ユーザーに依頼します。
- ユーザーをアップグレードする準備が整ったら、ワークフローの作成の
xtknewIdに戻り、この修正を削除します（これにより、不要な予期しない問題を回避できます）。
原因
主な問題はクリーンアップワークフローです。
増分クエリワークフローは、次のように動作します。
- 以前のイテレーションの結果を含む履歴テーブルを維持します。
- ターゲットクエリからすべての行を取得します。
- 履歴テーブルに存在するすべての行を除外します
- 次のイテレーションフィルタリングのために、残りの結果を履歴テーブルに追加します。
履歴ワークテーブル名は次のような表記です。wkfhisto<workflowid> <activityName>_
ここで、workflowID が 0< 場合（xtknewid で負のシーケンスを許可しているユーザーの場合）、実際には次のようになります。
wkfhisto<(uint)workflowid> <activityName>_
Although this is okay for workflow execution.
So, for example, the incremental activity incremental1 of workflow ID=-1 will create a table wkfhisto4294967295_incremental1.
The thing which is missed is the CleanUp workflow.
Here, we have a code that tries to delete worktables of deleted workflows.
A dedicated code here lists all the wkfhisto tables, extracts the workflowId from their names (from the above convention), and deletes them all except the ones whose worklowIDs are found in the xtkworkflow table.
However, it misses the uint part.
So, it tries to look up a workflow with ID 4294967295 instead of casting this back to int. Since this workflow is not found, this table is deleted. Next time, when this workflow runs, the incremental query activity does not find an existing history table and creates it thinking of this as the first run ever.