Share via


フィルターを使用してレポートのパフォーマンスを向上

大量のデータ セットを返すレポートは、使いにくく、パフォーマンス上の問題の原因となる場合があります。 レポートに表示するデータを制限するには、データ フィルターを使用します。

Reporting Services でサポートされているデータ フィルター処理に加え、Microsoft Dynamics 365 Customer Engagement (on-premises) ではデータの事前フィルター処理もサポートしています。 データの事前フィルター処理の使用には、次のような利点があります。

  • レポートの範囲を絞り込んで関連性の高いデータを返すようにすることで、状況に即したレポートを作成できる。

  • 関連性の高いデータだけが返されるので、結果セットの取得と表示が速くなる。

  • 高度な検索機能を使用してレポートをフィルター処理できる。

重要

現在のところ、Under 演算子などの階層演算子を使用したレポート クエリは、レポート フィルターでは使用することができません。 階層演算子を使用するレポートを実行しようとしても、レポートは作成されません。

フェッチベースのレポートでデータの事前フィルター処理を有効にする

フェッチベースのレポートがサポートしているのはデータの自動的事前フィルター処理だけです。 各レポートは複数のデータ セットと複数の FetchXML クエリを持つことができます。 1 つのデータ セットは 1 つの FetchXML クエリをサポートします。 フェッチベースのレポートで主エンティティまたはリンクしているエンティティの事前フィルター処理を有効にするには、enableprefiltering パラメーターの値を "1" に設定し、prefilterparametername プロパティでパラメーター名を指定する必要があります。 このパラメーター名は "CRM_" で始めることにより、非表示のパラメーターとして指定します。 SQL Server ベースのレポートの場合と同様に、FetchXML クエリで指定されるこのパラメーターは FetchXML クエリ内のサブクエリとして機能し、このサブクエリはユーザーがレポートの実行時に 高度な検索 領域で指定した値によって組み立てられます。

次の例は、FetchXML クエリで主エンティティについて事前フィルター処理を有効にする方法を示しています。

<CommandText  
 <fetch distinct="false" mapping="logical">  
   <entity name="account" enableprefiltering="1" prefilterparametername="CRM_FilteredAccount">  
      <attribute name="name" />  
      <attribute name="accountid" />  
   </entity>  
 </fetch>  
</CommandText>  
<DataSourceName>CRM</DataSourceName>  
  1. 同じようにして、リンクしているエンティティについても事前フィルター処理を有効にできます。 FetchXML クエリでリンクしているエンティティについて異なる事前フィルター処理条件を指定することもできます。それには、prefilterparametername プロパティでパラメーター名として別の一意名を指定します。

    レポート ウィザードや SQL Server Data Tools を使用せずに、フェッチベースのレポート定義を手動で変更して、主エンティティまたはリンクしているエンティティについて事前フィルター処理を有効にする場合は、以下のことを確認してください。

    <fetch distinct="false" mapping="logical">  
    <entity name="account" enableprefiltering="1" refilterparametername="CRM_FilteredAccount">  
    
  2. prefilterparametername プロパティで指定したものと同じ名前のクエリ パラメーターを作成します。 パラメーター名を CRM_ で始めることにより、非表示のパラメーターとして指定します。

    <QueryParameters>  
    <QueryParameter Name="CRM_FilteredAccount">  
    <Value>=Parameters!CRM_FilteredAccount.Value</Value>  
    </QueryParameter>  
    
  3. 同じ名前のレポート パラメーターを作成します。

    <ReportParameters>  
    <ReportParameter Name="CRM_FilteredAccount">  
    <DataType>String</DataType>  
    <Prompt>CRM Filtered Account</Prompt>        
    </ReportParameter>  
    </ReportParameters>    
    

SQL ベースのレポートでデータの事前フィルター処理を有効にする (Dynamics 365 On-premises ののみ)

Microsoft Dynamics 365 SQL ベースのレポートでデータの事前フィルター処理を有効にする方法は 2 つあります: 自動および明示的。

自動事前フィルター処理

自動データ事前フィルター処理は、単純なクエリに適しています。 レポートで自動データ事前フィルター処理を有効にするには、クエリでエンティティ テーブルのエイリアスを使用できます。 これを行うには、CRMAF_ で始まるエイリアス名を使用します。

たとえば、次の例は 2 つの単純なクエリを示しており、1 つはアカウント エンティティで事前フィルター処理を有効にするように変更されています。

