TreeGridViewとQuery Definitionは、どちらを先に作りますか。

Query Definitionが先です。TreeGridViewは、Query Definitionの結果を列に割り当てる部品なので、取ってくるデータが決まっていないと列が定義できません。画面のイメージから入りたくなりますが、先にデータの範囲を確定させるほうが早く終わります。

TreeGridViewの上で、行を直接編集できますか。

基本は表示・参照のための部品だと考えてください。1件ずつの編集は通常のフォームを開く形に、一括編集や複雑な入力は専用画面とMethodに寄せることをお勧めします。TreeGridViewに編集を詰め込むと、あとで作り直しになりやすいところです。

階層が深いと表示が遅くなります。どこから手を付けますか。

TreeGridViewではなくQuery Definitionを見てください。重さを決めているのはそちらです。まず、最初から何階層目までを表示する必要があるかを見直し、次に絞り込み条件を画面側ではなくQuery Definition側に移します。全件取ってから表示だけ減らしている構成が、いちばんよくある原因です。

親は表示されるのに、子だけが出てきません。

多くの場合、データではなく権限です。Query Definitionの結果には、ログインしているユーザーが参照できるItemしか含まれません。管理者アカウントでは正常に見えるため、発見が遅れます。実際の利用者の権限でテストしてください。

本番環境に移したら、TreeGridViewが真っ白になりました。

Query DefinitionとTreeGridViewは別々のItemなので、パッケージに両方入っているかを確認してください。片方だけを移すと参照が切れ、エラーも出ないまま何も表示されない状態になります。移行前にパッケージの中身を確認するのが、いちばん確実です。

Aras InnovatorのTreeGridViewとQuery Definitionを、つまずかずに組み立てる

TreeGridViewは「見せ方」、Query Definitionは「データの取り方」です。この2つを別の部品として意識しないまま作り始めると、必ずどこかで混乱します。そして実際に詰まるところは、ほぼすべてQuery Definition側にあります。

この記事は、当社がAras開発メンバーを育てるときの4回目の内容です。前回のItemTypeとRelationshipの設計が理解できている前提で書いています。

1. 役割の違う2つの部品

まず、どちらが何を決めているのかをはっきりさせます。

部品	決めること
Query Definition	どのItemTypeから始めて、どの関係をたどり、どのPropertyを取ってくるか。絞り込みと並び順も、ここ。
TreeGridView	その結果を、どの列に、どの幅で、どの順番で見せるか。

よくある誤解を、先に潰しておきます。

「TreeGridViewの設定で、表示するデータを増やせる」 — 増やせません。取ってきていないものは出せないので、Query Definitionに戻ることになります。
「TreeGridViewは表示だけだから軽い」 — 重さを決めているのはQuery Definitionです。画面が遅いときに見る場所は、ほぼ常にそちらです。
「1つのQuery Definitionは、1つのTreeGridView専用」 — 違います。同じQuery Definitionを複数のビューから使えますし、REST／OData経由で外部システムからも呼べます。ここが、あとで効いてきます。

2. Query Definitionを組み立てる順番

Query Builderの画面を開く前に、次の4つを紙の上で決めてください。この順番を飛ばすと、作り直しになります。

① 起点のItemTypeを決める

木のいちばん上に来るものです。「製品の一覧を出したい」のか「部品の一覧を出したい」のかで、起点が変わります。同じデータでも、起点が変われば別のQuery Definitionになります。

② たどる方向を決める

たどり方は3つあります。Relationshipをたどる、Reverse Relationshipで逆からたどる、item型のPropertyの先を見る。表示したいだけならRelationshipを増やさずforeign Propertyで足りることがある、というのは前回書いたとおりです。ここでも同じです。

③ 各ノードにaliasを付ける

ここがいちばん大事です。TreeGridViewの列は、このaliasに紐づきます。あとから気軽に変えないでください。変えた瞬間、列が全部空になります。最初に命名規則を決めて、チームで揃えておくことをお勧めします。

④ 絞り込みは「取ってきたあと」ではなく「取る前」に

Query Definition側の条件で絞れるものを、画面側で絞らないでください。全件取ってから表示だけ減らす形になっていると、データが増えた瞬間に止まります。期間、状態、担当部署。絞れる条件は、できるだけ手前に置きます。

3. Reverse Relationship — どちらから見るか

Relationshipは、source（親）とrelated（子）の向きを持っています。通常はsourceからrelatedへたどります。Reverse Relationshipは、その逆です。

やりたいこと	向き
この製品は、どの部品でできているか	通常（source → related）
この部品は、どの製品で使われているか	Reverse（related → source）

どちらの向きが必要かは、画面の見た目ではなくユーザーが実際に口にする問いで決まります。「この部品、今どこで使ってる？」という問いが業務の中に出てくるなら、Reverseが要ります。出てこないなら要りません。要件定義の場で、この質問を1つしておくだけで、あとの手戻りがかなり減ります。

4. 実務で必ず当たる4つ

当社が実際に踏んだもの、引き継いだ案件で見たものです。

権限のせいで、子だけが消える。 Query Definitionの結果には、ログインしているユーザーが見られるItemしか出てきません。親は見えるのに子が出ない、という状態になり、「木が壊れている」という報告が上がってきます。壊れていません。Permissionです。テストは必ず、管理者ではなく実際の利用者の権限で行ってください。
階層を深くしすぎて、重い。 Query Definitionは階層をいくらでも定義できてしまいます。3階層目から先は、本当に最初から表示が必要かを疑ってください。必要なければ、展開したときに取りに行く形にします。
aliasを変えたら、列が全部空になった。 原因としてはいちばん単純で、いちばん時間を溶かします。TreeGridView側の列定義が、古いaliasを指したまま残ります。
本番に移したら、TreeGridViewが真っ白。 Query DefinitionとTreeGridViewは別々のItemです。パッケージに片方しか入れないと、移行先で参照が切れます。画面が真っ白、エラーも出ない、という形で出るので原因にたどり着きにくい。移行前に、パッケージの中身を必ず両方の目で確認してください。

5. どこまでTreeGridViewでやるべきか

最後に、線引きの話です。

やりたいこと	向いているもの
見る・たどる・絞り込む	TreeGridView
1件ずつ開いて編集する	TreeGridViewから通常のフォームへ
一括編集、複雑な入力、独自の操作	専用画面とMethod

判断の基準は単純です。ユーザーがその画面で何かを書き換えるかどうか。書き換えるなら、TreeGridViewは入口にとどめてください。無理をさせると、あとで全部作り直しになります。

次回は、TOCとViewを扱います。作った画面を、誰にどこから開かせるかの話です。