トピックス

知識創造研究室 by CRM(xRM)

Paging Cookieの落とし穴

みなさん、こんにちは。

今回は、最近お客様よりご相談を受けることが多くあった他テーブルを結合して5,000件以上のデータ取得を行う際の落とし穴を紹介したいと思います。

発生事象

FetchXmlを使用して5,000件以上の取得にはPagingCookieの利用が推奨されています。
また、親子関係のあるテーブルを結合して取得する際には、link-entityを使用して取得することになりますが、その際に落とし穴があります。

以下のように1つの親レコードに対して子レコードを4つずつ持っているレコードがあるとします。

これらのレコードをページサイズを5にして取得する場合、以下のようなFetchXmlを書いて取得します。

<fetch mapping=”logical” count=”5″ version=”1.0″>
    <entity name="親エンティティ名"> 
        <link-entity name="子エンティティ名" from="親エンティティの主キーフィールド名" to="子エンティティの親を参照しているフィールド名"> 
            <attribute name="子エンティティの主キーフィールド名" /> 
            <attribute name="子エンティティのプライマリフィールド名" /> 
        </link-entity> 
    </entity> 
</fetch> 

この取得結果は、次のようになります。

そして次のPagingCookieも返されます。


<cookie page="1">
    <親エンティティ主キー項目名 last="b91f4114-fa69-44f4-992e-24b2cc49c726" first="70668a69-9ab9-4017-9bcb-4c841ffbd3f5" />
</cookie>

PagingCookieには、プライマリエンティティの最初と最後の値が含まれます。
2ページ目を取得する際にこのPagingCookieを使用し取得する場合、以下のようなFetchXmlを書いて取得します。

<fetch mapping=”logical” count=”5″ page="2" paging-cookie=&lt;cookie page=&quot;1&quot;&gt;
    &lt;親エンティティ主キー項目名 last=&quot;b91f4114-fa69-44f4-992e-24b2cc49c726&quot; first=&quot;70668a69-9ab9-4017-9bcb-4c841ffbd3f5&quot; /&gt;
&lt;/cookie&gt; version=”1.0″>
    <entity name="親エンティティ名"> 
        <link-entity name="子エンティティ名" from="親エンティティの主キーフィールド名" to="子エンティティの親を参照しているフィールド名"> 
            <attribute name="子エンティティの主キーフィールド名" /> 
            <attribute name="子エンティティのプライマリフィールド名" /> 
        </link-entity> 
    </entity> 
</fetch> 

2ページ目の取得結果は、次のようになり、Parent 2のレコードが3件取得できていないことになります。

解決方法案

上記の事象ですが、PagingCookieに保存された情報が親レコードの主キーのみを保持しており、結合した行を一意に識別しているわけではないために発生しています。

そのため、解決方法としては、以下の3案考えられます。

①プライマリエンティティのIDが一意になるようにFetchXmlを書く
プライマリエンティティを例の場合、子エンティティになるようにし、子から親を参照する形でデータ取得するとプライマリエンティティのIDが一意となり、本事象は発生しなくなります。

②Paging Cookieをそもそも使用しない
Paging Cookieを使用しない方法でも5,000件以上のレコードは取得可能ですので、そういった方法を使用するのも一つです。
ただし、FetchXmlでPaging Cookieを使用しない場合、50,000件までしか取得できないなどといった制約もあるので注意が必要です。

③FetchXmlを複数のクエリに分割し、取得結果をメモリ内で結合する
親と子を分けて取得するなどし、メモリ内で結合する方法です。
確実な方法ではありますが、パフォーマンス面などに注意して実装する必要があります。

どの方法をとるかは、データの持ち方、データ件数、取得したい結果の形により異なるかと思いますので、実現したい方法に合わせてご検討いただければと思います。

様々な実装の中でこういった落とし穴にはまることも多々あるかと思いますので、解決に困っている際には、ぜひ、お気軽にお問合せいただければと思います。

この記事を書いた人
河内 祐樹

国内大手SIerにて、Microsoft製品を中心としたシステムエンジニア/システムアーキテクトとしてキャリアをスタート。Dynamics CRM 4.0時代から一貫してCRM領域に携わり、営業・サポート・マーケティングなど多様な業務領域におけるCRM導入や立ち上げ、製品開発を手動。特にSFAやコールセンター領域での業務設計・導入支援を得意とする。 その後、CRM事業未経験のSIerに転職し、ゼロからCRM事業立ち上げにも携わる。 エンジニアのみでなく、プリセールスなども担当。複数の企業のCRM案件ではパフォーマンスチューニングやトラブルプロジェクトの再生も多数経験し、実装・運用双方に精通している。 近年は、Dynamics 365やPower Platformを活用し、ノンコーディングによる業務要件実現やASTERIA Warp等による他システム連携・BI統合など、CRMを中心としたデータ活用基盤の全体設計・構築を数多く手がける。導入後のBI支援や運用定着化まで一貫して支援することでクライアントのDX推進を伴走。 現在は、弊社で提唱しているCRM1.0~4.0による企業変革のステージモデルの普及活動を行い、"顧客との信頼を超えた共創関係"を実現するCRM4.0の普及をリードしている。コンサルティング、システム導入、運用支援、教育まで包括的に展開し、企業CRM成熟度向上を支援している。

同じカテゴリの記事