事前フィルター処理なしでクエリを実行します。

   SELECT <column1>, <column2>, <columnN>
   FROM FilteredAccount; 

CRMAF_ 接頭辞を使用して自動データ事前フィルター処理機能を有効にした場合、Microsoft Dynamics 365 は次の例に示すように Dynamics 365 にアップロードされるときにパラメーター (たとえば、P1) を含むようにクエリを変更します。

自動事前フィルター処理を使用してクエリを実行します。

   SELECT <column1>, <column2>, <columnN>
   FROM FilteredAccount AS CRMAF_FilteredAccount;

Dynamics 365 は、レポートのフィルター処理方法に応じて、クエリを P1 パラメーターに渡します。 つまり、自動データ事前フィルター処理は、既存のクエリ内のサブクエリとして機能します。

次の例は、さまざまなフィルター処理要件に従って、Dynamics 365 がパラメーター (P1) にクエリを渡す方法を示しています。 これらの例では、Dynamics 365 の レポート 領域からレポートを実行していることを推定しており、データのフィルター処理オプションを使用しています。

例 1

アクティブなアカウントのみを表示する場合、結果のクエリは次のようになります。

SELECT <column1>, <column2>, <columnN>
FROM (SELECT FilteredAccount.* FROM FilteredAccount WHERE statecode = 0)
AS CRMAF_FilteredAccount

例 2

特定のアカウント内にいてレポートを実行すると、結果のクエリは次のようになります。

SELECT <column1>, <column2>, <columnN>
FROM (SELECT FilteredAccount.* FROM FilteredAccount WHERE AccountId = '<CurrentAccountId>')
AS CRMAF_FilteredAccount

例 3

選択した 3 つのアカウントのリストがあり、選択したレコードに対してレポートを実行するオプションを選択した場合、結果のクエリは次のようになります。

