FetchXML クエリビルダー
<FetchXmlBuilder> 誰もFetchXMLを書かずにFetchXMLクエリを編集します。実際に人々がアクセスする言語の部分―テーブル、返される列、行のソート方法、条件やネストされたグループのフィルターツリー――をカバーし、関連するテーブルを結合し、集約し、構築したものを実行します。
今は反応だけを考えて
このコンポーネントはReactスタック上のみに存在しており、Blazorに相当するものはまだ存在しません。FetchXMLクエリを格納する必要があるBlazorポータルでも、それでも保存可能です。ただし、FetchXMLを作成するためのこのエディタはありません。
試してみて
この環境のメタデータに対する実際のコンポーネントです。テーブルを選び、カラムや条件を追加し、関連するテーブルに加入し、FetchXMLパネルが追いつくのを見守り、実行ボタンを押してクエリが何と一致するか確認してください。
FetchXMLBuilder とは違います
このページは コンポーネントについてです。
FetchXMLBuilderは、サーバー側の呼び出し者が手作業でクエリを作成するために、同じXMLをコードで構成するC#クラスです。それらは同じものを生成し、どちらも互いに必要ありません。
メタデータは必須であり、任意ではありません
すべてのテーブル、列、関係は、環境が実際に持っているものから選ばれます。これは意図的です。手書きで入力した論理名がFetchXMLを生成し、完璧に解析しますが、Dataverseでは失敗します。これは誰かに渡すには最悪のエラーです。 usePowerPortalsProFetchXmlMetadata フックはビルダーをフレームワークのキャッシュされたメタデータエンドポイントに配線し、ピッカーは同じページのグリッドがすでに取得したものを共有します。
クエリのラウンドトリップ
ビルダーはFetchXMLをドキュメントモデルに解析し、それを書き戻します。エディターが存在しないもの(新しいプラットフォームの属性や別のツールで書かれた要素など)は、ロード時に削除されることなく引き継がれるため、クエリを開いて保存しても静かに一部が失われることはありません。
保存されたクエリにとって何を意味するのか
フォーマットは保持されません。インデントや属性の引用は正規化されるため、ビルダーを通じて再保存されたクエリは同じテキストではなく同じクエリとなります。
クエリの提供
読む方法は3つあり、すべて同じリーダーを通して行われます:
valueプロップ。制御されたコンポーネント用のonChangeを供給するか、defaultValueを使い、その状態を建築業者に任せるか。- FetchXMLパネルです。 クエリを貼り付けるかタイプすると、入力を止めてから約1秒後にエディタが自動的に再構築されます。
- 保存されたビュー。Filtersヘッダーの ビューから始め 、テーブルのビューを一覧にし、選択したものからクエリ全体を取ってきます。それはコピーであり、ビューには何も書き戻されません。
届いたものはまず確認されます。歪んだXMLは行と列で報告され、編集者が書かれたものとは異なるものを見せるようなものも同様に報告されます。例えば、エディタが知らない演算子やリンクタイプ、テーブル名のないクエリなどです。それらは完全に拒否され、画面上のクエリはそのまま残されます。それ以外はすべて報告され、適用されます:スペルミスされた要素や属性、エイリアスを共有する2つのテーブル、何も宣言されないエイリアスから読み取る条件などです。
関連表
ジョインはリレーションシップピッカーから追加されるため、 from 列と to カラムはメモリではなくリレーションシップから得られます。ジョインが何を貢献できるかは、その型によって異なります。
- 返却タイプ (
inner、outer、matchfirstrowusingcrossapply)は関連するテーブルの列を戻し、それらの列を投影し、ソートし、比較できるようにします。 - フィルタリングタイプ (
exists、in、any、not any、all)は、行を最大一度だけ返し、関連する列は一切返しません。エディタはエイリアスに切り替えるとエイリアスを外し、名前は別のジョインのために空いてあります。 - 関連列がない場合 、リンクタイプではなくプリセットです。FetchXMLにはリンクタイプがないため、エディタはプラットフォームが期待する結合キーに対して外側の結合とnullテストを書き込み、両者を連携させます。
「すべて」について
FetchXMLの
allは名前の通りの意味ではなく、フィルターを満たしない関連する行を持つ行をマッチングし、not allは「anyと同等」として文書化されています。各型は名前ではなく、何をするかでラベル付けされ、フィルターグループに対するInvert Conditionアクションは、通常求められる読み取りを表現します。
集約クエリ
「Columns」セクションで 「Aggregate 」をオンにすると、各列が何を貢献するかを示します。行間で計算された値、またはグループ分けされているものです。提供される機能はカラムの種類に絞られ、エイリアスは必須となり自動的に埋められます。グループ化された日付列は日付部分を得て、ソートもエイリアスに切り替わります。なぜなら、集約クエリの行はグループ化され、計算された値で並べ替えることができないためです。
allowAggregate={false} これは、合計ではなく行を読むホストに対してスイッチを取り消します。つまり、1回に1つのレコードで評価されるルール、保存されたフィルター、計算された値の単一行が答えにならない場所などです。これは無効ではなく存在しているのではなく、クエリの変更が不要なため、戻ってきます。唯一の例外は 、すでに 集約されているクエリです。プロップの設定方法に関わらずコントロールを保持するため、FetchXMLパネルに貼り付けられたコントロールは通常のクエリに戻すことができます。
その一部を取り付ける
すべてのセクションは電源を切ることができ、セクションは別のレイアウトで個別にエクスポートされます。 <FetchXmlBuilderProvider> をマウントして FetchXml*Section コンポーネントを自分で配置してください。セクションを省略するとUIが失われますが、基盤となるFetchXMLは消えません。クエリの列は手つかず columns: falseせずに残ります。
表の制限
allowedTablesテーブルピッカーはリストリストの論理名に絞り込まれます。これは、ポータルが公開する数少ないテーブルを検索するレポートビルダーのような、環境全体をクエリする必要のないサーフェスに対してです。それを省くと、すべてのテーブルが提供されます。選択可能なものを絞り込み、表示できるものを絞り込むのではなく、リスト外のテーブル名をすでに付けているクエリは静かに書き換えるのではなく、関連するテーブルはジョインが言及する場所で表示名で名付けられます。ジョイン自体は制限されません。なぜなら、すでに選ばれたテーブルのプロパティである関係性に従うからです。
クエリの実行
renderResultsを供給すると、ビルダーは実行ボタン付きの結果パネルを作成し、それをいつ押すかを決めます。行を表示するには、ビルダーが意図的に持たないデータクライアントが必要になるため、結果の見た目はあなたのものになります。通常は、フレームワーク自身が返すクエリの上にある<MainGrid>を意味します。プロップを外すとパネルは存在しません。