SELECT <column1>, <column2>, <columnN>
FROM  (SELECT FilteredAccount.* FROM FilteredAccount WHERE AccountId in ('<1stAccountId>', '<2ndAccountId>', '<3rdAccountId>') 
AS CRMAF_FilteredAccount

エンティティ テーブル名にエイリアスが設定されている場合、Dynamics 365 から実行すると、高度な検索ユーザー インターフェイスが展開されたレポートに自動的に含まれます。

クエリ ビルダーでエンティティ テーブル名のエイリアスを作成するには、レポート内の各テーブルを右クリックして、プロパティ、次に例えば、CRMAF_FilteredAccount などをエイリアス値をフォーム CRMAF_FilteredEntity に入力します。

自動事前フィルター処理の制限

CRMAF_ 接頭辞を使用して、自動事前フィルター処理を有効にする場合、Dynamics 365 はクエリにパラメーターを追加します。 UNION ステートメントを使用するクエリなど、より複雑なクエリでは、Dynamics 365 が最初のクエリにのみパラメーターを追加する可能性があるため、予期しない結果が生じる可能性があります。

たとえば、UNION ステートメントを含む次のクエリについて考えてみます。

SELECT <column1>, <column2>, <columnN>
FROM FilteredAccount AS CRMAF_FilteredAccount
WHERE address1_stateorprovince = ‘FL'
UNION
SELECT <column1>, <column2>, <columnN>
FROM FilteredAccount AS CRMAF_FilteredAccount
WHERE address1_stateorprovince = 'CA'

レポートをアップロードすると、Dynamics 365 はパラメーターを使用して最初のクエリのみをフィルター処理する場合があります。 これにより、フィルター処理は 2 番目のクエリに適用されなくなります。

SELECT <column1>, <column2>, <columnN>
FROM  (@P1) AS CRMAF_FilteredAccount WHERE address1_stateorprovince = 'FL'
UNION
SELECT <column1>, <column2>, <columnN>
FROM FilteredAccount AS CRMAF_FilteredAccount
WHERE address1_stateorprovince = 'CA'

前の例では、Dynamics 365 の レポート 領域からレポートを実行している間、1,000,000 より大きい年間収益としてフィルターを選択すると、Dynamics 365 は次のように P1 パラメーターにクエリを渡します。

SELECT <column1>, <column2>, <columnN>
FROM  (SELECT FilteredAccount.* from FilteredAccount where AnnualRevenue > 1000000) AS CRMAF_FilteredAccount
WHERE address1_stateorprovince = 'FL'
UNION
SELECT <column1>, <column2>, <columnN>
FROM FilteredAccount AS CRMAF_FilteredAccount
WHERE address1_stateorprovince = 'CA'

これは、このクエリが年間収益が $1,000,000 を超えるフロリダのアカウントのみと、カリフォルニアのすべてのアカウントが返されることを意味します。これは、あなたが意図したものではありません。 あなたは年間収益が $1,000,000 を超えているフロリダとカリフォルニアのすべてのアカウントを表示したいと考えていました。

Dynamics 365 からレポートをダウンロードして Microsoft Visual Studio で開く場合、Dynamics 365 にアップロードしたレポートの元のバージョンが表示されます。 レポートを Microsoft SQL Server レポート サービスから直接ダウンロードする場合、Dynamics 365 がクエリを変更したが、パラメーターを必要な場所に配置しなかったことがわかります。

このような複雑なクエリの場合は、明示的な事前フィルター処理を使用する必要があります。

明示的な事前フィルター処理

UNION ステートメントを使用したクエリなどの複雑なクエリの場合、明示的な事前フィルター処理を使用する必要がある場合があります。 自動事前フィルター処理とは異なり、Dynamics 365 は、そのようなレポートが Dynamics 365 にアップロードされるときに、明示的な事前フィルター処理中にパラメーターに値を渡すことでレポート クエリを書き換えることはありません。 事前フィルター処理パラメーターをレポートに追加し、クエリでパラメーターを参照することにより、レポートに必要な変更を明示的に行う必要があります。 その後、動的 SQL を使用してクエリを実行できます。

動的 SQL を使用する場合、高度な検索を通じたフィルター処理は、例えば、CRM_FilteredAccount など、CRM_FilteredEntity という名前の非表示パラメーターを作成し、このパラメータを動的 SQL クエリ式で使用することで有効化されます。 このパラメーターは、指定されたフィルター ビューから取得されたテーブルデータのフィルター処理を有効にします。

自動事前フィルター処理の制限をハイライト下前に説明した例と同じものを使用して、次の表は、動的 SQL を使用して明示的な事前フィルター処理を使用するように変更された自動事前フィルター処理を使用したクエリを示しています。 また、Dynamics 365 領域の レポート からのレポートを実行している間、フィルターは年間売上 1,000,000 より大きいとして適用されています。

自動事前フィルター処理を使用してクエリを実行します。

   SELECT <column1>, <column2>, <columnN>
   FROM FilteredAccount AS CRMAF_FilteredAccount
   WHERE address1_stateorprovince = ‘FL'
   UNION
   SELECT <column1>, <column2>, <columnN>
   FROM FilteredAccount AS CRMAF_FilteredAccount
   WHERE address1_stateorprovince = 'CA'

Note

標準の Dynamics 365 SQL ベースのレポートのほとんどは、明示的な事前フィルター処理オプションを使用します。

フィルターの概要でフィルターを渡す

フィルターの概要には、レポートを実行する際に使用するフィルターの値が表示されます。 レポートでは、フィルター テキスト値が含まれるテキスト ボックス レポート項目としてレポート ヘッダーに表示されます。 ユーザーがレポートを実行すると、Report Viewer にフィルターの編集ボタンが表示されます。 このボタンをクリックすると、データ フィルターを定義できます。 フィルターの概要の例は、Customer Engagement (on-premises) に含まれている [ユーザーの概要] レポートで確認できます。

レポートにフィルターの概要を追加するには、次の手順を実行します。

  1. CRM_FilterText という非表示の文字列パラメーターを作成します。

  2. レポートにテキスト ボックス レポート項目を追加し、Value プロパティを次のように設定します。
    =Parameters!CRM_FilterText.Value.

    レポートを実行すると、システムにより、CRM_FilterText パラメーターの値が現在のフィルターのテキストに設定されます。

既定のフィルター

レポートを公開するときに、既定のフィルターを設定できます。 レポート ウィザードで作成されたレポートについては、既定のフィルターを設定しないと、最近 30 日以内に変更されたエンティティの全レコードに自動的に設定されます。 既定のレポート フィルタを定義する手順については、レポートの公開を参照してください。

関連情報

レポートと分析ガイド
Dynamics 365 for Customer Engagement (on-premises) レポートに関する考慮事項